Các mẫu kỹ thuật agentic

• Đây là hướng dẫn tổng hợp phương pháp phát triển trong thời đại các coding agent như Claude Code và Codex, đồng thời đề xuất những mẫu kỹ thuật mới để cộng tác với agent
• Giải thích qua nhiều mẫu khác nhau về việc nên thay đổi thói quen phát triển và workflow như thế nào trong môi trường mà chi phí viết mã đã giảm mạnh
• Sắp xếp có cấu trúc các lĩnh vực cốt lõi của phát triển lấy agent làm trung tâm như nguyên tắc, kiểm thử, hiểu mã và thiết kế prompt
• Mỗi mẫu được trình bày dưới dạng tài liệu mẫu thiên về thực tiễn, bao gồm ví dụ mã nguồn thực tế, cách làm việc và các trường hợp sử dụng prompt
• Là tài liệu tham khảo thực tiễn giúp lập trình viên trong thời đại coding agent thiết kế có hệ thống môi trường lập trình dựa trên agent và duy trì chất lượng

---

Tổng quan về Agentic Engineering Patterns

• Hướng dẫn tổng hợp các phương pháp kỹ thuật hiệu quả khi phát triển cùng coding agent (Claude Code, OpenAI Codex, v.v.)
• Tham khảo bài viết giới thiệu Writing about Agentic Engineering Patterns
  • Là tài liệu có cấu trúc liên tục bổ sung nhiều mẫu (chapter) như định dạng “Design Patterns” truyền thống
  • Lấy sự thay đổi trong workflow và cách ra quyết định của lập trình viên làm chủ đề trung tâm trong bối cảnh chi phí viết mã giảm đáng kể
  • Được vận hành dưới dạng nội dung kiểu guide có thể cập nhật, không phải bài blog thông thường, và dự kiến sẽ tiếp tục mở rộng

1. Principles

• Writing code is cheap now

  • Với sự xuất hiện của AI coding agent, chi phí viết mã ban đầu đã giảm xuống gần như bằng không
  • Trước đây, vì viết mã tốn kém nên phát triển thường xoay quanh thiết kế và lập kế hoạch, nhưng giờ đây đã có thể thử nghiệm ý tưởng ngay bằng mã
  • Dù chi phí tạo mã đã thấp, mã tốt (kiểm thử, khả năng bảo trì, v.v.) vẫn luôn có chi phí

• Hoard things you know how to do

  • Tài sản quan trọng của lập trình viên là "sự tích lũy tri thức về những gì có thể làm được"
  • Nhấn mạnh thói quen lưu trữ và tích lũy các ví dụ giải quyết vấn đề cùng các thử nghiệm mã nhỏ theo dạng có thể tái sử dụng
  • Mã và ví dụ được tích lũy như vậy có thể trở thành dữ liệu đầu vào rất mạnh để chỉ dẫn coding agent tạo ra tính năng mới

• Anti-patterns: things to avoid

  • Dù là mã do agent tạo ra, vẫn nên tránh chia sẻ hoặc gửi PR mà không review, vì đó là một anti-pattern
  • Phần mô tả PR do agent viết cũng cần được con người trực tiếp xác minh và chỉnh sửa
  • Để không lãng phí thời gian của người review mã, cần cung cấp kèm kiểm thử, quy trình xác minh và lý do chọn cách triển khai

2. Testing and QA

• Red/green TDD

  • Phát triển hướng kiểm thử trước (TDD) là một mẫu phát triển đặc biệt hiệu quả khi dùng cùng coding agent
  • Khi viết test trước, agent có thể tạo mã theo hướng đáp ứng được các bài test
  • Ngay cả với prompt tối thiểu, cách này vẫn giúp tạo ra mã chính xác và đáng tin cậy

• First run the tests

  • Khi làm việc với coding agent, kiểm thử tự động không phải lựa chọn mà là yếu tố bắt buộc
  • Trong môi trường mà chi phí viết test đã giảm, agent có thể nhanh chóng tạo và chỉnh sửa test
  • Vì không thể bảo đảm mã hoạt động đúng cho tới khi nó thực sự được chạy, nên kiểm thử là rất quan trọng

3. Understanding code

• Linear walkthroughs

  • Đây là mẫu đọc mã hoặc dự án do agent tạo ra theo thứ tự từ đầu đến cuối để hiểu cấu trúc
  • Ngay cả với dự án đơn giản, vẫn có thể học công nghệ mới và cấu trúc mới bằng cách lần theo luồng mã
  • Trước lo ngại rằng AI tạo mã có thể làm chậm tốc độ học, tài liệu cho rằng việc tự khám phá mã cũng có thể trở thành cơ hội học tập

