- Bài viết trình bày các nguyên tắc context engineering và quy trình làm việc thực tiễn để đạt hiệu quả với các mô hình ngôn ngữ mới nhất trong codebase production quy mô lớn
- Trọng tâm là Frequent Intentional Compaction, tức cấu trúc hóa và nén ngữ cảnh xuyên suốt toàn bộ quá trình phát triển để ổn định chất lượng phán đoán và trajectory tiến hành của agent
- Với 3 giai đoạn nghiên cứu → lập kế hoạch → triển khai, bài viết tạo ra đầu ra nghiên cứu trước và tài liệu kế hoạch, đồng thời đặt khâu review của con người vào các điểm đòn bẩy cao để giảm slop và làm lại
- Bài viết chứng minh cách này hiệu quả cả trong môi trường brownfield thông qua các ví dụ thực tế trên BAML nền Rust với 300.000 LOC, nơi đã hoàn thành nhanh các bài toán phức tạp như sửa bug và hỗ trợ cancellation/WASM
- Kết luận là AI coding không phải đồ chơi mà là một dạng thủ công kỹ nghệ tinh vi, và chuyển đổi quy trình/văn hóa ở cấp đội ngũ mới là chìa khóa tạo lợi thế cạnh tranh
Bối cảnh: giới hạn của AI trong codebase phức tạp và vấn đề đặt ra
- Phần lớn lập trình viên đều biết rõ rằng công cụ AI coding trong codebase production thực tế thường không hoạt động tốt như kỳ vọng
- Có các nghiên cứu cho thấy công cụ AI coding làm giảm năng suất trong codebase lớn và với bài toán phức tạp
- Nghiên cứu của Stanford cho thấy một phần đáng kể lượng code do AI thêm vào thực chất là gây ra công việc lặp lại, vì sau đó lại phải sửa phần code yếu kém mà AI từng tạo trước đó
- AI coding agent có hiệu quả với dự án mới hoặc thay đổi nhỏ, nhưng trong codebase lớn thì ngược lại có thể làm giảm năng suất của lập trình viên
- Vì vậy phản ứng phổ biến tại hiện trường là thái độ thận trọng kiểu “bây giờ vẫn khó, đợi mô hình thông minh hơn nữa xuất hiện”
- Tuy nhiên, khi áp dụng context engineering vào một codebase Rust lớn 300.000 LOC, tác giả nhận thấy ngay cả với các mô hình hiện có vẫn có thể vượt mặt mức thị trường cả về năng suất lẫn chất lượng
- Cốt lõi là nén có chủ đích thường xuyên (frequent intentional compaction), tức luôn biến ngữ cảnh cung cấp cho AI thành dạng có cấu trúc và được quản lý trong suốt quá trình phát triển
- Rốt cuộc, ‘AI coding’ là một lĩnh vực đòi hỏi tay nghề kỹ thuật thủ công
Nền tảng tư tưởng: “Specs are the new code” và nghiên cứu về năng suất
- Hai bài trình bày tại AI Engineer 2025 đã thúc đẩy sự thay đổi trong cách tư duy
- Trong bài nói Sean Grove's "Specs are the new code", ông cho rằng hãy từ bỏ prompt hội thoại và lưu giữ spec như code
- Thói quen bỏ prompt đi và chỉ commit code đầu ra được ví như check-in chỉ binary mà không có source
- Nghiên cứu của Stanford về tác động của AI tới năng suất lập trình viên gợi ý rằng dù AI có thể tăng đầu ra ngắn hạn, suy giảm chất lượng và làm lại có thể làm giảm hiệu quả ròng
- Phân tích commit của 100.000 lập trình viên cho thấy hiện tượng công cụ AI làm tăng khối lượng làm lại, từ đó bù trừ phần lợi ích năng suất
- Nghiên cứu đưa ra nhận định rằng AI hiệu quả trong greenfield nhưng thường phản tác dụng trong brownfield và công việc độ khó cao
Nguyên tắc: khái niệm Frequent Intentional Compaction
- Quản lý context window luôn ở mức 40–60%, và áp dụng chiến lược nén liên tục để giảm tối đa tình trạng dư thừa nội dung, thiếu sót và thông tin sai
- Đối tượng cần nén là nhiễu như log tìm file, truy vết luồng code, lịch sử chỉnh sửa, log test/build, JSON lớn
- Đầu ra của từng giai đoạn được lưu dưới dạng artifact có cấu trúc để đảm bảo chất lượng input cho lượt tiếp theo
- Ví dụ: tạo tài liệu progress ghi lại tóm tắt tiến độ, mục tiêu và cách tiếp cận, các bước đã hoàn thành, cùng điểm thất bại hiện tại
Quy trình làm việc: Research → Plan → Implement
- Ở giai đoạn Research, tác giả khảo sát các file liên quan, luồng xử lý và giả thuyết nguyên nhân để tạo ra tài liệu nghiên cứu tóm tắt
- Khi cần, có thể dùng sub-agent để khám phá phạm vi và tóm tắt trong một context mới, sạch
- Ở giai đoạn Plan, tác giả viết kế hoạch triển khai mô tả chi tiết các file cần sửa, cách thay đổi, cùng quy trình xác minh và kiểm thử
- Kế hoạch được dùng như điểm review đòn bẩy cao hơn cả code review
- Ở giai đoạn Implement, kế hoạch được thực thi từng bước; sau mỗi bước xác minh, trạng thái lại được nén trở lại vào tài liệu kế hoạch và tích lũy dần
- Với tác vụ phức tạp, hệ thống sẽ sắp xếp lại context tại mỗi điểm hợp dòng theo từng giai đoạn
Anti-pattern và nâng cấp dần dần
- Cách tiếp cận ngây thơ trong luồng chat dễ khiến context bị nhiễm bẩn, dẫn tới vòng lặp xin lỗi hoặc đi chệch hướng
- Cách tốt hơn một chút là reset session và thêm “prompt bổ sung chỉ thị”, nhưng vẫn thiếu kiểm soát nhiễu căn bản
- Nén có chủ đích là cách tốt hơn để tái dựng ngữ cảnh bằng cách dùng tóm tắt tiến độ (file) và commit message
- Bài viết còn đưa ra ví dụ định dạng đầu ra nén lý tưởng, với mục tiêu tối ưu độ chính xác/độ đầy đủ/kích thước/trajectory
Góc nhìn kỹ thuật về tối ưu context
- Vì LLM là hàm không trạng thái, chất lượng phụ thuộc hoàn toàn vào input context
- Thứ tự tình huống tệ nhất là thông tin sai > thiếu sót > quá nhiều nhiễu
- Context càng nhỏ càng có lợi, nên điểm mấu chốt là nén để đạt độ nhất quán tối đa với input tối thiểu
- Bài viết cũng nhắc tới các góc nhìn thay thế như chiến lược chạy agent dạng vòng lặp đơn giản (ví dụ quy trình “Ralph”)
Vai trò của sub-agent: không phải đóng vai con người mà là kiểm soát context
- Sub-agent thực hiện tìm kiếm/tóm tắt/sắp xếp trong context độc lập để giữ cửa sổ của agent chính luôn sạch
- Phản hồi lý tưởng là đầu ra nén có cấu trúc với mục tiêu/hiện trạng/lộ trình
- Thông qua sub-agent, chi phí khám phá được cục bộ hóa, đồng thời tăng mức độ tập trung cho context của tác vụ chính
Trường hợp 1: sửa bug BAML và vượt qua ngay trong một lần
- Bài viết nêu ví dụ một người mới vào đã gửi và được duyệt PR sửa bug trong vài giờ trên BAML với 300.000 LOC Rust
- Chất lượng được nâng lên bằng cách chạy tài liệu nghiên cứu nhiều lần, sau đó triển khai dựa trên kế hoạch cuối cùng để vượt qua ngay từ lần đầu
- Cách làm này đáp ứng được nhiều mục tiêu về phù hợp brownfield, loại bỏ slop và giữ vững alignment
Trường hợp 2: thêm hỗ trợ cancellation/WASM 35k LOC cho BAML
- Hai người đã trình diễn một thay đổi quy mô lớn khi thêm tính năng cancellation và hỗ trợ biên dịch WASM chỉ trong 7 giờ
- Theo ước tính của đội, mỗi phần vốn mất 3–5 ngày đã được rút ngắn nhờ pipeline nghiên cứu/lập kế hoạch/triển khai
- Một số PR được merge ngay, số khác vẫn mở ở mức demo hoạt động, qua đó chứng minh khả năng giải quyết bài toán độ khó cao
Giới hạn và bài học từ thất bại
- Nỗ lực loại bỏ phụ thuộc Hadoop trong Parquet Java đã thất bại vì chưa đào đủ sâu vào cây phụ thuộc
- Kết luận là không phải mọi vấn đề đều có thể giải bằng 7 giờ prompt engineering, và vẫn cần sự tham gia của chuyên gia domain
- Đòn bẩy của review con người tăng dần theo thứ tự nghiên cứu > kế hoạch > code, và chỉ một dòng nghiên cứu sai cũng có thể khuếch đại thành hàng nghìn dòng lỗi
Ưu tiên tài liệu để giữ alignment trong đội ngũ
- Bài viết đưa ra quan điểm rằng bản chất của code review là duy trì mental alignment
- Chuỗi PR lớn có thể làm đội ngũ mất hiểu biết về sản phẩm và gia tăng bất an, nên việc dùng spec/kế hoạch/nghiên cứu giúp giảm chi phí alignment
- Kỹ sư có thể đọc một tài liệu kế hoạch 200 dòng thường xuyên và chính xác hơn nhiều so với 2.000 dòng code
- Ngay cả khi xử lý issue ở khu vực xa lạ, research prompt vẫn đóng vai trò hướng dẫn nhanh
Tổng kết và cấu trúc chi phí
- Bài viết khẳng định đã đáp ứng toàn bộ mục tiêu: tương thích brownfield, giải quyết vấn đề phức tạp, giảm slop, giữ alignment đội ngũ
- Xét về chi phí vận hành, một đội 3 người đang chạy với chi phí token Opus khoảng $12k/tháng
- Dù vẫn có ngoại lệ, tác giả nhấn mạnh đây nhìn chung là một phương pháp luận có hiệu quả thực tế
Những thay đổi sắp tới và sản phẩm hóa
- Coding agent rồi sẽ trở thành hàng hóa phổ thông, còn chuyển đổi tổ chức và workflow mới là bài toán thực sự khó
- Trong một thế giới nơi AI viết 99% code, việc đại tu toàn bộ cách cộng tác sẽ là điểm phân tách năng lực cạnh tranh
- Để hỗ trợ điều này, tác giả công bố bản private beta của công cụ “post-IDE” mang tên CodeLayer
- Công cụ này hướng tới Superhuman for Claude Code và tăng tốc phát triển agentic theo hướng spec-first
3 bình luận
Kết thúc quảng cáo...
Kết lại bằng phần giới thiệu về dịch vụ có tên CodeLayer...
Ý kiến Hacker News
Đây là một bài đọc thú vị và có vài ý tưởng mới mẻ. Nhưng tôi nghĩ những khẳng định kiểu này có vấn đề. Sean dự đoán rằng AI sẽ tiến bộ đến mức trong tương lai, tài liệu đặc tả sẽ trở thành mã nguồn thực sự. Anh ấy nói rằng trong vòng 2 năm tới, tần suất con người mở file Python trong IDE sẽ ngang với tần suất ngày nay người ta mở hex editor để xem assembly. Ban đầu anh ấy cũng thấy không thoải mái, nhưng rồi chấp nhận cách làm tập trung vào test thay vì đọc từng dòng code trong PR, và xem đặc tả là nguồn chân lý thực sự. Tuy vậy, vì vấn đề tính không xác định (
non-determinism) của LLM, dù có viết prompt tốt đến đâu cũng không thể luôn kỳ vọng một cách triển khai hợp lý. Compiler thì có tính xác định, và dù có bug vẫn có thể tái hiện và debug được, còn LLM thì không như vậyNgay cả khi làm việc với lập trình viên junior thì việc triển khai ít nhiều vẫn mang tính xác định. Nhưng với mô hình AI, dù chỉ dẫn rõ ràng thì vẫn liên tục cho ra những cách triển khai hoàn toàn khác nhau
Điều thú vị là thật ra bản thân tài liệu đặc tả cũng đã mang tính không xác định rồi. Nếu cố viết requirements bằng tiếng Anh sao cho không ai có thể hiểu sai, rốt cuộc nó sẽ biến thành một ngôn ngữ lập trình
Tôi đồng ý với lo ngại rằng “prompt có thể hoàn hảo, nhưng cũng không có gì đảm bảo LLM sẽ chuyển nó thành một triển khai hợp lý”. Thậm chí prompt viết bằng ngôn ngữ tự nhiên về bản chất thường mơ hồ và không hoàn chỉnh. Vì vậy nó là hướng đi tốt ở những nơi cần kết quả sáng tạo, nhưng nếu ngôn ngữ tự nhiên thực sự phù hợp để định nghĩa yêu cầu phần mềm thì ngành kỹ nghệ phần mềm đã giải quyết chuyện này từ vài chục năm trước rồi. Tôi từng rất hào hứng với LLM, nhưng nghĩ rằng dùng nó để giải quyết mọi vấn đề là hơi quá. Với đặc tả yêu cầu, nó tạo cảm giác giống những hệ thống hình thức và các nỗ lực kiểm chứng toán học ngày xưa, nhưng ở cực đối diện. Dù chuyện này có thể chỉ thành công một phần rồi thất bại, tôi vẫn xem đây là một thử nghiệm có thể mang lại góc nhìn mới về phát triển phần mềm. Ở một số lĩnh vực nó sẽ tạo ra giá trị thật, còn ở nơi khác có thể bị vứt bỏ hoàn toàn. Thời đại thật thú vị
Thực ra cũng hiếm khi người ta viết được đặc tả kỹ thuật hay tài liệu một cách rõ ràng và chi tiết. Mà dù có, tôi cũng không nghĩ chuyện đó sẽ trở nên phổ biến trong vòng 2 năm. Một technical writer thực sự hiểu sâu về kỹ nghệ phần mềm mà lại hài lòng với việc không xem code và chỉ prompt cho AI agent thôi sao? Tôi không đồng ý. Nó khá giống kiểu tư duy “kỹ sư xem con người như máy móc” điển hình
Lập luận rằng “nhờ compiler mà không cần mở hex editor để xem assembly mỗi lần build” cũng đúng là nhờ công cụ tốt hơn, nhưng trong lĩnh vực nghiên cứu khoa học HPC, người ta thường vẫn mổ xẻ assembly bằng Intel VTune hoặc công cụ tương tự để kiểm tra xem compiler có vectorize đúng các vòng lặp quan trọng hay không
Tôi đã thử dùng kiểu này trên hai codebase khác nhau. Một là repo monolithic apache airflow cỡ lớn khoảng 500 nghìn dòng, và một cái khác là dự án side project cá nhân làm mới từ đầu bằng flutter. Tôi gần như không biết gì về flutter và dart. Dù vậy tôi vẫn cảm nhận được cách này có hiệu quả. Với dự án greenfield, gần như chỉ cần chạy
/create_planlà đủ và có thể tận dụng toàn bộ hỗ trợ của agent. Điều quan trọng là phải review kỹ các tài liệu AI tạo ra. Chỉ cần tự kiểm tra xem nó có xử lý các edge case mà tôi lo hoặc bỏ sót không, và lựa chọn kỹ thuật có hợp lý không. Ví dụ, tôi có thể nhận ra ngay nếu nó đưa ra quyết định sai như phá vỡ pattern sqlite rồi khuyên dùng postgres. Thông thường tôi cũng có thể chat trực tiếp với agent để chỉnh plan ngay. Ở công ty thì tôi phải dùng GitHub Copilot nên cần viết prompt hơi khác, nhưng việc compaction có chủ đích giữa các bước thì tôi vẫn làm. Copilot không hỗ trợ sub-agent như Claude Code, nhưng năng suất nhìn chung vẫn được giữ ổn.Tôi cũng muốn chia sẻ một trải nghiệm cá nhân. Ngay trước thời đại AI hỗ trợ code, tôi từng trầm cảm nặng vì cảm thấy công việc của mình ngày càng quá tẻ nhạt. Do phải xử lý nhiều repo, nhiều team và đủ kiểu tính cách con người, làm việc với codebase lớn lúc nào cũng đầy việc vặt. Điều tôi thích nhất ở AI coding là nó xử lý mượt mà những việc lặt vặt ấy. Tôi thấy rất có ý nghĩa khi tạo ra thứ gì đó hoạt động tốt, nhưng niềm vui đó cứ liên tục bị chặn lại bởi các việc linh tinh. Giờ thì tôi đều đặn tạo ra kết quả tốt và bản thân cũng cảm thấy tự hào hơn
Tôi đã tạo một package dùng khi làm việc với codebase lớn: [GitHub.com/iambateman/speedrun]. Trước hết, nhập mô tả tính năng bằng
/featurethì nó bắt đầu phân tích codebase và đặt câu hỏi. Khi tôi trả lời, nó sẽ viết một kế hoạch ở dạng markdown. Trong quá trình đó sẽ sinh ra 8–10 file markdown, chứa nội dung cần làm và cả ví dụ code. Tiếp theo là giai đoạn “code critic”, cố tìm lỗi nhưng thật ra 60% là sai. Tôi sẽ lọc bỏ những lỗi vớ vẩn trong phản hồi đó. Đến lúc này tôi sẽ có một thư mục gọn gàng chứa mô tả tính năng và những thay đổi mình muốn. Giờ chỉ cần bảo Claude Code “tiến hành” là nó bắt đầu làm theo từng bước. Cách này giúp tránh bị chệch hướng và khiến tôi tự tin hơn vào kết quả. Tôi dùng workflow này vài lần mỗi ngày cho các công việc lớn, còn với việc tương đối cụ thể thì chỉ dùng Claude code bình thường. Tôi thấy đây là một workflow khá hiệu quảTôi hoàn toàn không hiểu vì sao người ta lại muốn đi qua một quy trình phức tạp như vậy. Tôi nghĩ code kiểu bình thường, chỉ tham khảo LLM một chút, sẽ năng suất hơn cách này
Vấn đề lớn khi dùng LLM cho codebase lớn là nó lặp lại cùng một sai lầm. Tôi tò mò không biết bạn theo dõi liên tục các quyết định liên quan đến kiến trúc theo ngữ cảnh của từng task như thế nào
Trông thật tuyệt. Có một bước pseudo code ở giữa, nên tôi muốn hỏi liệu việc định nghĩa workflow hoặc quy trình từ trước có thực sự hữu ích không. Ngoài ra tôi từng nghe nói việc giữ mỗi file dưới 100 dòng là quan trọng, không biết bạn có cảm thấy tương tự không
Bài này như một cái time capsule ghi lại đúng khoảnh khắc tôi hoàn toàn bỏ cuộc với việc quản lý context trong Claude code. Tôi đã tạo đặc tả riêng theo từng thư mục cho từng phần code và ghi log theo từng tính năng. Tôi quản lý nhiều subsystem của API server bằng Python như tài khoản, thông báo, đăng ký, v.v. Khi mọi thứ trở nên phức tạp hơn, Claude không còn nắm được business logic một cách đúng đắn và việc quản lý context trở nên cực kỳ khó khăn. Ví dụ, chỉ để làm một hệ thống RBAC đơn giản, tôi phải đưa cả sơ đồ UML và ví dụ mô tả quan hệ account-profile thì nó mới hoạt động gần với kỳ vọng
research_codebase.mdtrước. Nỗi băn khoăn lớn nhất là: “Nếu chúng ta vừa nhận codebase này mà còn chưa hiểu cấu trúc của nó, thì làm sao giao việc cho model được?” Với code chủ yếu do AI viết, có hai vấn đề. 1) Nếu chưa quen code thì cần một giai đoạn research để nhanh chóng nắm được luồng và tính năng 2) Review PR khổng lồ rất đau đớn, trong khi plan giúp cấu trúc hóa những gì đã thay đổi và lý do thay đổi. Nhân tiện, Mitchell đã khen thread sharing của ampcode hết lời, và đây là một giải pháp tốt cho #2 [https://x.com/mitchellh/status/1963277478795026484]Có vô số tuyên bố và khẳng định về việc sử dụng AI, nhưng hầu như không ai công khai quy trình hay prompt cụ thể. Chém gió cho hay thì dễ, còn nếu thật sự hữu ích thì phải có log prompt. Các commit do AI tạo ra nên kèm cả log về những prompt nào đã được áp dụng, để người ta có thể lần theo quá trình viết code như khi đọc commit log
Tác giả khoe rằng đã điều tra và triển khai 35K dòng code trong 7 giờ, nhưng thực tế lại có 40 commit trong 7 ngày. Tự hỏi không biết là làm mỗi ngày một tiếng hay sao. Và buồn cười là một trong những commit gần đây nhất lại là “bỏ qua một số test”
Có câu thế này: “Vài tuần sau, cùng với @hellovai, tôi đã thêm 35k LOC vào BAML để hỗ trợ cancel, compile WASM và các tính năng mới khác. Đội ngũ hiện tại ước tính mỗi tính năng sẽ mất 3–5 ngày.” Vậy ý là họ nghĩ một kỹ sư senior có thể viết 4–6KLOC mỗi ngày à? (trước thời genAI?)
Điều bị bỏ qua ở đây là nếu là kỹ sư senior thì thực ra họ có lẽ chỉ cần giải quyết bằng 2KLOC
Và thực tế tác giả cũng thừa nhận ở chỗ khác rằng công việc này mất một tuần https://news.ycombinator.com/item?id=45351546
Tôi hoàn toàn đồng ý với đoạn “Ban đầu rất khó chịu, nhưng rồi tôi bỏ việc đọc toàn bộ code trong PR và chỉ kiểm tra test thật kỹ. Đặc tả đã trở thành source thực sự”. Tôi cảm thấy vai trò của chúng ta đang chuyển từ trực tiếp viết chi tiết triển khai sang định nghĩa và xác minh hành vi. Gần đây tôi cần thêm recursive upload vào Python operator S3-to-SFTP, trong đó có nhiều cờ đường dẫn phức tạp. Quy trình của tôi như sau - 1) trích xuất hành vi hiện tại thành một đặc tả rõ ràng (tức là thông qua việc làm cho unit test pass) 2) mở rộng đặc tả đó cho tính năng mới 3) đưa bài toán và test cho coding agent. Cuối cùng tôi nhận ra mình hoàn toàn không cần hiểu code cũ. Điều tôi tập trung chỉ là code mới có tuân theo đặc tả hay không. Trong tương lai, giá trị của chúng ta sẽ nằm ở việc xác minh tính đúng đắn, còn code thực tế sẽ là chi tiết để agent tự lo
Tôi đồng ý với ý “vai trò của chúng ta đang chuyển từ việc viết chi tiết triển khai sang định nghĩa và xác minh hành vi”. Thực ra có khi đây vốn đã là công việc chính rồi. Nhờ ngôn ngữ bậc cao, compiler và các lớp trừu tượng khác, thời gian dành cho việc viết chi tiết triển khai vốn đang giảm đều
Với ý “tôi chỉ tập trung vào việc code mới có hoạt động theo đặc tả hay không”, tôi liên tưởng đến Định luật Postel (
Postel's Law). Hành vi quan sát được của một hệ thống được dùng rộng rãi thường trở thành giao diện công khai và đặc tả trên thực tế của chính hệ thống đó, bao gồm cả mọi điểm lệch lạc và bug triển khai. Cũng cần kiểm tra phía client của code xem nó có thật sự tuân theo đặc tả không, và nếu có sai lệch thì phải phát hiện rồi xử lýClaude Plays Pokemon cũng cho thấy điều tương tự. AI yếu trong việc đánh giá xem thứ gì đó có đang hoạt động tốt hay không. Thay vào đó nó cứ quanh quẩn lặp đi lặp lại. Nhưng nếu con người thỉnh thoảng chỉnh hướng thì đây có thể là một tổ hợp rất mạnh
Nếu thật sự cố định nghĩa mọi khía cạnh của hành vi, thì cuối cùng bạn gần như đang viết toàn bộ code rồi. Nếu có bất kỳ dòng nào trong PR mà bạn không thể hiểu ngay ý nghĩa của nó, thì có lẽ bạn vẫn chưa định nghĩa đủ đầy hành vi tổng thể
Có ý kiến rằng “trong vài năm tới, tài liệu đặc tả sẽ trở thành code thực sự, và gần như sẽ không còn phải mở file Python nữa”. Muốn chuyện này thành hiện thực thì AI sinh code phải đúng tới 99,9% và gần như không có hallucination. Lý do chúng ta tin compiler và không xem mã assembly là vì tin rằng đầu ra luôn nhất quán và không sai (thỉnh thoảng có bug hoặc vấn đề tối ưu hóa nhưng hiếm và thường được sửa rất nhanh). Còn hiện tại, nếu code do AI sinh ra hoạt động khác với đặc tả — tức mã nguồn ban đầu — thì cuối cùng con người vẫn phải quay lại sửa
Mẹo chia nhỏ phần triển khai để xử lý hoặc review theo từng đơn vị công việc thật sự rất ấn tượng.
ARCHITECTURE.md, còn với module lớn thì nên cóDESIGN.mdCLAUDE-feature.mdđể ghi kế hoạch triển khai và thông tin hỗ trợ như những thành phần có thể truy cập trong codebase. Nếu tôi thấy file còn thiếu gì hoặc chỗ nào giải thích gây rối thì sẽ bổ sung bằng prompt tiếp theo. Giữa các prompt tương đối lớn tôi dùng/reset, rồi bắt nó tham chiếu lại tài liệu và cải thiện lặp đi lặp lại. Khi triển khai thật tôi lại/resetthêm một lần nữa, rồi ở mỗi checkpoint của kế hoạch lại cho/resetvà cập nhật tiến độ vào tài liệu. Nhìn chung nó hoạt động đủ ổn, nhưng ở công ty thì tôi không chắc mình có tin tưởng đến mức đó không