Phát Triển Dựa Trên AI Không Giống Với Việc Dùng AI Viết Code

Tóm tắt: Phát triển dựa trên AI là một quyết định về quy trình: mỗi công đoạn phải nói trước chỗ nào AI ra bản nháp và người nào có tên cụ thể sẽ phê duyệt. Dùng AI viết code là quyết định về công cụ, do từng kỹ sư tự chọn. Hai thứ này được bán chung một cái tên, nhưng chỉ thứ đầu tiên làm dịch chuyển được ngày giao hàng, vì chỉ nó chạm tới cách công việc được kiểm chứng.

Mục lục

• Vì sao câu "bên tôi có dùng AI" không nói lên điều gì về ngày giao hàng
• Phát triển dựa trên AI là gì?
• Khung 5 chốt phê duyệt
• Sáu bước để đưa vào áp dụng
• Năm sai lầm khiến việc áp dụng AI trông giống như tiến bộ
• Khi nào KHÔNG nên áp dụng
• Câu hỏi thường gặp

Vì sao câu "bên tôi có dùng AI" không nói lên điều gì về ngày giao hàng

Hỏi năm nhà cung cấp phần mềm xem phát triển dựa trên AI nghĩa là gì. Bạn sẽ nhận về hai câu trả lời chẳng liên quan đến nhau nhưng đeo chung một cái nhãn. Một nhóm mô tả công cụ mà kỹ sư của họ dùng. Nhóm kia mô tả cách quy trình của họ được tổ chức. Khoảng cách giữa hai câu trả lời chỉ lộ ra sau khi ký hợp đồng, lúc bảng tiến độ đề xuất hoá ra vẫn giống hệt bảng tiến độ hồi chưa có AI.

Giờ đã có bằng chứng đo được cho việc vì sao câu trả lời về công cụ là chưa đủ.

METR chạy một thử nghiệm ngẫu nhiên có đối chứng với 16 kỹ sư mã nguồn mở giàu kinh nghiệm, trên 246 tác vụ thật trong chính những repo họ đã làm nhiều năm. Trước khi bắt đầu, họ dự đoán AI sẽ giúp mình nhanh hơn 24%. Làm xong, họ ước lượng AI đã giúp nhanh hơn 20%. Đo thực tế, họ chậm hơn 19% khi có AI so với khi không (METR, 07/2025). METR nói rõ đây là một bối cảnh cụ thể, kỹ sư kỳ cựu làm trên codebase họ đã quá quen, và không chứng minh rằng AI không giúp được lập trình viên nói chung.

Cứ nhận lấy phần lưu ý đó một cách nghiêm túc, vẫn còn một kết luận đứng vững: chiều của khoảng lệch nhận thức. Cảm giác "đội mình đang nhanh hơn" không phải là một phép đo, và trong thử nghiệm này nó lệch sai hướng khoảng 39 điểm phần trăm.

Bức tranh ở quy mô toàn ngành cho thấy đúng sự căng thẳng đó từ phía bên kia. Báo cáo DORA 2025 ghi nhận 90% người làm công nghệ hiện đã dùng AI trong công việc, và mức độ áp dụng AI cao hơn đi kèm với sự gia tăng đồng thời của cả năng suất giao hàng lẫn mức bất ổn khi giao hàng. Thời gian quay vòng review code được chỉ đích danh là nút thắt, vì người review chịu tải nhận thức nặng hơn hẳn khi phải soát những thay đổi do AI sinh ra (DORA, 2025).

Đọc hai kết quả cạnh nhau sẽ thấy một điều mà bảng đánh giá nhà cung cấp hiếm khi nắm được. Năng lực sinh ra và năng lực kiểm chứng là hai thứ tách rời. Mua thứ nhất mà không nhấc thứ hai lên thì lịch không ngắn lại; chi phí chỉ chuyển sang khâu tích hợp, và tới đó nó mang tên "làm lại".

