Tôi đang tạo ra các agent chạy khi tôi ngủ

• Agent viết mã bằng AI có thể tạo mã và phản ánh các thay đổi lên nhánh ngay cả khi lập trình viên đang ngủ, nhưng rất khó xác minh độ chính xác và độ tin cậy của kết quả
• Nếu để cùng AI đã viết mã đi kiểm thử chính đoạn mã đó, nó sẽ trở thành một cỗ máy tự khen mình, không thể phát hiện những hiểu sai khác với ý định ban đầu
• Mượn nguyên tắc cốt lõi của TDD: viết tiêu chí chấp nhận trước khi viết mã, để agent triển khai theo đó rồi thực hiện xác minh riêng biệt
• Xây dựng pipeline 4 bước kết hợp chế độ headless của Claude Code (claude -p) với Playwright MCP làm công cụ xác minh, không cần backend riêng
• Muốn tin tưởng đầu ra của agent thì phải định nghĩa rõ “hoàn thành” là gì trước khi bắt đầu công việc; đây là quy trình khó hơn viết prompt nhưng bắt buộc phải có

---

Bài toán xác minh mã của các agent tự chủ

• Với các công cụ AI như Gastown, agent có thể viết mã hàng giờ và phản ánh thay đổi lên nhánh, nhưng không có cách xác minh đáng tin cậy để biết kết quả đó có thực sự đúng hay không
• Kết quả từ các workshop Claude Code với hơn 100 kỹ sư trong 6 tháng qua cho thấy mọi nhóm đều gặp cùng một vấn đề
• Các nhóm dùng Claude cho PR hằng ngày ghi nhận số PR được merge tăng từ 10 mỗi tuần lên 40~50, khiến họ phải dành nhiều thời gian hơn đáng kể cho việc review code
• Hệ thống càng tự động vận hành thì vấn đề càng nghiêm trọng — đến một lúc nào đó người ta không còn review diff nữa mà chỉ quan sát quá trình deploy và hy vọng không có vấn đề, rồi chỉ phát hiện lỗi sau khi đã triển khai

Giới hạn của các cách giải quyết hiện có

• Cách tuyển thêm reviewer không theo kịp tốc độ, và việc kỹ sư senior ngồi đọc code do AI tạo ra cả ngày là rất kém hiệu quả
• Nếu Claude tự viết test cho chính đoạn mã nó vừa tạo, thì cấu trúc xác minh đó thực chất chỉ kiểm tra thứ Claude cho là người dùng muốn, chứ không phải điều người dùng thực sự muốn
  • Nó có thể bắt được bug hồi quy, nhưng không thể phát hiện sự hiểu sai (misunderstanding) ban đầu
• Nếu dùng cùng một AI để vừa viết vừa xác minh, nó sẽ trở thành một "cỗ máy tự khen mình (self-congratulation machine)"
• Mục đích gốc của code review là có góc nhìn thứ hai từ người không phải tác giả ban đầu; còn việc AI kiểm tra chéo lẫn nhau vẫn xuất phát từ cùng một nguồn nên sẽ bỏ sót cùng một thứ

Điều TDD đã chỉ ra đúng ở phần cốt lõi

• Nguyên tắc của TDD: viết test trước, viết code, rồi dừng lại khi test pass (không triển khai thêm nữa)
• Lý do đa số đội ngũ không làm TDD là vì phải nghĩ trước xem code cần làm gì, và điều đó tốn thời gian
• AI giải quyết vấn đề tốc độ nên cái cớ này không còn nữa — giờ phần chậm nhất là đánh giá xem code có đúng hay không
• Thay vì unit test, cách dễ hơn là mô tả bằng ngôn ngữ thường những gì tính năng phải làm
  • Ví dụ: "Người dùng xác thực bằng email và mật khẩu. Nếu thông tin đăng nhập sai thì hiển thị 'Invalid email or password'. Nếu thành công thì chuyển đến /dashboard. Token phiên sẽ hết hạn sau 24 giờ"
• Có thể viết các tiêu chí này trước cả khi mở trình soạn thảo code; sau đó để agent triển khai và một thứ khác đảm nhiệm việc xác minh

Ví dụ áp dụng thực tế

