Vì sao những lập trình viên giỏi lại dè dặt với phát triển bằng AI agent?

Rachel Laycock, CTO của Thoughtworks, chia sẻ một quan sát đáng chú ý: rất nhiều lập trình viên xuất sắc — những người thường tiên phong thử nghiệm công cụ và phương pháp mới — lại tỏ ra dè dặt khi được đề nghị "thả ga" với các AI agent viết mã. Câu trả lời quen thuộc là họ thích tự viết code hoặc lo mất việc, nhưng tác giả cho rằng đằng sau đó còn một nỗi lo sâu xa hơn: xây xong không đồng nghĩa với chạy ổn định trên production.

Minh họa về phát triển phần mềm bằng AI agent

Xây đúng và xây cho đúng

Văn hóa của Thoughtworks đặt nặng hai câu hỏi: xây đúng thứ cần xây, và xây nó một cách tử tế. Phần mềm phải hữu ích, có thể sửa đổi vào năm sau và không "sập" khi lên production. Chính từ triết lý này mà đội ngũ của công ty đã sớm tiếp nhận và góp phần tạo ra những thực hành nay đã phổ biến: tích hợp liên tục (CI), lập trình cặp, kiểm thử tự động, continuous delivery, microservices.

Các AI agent thế hệ đầu dễ dàng sinh ra rất nhiều mã — kể cả những đoạn mã không ai muốn đưa vào production, do những người chưa từng nếm trải khoảng cách giữa "build được" và "chạy an toàn trên production" viết ra. Công cụ đã tiến bộ vượt bậc, nhưng lập trình viên giàu kinh nghiệm vẫn đặt câu hỏi:

• Chúng ta có chắc đây là hành vi đúng không?
• Hệ thống có ranh giới phù hợp chưa?
• Liệu ta có thể tiến hóa nó về sau?
• Khi có sự cố thì chuyện gì xảy ra?
• Đội ngũ khác có sống chung được với nó không?

Bên dưới những câu hỏi ấy là một câu lớn hơn: có thể tin một hệ thống đến mức nào khi chưa ai từng có kinh nghiệm xây dựng theo cách đó? Gần như mọi hệ thống đang chạy hiện nay đều được làm thủ công bởi những người ta có thể tin tưởng. Còn những gì đang được xây bây giờ thì chưa ai sống chung đủ lâu để biết.

Sau hơn 25 năm trong ngành, tác giả đánh giá cao phán đoán mà con người tích lũy qua kinh nghiệm. Với những câu hỏi khó, con người vẫn đưa ra câu trả lời hữu ích hơn: họ thách thức tiền đề, nhận ra mô thức từ một sự cố mười năm trước, hoặc phát hiện vấn đề tổ chức ẩn trong vấn đề kỹ thuật. Có thể truy cập lượng thông tin khổng lồ, nhưng vẫn cần người giúp suy nghĩ thấu đáo — và đó chính là thứ mà các lập trình viên dè dặt đang cố bảo vệ.

Cần nói rõ: họ không ngại dùng trợ lý viết mã. Họ ngại giao toàn bộ khâu thực thi cho agent và buông tay khỏi vô lăng khi chưa chắc agent có đủ "lan can" an toàn để tự chạy.

Một tuần bên bảng trắng

Giles Alexander, Regional CTO khu vực châu Âu của Thoughtworks, đã tập hợp các kỹ sư cấp cao, chuyên gia hạ tầng và nhân sự sản phẩm cho một tuần làm việc theo đúng mô hình mới: không ai viết mã, mọi thứ do agent xây. Mục tiêu không phải chứng minh có thể làm xong một ứng dụng hàng không trong một tuần — và đúng là họ đạt khoảng 80%, ngưỡng mà ai trong nghề cũng biết nghĩa là gì. Mục tiêu thực sự là học xem công việc của đội thay đổi ra sao khi agent đảm nhận toàn bộ việc viết mã.

Điều gây ấn tượng là đội dành rất nhiều thời gian bên bảng trắng: làm rõ miền nghiệp vụ, vạch ranh giới, quyết định bước tiếp theo và lập kế hoạch để agent thực thi. Trong khi đó, agent vẫn tiếp tục sinh mã ngoài giờ làm việc của con người.

Con người còn thiết kế vòng phản hồi cho công việc đó: kiểm thử, contract test, kiểm tra kiến trúc và pipeline triển khai. Họ tìm cách trao cho agent đủ tự do để tiến lên, đồng thời giữ vững niềm tin vào kết quả. Phần lớn thao tác bàn phím là hướng dẫn agent đưa các bài học vào "harness" để lần chạy sau đúng hơn.

Ước lượng của đội: khoảng 2/3 thời gian bên bảng trắng, 1/3 dành cho harness.

Điều thú vị: cuối cùng, người phụ trách sản phẩm lại là người commit nhiều mã tính năng nhất trong đội.

Ứng dụng chạy được, nhưng build thì đỏ

Ứng dụng chạy được, nhưng build thường xuyên đỏ. Lại là câu chuyện "chạy được trên máy tôi" — lần này trong bối cảnh AI agent. Một build đỏ phải có ý nghĩa: dừng lại, điều tra, sửa. Nếu nó đỏ thường xuyên đến mức mọi người thôi để ý, làm sao phát hiện lỗi thật tiếp theo? Và nếu không tin được các bước kiểm tra, thì một build xanh cũng chẳng còn khiến ai yên tâm — đúng điều mà CI ra đời để xóa bỏ.

