AI có thể viết phần mềm đạt chuẩn triển khai?

Ý tưởng để AI viết mã đạt chuẩn triển khai (production-grade code) có thể gây cả sự tò mò lẫn hoài nghi. Một số người thấy được tiềm năng năng suất gần như tức thì – chỉ cần nhấn nút là có mã – trong khi những người khác lo sợ sẽ có một loạt các script khó đọc và không thể bảo trì tràn vào các codebase. Là những kỹ sư từng dành vô số giờ tinh chỉnh tiêu chuẩn của "mã tốt", chúng tôi tiếp cận cuộc tranh luận này với cả sự tò mò và thận trọng.

Chúng tôi đặt ra một giả thuyết đơn giản: Liệu AI có thể xây dựng một ứng dụng không tầm thường từ con số 0 – mà không có dòng mã nào do con người viết – và vẫn tạo ra thứ mà con người có thể bảo trì? Chúng tôi đã tiến hành ba thí nghiệm để khám phá câu hỏi này. Trong mỗi trường hợp, chúng tôi tương tác với AI để định hướng việc xây dựng, nhưng kỳ vọng đặt ra rất khác nhau. Trong một thí nghiệm, chúng tôi sử dụng phong cách tự do, ứng biến – mà các nhà nghiên cứu AI như Andrej Karpathy gọi là vibe coding – tập trung hoàn toàn vào chức năng và hầu như không đưa ra chỉ dẫn về cách tổ chức hệ thống. Trong các thí nghiệm còn lại, chúng tôi đưa ra hướng dẫn cụ thể – áp dụng các nguyên lý thiết kế, yêu cầu về tính module, khả năng kiểm thử (testability) và củng cố chất lượng qua phản hồi liên tục.

Để có cơ sở thực tế, chúng tôi chọn xây dựng một ứng dụng có tên System Update Planner – một công cụ quản lý cập nhật phần mềm và triển khai bản vá trên một loạt thiết bị. Ứng dụng cho phép người dùng xác định gói cần cập nhật, lên kế hoạch triển khai theo từng đợt và theo dõi tiến độ trên từng thiết bị. Miền ứng dụng bao gồm quản lý phiên bản phần mềm, trạng thái thiết bị, trình tự theo lô và giám sát thời gian thực. Nói cách khác, nó không phải là bài tập "Hello World" đơn giản cũng không phải là hệ thống doanh nghiệp khổng lồ – vừa đủ để kiểm nghiệm thực tế chất lượng mã do AI tạo ra.

Cách tiếp cận khác nhau giúp chúng tôi xem xét vai trò của ý định con người và kỷ luật kỹ thuật trong việc định hình hệ thống do AI viết. Phần tiếp theo sẽ đi qua từng thí nghiệm, các quyết định được đưa ra và những gì chúng tiết lộ về tiềm năng – và giới hạn – của việc dùng AI để xây dựng phần mềm đạt chuẩn triển khai.

“Production-grade software” nghĩa là gì?

Trước khi đi vào các thí nghiệm, cần lưu ý rằng "production-grade" không phải là một thuật ngữ có định nghĩa thống nhất. Nếu có, nhiều codebase trong thực tế có thể không đạt được.

Trên thực tế, thuật ngữ này phản ánh sự kết hợp giữa phán đoán kỹ thuật, ngữ cảnh tổ chức và kinh nghiệm sống. Trong khuôn khổ bài viết này, chúng tôi dùng "production-grade" để chỉ phần mềm bền vững, dễ bảo trì và có thể triển khai cũng như phát triển có trách nhiệm trong môi trường thực.

Chúng tôi sử dụng hỗn hợp các tiêu chí định tính và định lượng mà lập trình viên giàu kinh nghiệm thường liên kết với mã đạt chuẩn sản xuất. Đây không phải là luật cứng, mà là hướng dẫn đánh giá: phần mềm có đáng tin, dễ tiến hóa và vận hành ổn định không?

Các tiêu chí chính của phần mềm đạt chuẩn sản xuất