• Thay đổi frontend

  • Tạo tiêu chí chấp nhận (Acceptance Criteria) dựa trên file đặc tả
    • AC-1: Truy cập /login với thông tin hợp lệ thì được chuyển hướng sang /dashboard và thiết lập cookie phiên
    • AC-2: Nếu nhập sai mật khẩu thì hiển thị chính xác "Invalid email or password" và vẫn ở trang /login
    • AC-3: Nếu để trống trường thì nút gửi bị vô hiệu hóa hoặc hiển thị lỗi inline
    • AC-4: Sau 5 lần thất bại thì chặn đăng nhập trong 60 giây và hiển thị thông báo thời gian chờ
  • Mỗi tiêu chí đều có thể xác định rõ ràng là pass hay fail
  • Sau khi agent xây dựng tính năng, agent trình duyệt Playwright sẽ chạy xác minh cho từng AC, chụp ảnh màn hình và tạo báo cáo đánh giá theo từng tiêu chí
  • Nếu thất bại, có thể biết chính xác tiêu chí nào fail và trình duyệt đã hiển thị điều gì

• Thay đổi backend

  • Có thể áp dụng cùng một mẫu mà không cần trình duyệt
  • Mô tả hành vi API có thể quan sát được (status code, response header, thông báo lỗi) và xác minh bằng lệnh curl

• Giới hạn

  • Không thể phát hiện sự hiểu sai trong chính bản đặc tả — nếu spec sai ngay từ đầu thì dù vượt qua xác minh, tính năng vẫn sai
  • Những gì Playwright bắt được: lỗi tích hợp, bug render, hành vi bị vỡ trong trình duyệt thực
  • Đây là một tuyên bố hẹp hơn so với “độ chính xác đã được xác minh”, nhưng vẫn bắt được nhiều thứ hơn những gì code review vốn thường xuyên bắt được một cách ổn định

• Tóm tắt workflow

  • Viết tiêu chí chấp nhận trước prompt → agent triển khai theo tiêu chí → chạy xác minh → chỉ review những gì thất bại (review lỗi thay vì review diff)

Cách xây dựng: pipeline 4 bước

• Được triển khai dưới dạng Claude Skill (github.com/opslane/verify), sử dụng claude -p (chế độ headless của Claude Code) và Playwright MCP
• Không cần backend tùy chỉnh riêng hay API key bổ sung; chỉ dùng token Claude OAuth hiện có

• Bước 1: Pre-flight

  • Bash thuần túy, không gọi LLM
  • Kiểm tra server phát triển có đang chạy không, phiên xác thực còn hiệu lực không, file đặc tả có tồn tại không
  • Fail sớm trước khi tiêu tốn token

• Bước 2: Planner

  • Gọi Opus một lần
  • Đọc spec và các file đã thay đổi, rồi quyết định những gì cần cho từng phép xác minh và cách thực thi
  • Nó đọc code để tìm selector đúng nên không đoán mò tên class

• Bước 3: Browser Agents

  • Gọi Sonnet một lần cho mỗi AC, tất cả chạy song song
  • Nếu có 5 AC thì 5 agent sẽ độc lập điều hướng và chụp ảnh màn hình
  • Sonnet rẻ hơn Opus 3~4 lần nhưng cho hiệu năng tương đương trong các tác vụ dựa trên click

• Bước 4: Judge

  • Một lần gọi Opus cuối cùng để đọc toàn bộ bằng chứng và trả về đánh giá cho từng tiêu chí: pass, fail hoặc needs-human-review

• Cách cài đặt

  • Có thể cài như plugin Claude Code: /plugin marketplace add opslane/verify
  • Hoặc clone repo để tùy biến — mỗi bước đều có một lệnh gọi claude -p duy nhất với đầu vào rõ ràng và đầu ra có cấu trúc
  • Có thể thay model, thêm bước, và tích hợp CI bằng tùy chọn --dangerously-skip-permissions

Bài học cốt lõi

• Điểm then chốt là: “Nếu không mô tả trước định nghĩa của ‘hoàn thành’, bạn sẽ không thể tin vào kết quả.”
• Viết tiêu chí chấp nhận khó hơn viết prompt, nhưng nó buộc bạn phải nghĩ trước về các edge case, từ đó nâng cao chất lượng
• Các kỹ sư phản kháng vì cùng lý do họ từng phản đối TDD: ban đầu cảm thấy chậm hơn
  • Nếu không có tiêu chí chấp nhận, bạn chỉ còn cách đọc kết quả rồi hy vọng nó đúng
• Đây là thủ tục bắt buộc để đảm bảo độ tin cậy trong môi trường phát triển do AI dẫn dắt

[github88]

Dù có làm TDD đến đâu thì ở mức hiện tại, nơi LLM có thể thao túng bài test để vượt qua, vẫn nhất định cần con người review..

[GN⁺]

Ý kiến trên Hacker News