Đội thí nghiệm vẫn đang tìm nguyên nhân: quá nhiều agent chạy song song giẫm lên thay đổi của nhau? Hệ thống chưa đủ mô-đun hóa? Hay thay đổi đến nhanh hơn tốc độ kiểm tra? Có thể là tất cả.

Điều này không chỉ xảy ra trong thí nghiệm nội bộ. Nghiên cứu DORA 2025 cho thấy việc áp dụng AI gắn với thông lượng giao hàng cao hơn nhưng độ ổn định thấp hơn — đúng vấn đề mà continuous delivery và DevOps từng được sinh ra để giải quyết. Tác giả dự đoán phong trào DevOps/continuous delivery sẽ có một đợt "hồi sinh và tư duy lại" trong kỷ nguyên agent.

Trong nội bộ, nhiều tranh luận nảy lửa đã nổ ra:

• TDD còn vai trò gì khi bạn không đọc từng dòng và agent tự viết cả kiểm thử lẫn mã?
• Kiểm thử chấp nhận, contract test và kiểm tra ở ranh giới hệ thống nên đặt ở đâu để đủ tin cậy mà không quá giòn?
• Cần thiết kế bao nhiêu trước khi thả agent, khi mà cách tiếp cận có thể sửa rất nhanh?
• Kích thước lô công việc nên là bao nhiêu? Nhiều đội đang chuyển từ Story sang Epic — tốt cho tốc độ, nhưng pipeline CI có xử lý nổi đơn vị công việc lớn như vậy, song song, với tốc độ đó không?

Đội thí nghiệm chưa giải quyết xong tất cả sau một hay hai tuần, và tác giả nói thẳng: ai tuyên bố đã giải xong thì đừng tin. Nhưng đây chính là kiểu công việc mà các lập trình viên giàu kinh nghiệm nên tham gia: thử nghiệm, đặt câu hỏi, giúp phát hiện thực hành nào còn vững và chỗ nào cần cách làm mới.

Ra khỏi đường trượt đã được dọn sẵn

Tác giả so sánh với việc học trượt tuyết: trẻ con lao thẳng xuống dốc không sợ hãi, giống như lập trình viên mới chưa từng đưa phần mềm lên production và chưa từng xử lý sự cố lúc 3 giờ sáng. Người lớn học trượt tuyết thì nghĩ đến việc mình có thể làm gãy chân — họ muốn trượt, nhưng đủ lớn để thấy hậu quả. Vấn đề lớn nhất là chưa biết cách rẽ và phanh; thiếu hai kỹ năng đó thì họ là một đoàn tàu mất phanh trên dốc.

Martin Fowler — người cũng học trượt tuyết muộn — chỉ ra chỗ ví von bị phá vỡ: trên dốc trượt tuyết, bạn đã thấy vô số người xuống chân dốc lành lặn, người hướng dẫn đã dạy hàng nghìn người trên cùng con dốc. Còn phát triển bằng agent hiện nay giống một chuyến đi vào vùng hoang dã chưa có bản đồ: chưa biết kỹ năng nào quan trọng nhất, rất ít người đã hoàn thành chuyến đi an toàn, và phản hồi về cách điều hướng thì chậm hoặc không có.

"Build xong không giống với chạy được trên production." — và như Charity Majors nói: "Staging chỉ là một chiếc laptop hào nhoáng. Chỉ có prod mới là prod."

Điều này củng cố cảm giác bất an của tác giả trước những lãnh đạo — kỹ thuật lẫn phi kỹ thuật — cho rằng lập trình viên thiếu tò mò hoặc chậm tiếp thu, rồi quy cho nỗi sợ đơn giản như thích viết code hay lo mất việc. Những lập trình viên giỏi nhất không phải người mới run rẩy trên con dốc tập mà ai cũng đã chinh phục. Họ đang nhìn vùng đất chưa có dấu chân và đặt những câu hỏi hợp lý về lộ trình. Bảo họ bớt thận trọng là hiểu sai vấn đề — họ cần nằm trong đội vẽ bản đồ.

Dĩ nhiên, kinh nghiệm cũng có thể khiến ta bám chặt vào thực hành quen thuộc. Một phần bài học trên "đường trượt đã dọn" sẽ không còn đúng ngoài vùng hoang dã, và ta phải sẵn sàng kiểm chứng lại các giả định.

Thách thức cho cả hai phía

Bài viết kết lại bằng một thách thức kép:

• Với lãnh đạo: cần lắng nghe đủ kỹ để phân biệt lo ngại hữu ích với sự ngại thay đổi, đồng thời tạo không gian thật cho thử nghiệm — nghĩa là thời gian, sự cho phép sai, và không đánh giá thành công bằng lượng mã agent sinh ra.
• Với lập trình viên: cần mang kinh nghiệm vào các thí nghiệm và sẵn sàng phát hiện rằng một số giả định của mình không còn đúng.

Một số thực hành quen thuộc sẽ trở nên quan trọng hơn; số khác cần hình hài mới. Sẽ không ai trao sẵn bản đồ cho chúng ta.

Nếu bạn thực sự quan tâm đến việc xây đúng thứ và xây nó tử tế, phán đoán của bạn chính là thứ mà cách làm việc mới này cần. Hãy mang theo sự thận trọng — rồi cùng bước vào vùng tuyết.