- Một phương pháp buộc công cụ lập trình AI phải lập kế hoạch trước khi viết mã, giúp ngăn chặn triển khai sai và tăng tốc độ phát triển
- Áp dụng 8 chiến lược lập kế hoạch theo mức độ khó, trong đó mỗi chiến lược có cấu trúc các tác nhân chuyên biệt nghiên cứu song song rồi nhà phát triển đưa ra phán đoán và quyết định
- Mỗi chiến lược bao gồm tái hiện lỗi, tìm kiếm best practices, phân tích codebase hiện có, điều tra lịch sử git, v.v.; đồng thời các sở thích và mẫu mà tác nhân học được sẽ tự động được tích lũy
- Có thể cài hệ thống mã nguồn mở này vào Claude Code, hoặc bắt đầu từ một tính năng đơn lẻ để dần huấn luyện cho AI cách suy nghĩ của nhà phát triển
Cách phát triển lấy kế hoạch AI làm trung tâm
- Giới thiệu cách tiếp cận khiến AI phải lập kế hoạch trước khi viết mã
- Cách này không chỉ viết mã đơn thuần mà còn tăng tốc độ triển khai tính năng và giảm lỗi
- Ví dụ là quá trình phát triển tính năng “email bankruptcy” của ứng dụng quản lý email Cora
- Khi triển khai tính năng dọn 53.000 email mà không làm mất các thư quan trọng, tác nhân nghiên cứu AI đã thực hiện phân tích trước
- Nhờ đó phát hiện trước giới hạn 2.000 mục của Gmail, timeout hệ thống và vấn đề thời gian chờ của người dùng, tránh được triển khai sai
8 chiến lược lập kế hoạch
Chiến lược 1: Tái hiện và tài liệu hóa lỗi
- Mục đích: tái hiện lỗi trước khi sửa và tạo hướng dẫn từng bước
- Thời điểm dùng: Fidelity 1~2, đặc biệt khi sửa lỗi
- Ngay sau khi phát hành tính năng email bankruptcy, phát sinh sự cố khiến 19 người dùng bị kẹt ở trạng thái thất bại tác vụ
- Sau khi rà soát log AppSignal để chẩn đoán, phát hiện lỗi giới hạn tốc độ của Gmail đang bị bỏ qua trên production
- Khi một batch thất bại thì toàn bộ tác vụ dừng lại, nhưng không thông báo cho người dùng, nên họ chỉ thấy spinner tải vô hạn
- Trong quá trình tái hiện, phát hiện cần có xử lý theo batch và khả năng tiếp tục tác vụ, xác nhận rằng chỉ retry đơn thuần là không đủ
- Hiệu ứng lãi kép: thêm vào checklist của tác nhân @kieran-rails-reviewer mục “đối với background job gọi API bên ngoài, có xử lý rate limit không, có retry không, có để lại trạng thái dở dang không”
Chiến lược 2: Nghiên cứu best practices
- Mục đích: tìm trên web các trường hợp giải quyết vấn đề tương tự
- Thời điểm dùng: mọi mức độ khó, đặc biệt với các pattern còn lạ
- Khi nâng cấp một gem đang chậm 2 phiên bản, tác nhân tìm kiếm “lộ trình nâng cấp từ phiên bản X lên Y”, “các breaking change giữa các phiên bản”, “các vấn đề migration phổ biến”
- Tìm thấy hướng dẫn nâng cấp chính thức và 3 bài blog của các kỹ sư đã làm đúng đợt nâng cấp đó
- 3 phút nghiên cứu giúp tránh hàng giờ debug kiểu thử-sai
- Cũng áp dụng được cho các quyết định phi kỹ thuật: “best practices cho các tier giá SaaS”, “nội dung chuyển đổi cho email drip campaign”, “chiến lược retry cho background job”, v.v.
- Hiệu ứng lãi kép: khi phát hiện pattern hữu ích, tự động lưu vào file `docs/*.md`; lần sau gặp câu hỏi tương tự sẽ kiểm tra trước khi tìm trên web
Chiến lược 3: Khảo sát codebase
- Mục đích: tìm các pattern tương tự trong mã hiện có
- Thời điểm dùng: mọi công việc có khả năng trùng lặp với chức năng hiện hữu
- Trước khi thêm event tracking cho một tính năng mới, tác nhân tìm trong codebase: “hiện đang xử lý event tracking như thế nào?”, “pattern gọi analytics là gì?”, “gửi event ở đâu?”
- Phát hiện một hệ thống tracking sẵn có thậm chí còn có helper method (chính tác giả đã quên mất)
- Nếu AI không tham chiếu codebase, nó sẽ cố tạo lại từ đầu
- Thay vì tạo hệ thống tracking mới, giải quyết bằng cách mở rộng pattern hiện có, tránh xây thêm một hệ thống thứ hai không tương thích
- Hiệu ứng lãi kép: tạo tác nhân “@event-tracking-expert”, tự động chạy khi lập kế hoạch cho mọi tính năng cần tracking
Chiến lược 4: Khảo sát mã nguồn thư viện
- Mục đích: đọc trực tiếp mã nguồn của các package và gem đã cài
- Thời điểm dùng: khi dùng thư viện thay đổi nhanh hoặc tài liệu còn thiếu
- Gem RubyLLM liên tục bổ sung model, tham số và tính năng mới nhưng tài liệu luôn chậm hơn
- Tác nhân phân tích mã nguồn RubyLLM: “các tùy chọn model khả dụng là gì?”, “có thể truyền tham số nào?”, “các tính năng chưa được tài liệu hóa trong bản mới nhất là gì?”
- Nó cung cấp: “streaming được thêm ở phiên bản 1.9 nhưng chưa được tài liệu hóa; đây là tên tham số và ví dụ sử dụng trong test suite”
- Hiệu ứng lãi kép: mỗi lần cập nhật dependency, tri thức cũng tự cập nhật theo, không còn làm việc với thông tin cũ
Chiến lược 5: Nghiên cứu lịch sử git
- Mục đích: phân tích lịch sử commit để hiểu ý đồ của các quyết định trong quá khứ
- Thời điểm dùng: refactor, tiếp tục công việc dang dở, hoặc khi cần hiểu “vì sao”
- Phát hiện đang dùng EmailClassifier bản cũ, trước khi thử nâng cấp đã tra lịch sử git: “vì sao đang dùng v1?”, “đã từng thử nâng cấp lên v2 chưa?”
- Tìm thấy PR của một thành viên khác từ 3 tháng trước: sau khi nâng lên v2 thì email trong inbox bị chuyển vào archive, còn email archive lại đi vào inbox
- Trong phần thảo luận PR có ghi lại lý do chi tiết và lịch sử rollback có chủ đích
- Hiệu ứng lãi kép: trí nhớ tổ chức được lưu giữ và có thể tìm kiếm; thành viên mới có thể kế thừa logic của các quyết định trước đây
Chiến lược 6: Làm prototype để làm rõ yêu cầu
- Mục đích: làm prototype nhanh trong môi trường riêng để làm rõ yêu cầu
- Thời điểm dùng: Fidelity 3, khi UX chưa chắc chắn, hoặc công việc mang tính khám phá
- Khi thiết kế lại giao diện Brief email, đã tạo 5 prototype bố cục khác nhau trong Claude, mỗi cái mất 5 phút
- Có thể tự bấm thử để nhận ra điểm bất tiện, rồi đưa các phiên bản tối ưu cho một số người dùng xem
- Một phản hồi của người dùng: “bố cục gây choáng ngợp và tôi không biết cách archive email”
- Insight đó được phản ánh vào yêu cầu của kế hoạch thực tế: “nút archive bắt buộc đặt ở góc trên bên trái — muscle memory của người dùng kỳ vọng vị trí đó từ Gmail”
- Hiệu ứng lãi kép: prototyping biến sự không chắc chắn thành đặc tả cụ thể, đồng thời tài liệu hóa phản ứng của người dùng
Chiến lược 7: Tổng hợp kèm các lựa chọn
- Mục đích: hợp nhất toàn bộ nghiên cứu thành một kế hoạch duy nhất có kèm trade-off
- Thời điểm dùng: sau khi kết thúc giai đoạn nghiên cứu, trước khi triển khai
- Sau khi chạy chiến lược 1~6, tác nhân tổng hợp: “dựa trên nghiên cứu này, hãy nêu 3 cách giải quyết vấn đề. Với mỗi cách, cho biết độ phức tạp triển khai, ảnh hưởng hiệu năng, gánh nặng bảo trì và pattern hiện có tương ứng”
- Ví dụ với đồng bộ inbox Gmail:
- Phương án A—dùng hệ thống đồng bộ hiện có: triển khai nhanh, nhưng gây trùng lặp mã và làm suy yếu tách biệt mối quan tâm
- Phương án B—đồng bộ thời gian thực: kiến trúc sạch, nhưng chậm và có thể gặp vấn đề độ tin cậy
- Phương án C—xây hệ thống mirror caching: giải pháp dài hạn tốt nhất, tách biệt sạch nhất, nhưng khối lượng công việc ban đầu lớn nhất
- Sau khi đối chiếu so sánh, có thể đưa ra lựa chọn có cơ sở chỉ trong 30 giây
- Hiệu ứng lãi kép: lựa chọn sẽ bộc lộ sở thích; nếu đánh dấu “ưu tiên tương thích”, lần sau hệ thống sẽ gán trọng số cao hơn cho tính tương thích trong các quyết định tương tự
Chiến lược 8: Review bằng tác nhân phong cách
- Mục đích: chuyển kế hoạch hoàn chỉnh cho reviewer chuyên biệt để kiểm tra mức độ phù hợp với sở thích của nhà phát triển
- Thời điểm dùng: giai đoạn kế hoạch cuối cùng, trước khi triển khai
- 3 tác nhân review chạy tự động:
- Tác nhân đơn giản hóa: gắn cờ over-engineering, “tính năng này thật sự cần 3 bảng cơ sở dữ liệu sao? Có thể làm bằng 1 bảng với trường type không?”
- Tác nhân bảo mật: kiểm tra các lỗ hổng phổ biến, “kế hoạch này cho phép đầu vào người dùng đi thẳng vào truy vấn cơ sở dữ liệu — cần thêm bước sanitize input”
- Tác nhân phong cách Kieran: áp dụng sở thích cá nhân, “đang dùng join phức tạp; Kieran thích truy vấn đơn giản hơn, hãy cân nhắc phi chuẩn hóa”
- Hiệu ứng lãi kép: theo thời gian, tác nhân tích lũy gu của nhà phát triển; khi đánh dấu “ghét kiểu này” hoặc “bắt rất chuẩn”, hệ thống sẽ học theo
Bắt đầu
Cách có thể thử ngay hôm nay
- Hệ thống lập kế hoạch đã được công bố mã nguồn mở trên Github Marketplace của Every
- Cài vào Claude Code là có thể dùng ngay slash command /plan và các tác nhân nghiên cứu
- Có thể dùng plugin trên Claude Code hoặc Droid
Cách bắt đầu đơn giản
- Chọn một tính năng Fidelity 2 bạn đang xây trong tuần này: công việc trải trên nhiều file và có phạm vi rõ ràng (thêm view mới, triển khai hệ thống phản hồi, refactor component)
- Trước khi yêu cầu Claude Code hoặc Cursor xây dựng, hãy dành 15~20 phút nghiên cứu:
- Best practices: người khác đã giải quyết thế nào? Tìm blog post, Stack Overflow, tài liệu trên web
- Pattern của chính bạn: bạn đã giải quyết thế nào? Tìm các tính năng tương tự trong codebase hiện có
- Khả năng của thư viện: công cụ bạn đang dùng thực sự hỗ trợ gì? Dùng AI đọc tài liệu hoặc mã nguồn
- Để AI tổng hợp nghiên cứu thành một kế hoạch có các mục sau:
- Vấn đề cần giải quyết (một câu rõ ràng)
- 2~3 hướng giải pháp (ưu và nhược điểm trung thực của từng hướng)
- Các pattern mã hiện có cần khớp theo
- Edge case hoặc các cân nhắc bảo mật
- Review kế hoạch và quan sát phản ứng của bản thân: nếu bạn nghĩ “quá phức tạp” hoặc “đã có cách tốt hơn”, đừng chỉ sửa kế hoạch mà hãy ghi lại vì sao bạn nghĩ vậy
- Phát hành tính năng dựa trên kế hoạch, so sánh triển khai cuối cùng với kế hoạch ban đầu: đã lệch ở đâu? Vì sao? Điều gì có thể làm kế hoạch tốt hơn?
- Dành 10 phút để chính thức hóa một bài học: thêm vào file CLAUDE.md, viết một quy tắc như “khi làm việc kiểu X thì nhớ kiểm tra Y” hoặc “vì lý do C nên ưu tiên cách A hơn B”
- Sau khi tích lũy các bài học, hãy tạo tác nhân nghiên cứu hoặc command chuyên biệt: “Event Tracking Expert” (nắm pattern của bạn), “Security Checker” (gắn cờ lỗi phổ biến)
- Lặp lại vào tuần sau, tham chiếu lại ghi chú, kiểm tra xem kế hoạch thứ hai có tốt hơn kế hoạch đầu tiên không, và sau vài tháng hãy xây dựng một hệ thống hiểu cách suy nghĩ của nhà phát triển
Chưa có bình luận nào.