• Interactive explanations

  • Là cách trao đổi với agent và yêu cầu giải thích khi muốn hiểu mã hoặc hệ thống
  • Bằng cách lặp lại câu hỏi, có thể nắm dần nguyên lý hoạt động và cấu trúc của mã
  • Đây là mẫu mở rộng quá trình hiểu mã thành một hình thức học tập tương tác

4. Annotated prompts

• GIF optimization tool using WebAssembly and Gifsicle

  • Bao gồm ví dụ prompt để tạo công cụ tối ưu GIF dựa trên WebAssembly và Gifsicle
  • Trình bày cách triển khai công cụ một trang duy nhất gồm HTML, JavaScript và CSS
  • Giải thích cách tận dụng coding agent thông qua prompt thực tế và ví dụ mã nguồn

5. Appendix

• Prompts I use

  • Tuyển tập các ví dụ prompt cho coding agent đang được sử dụng thực tế
  • Tổng hợp các mẫu prompt thực chiến được dùng cho nhiều loại công việc khác nhau
  • Cung cấp các template thực dụng có thể dùng khi cộng tác với agent

[GN⁺]

Ý kiến trên Hacker News

• Có vẻ như chúng ta lại sắp lặp lại cùng một việc
  Những khái niệm đơn giản và hợp lý — ví dụ như "hãy viết test trước", "hãy tạo các module nhỏ có thể kết hợp được" — sẽ lại bị gói trong những cái tên phức tạp, rồi từ đó tạo ra cả một ngành công nghiệp tư vấn
  Chỉ là lần này đối tượng là "cỗ máy biết nói". Một thế giới nơi chỉ cần ra lệnh bằng lời nói

  • COBOL cũng từng hứa hẹn điều tương tự. Nó được quảng bá là ngôn ngữ dễ đọc với con người đến mức sẽ không còn cần lập trình viên nữa, nhưng rốt cuộc để chia nhỏ vấn đề và giải quyết nó thì con người vẫn phải tư duy như một lập trình viên. Nói cách khác, việc một ngôn ngữ thân thiện với con người không có nghĩa là lập trình viên sẽ biến mất
  • Lần này có lẽ chu kỳ của cơn sốt AI cũng sẽ lặp lại. Bây giờ hễ phê bình là bị đáp lại bằng kiểu "bạn không hiểu đâu", nhưng chẳng bao lâu nữa các vấn đề sẽ bùng ra. Đặc biệt là tình huống "AI tạo ra quá nhiều code đến mức cả con người lẫn AI đều không thể gánh nổi". Đến lúc đó lại sẽ xuất hiện pattern và anti-pattern, cùng những nhà tư vấn nói rằng họ có thể giải quyết việc đó
  • Vì AI nói và hiểu tiếng Anh nên độ rõ ràng của giao diện bị giảm đi. Nó mạnh như CLI, nhưng không rõ cách nào là hiệu quả. Vì vậy, điều quan trọng là phải ghi chép và chia sẻ "nên giao việc như thế nào để có kết quả tốt". Chỉ có điều không nên để nó lại biến chất thành kiểu ngành công nghiệp huấn luyện OOP một lần nữa
  • Đúng vậy. Nó sẽ lại xảy ra, và lần này còn nhanh hơn nhiều. Chu kỳ 10 năm theo thứ tự blogger → diễn giả → sách → tư vấn → tổ chức cấp chứng chỉ sẽ bị nén lại chỉ trong vài năm
  • Tôi không đồng ý với ý kiến cho rằng tiêu đề bài viết quá phức tạp. Nhưng vấn đề là sự hiểu lầm kiểu "cứ nói bằng lời là xong". Thực tế kết quả khác nhau một trời một vực tùy từng người. Cuối cùng bài học rút ra là "thói quen phát triển tốt cho con người cũng tốt cho AI". AI trông giống con người nhưng không phải con người. Vì vậy cần nhiều giải thích hơn