Bài này chỉ ra AI nên nằm ở công đoạn nào, ai vẫn là người ký duyệt, và công đoạn nào AI hoàn toàn không giúp được. Đây cũng là mô hình chúng tôi áp dụng trong dịch vụ phát triển hệ thống cho doanh nghiệp Nhật.

Phát triển dựa trên AI là gì?

Phát triển dựa trên AI là cách thiết kế quy trình, trong đó mọi công đoạn đều tuyên bố trước chỗ nào AI ra bản nháp và người có tên cụ thể nào phê duyệt kết quả. Dùng AI viết code là lựa chọn công cụ, do từng kỹ sư tự quyết, về cách họ viết code.

Khác biệt ở đây không phải là khác về mức độ. Hai thứ thay đổi những đối tượng khác nhau, do những người khác nhau quyết, và hỏng vì những lý do khác nhau.

Một đội hoàn toàn có thể mua đủ mọi trợ lý code trên thị trường mà không đổi một chút nào trong quy trình. Nhiều đội đúng là như vậy. Đó là lựa chọn chính đáng; chỉ là nó không phải thứ làm dịch chuyển một cái deadline, nên cũng đừng báo giá như thể nó là.

Khung 5 chốt phê duyệt

Đây là bảng chúng tôi điền trước khi dự án bắt đầu. Mỗi dòng nêu rõ AI nháp cái gì, ai phán quyết, và còn lại bằng chứng gì. Dòng nào để trống cột thứ ba thì đó không phải quy trình, đó là ý định.

Có một quy định chạy xuyên suốt cả năm dòng: dữ liệu nào được gửi tới dịch vụ AI nào là một quyết định thành văn về dữ liệu khách hàng, không phải phán đoán riêng của từng kỹ sư ngồi tại chỗ.

Sáu bước để đưa vào áp dụng

Bước 1. Đo nút thắt hiện tại trước khi mua bất cứ thứ gì. Nếu công việc vốn đã xếp hàng ở khâu review thì sinh code nhanh hơn chỉ làm hàng đợi dài thêm. DORA chỉ đích danh thời gian quay vòng review là nút thắt phổ biến, nên hãy kiểm tra xem nó có phải nút thắt của bạn không.

Bước 2. Ghi ra đường phê duyệt, theo từng công đoạn. Mỗi công đoạn một câu: AI nháp X, người giữ vai trò Y phê duyệt. Đội nào bỏ qua bước này thì đến lúc có sự cố mới phát hiện chưa ai từng thống nhất điều đó.

Bước 3. Chốt quy định về dữ liệu. Loại dữ liệu khách hàng nào được chạm tới dịch vụ nào, ai duyệt, và bản ghi nằm ở đâu. Làm trước khi có kỹ sư đầu tiên cần đến, không phải sau đó.

Bước 4. Bắt đầu từ những công đoạn kiểm được. Sinh test, khảo sát codebase lạ, chuẩn bị chuyển đổi hệ thống, giữ tài liệu luôn khớp. Đây là những việc có đích rõ ràng và kết quả kiểm được bằng máy, nên một bản nháp sai bị bắt với giá rẻ.

Bước 5. Nâng năng lực kiểm chứng trước năng lực sinh. Thêm người review, pull request nhỏ lại, test chạy trên mọi commit. Đây là bước không hào nhoáng gì nhưng quyết định bốn bước trên cho ra một cái lịch ngắn hơn hay một hoá đơn tích hợp lớn hơn.

Bước 6. Đo bằng kết quả giao hàng, không đo bằng tự đánh giá. Cycle time, tỷ lệ thay đổi gây lỗi, khối lượng làm lại. Thử nghiệm của METR chính là lý do: cảm giác nhanh và tốc độ đo được của một đội có thể chỉ về hai hướng ngược nhau.

Điều chúng tôi rút ra từ dự án thật

Chúng tôi xây một dịch vụ OCR đa ngôn ngữ chạy thuần CPU, đọc mã định danh từ ảnh chụp nhãn sản phẩm. Engine chính làm rụng sạch dấu tiếng Việt: Sản phẩm Việt Nam trả về thành Sn phm Vit Nam, không phải giảm chất lượng, mà mất hẳn.