Đặc điểm	Mô tả	Các dấu hiệu định tính	Các chỉ số định lượng
Correct (Chính xác)	Hoạt động như dự kiến, được xác nhận bằng test tự động nhanh	Xử lý edge case; không có lỗi hồi quy (regression bug)	Tỷ lệ pass test gần 100%; mutation score > 80%
Testable (Có thể kiểm thử)	Hỗ trợ kiểm thử unit, integration, end-to-end	Test nhanh, tập trung, đặt tên rõ ràng	Unit test coverage > 90%; không flake test
Maintainable (Bảo trì được)	Mã dễ đọc, có cấu trúc module, dễ hiểu với người khác	Cấu trúc chuẩn, dễ onboard người mới	Độ phức tạp nhận thức thấp, thay đổi ổn định
Scalable (Có thể mở rộng)	Có tính đến hiệu năng, bảo mật, vận hành	Thiết kế dự đoán được sự tăng trưởng, không quá chặt chẽ	Benchmark hiệu năng; có fallback hợp lý
Diagnosable (Chẩn đoán được)	Có logging và cấu trúc hỗ trợ debug hiệu quả	Log có ngữ cảnh, truy vết lỗi dễ dàng	Log có cấu trúc; có "alert" cho lỗi quan trọng
Disciplined (Có kỷ luật)	Tuân thủ thực hành kỹ thuật: Git, CI, phân tích tĩnh…	Commit thường xuyên, CI tuân thủ	Commit qua CI, chạy lint sạch, không có lỗi SAST nghiêm trọng

Công cụ và thiết lập

Trong cả ba thí nghiệm, chúng tôi chủ yếu dùng Cursor IDE ở chế độ agent – cho phép AI thực hiện nhiều tác vụ vượt xa chỉnh sửa mã, như chạy lệnh dòng lệnh, tương tác với Git, dùng công cụ qua MCP servers.

Chúng tôi cũng thử dùng Junie và Windsurf (plugin của IntelliJ IDEA) vì tương tự Cursor về workflow. Tuy nhiên, để đồng nhất, phần lớn công việc dùng Cursor.

Chúng tôi bắt đầu với mô hình AI mặc định của Cursor, sau chuyển sang Claude 3.7 Sonnet vì khả năng lý luận tốt hơn. Sau đó, gần như dùng Google Gemini 2.5 Pro hoàn toàn vì hiểu rõ yêu cầu chức năng và tranh luận kiến trúc hiệu quả.

Chúng tôi tích hợp thêm các MCP server như: Sequential Thinking, Git, GitHub, Memory… để duy trì mạch suy luận, chạy Git, giữ ngữ cảnh liên tục.

Tuy nhiên, dù dùng Memory server, AI vẫn "quên" codebase nếu mở session mới, điều này mô phỏng bối cảnh brownfield tốt.

Tất cả các thí nghiệm đều bắt đầu bằng cách cung cấp cho AI bản mô tả chức năng đầy đủ của System Update Planner trước khi vào chi tiết kiến trúc.

• Thí nghiệm 1: Giao AI bản mô tả chức năng và để nó tự xây dựng ứng dụng. Kết quả chủ yếu viết bằng JavaScript.
• Thí nghiệm 2: Ngoài yêu cầu chức năng, áp đặt quy tắc triển khai: theo TDD, module rõ ràng… AI chọn TypeScript và Prisma làm ORM.
• Thí nghiệm 3: Tắt hết MCP server, chỉ dùng Google Gemini 2.5 Pro, hợp tác theo phong cách hội thoại như đồng nghiệp. Kết quả viết bằng Python.

Thí nghiệm 1: AI nắm quyền điều khiển (Letting the AI take the wheel)

Chúng tôi để AI "cầm lái", chỉ đưa ra yêu cầu chức năng. Kết quả rất ấn tượng: ứng dụng gần như hoàn chỉnh chỉ trong một lượt tạo mã.

Tuy nhiên, khi cần sửa – ví dụ định dạng UI, thêm menu, tích hợp Knex.js, viết test – thì gặp khó. AI xử lý sửa đổi kém, dễ sinh lỗi, phải can thiệp thủ công.