• Mình có cảm giác các framework LLM ra mắt dạo này lại đang khiến việc phát triển khó hơn và tốn kém hơn
  Chỉ với thiết lập mặc định cũng đã đi được khá xa, nên trong bối cảnh model liên tục thay đổi, việc tạo ra vô số wrapper và harness là không hiệu quả
  Cách làm kiểu để chạy qua đêm rồi đốt tiền như thế này về sau có lẽ sẽ trở thành trò cười như meme PHP

  • Nếu bạn là người bán xẻng trong cơn sốt AI thì lại là chuyện khác
    Theo bài viết, “trong 6 tháng qua đã tổ chức workshop Claude Code cho hơn 100 kỹ sư”
  • Tôi mong các đối thủ dùng AI agent nhiều nhất có thể trong codebase của họ
    Cứ để nó chạy ngày đêm, rồi đến lúc công ty AI phá sản, thứ còn lại chỉ là đống spaghetti code do AI viết chiếm 80%, lúc đó xem ai cười
  • Không nên chế giễu PHP. Ngay cả bây giờ, một số dự án tốt nhất của tôi vẫn được làm bằng PHP
    Tôi còn thấy những thứ làm bằng PHP từ 15 năm trước tốt hơn môi trường full-stack JS/TS ngày nay
  • Giờ mới thấy meme anti-PHP ngày xưa ngu ngốc đến mức nào
    PHP vẫn sống tốt và tiếp tục phát triển. Tooling cho LLM rồi cũng sẽ trở thành công cụ cơ bản theo cách đó
  • Đây không chỉ đơn giản là công việc tăng thêm mà là sự hợp nhất vai trò
    Ranh giới giữa BA, PO, QA, SWE đang mờ đi. Giờ đang xuất hiện những vai trò lai nằm giữa kinh doanh và phát triển

• Có vẻ giờ mọi người dùng agent chỉ vì muốn thử agent
  Tôi chỉ chạy hai cái, một cho viết và một cho review, mà năng suất tăng 5~7 lần đã là quá đủ
  Tôi dành nhiều thời gian hơn cho việc xem xét spec, còn phần code thì agent làm xong trong 10~30 phút nên chẳng có gì phải vội

  • Tôi không hiểu khái niệm “agent chạy qua đêm”. Claude phần lớn chỉ mất 5~20 phút là xong
    Ngày mai vẫn còn việc, nên chẳng có lý do gì phải để nó chạy suốt đêm
  • Ban đầu tôi cũng chạy nhiều agent song song, nhưng cuối cùng thấy tập trung theo từng thư mục hiệu quả hơn hẳn
  • Phần lớn những việc SWE từng làm giờ AI có thể xử lý bằng kiểu brute force
    Từ góc nhìn khách hàng, bug đến từ Ấn Độ, San Francisco hay AI thì cũng chẳng khác nhau mấy
  • Tôi cũng chỉ chạy hai agent và làm khá nhiều tinh chỉnh vi mô
    Đây là cách làm được kiểm soát hơn nhiều so với kiểu ‘dàn nhạc agent’ đang thịnh hành
  • Tôi nghĩ bước quan trọng nhất là xác thực spec
    Vì vậy tôi đã tự làm kỹ năng verify để kiểm tra xem Claude có bám spec tốt hay không

• Nếu bắt Claude dùng mẫu red-green-refactor thì chất lượng test thực sự tăng lên
  Tiến thêm một bước nữa, tạo các sub-agent red/green/refactor để chúng kiểm chứng lẫn nhau cũng hoạt động khá tốt
  Mấu chốt là không trộn lẫn context

  • Nhưng khi quá trình refactor diễn ra, test thường trở nên vô dụng hoặc bị bỏ sót
    Reward hacking là có thật và rất khó phòng thủ
  • Dù bắt làm red/green TDD, nó vẫn viết những test không thể fail rồi bảo “đã giải quyết xong” để lướt qua
    Ngay cả khi tham khảo hướng dẫn này thì vấn đề test kém chất lượng vẫn rất lớn
  • Tôi đã áp dụng hoàn toàn Outside-in TDD cho Claude Code
    Kết quả tốt đến mức tôi đã công bố nguyên lý và ví dụ cùng starter repo
  • Tôi muốn biết chi tiết hơn về cách triển khai mẫu green/red/refactor. Nếu có tài liệu tham khảo thì tốt quá
  • Cách tiếp cận này cũng hiệu quả trong review PR
    Việc tách người viết và người xác minh là rất quan trọng; ngay cả cùng một model, nếu tách context thì chất lượng cũng cao hơn