Bốn quyết định đã gỡ được nút đó, và không quyết định nào trong số đó là quyết định viết code.

Chúng tôi không fine-tune engine chính. Mọi ngôn ngữ dùng chung một bộ trọng số nhận dạng, nên huấn luyện lại cho tiếng Việt sẽ đặt độ chính xác đã kiểm chứng của tiếng Anh và tiếng Nhật vào rủi ro. Thay vào đó chúng tôi thêm một engine riêng cho tiếng Việt, không đụng vào phần đang chạy tốt.

Chúng tôi để engine thứ hai mặc định tắt. Nó nặng gấp khoảng năm lần engine chính, nên chỉ nạp khi thực sự có yêu cầu tiếng Việt.

Chúng tôi từ chối xác nhận nó cho đầu vào ảnh chụp. Độ chính xác của nó mới đo trên chữ render, chưa đo trên ảnh chụp từ camera. Chừng nào chưa kiểm chứng trên ảnh chụp thì với ảnh chụp nó vẫn tắt, và chúng tôi nói thẳng điều đó thay vì trích con số đẹp hơn.

Chúng tôi chọn trích xuất mã định danh bằng luật thay vì bằng model huấn luyện, để mỗi giá trị trích ra đều truy ngược được về đúng luật đã sinh ra nó khi cần điều tra một trường hợp nhận nhầm.

AI hỗ trợ xuyên suốt phần việc đó. Nó không đưa ra bất kỳ quyết định nào trong bốn quyết định trên, và tốc độ sinh code nhanh đến mấy cũng không thay thế được. Toàn bộ phương pháp đo nằm trong case study OCR.

Năm sai lầm khiến việc áp dụng AI trông giống như tiến bộ

1. Mua năng lực sinh trong khi năng lực review giữ nguyên. Hậu quả: năng suất và mức bất ổn cùng tăng, đúng khuôn mẫu DORA đã đo được. Cách tránh: coi thời gian của người review là dòng ngân sách phải nhúc nhích đầu tiên.

2. Không bao giờ ghi lại ai là người duyệt output của AI. Hậu quả: trách nhiệm rõ ràng cho tới sự cố đầu tiên, sau đó thì không. Cách tránh: mỗi công đoạn một câu, lưu ở chỗ đội thật sự có mở ra xem.

3. Đưa AI vào khi yêu cầu chưa chốt. Hậu quả: đội làm sai nhanh hơn, và phần làm lại xuất hiện sớm hơn, lớn hơn. Cách tránh: giữ AI ở khâu khảo sát và soạn nháp cho tới khi đặc tả ngừng dịch chuyển.

4. Để quy định về dữ liệu cho từng kỹ sư tự quyết. Hậu quả: dữ liệu khách hàng chạm tới những dịch vụ chưa ai phê duyệt, và điều đó bị phát hiện trong một đợt rà soát bảo mật chứ không phải trước đó. Cách tránh: một danh sách thành văn, quyết một lần.

5. Đo mức độ áp dụng bằng cảm giác nhanh của đội. Hậu quả: con số được báo cáo lên trên lại đúng là con số mà thử nghiệm METR cho thấy có thể đảo chiều. Cách tránh: báo cáo cycle time và tỷ lệ thay đổi gây lỗi.

Khi nào KHÔNG nên áp dụng

Đặc tả vẫn còn dịch chuyển ở đúng công đoạn bạn định thay đổi. Việc khảo sát thì lúc nào bắt đầu cũng được. Còn mọi thứ nằm sau một yêu cầu chưa chốt thì nên chờ, vì tốc độ nhắm vào sai đích chỉ tạo ra việc làm lại, không tạo ra hàng giao.

Không rút được ai ra để review. Nếu khâu review vốn đã bão hoà, chương trình này chỉ dồn thêm áp lực vào đúng chỗ đang hỏng. Sửa nút thắt trước đã.