• Tôi muốn hỏi Simon — "review code nên làm thế nào trong một thế giới nơi code trở nên rẻ?"
  Các thành viên trong nhóm tiếp cận theo kiểu "chạy được là được rồi" mà không hiểu cấu trúc. Review ngày càng to ra, còn tôi thì trở thành nút thắt cổ chai. Tôi cũng từng nghĩ đến cách dùng AI reviewer làm người đại diện, nhưng tôi không thích việc cảm quan con người bị mất đi

  • Đây thực sự là một chủ đề rất thú vị. Khi tốc độ sinh code tăng lên thì review trở thành nút thắt cổ chai. Nếu code rẻ đi thì có thể hạ tiêu chuẩn review, nhưng cá nhân tôi lại muốn chất lượng tốt hơn. Đặc biệt kiểm tra bảo mật thì tuyệt đối không thể bỏ qua. Có lẽ sẽ cần một cách tiếp cận có hệ thống như đội bảo mật ở các tổ chức lớn
  • Nếu muốn dùng review dựa trên agent thì việc thiết lập ngữ cảnh là rất quan trọng. Nếu chạy vòng lặp kế hoạch → thực thi → test/sửa → review/refactor → tạo hướng dẫn QA, thì không chỉ code mà cả tài liệu và hướng dẫn test cũng cùng tiến hóa
  • "Chạy được là được rồi" không phải vấn đề kỹ thuật mà là vấn đề văn hóa tổ chức. Vẫn có những công ty coi trọng code dễ đọc. Điều đó thậm chí có thể trở thành lợi thế cạnh tranh
  • Tôi đầu tư vào tự động hóa phân tích tĩnh và động. Tôi tích cực dùng các công cụ chất lượng như luật lint tùy chỉnh, kiểm tra kiểu mạnh, và mutation testing. Chỉ dựa vào review thì chậm và kém hiệu quả, nên cốt lõi là tự động hóa phản hồi sớm
  • Thái độ như vậy không dễ thay đổi. Có khi chuyển sang một đội ngũ coi trọng chất lượng phần mềm còn tốt hơn

• Tôi chủ yếu dùng AI cho code boilerplate hoặc xử lý vấn đề về tài liệu
  Tôi cũng đã thử các tác vụ kiểu agent, nhưng đầu ra vẫn chưa đủ đáng tin. Trong khi đó có người nói rằng "giờ gần như không còn viết code nữa". Khoảng cách đó khá thú vị

  • Với tôi, nhiều khi tự viết code còn nhanh hơn AI. Quá trình lập kế hoạch, cho chạy và xác minh ngược lại còn chậm hơn. Nhưng refactor quy mô lớn thì AI nhanh hơn hẳn
  • Trong vài tháng gần đây, hiệu năng của agent đã tăng vọt. Giờ nó đã vượt qua mức tự động hoàn thành đơn giản và có thể hiện thực cả một tính năng hoàn chỉnh
  • Có thể giải thích điều này bằng sự khác biệt giữa những lập trình viên cảm thấy một kiểu "ghê ghê (eww)" khi nhìn code AI viết và những người không cảm thấy như vậy
  • Cuối cùng, tùy theo loại công việc mà sẽ có những trường hợp AI rất hợp và những trường hợp không hợp
  • Tôi cũng không thích kết quả đầu tiên, nhưng nếu chạy vòng review nhiều lần thì chất lượng tăng lên rõ rệt. Nếu để AI review lẫn nhau hoặc làm rõ tiêu chí test thì kết quả tốt hơn hẳn

• Gần đây tôi đang thử nghiệm vòng lặp coding kiểu agent
  Ví dụ, trong dự án fesh, mục tiêu là "nén binary Linux nhỏ hơn nữa". Vì đây là một bài toán có test rõ ràng nên rất phù hợp với vòng lặp AI
  Những điều tôi học được là:

  • Test harness là tất cả. Không có vòng lặp xác minh thì hướng đi sẽ lệch
  • Điều quan trọng là để AI thử nghiệm theo kiểu thăm dò
  • Cần để lại scratchpad .md giữa các phiên thì việc học mới được tiếp nối
  • Test thực sự rất quan trọng. AI thất bại theo những cách rất kỳ quặc nên phải tích cực tận dụng tạo test tự động
  • Nếu không có test thì không thể tin vào kết quả của vòng lặp. Quy trình xác minh mang tính quyết định là bắt buộc
  • Việc ghi tách riêng nhật ký quyết định và nhật ký từ chối là rất hữu ích. Đặc biệt rejections.md còn có giá trị hơn. Phải lưu lại "vì sao bỏ cách tiếp cận này" thì AI mới không lặp lại cùng một sai lầm
  • Trong tự động hóa trình duyệt cũng tương tự. Không chỉ xác minh chức năng mà còn phải thêm xác minh hành vi (trông có giống con người không) thì mới hữu ích. Và log .md nâng chất lượng của phiên tiếp theo lên đáng kể