Như Birgitta Böckeler (trong Exploring Generative AI) nói: AI tạo mã nhanh nhưng yếu trong hệ thống phức tạp. Mã cần module rõ thì AI mới hợp tác tốt.

LeadDev cũng nhấn mạnh: mã AI có thể làm tăng technical debt nếu thiếu kiểm soát. Con người vẫn cần để đảm bảo chất lượng và bảo trì.

Dù còn hạn chế, AI giúp giảm rào cản nhập môn, cho phép non-dev tạo prototype, dev tăng tốc proof-of-concept (POC). Nhưng để có chất lượng tốt hơn, ta chuyển sang thí nghiệm 2.

Thí nghiệm 2: Định hình AI một cách có kỷ luật (Shaping the AI with discipline)

Lần này, chúng tôi đưa ra hướng dẫn kỹ lưỡng: theo TDD, commit thường xuyên, viết module nhỏ, yêu cầu type safety. AI chọn TypeScript và Prisma – lựa chọn hợp lý.

Kết quả ban đầu tốt: AI tạo domain model, test scaffold, theo trunk-based workflow. Có ngưỡng coverage, kiểm thử mutation bằng Stryker, có phần đạt gần 100% mutation coverage.

Tuy nhiên, AI đôi lúc vẫn quay về thói quen cũ: viết mã trước rồi test sau. Điều này có thể do dữ liệu huấn luyện thiếu ví dụ viết theo TDD.

Một lần AI được yêu cầu xóa console.log, nhưng lại gây ra hàng loạt lỗi test, rồi tự ý hạ phiên bản Prisma – không cảnh báo. AI tự truy ra lỗi là "mismatch phiên bản" theo cách khá thông minh – nhưng hành vi tự ý như vậy gây lo ngại.

Điểm sáng: với đủ cấu trúc và phản hồi, AI có thể tạo ra hệ thống không chỉ chạy được mà còn dễ bảo trì.

Thí nghiệm 3: Hợp tác và đối thoại như đồng nghiệp (Conversational collaboration)

Lần này, chúng tôi dùng Google Gemini 2.5 Pro và trò chuyện sâu như với đồng nghiệp.

AI thể hiện khả năng phản biện kiến trúc rõ ràng, ví dụ khi bàn về snapshot API:

• Có cần lưu toàn bộ trạng thái gói đã cài tại thời điểm không?
• Nếu trạng thái khác giữa báo cáo và cơ sở dữ liệu thì xử lý ra sao?
• Ghi đè trạng thái hiện tại hay giữ bản lịch sử?

AI thiết kế API, tranh luận "eager vs. lazy loading", chỉ ra khoảng trống giả định ban đầu. Mã tạo ra (Python/FastAPI) rõ ràng, chuẩn RESTful hơn các lần trước.

So sánh kết quả 3 thí nghiệm

Tiêu chí	Thí nghiệm 1 (Vibe coding)	Thí nghiệm 2 (Kỷ luật)	Thí nghiệm 3 (Hội thoại)
Correct	3 – Hoạt động cơ bản, dễ lỗi khi sửa	4 – Có test và mutation check	4 – Xác minh bằng hội thoại
Testable	1 – Hầu như không test	5 – Test kỹ, mutation cao	3 – Có test, chưa hệ thống
Maintainable	2 – Mã rối, đặt tên lộn xộn	4 – Module nhỏ, dễ commit	4 – Cấu trúc rõ, API chuẩn
Scalable	2 – Không quan tâm hiệu năng	3 – Có modular, chưa sâu	3 – Kiến trúc bàn sơ, chưa đo
Diagnosable	2 – Log tùy tiện	3 – Có log cấu trúc cơ bản	3 – Có suy nghĩ về lỗi
Disciplined	2 – Ít commit, ESLint thêm sau	4 – CI, mutation gate	4 – Commit rõ, lý luận tốt

Bài học rút ra

