"Đây là nơi có quái vật": Bạn thực sự cần biết gì khi AI Agent làm hết mọi việc?

CI đang báo lỗi. Điều này thật bất ngờ, bởi tôi đã tinh chỉnh quy trình agent của mình đến mức khó có chuyện một agent commit nhánh code có test thất bại. Có thể là lỗi môi trường hoặc CI chập chờn? Khoan đã — SonarQube đang phàn nàn về App.tsx?

Bài viết gốc của tác giả trên blog cá nhân đặt ra một câu hỏi rất đáng suy ngẫm: khi các AI agent gánh phần lớn công việc viết code, con người còn cần biết những gì? Đây không chỉ là câu chuyện kỹ thuật, mà là vấn đề sống còn với ngành phần mềm, và với cả đội ngũ kỹ sư tại Việt Nam khi làn sóng AI coding tràn vào các công ty outsourcing và startup.

Minh họa về AI agent và lập trình

Khi code do agent viết mà không ai từng đọc

Hóa ra App.tsx chỉ có khoảng 30 dòng code, nhưng 15 trong số đó là những component hoàn chỉnh mà Codex quyết định viết gọn trên một dòng. Điều đó tự nó không quá nghiêm trọng — chạy qua prettier là xong. Nhưng nó không giải thích được lý do SonarQube phản ánh về độ phức tạp cyclomatic (cyclomatic complexity).

Mỗi component đều khá phức tạp, chứa nhiều logic hiển thị và nghiệp vụ. Một lập trình viên "thời xưa" sẽ cẩn thận refactor để code dễ đọc. Còn Codex thì không bận tâm — nó đã liên tục lặp và phát triển file này qua nhiều tính năng một cách trơn tru.

Sau khi format lại, tác giả kiểm tra từng component và nhận ra: agent có phần "over-engineer" và xử lý nhiều edge case hơn mức một dev thông thường, nhưng tất cả đều đúng. Độ phức tạp là chính đáng so với yêu cầu nghiệp vụ. Cuối cùng, chỉ cần bảo Codex làm SonarQube hài lòng — nó refactor và tách thành 10 file. CI xanh, sản phẩm ship.

Nhưng điều khiến tác giả giật mình: đây là đoạn code anh chưa từng nhìn thấy trước đó.

Xu hướng: sở hữu hệ thống không còn đồng nghĩa với tự tay viết

Ngành công nghiệp phần mềm đang dịch chuyển theo hướng này: việc "sở hữu" một hệ thống phần mềm sẽ ít phụ thuộc vào chuyện bạn đã tự tay viết nó hay không. Điều quan trọng hơn là biết đủ để nhận ra khi có gì đó sai, và sẵn sàng đào sâu đến mức cần thiết, đúng lúc cần thiết.

Tác giả dùng một ẩn dụ thú vị: hãy tưởng tượng bạn ngồi trên một con thuyền, nhiệm vụ là thu thập những "hạt vàng" nhỏ dưới đáy biển. Trước đây, bạn phải tự lặn xuống, tìm kiếm, nhặt vàng. Rồi các kỹ sư chế tạo máy móc để khai thác ở vùng nước sâu, nguy hiểm hơn.

Giờ đây xuất hiện các "divebot" — robot lặn có thể tự xuống đáy biển, xây dựng cơ sở khai thác và chỉ nổi lên để báo cáo cùng giao vàng. Bạn chỉ cần ngồi trên thuyền và lo xem chở được bao nhiêu vàng.

Nhưng rồi những câu chuyện kinh hoàng xuất hiện: divebot lạc đường, quên mất mình đang xây gì; divebot dựng nên công trình phức tạp đến mức chính nó cũng không bảo trì nổi; các "thánh đường" khai thác được thiết kế cẩn thận biến thành những dinh thự hỗn loạn với lối đi ngầm và hiểm họa rình rập. Bạn càng tách xa khỏi vận hành, thất bại càng thảm khốc.

Đây là hai phe trong ngành: Phe lạc quan (Optimists) và Phe hoài nghi (Skeptics). Bản thân tác giả tin rằng cả hai thái cực đều sai.