• Tôi nghĩ phần về test nên đề cập đến vấn đề "bài test tự hoàn thành lời tiên tri" do LLM tạo ra
  Có trường hợp test thực tế không xác minh gì cả, hoặc thậm chí vượt qua bằng giá trị hardcode. Con người phải dẫn dắt AI theo thói quen test nghiêm ngặt

  • Tôi tò mò về ví dụ cụ thể. Có vẻ đây không phải lỗi logic đơn giản mà là loại test nhìn bề ngoài có vẻ ổn nhưng thực chất vô nghĩa
  • Test tệ còn nguy hiểm hơn là không có test. Một khi niềm tin bị phá vỡ thì sự tin cậy vào cả test suite cũng sụp đổ
  • Vì vậy mutation testing rất quan trọng. Nếu code bị biến đổi mà test vẫn pass thì đó là test tệ
  • Có thể bảo AI cố ý thay đổi một phần code rồi kiểm tra xem test có fail không. Nếu không fail thì đó là test vô dụng
  • Tất nhiên, ngay cả với con người thì cũng không dễ buộc họ viết kiểu test này

• Mỗi khi một thế hệ LLM mới ra đời, tôi có cảm giác mọi bài học cũ đều bị vô hiệu hóa hoàn toàn
  Những cấu trúc phức tạp như LangChain vốn được tạo ra để lách giới hạn của các model đời cũ đã trở nên không cần thiết sau GPT-3.5. Chẳng bao lâu nữa có lẽ chỉ với một agent duy nhất cũng đủ xử lý mọi thứ

  • Vì thế tôi đang cố gắng tổng hợp những pattern không phụ thuộc vào phiên bản model. Ví dụ red/green TDD có thể sớm được model tự làm lấy, nhưng bản thân khái niệm này vẫn hữu ích
  • Cuối cùng mọi thứ có thể hội tụ về dạng như ClaudeVM
    Xem bài liên quan

• Có một điểm thường bị bỏ sót trong các cuộc thảo luận về agent engineering
  Phần lớn bài học được nói đến như chân lý phổ quát, nhưng trên thực tế chúng thay đổi tùy theo quy mô đội ngũ, độ trưởng thành của codebase, mức độ test và khả năng chấp nhận rủi ro. Điều quan trọng là phải nói rõ "khi nào pattern này có hiệu quả"

  • Vì thế tôi không viết thành sách mà tổng hợp pattern dưới dạng website. Tôi dự định sẽ tiếp tục cập nhật và ghi rõ phạm vi áp dụng
  • Khi làm tư vấn và xử lý nhiều codebase khác nhau, bạn sẽ thấy hiệu năng của Claude Code thay đổi cực đoan tùy vào chất lượng codebase. Những dự án có kiểu mạnh và test thì gần như hoạt động hoàn hảo, nhưng trong môi trường JavaScript lỏng lẻo thì không tốt lắm
  • Dù vậy, một số pattern vẫn mang tính phổ quát. Ví dụ, việc có một source of truth độc lập (harness) là đúng trong mọi trường hợp. Các công cụ như showboat, rodney đang hỗ trợ điều đó

• Dạo này các "framework đội agent" mọc ra hàng chục cái mỗi ngày
  Đây là một giai đoạn thử nghiệm hỗn loạn giống như kỹ nghệ phần mềm thời kỳ đầu. Nhưng rồi cuối cùng một vài pattern sẽ trở thành chuẩn.
  Đội của chúng tôi thấy cách tiếp cận như một đội ngũ con người là hiệu quả — trước tiên viết đặc tả sản phẩm (spec), tinh chỉnh nó bằng AI, rồi dựa trên đó chuyển sang luồng agent phân vai rõ ràng

• Hôm nay tôi đã giảng về sự tiến hóa của kiến trúc CPU·GPU trong lớp đại học
  Trước đây nhờ Moore's Law mà phần cứng giải quyết được mọi thứ, nhưng giờ tính song song mới là cốt lõi.
  Khái niệm "code là rẻ" mà Simon nói đến cũng là một sự chuyển đổi mô hình tương tự như vậy.
  Cũng như trong thời đại phần cứng song song, code hiệu quả đã thay đổi hoàn toàn, thì trong thời đại AI bản thân quy trình phát triển cũng sẽ thay đổi. Người hiểu điều này trước sẽ giành được lợi thế gấp 10 đến 100 lần

• Trong nhóm của chúng tôi, "vòng lặp có chèn bước xác minh của con người ở giữa" là thực tế nhất
  Agent hoàn toàn tự chủ thường vẫn pass test nhưng lại phá vỡ các bất biến ngầm định.
  Vì vậy chúng tôi để con người can thiệp ngay trước những quyết định không thể đảo ngược.
  Tuy vậy, khiến AI hiểu được "điều gì là không thể đảo ngược" lại là một bài toán khác.
  Ngoài những tài liệu như CLAUDE.md, chúng tôi đang tìm một cách có hệ thống để truyền đạt các quy tắc ngầm của codebase