- Sự lan rộng gần đây của AI coding agent đã đẩy nhanh tốc độ phát triển, nhưng đồng thời chất lượng phần mềm suy giảm và tính bất ổn gia tăng
- Các agent tích lũy cùng một lỗi mà không có khả năng học lặp lại, và trong codebase quy mô lớn sẽ xảy ra suy giảm recall của tìm kiếm và bùng nổ độ phức tạp
- Nếu giao toàn bộ hệ thống mà không có sự kiểm soát của con người, sẽ dẫn tới mã trùng lặp, pattern thiết kế sai và codebase không thể bảo trì
- Ở thời điểm hiện tại, nên chỉ sử dụng agent một cách có giới hạn cho các tác vụ không cốt lõi hoặc khu vực mang tính thử nghiệm, và con người phải là cổng kiểm soát chất lượng cuối cùng
- Giảm tốc và khôi phục vai trò chủ thể của con người là điều cốt lõi cho việc học tập, trưởng thành và một hệ sinh thái phần mềm bền vững
Mọi thứ đang hỏng hóc
- Trong 1 năm qua, coding agent đã phát triển tới mức có thể hoàn thành các dự án thực tế, nhưng hệ quả là chất lượng phần mềm suy giảm ngày càng rõ rệt
- Ngay cả ở các dịch vụ lớn, mức uptime 98% đang dần trở nên phổ biến, và bug UI xuất hiện thường xuyên
- Bài viết cũng nhắc tới các sự cố liên quan đến AI của AWS và phát biểu của Microsoft về việc tỷ trọng mã do AI viết tăng lên
- Một số công ty tuyên bố 100% mã sản phẩm do AI viết, nhưng đầu ra lại có chất lượng thấp với rò rỉ bộ nhớ, lỗi UI, chức năng thiếu ổn định
- Nhiều lập trình viên cho biết phát triển lấy agent làm trung tâm đã khiến họ rơi vào codebase không thể bảo trì, do thiếu code review, thiếu thiết kế và phình to các tính năng không cần thiết
Những cách không nên làm việc cùng agent
- Các lập trình viên đang nghiện tốc độ và số lượng code, đến mức từ bỏ chất lượng và quyền kiểm soát
- Dưới khẩu hiệu “phân tán, tự trị, tự động hóa”, họ thử orchestration agent quy mô lớn, nhưng thực tế chỉ tạo ra các kết quả thiếu ổn định
- Một số dự án thậm chí còn khó chạy nổi và không thể được duy trì nếu không có con người can thiệp
- Ở cấp độ dự án cá nhân thì có thể khả thi, nhưng với sản phẩm có người dùng thật, phần lớn đều thất bại
-
Tích lũy lỗi, thiếu học hỏi, không có nút thắt cổ chai, nỗi đau đến muộn
- Agent không có khả năng học lặp lại, nên cứ tiếp tục tạo ra cùng một lỗi
- Con người học từ sai lầm, còn agent thì lặp lại cùng một sai lầm vô hạn
- Tốc độ viết code của con người có giới hạn nên lỗi tích lũy chậm, nhưng đội quân agent không có nút thắt cổ chai nên lỗi tích lũy bùng nổ
- Kết quả là codebase trở nên không đáng tin, đến mức ngay cả test tự động cũng không còn đáng tin cậy
- Cuối cùng, test thủ công trở thành phương tiện xác minh duy nhất, và đội phát triển tự đẩy mình vào cái bẫy này
-
Những kẻ buôn bán đã học được sự phức tạp
- Agent chỉ đưa ra quyết định cục bộ mà không nhìn được bối cảnh toàn hệ thống
- Hệ quả là mã trùng lặp, abstraction không cần thiết và hỗn loạn cấu trúc tích tụ rất nhanh
- Trong tổ chức con người, kiểu phức tạp này thường tích lũy từ từ trong nhiều năm, còn đội ngũ dựa trên agent có thể đạt mức hỗn loạn tương tự chỉ trong vài tuần
- Agent tái hiện nguyên xi các pattern thiết kế sai học được từ dữ liệu huấn luyện, và nếu thiếu kiểm soát của con người sẽ tạo ra độ phức tạp không thể cứu vãn
-
Recall thấp trong tìm kiếm của agent
- Khi agent cố sửa code hoặc refactor, nó không tìm được toàn bộ phần mã cần thiết
- Codebase càng lớn thì recall của tìm kiếm càng giảm mạnh, dẫn tới trùng lặp và thiếu nhất quán
- Dù dùng nhiều công cụ như Bash, LSP, vector DB..., vẫn tồn tại giới hạn với codebase lớn
- Vì vậy, code smell và độ phức tạp không cần thiết càng trở nên nghiêm trọng hơn
Cách nên làm việc cùng agent (ở thời điểm hiện tại)
- Agent hấp dẫn nhờ tạo code nhanh và chất lượng ban đầu cao, nhưng nếu giao cả hệ thống cho chúng thì sẽ sụp đổ
- Các trường hợp phù hợp là tác vụ không cốt lõi trong phạm vi nhỏ, tác vụ có vòng lặp tự đánh giá, và tác vụ thất bại cũng không mang tính chí mạng
- Ví dụ, xây dựng công cụ nội bộ, thử nghiệm ý tưởng, nghiên cứu tự động dựa trên đo lường hiệu năng (auto-research) là những hướng phù hợp
- Con người nhất định phải là cổng kiểm soát chất lượng cuối cùng, đồng thời xem xét, chỉnh sửa và tích hợp kết quả của agent
- Nếu hàm đánh giá chỉ phản ánh các chỉ số hẹp, agent có thể bỏ qua chất lượng code, độ phức tạp và tính chính xác
- Giảm tốc là điều then chốt
- Cần dành thời gian suy nghĩ mình đang tạo ra cái gì và vì sao, đồng thời dứt khoát từ chối những tính năng không cần thiết
- Giới hạn lượng code mà agent có thể tạo ra mỗi ngày ở mức con người có thể review được
- Kiến trúc, API và các hình thái bản chất của hệ thống nhất định phải do con người trực tiếp viết
- Hãy pair programming cùng agent để giữ lại sự ma sát và cơ hội thấu hiểu trong quá trình viết code
- Cách tiếp cận này giúp tạo ra codebase có thể bảo trì, nâng cao mức độ hài lòng của người dùng, và tập trung vào tính năng cốt lõi thay vì tính năng thừa
- Nếu hiểu biết của con người vẫn còn hiện diện, vấn đề recall trong tìm kiếm của agent cũng được giảm nhẹ, và khi có sự cố thì có thể tự sửa trực tiếp
- Dù thiết kế ban đầu có sai, vẫn giữ được khả năng hiểu lý do và cải thiện nó
- Sau cùng, điều cần thiết là kỷ luật và vai trò chủ thể của con người
- Chất lượng và tính bền vững của hệ thống phụ thuộc vào sự can thiệp và phán đoán của con người
- Đi chậm lại mới chính là con đường duy nhất để duy trì học hỏi, trưởng thành và một hệ sinh thái phần mềm lành mạnh
2 bình luận
Pi – bộ harness lập trình terminal tối giản
Là người đã tạo ra cái này đây mà
Ý kiến trên Hacker News
Mỗi lần đọc những bài viết đầy suy tư như thế này dạo gần đây, tôi cũng có cảm giác mình đã mệt mỏi ở một thời điểm nào đó
Cuối cùng, điều quan trọng là “chúng ta đang xây cái gì” và “công cụ đó có thực sự hữu ích hay không”
Chúng ta đã lặp lại cùng một sai lầm từ thời Ruby, PHP, Lotus Notes, Visual BASIC
Cần dùng công cụ một cách khôn ngoan và làm việc với tốc độ đủ để hiểu được thực tế phức tạp mà cả đội đang thật sự xây dựng
Agile hay Waterfall, Docker hay Podman, những thứ đó không phải bản chất
Giờ là thời đại mà LLM xóa cả DB production rồi còn vẽ hình minh họa cho bài blog postmortem về chuyện đó, nhưng tôi không biết đó có phải kỹ thuật thực sự hay không
Có lẽ phát triển phần mềm ngay từ đầu vốn đã không phải là một ngành kỹ thuật
10 năm qua ngành phần mềm ngập tràn công việc meta — framework mới, công cụ mới, lớp ảo hóa mới, cơ cấu tổ chức mới, v.v.
Nhưng rốt cuộc lại không rõ là đang xây những thứ đó để làm gì
Nó giống như một cấu trúc kiểu kim tự tháp, cảm giác như đang tạo ra việc làm mới để duy trì chính ngành này
Dù vậy, kỹ thuật thực sự vẫn tồn tại — khi ta đặt câu hỏi theo cách khoa học và đưa ra quyết định dựa trên câu trả lời đó
Ngược lại, làm việc theo ‘cảm giác’ rồi chỉ nghe lời CEO thì không phải kỹ thuật
Ngày xưa nhiều đội còn chẳng có nổi quản lý phiên bản, mà có thì cũng rất tệ
Nhìn vào Joel Test của Joel Spolsky thì phần lớn công ty thời đó đều là “không”
Cầu thì tính chính xác tải trọng, vật liệu, tuổi thọ..., còn website thì ngay cả traffic cũng khó dự đoán
Không có tiêu chuẩn nào để xử lý định lượng giới hạn chịu tải của server hay framework
Có thể một ngày nào đó phần mềm sẽ trở thành kỹ thuật đúng nghĩa, nhưng hiện giờ vẫn còn rất xa
Có cảm giác người ta gắn chữ “engineer” vào chỉ để kiếm được nhiều tiền hơn
Kỹ sư thực thụ coi trọng chứng minh và kiểm chứng, còn chúng ta thì thích các pattern mới và những thử nghiệm mới
Vì vậy từ “engineer” đôi khi lại khiến tôi thấy khó chịu
Ông chỉ trích đó là “phương pháp luận để những người không biết lập trình cố lập trình”, và đến giờ nghe vẫn đúng
Gần đây quy trình phát triển dựa trên AI đang dần cố định theo hướng các tập đoàn lớn, kéo theo vendor lock-in ngày càng nặng
Khi codebase chuyển sang lấy agent làm trung tâm, cuối cùng chỉ còn chính agent đó hiểu được code
Đến lúc ấy giá sẽ tăng, và đó có thể trở thành một chuyển đổi một chiều khiến lập trình viên con người rất khó quay lại
Những người lạc quan nói rằng “công nghệ lúc nào cũng rẻ hơn và tốt hơn”, nhưng nó cũng có thể đi theo con đường như thị trường dầu mỏ
Giống như ngày xưa chuyển từ DVD sang streaming, chúng ta đang như thể mua cùng một bộ phim hai lần
Các model như Claude Opus 4.6 giờ đã đắt tới mức 1 đô mỗi phút, và prompt engineering cũng không còn cứu vãn được nữa
Cuối cùng các dịch vụ AI cũng đang phân tầng thành giá rẻ – tầm trung – premium
Prompt engineering giờ gần như bị xem là dạng jailbreaking tinh vi
Việc “cho thuê” năng lực lao động tri thức của mình cho các công ty AI là rất nguy hiểm
Câu “chi phí sẽ không tăng nữa đâu” là dấu chấm hết của cuộc đối thoại — họ đã ném xúc xắc rồi
Các ông lớn AI cũng sẽ đi theo con đường đó
Cuối cùng có khi chúng ta sẽ bị nhốt trong một thị trường nghiện token
Bàn tay vô hình của mã nguồn mở cuối cùng sẽ khiến mọi thứ trở nên miễn phí
Khi phần cứng và phần mềm tiến bộ, đơn giá tính toán vẫn đều đặn đi xuống
Những công nghệ không có nhu cầu sử dụng thực như cơn sốt blockchain sẽ biến mất, nhưng AI thì có người dùng thật
Những dịch vụ từng bị chỉ trích thời đầu như Uber rồi cũng đã trở thành mô hình kinh doanh bền vững
Không giống dầu mỏ, điện toán mỗi năm đều rẻ hơn và nhanh hơn
Tác giả bài này là người tạo ra Pi, một framework coding agent mã nguồn mở
Nó cũng đang được dùng trong OpenClaw
Bài blog về Pi của anh ấy cũng đáng đọc
Ông ấy là người đã đào sâu LLM và agent hơn hầu như bất kỳ ai
Càng là công ty tuyên bố “AI viết 100% code” thì càng hay tung ra sản phẩm tệ hại
Hồi thời DOS hay MacOS trước kia, kiểu code đó có thể làm sập cả hệ thống, nên chất lượng được coi trọng hơn
Bây giờ OS khoan dung hơn nên code cẩu thả vẫn sống được
Nhờ OTA update, người ta dễ dàng tung ra sản phẩm chưa hoàn thiện để ra mắt nhanh hơn đối thủ
Chỉ là thứ chúng ta nhớ đến là số ít sản phẩm được làm tốt mà thôi
Còn giờ chỉ cần có kết nối mạng thì ngay cả OS cũng được update dễ như game
Coding agent giống như “tiếng hát mê hoặc của siren”
Ban đầu nó trông nhanh và thông minh, nhưng đến lúc nghĩ “máy tính ơi, làm thay việc của tôi đi” thì mọi thứ bắt đầu sụp đổ
Nhưng đây chỉ là tạm thời — AI đã vượt con người trong những lĩnh vực có thể đo đếm
Vấn đề thực sự là HCI (tương tác người–máy)
Thiết kế giao diện phù hợp với giá trị của con người sẽ là nhiệm vụ cốt lõi trong tương lai
Hiện tại đang là đỉnh điểm của cơn sốt AI
Giống như thời MongoDB hay NoSQL từng hô hào “SQL đã chết”, cuối cùng người ta rồi cũng sẽ quay về điểm cân bằng thực tế
NoSQL không biến mất, nhưng giờ chỉ được dùng ở những nơi thật sự cần
Tôi đồng cảm với câu “phần mềm ngày nay là một mớ mong manh dễ vỡ”, nhưng thực ra bản thân phần mềm không thay đổi
Trước đây vì thiếu niềm tin nên con người tự kiểm tra trực tiếp, và chính tốc độ chậm đó mới làm giảm bớt vấn đề
Cốt lõi của DevOps là di chuyển nhanh dựa trên niềm tin nhưng vẫn giữ được chất lượng
Giống như dây Andon của Toyota, khi phát hiện vấn đề thì phải dừng lại ngay và xử lý tận gốc nguyên nhân
Đây không phải vấn đề công nghệ mà là vấn đề văn hóa và quy trình
Cần phát hiện sớm interface sai hoặc sự lệch nhau về ngữ cảnh kinh doanh
Ai cũng dùng GitHub, AWS, Cloudflare nên chỉ cần một nơi dừng là cả thế giới dừng theo
Nếu phát hiện bug ngay trước tape-out, người ta sẽ cân nhắc thận trọng thay vì đổ lỗi cho người báo tin
Thành quả của lập trình không chỉ là code mà còn là chính bản thân lập trình viên
Mô hình tinh thần và trí nhớ cơ bắp được tích lũy trong quá trình viết code mới là tài sản thật sự
Nếu AI thay thế quá trình đó, cuối cùng sự trưởng thành của lập trình viên cũng biến mất
“Preventing the Collapse of Civilization” của Jonathan Blow cũng bàn về cùng vấn đề này
Xem “Programming as Theory Building”
Hôm qua tôi cũng đã có một cuộc trò chuyện tương tự với đồng nghiệp
Tôi xem một bản demo nơi AI đọc log, sửa bug, rồi còn viết cả postmortem,
nhưng vấn đề là con người không có thời gian để nội tại hóa quá trình đó
Giống như câu “xe chạy nhanh được là vì có phanh”,
ta cần giữ lại ma sát của việc học ở tốc độ mà con người có thể hiểu được
Nếu agent tự nhận biết và tự phục hồi được, liệu con người còn cần phải học không?
Tất nhiên có thể bỏ lỡ nguyên nhân gốc rễ, nhưng nếu hệ thống tự phục hồi đủ vững thì điều đó có còn là vấn đề không?
Từ góc độ product design tôi cũng cảm thấy vấn đề tương tự
Tốc độ phát triển quá nhanh nên không có thời gian tự dùng thử để kiểm chứng
Nếu cứ chồng thêm tính năng lên một thiết kế sai thì càng ngày càng khó quay đầu
Cuối cùng điều quan trọng không phải là tốc độ mà là sự cân bằng giữa chất lượng và học hỏi
Quá trình đó nhất định cần thời gian