Hai lời khuyên cực đoan và vì sao cả hai đều không ổn

Phe này nói: cách duy nhất để kiểm soát hệ thống là đọc từng dòng code agent viết ra, phải tự tay code được, giải thích được từng phần code hoạt động thế nào.

Phe kia nói: đừng buồn nhìn code. Tập trung vào việc cần xây gì, quên đi cách nó được xây. Các mô hình sẽ lo liệu.

Tác giả phản biện: cách mà các kỹ sư senior ngày nay học nghề — code tay hàng giờ, debug triền miên, xử lý sự cố production — không còn khả thi về mặt kinh tế cho thế hệ junior. Rất khó có công ty nào chịu tài trợ cho junior học code tay trong nhiều năm. Lời khuyên "hiểu từng dòng agent viết", "pair với senior" hay "review code cẩn thận" đều là ảo tưởng ở quy mô toàn ngành.

Vậy con đường nào khả thi?

Ba trụ cột của người sở hữu hệ thống tương lai

Để trả lời, cần nhìn vào cách một kiến trúc sư trưởng hay CTO vận hành. Họ không hiểu từng dòng của codebase hàng triệu dòng. Họ có một tấm bản đồ tổng thể, biết đủ để xác định mình cần lặn xuống đâu, chỗ nào có quái vật. Và họ có thể nhảy vào bất kỳ codebase lạ nào, tìm ra vấn đề, đẩy hotfix và viết báo cáo sự cố rõ ràng.

Bản đồ của họ được xây từ các lớp trừu tượng, và không ai thực sự hiểu toàn bộ mọi lớp. Sự khác biệt giữa "tôi viết module X và hiểu nó tường tận" và "tôi có mô hình phù hợp về các lớp trừu tượng và có thể lặn vào bất kỳ module nào để sửa khi hỏng" là rất lớn.

Ba trụ cột tạo nên năng lực đó:

1. Nền tảng vững (Fundamentals)

Những lỗi nguy hiểm nhất trong hệ thống phức tạp là lỗi âm thầm (quiet failures): hệ thống vẫn chạy nhưng có gì đó sai — chậm hơn, tỷ lệ lỗi tăng, hoặc chạy hoàn hảo nhưng cứ 19 lần thì hỏng một lần.

Để nhận ra điều đó, bạn cần hiểu failure mode của hệ thống. Các công cụ để dạy điều này đã tồn tại từ lâu: cấu trúc dữ liệu và giải thuật, mạng, lập trình đồng thời, hệ phân tán. Ví dụ, một thuật toán có độ phức tạp bậc hai (quadratic) sẽ khiến thời gian tăng phi tuyến khi quy mô tăng — chỉ ai nắm lý thuyết mới nhận ra ngay điều bất thường.

2. Độ rộng kiến thức (Breadth)

Những kỹ sư và lãnh đạo giỏi nhất mà tác giả từng làm việc đều có thể thảo luận gần như mọi chủ đề, kể cả ngoài kỹ thuật. Họ biết cách kết nối những khái niệm tưởng như không liên quan từ các lĩnh vực khác nhau để giải quyết vấn đề.

Độ rộng chính là tấm bản đồ cấp cao của vùng biển — nó cho bạn biết vùng nào nguy hiểm hơn, nơi nào nên lặn xuống. Không phải chuyên gia mọi lĩnh vực, chỉ cần biết đủ để tra cứu khi có vấn đề.

Đáng chú ý: độ rộng không thể dạy được. Không có môn "Nhập môn mọi thứ". Cách duy nhất là khuyến khích đọc, khám phá, tò mò, ghi nhớ những sự cố kỳ lạ và cách chúng liên hệ với công việc của bạn. Kinh nghiệm và độ rộng cộng dồn theo thời gian, nhưng phải được duy trì.

3. Đào sâu đúng lúc (Just-in-time depth)

Đây là khả năng — và sự sẵn lòng — lặn sâu vào bất kỳ vấn đề nào để tìm hiểu. Kể cả khi vùng nước chưa được khám phá. Kể cả khi phải xuống tận nơi cá mập sống. Kể cả khi phải huy động cả đội và con tàu ngầm lớn vượt qua những con mực khổng lồ.