• Chọn công cụ rất quan trọng: Claude giỏi lý luận, Gemini giỏi yêu cầu chức năng và kiến trúc.
• AI thiếu trí nhớ liên tục: dù có MCP vẫn quên trong session mới.
• Hợp tác AI-con người tốt hơn: Đối thoại, tranh luận giúp AI làm việc tốt hơn.
• Chất lượng cần có hướng dẫn và phản hồi: Nhắc test, kiến trúc, review giúp tăng chất lượng.
• Phải thử nghiệm nhiều: Setup và cách prompt ảnh hưởng mạnh đến kết quả.

Các vai trò nên làm gì tiếp?

• Developer: Thử nghiệm. Hướng dẫn AI bằng mô hình kiến trúc, TDD, nguyên lý mã sạch.
• Tech lead/Architect: Tạo template chuẩn, repo mẫu, chính sách AI development.
• Tester/Security Analyst: Dùng AI để test nhanh các "edge case", kiểm thử giả định.
• PM/BA: Dùng AI để prototype quy trình nghiệp vụ, logic nghiệp vụ bằng ngôn ngữ tự nhiên.
• IT Leader: Chuẩn bị tổ chức. AI mang lại lợi ích và rủi ro. Tạo môi trường thử nghiệm an toàn.

Tương lai phát triển phần mềm

AI không còn là công cụ autocompletion đơn thuần. Giờ đây, nó có thể xây dựng cả API, database, test… Dù còn lỗi và cần con người kiểm tra, nhưng chuẩn đã nâng lên.

Điều từng mất vài ngày giờ làm trong vài giờ – AI như đồng đội lập trình siêu tốc.

Vậy AI có thể tạo ra phần mềm production-grade không?

Chưa đồng đều – nhưng đang dần tiến gần.

Và tương lai còn hứa hẹn:

• AI chưa tối ưu cho mã tự xác minh (self-verifying code). Phải cải thiện bằng cách huấn luyện tốt hơn và phát triển toolchain.
• Codebase tương lai có thể sẽ nhỏ và module hóa hơn, để nằm trọn trong context window của AI.
• Bảo trì có thể sẽ không còn là giữ mã lâu dài, mà là viết lại dễ dàng khi cần.

Kết luận

Tương lai phát triển phần mềm sẽ không hoàn toàn tự động, nhưng chắc chắn sẽ AI-assisted.

Những tổ chức học cách hướng dẫn, kiểm soát và tích hợp AI từ hôm nay, sẽ là người dẫn đầu ngày mai.

Đã đến lúc ngừng coi AI coding là thử nghiệm – mà bắt đầu xem nó như người đồng sáng tạo thực sự.

A A A A

[{"displaySettingInfo":"[{\"isFullLayout\":false,\"layoutWidthRatio\":\"\",\"showBlogMetadata\":true,\"showAds\":true,\"showQuickNoticeBar\":true,\"includeSuggestedAndRelatedBlogs\":true,\"enableLazyLoad\":true,\"quoteStyle\":\"1\",\"bigHeadingFontStyle\":\"1\",\"postPictureFrameStyle\":\"2\",\"isFaqLayout\":false,\"isIncludedCaption\":false,\"faqLayoutTheme\":\"1\",\"isSliderLayout\":false}]"},{"articleSourceInfo":"[{\"sourceName\":\"Tác giả: Premanand Chandrasekaran (thoughtworks.com)\",\"sourceValue\":\"https://www.thoughtworks.com/insights/blog/generative-ai/can-vibe-coding-produce-production-grade-software\"}]"},{"privacyInfo":"[{\"isOutsideVietnam\":false}]"},{"tocInfo":"[{\"isEnabledTOC\":true,\"isAutoNumbering\":false,\"isShowKeyHeadingWithIcon\":false}]"},{"bannerInfo":"[{\"isBannerBrightnessAdjust\":false,\"bannerBrightnessLevel\":\"\",\"isRandomBannerDisplay\":true}]"},{"termSettingInfo":"[{\"showTermsOnPage\":true,\"displaySequentialTermNumber\":false}]"}]

Khám phá thêm các chủ đề sau