Những Lỗi Phổ Biến Khi Dùng AI Viết Code Production

Giới Thiệu

Đoạn code AI sinh ra thường có một đặc điểm nguy hiểm: nhìn rất hoàn chỉnh. Có namespace, có class, có method, thậm chí có test. Điều đó khiến nhiều developer bỏ qua bước đánh giá kỹ hơn về độ đúng, hiệu năng và khả năng vận hành.

Với code production, chạy được mới chỉ là điều kiện tối thiểu.

Mục lục

Vì sao code AI trông rất thuyết phục
Authorization, validation và bối cảnh domain
Query cost, failure path và idempotency
Demo code so với production-oriented code
Workflow dùng AI thực dụng hơn
Checklist trước khi merge code do AI hỗ trợ viết

1. Tin Vào Code Mẫu Quá Sớm

AI thường trả về code theo pattern phổ biến nhất, không phải pattern phù hợp nhất với hệ thống của bạn. Ví dụ, nó có thể đưa business logic vào observer hoặc controller chỉ vì đó là cách phổ biến trên internet.

Giải pháp:

Xác định abstraction boundary trước
Chỉ yêu cầu AI viết phần nằm trong boundary đó

Vì Sao Code AI Trông Rất Thuyết Phục

Đây là điểm nguy hiểm nhất. AI thường tạo ra code có mọi dấu hiệu hình thức của "code tốt":

class và method được đặt tên khá sạch
indentation chuẩn
có type hints
có test mẫu
có comment giải thích

Nhưng chất lượng production không nằm ở vẻ ngoài. Nó nằm ở behavior dưới tải, khả năng rollback, safety khi lỗi xảy ra, và mức độ dễ hiểu khi người khác phải maintain 6 tháng sau.

2. Bỏ Qua Authorization Và Validation

Rất nhiều đoạn code AI sinh ra tập trung vào happy path. Nó có thể validate dữ liệu cơ bản nhưng bỏ qua quyền truy cập hoặc state transition phức tạp.

public function update(UpdatePostRequest $request, Post $post): JsonResponse
{
    $this->authorize('update', $post);

    $post->update($request->validated());

    return response()->json($post->refresh());
}

Đây là ví dụ ngắn nhưng nhắc đúng điều cần có: authorization và validated input.

3. Không Hiểu Bối Cảnh Domain

AI không biết post ở hệ thống của bạn có được publish lại hay không, order có được refund một phần hay không, hay user có được tự sửa role của mình hay không. Những rule kiểu này thường không hiện rõ trong đoạn code ngắn bạn paste vào prompt.

Vì vậy, kể cả khi code "đúng cú pháp Laravel", nó vẫn có thể sai nghiệp vụ ở những chỗ rất quan trọng.

4. Query Chạy Được Nhưng Không Rẻ

Một đoạn Eloquent code có thể đúng về mặt chức năng nhưng gây chậm ở production do:

N+1 query
select * không cần thiết
thiếu index phù hợp
eager loading sai chỗ

AI thường nhìn code chứ không thấy dữ liệu thật, cardinality thật hoặc query plan thật.

5. Bỏ Qua Failure Path Và Idempotency

Production code không chỉ cần đường thành công. Nó cần hành xử đúng khi:

request bị gửi lại
queue retry
provider timeout
cache trả dữ liệu cũ
external API trả response không mong muốn

Đây là phần AI thường không chủ động bao phủ nếu bạn không ép nó nghĩ tới.

6. Test Quá Mỏng

AI dễ generate test happy path, nhưng production thường hỏng ở đường fail.

Hãy luôn hỏi thêm:

điều gì xảy ra khi job chạy lại?
nếu provider timeout thì sao?
request lặp lại có tạo duplicate không?
nếu cache stale thì user thấy gì?

7. Thiếu Góc Nhìn Vận Hành

Code dùng queue, cache, webhook hoặc AI provider mà không có timeout, retry và logging là dấu hiệu của code demo, không phải code production.

Một Ví Dụ So Sánh: Demo Code Và Production-Oriented Code

Demo version:

public function __invoke(Request $request): JsonResponse
{
    $summary = OpenAI::responses()->create([
        'model' => 'gpt-4.1-mini',
        'input' => 'Summarize: ' . $request->string('content'),
    ])->outputText;

    return response()->json(['summary' => $summary]);
}

Production-oriented version sẽ nghĩ thêm tới:

request validation
timeout và exception handling
cache key theo prompt version
logging token usage
fake service trong test
response normalization

Đoạn code có thể dài hơn một chút, nhưng độ tin cậy cao hơn hẳn.

Một Workflow Dùng AI Thực Dụng Hơn

Thay vì prompt kiểu viết giúp tôi feature X, hãy tách thành:

đề xuất thiết kế và ranh giới lớp
viết request validation
viết action class
liệt kê failure modes
viết tests cho các failure modes đó

AI thường tệ khi phải làm tất cả trong một lần, nhưng khá hữu ích khi bạn ép nó đi theo từng bước nhỏ.

Những Điều Nên Bắt AI Trả Lời Trước Khi Nhận Code

chỗ nào có side effect?
có cần queue không?
logic này có idempotent không?
cần test fail path nào?
query nào có nguy cơ N+1?
cần cache invalidation ở đâu?

Nếu AI chưa trả lời được những câu này, bạn chưa nên xin code implementation.

Checklist Trước Khi Merge Code Do AI Hỗ Trợ Viết

Có authorization phù hợp chưa?
Input đã được validate đủ chưa?
Failure path đã có test chưa?
Side effect đã được tách khỏi request cycle khi cần chưa?
Có logging/monitoring tối thiểu chưa?
Reviewer khác có đọc hiểu được flow này nhanh không?

FAQ

Có nên cấm dùng AI cho code production không?

Không cần. Vấn đề không nằm ở việc có dùng AI hay không, mà là quy trình review và mức độ bạn ép AI suy nghĩ về failure modes và trade-off.

Có phải code do AI viết luôn tệ hơn code người viết tay?

Không hẳn. Với tác vụ lặp lại hoặc scaffold chuẩn, AI có thể rất hiệu quả. Nhưng càng gần core business logic và production risk, con người càng phải giữ quyền quyết định chặt hơn.

Key takeaways:

Code AI sinh ra thường thuyết phục về hình thức nhưng chưa chắc an toàn cho production.
Các lỗi nặng nhất thường nằm ở domain rule, authorization, query cost và failure path.
Hãy ép AI trả lời về side effects, idempotency và cache invalidation trước khi xin implementation.
Demo code và production-oriented code khác nhau ở timeout, logging, retry và test strategy.
Reviewer vẫn phải giữ quyền quyết định cuối cùng ở các phần có production risk cao.

Kết Luận

AI giúp rút ngắn thời gian từ ý tưởng đến bản nháp đầu tiên. Nhưng production code luôn cần thêm ba lớp kiểm tra: correctness, operability và maintainability. Nếu bỏ qua ba lớp này, tốc độ ban đầu chỉ đổi lấy chi phí sửa lỗi về sau.