Dữ liệu không được rời khỏi môi trường của bạn và chưa có phương án self-hosted nào được duyệt. Với tổ chức chịu ràng buộc của APPI hay GDPR, quy định đứng trước công cụ. Model chạy tại chỗ có thể là lời giải; đó là câu hỏi kiến trúc, và chúng tôi đã viết lại một trường hợp như vậy trong bài về OCR thuần CPU.

Một kỹ sư, một bản prototype ngắn. Chi phí vận hành quy trình lớn hơn phần lợi ích. Cứ dùng trợ lý code và bỏ qua cái khung này.

Câu hỏi thường gặp

Phát triển dựa trên AI có phải chỉ là trợ lý code được gọi bằng cái tên kêu hơn không? Không. Trợ lý code thay đổi tốc độ một cá nhân viết code. Phát triển dựa trên AI thay đổi công đoạn nào sinh bản nháp tự động và chỗ nào bắt buộc có phê duyệt của con người. Dùng trợ lý mà không đổi quy trình là chuyện phổ biến, và nó thay đổi rất ít.

Nó có rút ngắn lịch giao hàng của chúng tôi không? Chỉ khi năng lực kiểm chứng đi lên cùng nhịp. DORA thấy mức áp dụng AI cao làm tăng cả năng suất lẫn mức bất ổn, với nút thắt nằm ở thời gian quay vòng review. Hãy đổi trước những công đoạn kiểm được: test, tài liệu, khảo sát codebase.

Kỹ sư bên tôi nói AI đã giúp họ nhanh hơn hẳn. Vậy chưa đủ làm bằng chứng sao? Đó là tín hiệu, không phải phép đo. Trong thử nghiệm của METR, lập trình viên ước lượng mình nhanh hơn 20% trong khi đo ra chậm hơn 19%. Hãy hỏi cycle time và tỷ lệ thay đổi gây lỗi trước và sau, thay vì hỏi cảm nhận.

Có cần chốt xong yêu cầu rồi mới đưa AI vào không? Với những công đoạn phụ thuộc vào yêu cầu thì đúng vậy. Những công đoạn không phụ thuộc, chẳng hạn khảo sát hệ thống hiện có, thì bắt đầu lúc nào cũng được.

Khi code do AI sinh gây lỗi thì ai chịu trách nhiệm? Vẫn đúng những người như trước. Coi output của AI là bản nháp và có một người cụ thể phê duyệt thì đường trách nhiệm không đổi. Nếu không ai chỉ ra được ai đã duyệt một thay đổi, thì AI chỉ làm lộ ra lỗ hổng đó chứ không tạo ra nó.

Làm sao biết một nhà cung cấp có quy trình hay chỉ có công cụ? Ba câu hỏi. Ai duyệt output của AI và theo tiêu chí nào. Công đoạn nào cố ý không dùng AI. Dữ liệu khách hàng nào được chạm tới dịch vụ nào, và ai đã quyết. Bên có quy trình trả lời bằng vai trò và chốt kiểm; bên chỉ có công cụ trả lời rằng kỹ sư của họ có kiểm tra lại.

Kết luận

• Năng lực sinh và năng lực kiểm chứng là hai dòng ngân sách tách rời. Chỉ nhấc dòng thứ nhất là dời chi phí sang khâu tích hợp.
• Đường phê duyệt, ghi theo từng công đoạn trước khi bắt tay vào việc, chính là thứ phân biệt một quy trình với một bộ công cụ.
• Tốc độ tự đánh giá không phải phép đo. Hãy báo cáo cycle time, tỷ lệ thay đổi gây lỗi và khối lượng làm lại.

Nếu bạn đang cân nhắc công đoạn nào trong quy trình phát triển nên đưa AI vào và công đoạn nào thì không, đặt lịch tư vấn miễn phí. Chúng tôi rà năm chốt phê duyệt ở trên với chính quy trình hiện tại của bạn và trả lại kết quả.