Đó cũng là sự khiêm tốn để nhận ra khi một lần lặn vượt quá khả năng và cần nhờ giúp đỡ. Không phải lần lặn nào cũng làm một mình được; không phải lần lặn nào cũng đáng làm.

Tác giả kể lại một câu chuyện thực tế: khi phát triển agent orchestrator của mình, anh gặp lỗi ổn định và vòng đời (lifecycle) của agent/subagent. Các "divebot" đã xây nó khá lộn xộn, mọi lỗi ập đến cùng lúc. Sau nhiều lần thất bại khi bảo chính agent sửa đống hỗn độn của nó, anh chợt nhớ đến cuốn sách về Kubernetes đọc từ nhiều năm trước — cụm từ "level-triggered state machine" bất ngờ hiện ra trước mắt.

Anh đã lặn sâu hơn dự định ban đầu, tận đến tận gốc gác về điện tử học của khái niệm "level-triggered", và thiết kế lại kiến trúc cốt lõi từ đầu. Kết quả: hệ thống chạy ổn định cho đến nay. Thành công đó chủ yếu nhờ vào một kiến thức tình cờ đọc được nhiều năm trước và sự sẵn lòng học hỏi.

Mô hình người sở hữu hệ thống tương lai

Không còn là chuyên gia hay "chữ T" — mà là người học nhanh dưới áp lực

Cách xây dựng phần mềm mới đòi hỏi một generalist có khả năng lặn sâu vào điều chưa biết — một "quick learner dưới áp lực", nhưng không phải kiểu ghi trên CV cho đẹp. Bạn sẽ thực sự phải học nhanh trong lúc chiến đấu với quái vật biển cả.

Đây là câu hỏi phỏng vấn đáng giá: khi ứng viên ghi "học nhanh", hãy hỏi họ kể về một lần phải nắm bắt một hệ thống phức tạp trong thời gian ngắn — họ đã làm thế nào?

Ba trụ cột này tạo thành "cổ phần sở hữu" mà mỗi người có thể tích lũy trong một hệ thống:

• Nền tảng — học được qua giáo dục chính quy hoặc tự học
• Độ rộng — tích lũy qua tò mò và trải nghiệm
• Đào sâu đúng lúc — rèn luyện qua thực chiến

Có thể bạn bắt đầu ở vùng nước nông, thả divebot xuống. Bạn có nền tảng vững, độ rộng ổn, vậy hãy xây cái gì đó. Chỉ cần sẵn sàng mặc bộ đồ lặn và bơi cùng quái vật khi có sự cố.

Ý nghĩa với kỹ sư Việt Nam

Câu chuyện này đặc biệt liên quan đến thị trường công nghệ Việt Nam, nơi nhiều kỹ sư trẻ đang bước vào ngành đúng lúc công cụ AI coding như Copilot, Cursor hay Codex trở nên phổ biến. Rủi ro là một thế hệ kỹ sư quen "duyệt" code do AI sinh ra mà không hiểu tường tận — đủ để chạy nhưng chưa đủ để sửa khi hệ thống sập lúc 2 giờ sáng.

Lời khuyên thực tế: đừng bỏ qua nền tảng khoa học máy tính vì "AI làm được rồi". Thay vào đó, hãy dùng agent để tăng tốc việc học — yêu cầu chúng giải thích, đặt câu hỏi ngược lại, hoặc thử thách bạn hiểu sâu hơn về một đoạn code. Và hãy rèn luyện thói quen đọc, ghi nhớ những sự cố, vì đó chính là cách xây dựng tấm bản đồ vùng biển của riêng bạn.

Ai sẽ chịu trách nhiệm cho những "cơ sở khai thác dưới nước" mênh mông trong tương lai? Không ai biết chắc, nhưng nhiều khả năng là những người nắm vững ba trụ cột trên — như đứa trẻ tháo chiếc radio cũ ra sửa mà chẳng biết gì về radio, chỉ với mong muốn được nghe nhạc, kể cả khi lắp lại xong thì thừa vài con ốc.