• Do giới hạn context của LLM hiện tại, agent thực thụ vẫn chưa khả thi
  Với code trên 500 dòng thì lỗi tăng vọt, và khoảng 200 dòng đã là giới hạn
  Cuối cùng LLM chỉ là một công cụ cần được dùng lặp đi lặp lại như máy tính bỏ túi

• Tôi gọi hiện tượng này là “Test Theatre”
  Tôi đã viết về nó ở đây. Nên chủ động tránh nó

  • Agent có thể viết 600 dòng test cho 100 dòng code, nhưng phần lớn là test vô nghĩa
    Test tốt phải kiểm chứng được pattern thiết kế và dependency, đồng thời hỗ trợ debug
  • Dùng property testing sẽ cho kết quả tốt hơn nhiều
    Ví dụ, với Schemathesis có thể tự động xác thực quyền người dùng hoặc việc có xuất hiện phản hồi 5xx hay không
  • Test Theatre là cách gọi rất chính xác. Test có pass thì trên thực tế cũng không chứng minh được gì
  • Cách tốt nhất là ép buộc Outside-in TDD + mutation testing
    Tôi đã đăng POC liên quan ở đây
  • Thực ra kiểu test mang tính hình thức này đã tồn tại từ trước rồi. Phần lớn chỉ là test chính phần triển khai

• Gần đây tôi đang thử nghiệm agent orchestration
  Trọng tâm là giảm số lần gọi LLM và nối chúng bằng pipeline script mang tính xác định
  Tôi đã tổng hợp chi tiết trong bài này

  • Tôi cũng đang thử kiểu orchestration lấy script làm trung tâm tương tự
    Giống như ghi chép thử nghiệm này, script mới là phần cốt lõi chứ không phải LLM

• Tôi đang vận hành 6 agent cho hoạt động kinh doanh
  Chúng đảm nhiệm nhiều vai trò như nghiên cứu thị trường, viết nội dung, kịch bản video
  “Chạy qua đêm” là một khái niệm bị phóng đại; trên thực tế mục tiêu rõ ràng và phạm vi hẹp mới hiệu quả
  Nút thắt thực sự không phải ở khâu thực thi mà là quản lý context

  • Cách tiếp cận thú vị đấy. Tôi tò mò bạn đang làm sản phẩm gì, và liệu kiểu nghiên cứu dựa trên Reddit vẫn còn hiệu quả không

• Tôi không hiểu người này thực sự đang làm gì
  Trên LinkedIn chỉ thấy các bài viết liên quan đến Claude

  • Việc triển khai code mà còn không thể xác minh là một rủi ro nghiêm trọng
    Với một doanh nghiệp nghiêm túc thì chuyện này là không thể tưởng tượng nổi
  • Với 25 năm kinh nghiệm trong ngành, tôi chưa từng thấy công ty nào cần code ở tốc độ như vậy
    Cuối cùng code vẫn nằm đó trong lúc họ lo nghĩ xem bán nó bằng cách nào

• Đây cũng giống vấn đề khi thuê người chỉ viết test
  Cuối cùng cũng chỉ là xác nhận rằng “code hoạt động đúng theo cách code vận hành”
  Việc định nghĩa spec rõ ràng quan trọng hơn nhiều

  • Test làm sau phần lớn chỉ là xác minh đồng nghĩa lặp lại
    Thật ngạc nhiên khi các ngành kỹ thuật khác không lặp lại sai lầm này, còn phần mềm thì lại đặc biệt hay như vậy
  • Giá trị thật của test nằm ở ngăn hồi quy
    Dù bản phát hành đầu có sai, nó vẫn đảm bảo hành vi không thay đổi về sau
  • Mục đích của test rốt cuộc là xác minh mock
  • Điều cốt lõi là định nghĩa spec trước rồi xác minh theo nó
    Nhiều công ty tư vấn làm việc bằng cách xác minh dựa trên acceptance criteria

• AI hiện tại không còn chỉ là công cụ hỗ trợ phát triển mà đã đạt đến mức thay thế lập trình viên
  Việc chúng ta không còn kiểm soát hay xác minh được code nữa là một vấn đề nghiêm trọng
  Điều này không giống một phương pháp phát triển mới mà giống một sự chuyển đổi mang tính tôn giáo, dựa vào niềm tin thay vì sự hiểu biết

  • Tôi tuyệt đối không deploy đoạn code mà mình không hiểu
    Dù mức độ tự động hóa thấp hơn, tôi chỉ merge những phần code có thể xác minh được
  • Hoặc cần đi theo hướng dùng các công cụ như formal methods để đảm bảo tính an toàn của code