BlastLoop: Phương pháp lập trình lấy cấu trúc làm gốc dành cho AI agent

Trong bối cảnh AI agent ngày càng tham gia sâu vào quy trình viết code, một câu hỏi lớn đặt ra: làm sao để tốc độ không đi kèm với sự cẩu thả? BlastLoop — một framework lập trình do Ross Shaw phát triển — được thiết kế để giải quyết đúng bài toán đó.

BlastLoop là gì?

BlastLoop là một framework lập trình thực chiến dành cho AI agent, hoạt động theo nguyên tắc "cấu trúc trước, chức năng sau, tấn công cuối cùng".

Ý tưởng trung tâm rất rõ ràng: mỗi thay đổi trong mã nguồn cần có một "chủ sở hữu" ở đúng tầng trách nhiệm, và mọi kết quả phải vượt qua ba cổng kiểm tra — cấu trúc, vận hành và đối kháng — theo một thứ tự cố định trước khi được đưa vào sản phẩm.

AI coding agent giúp đội ngũ nhanh hơn, nhưng cũng khiến thất bại đến nhanh hơn. BlastLoop áp dụng tư duy vận hành vào công việc của agent.

Ba tầng viết code: Blast, Mid và Inner

BlastLoop chia công việc lập trình thành ba độ cao (altitude) khác nhau, mỗi tầng có phạm vi trách nhiệm riêng:

• Blast — viết code và cấu trúc ở cấp hệ thống. Dùng khi công việc thay đổi hình dạng repo, ranh giới dịch vụ, giao diện cấp cao nhất, hợp đồng chia sẻ, cấu trúc triển khai hoặc bộ khung của một năng lực mới.

• Mid — viết code ở cấp hệ thống con. Dùng khi công việc lớn hơn một bản vá cục bộ nhưng nhỏ hơn một thiết kế lại toàn hệ thống: một lát cắt tính năng, một module dịch vụ, một bề mặt tích hợp hoặc một đợt tái cấu trúc subsystem.

• Inner — viết code đơn vị cục bộ. Dùng khi công việc chỉ gói gọn trong vài file, hàm, bài test hoặc adapter. Đây là tầng có phạm vi tập trung, quyền sở hữu rõ ràng và hoàn thành thay đổi một cách trực tiếp.

Điểm khác biệt so với các phương pháp khác: BlastLoop không đi theo lối "viết spec trước, lập kế hoạch trước, rồi mới giao cho một người triển khai". Tầng viết code nào thì tự sản xuất code trong phạm vi của chính nó.

Vòng kiểm thử T1 → T2 → T3

Sau khi code được viết, nó phải đi qua ba vòng kiểm thử theo đúng thứ tự:

T1 — Kiểm tra cấu trúc

T1 tìm kiếm các vấn đề về cấu trúc: ranh giới sai, logic đặt ở sai độ cao, abstraction bị rò rỉ, quyền sở hữu file bị phá vỡ, thiếu interface hoặc các mối quan tâm xuyên suốt bị đặt sai chỗ. T1 không đóng vai trò sửa lỗi tổng quát — nhiệm vụ của nó là quyết định xem code có đúng hình dạng hay không và định tuyến việc sửa chữa về đúng tầng: Inner, Mid hay Blast.

T2 — Sửa lỗi và vận hành

T2 xử lý lỗi và các vấn đề vận hành trực tiếp khi cấu trúc đã vững. Nếu T2 phát hiện vấn đề thực chất là kiến trúc, nó leo thang trở lại T1 thay vì vá tạm ở cấp cục bộ.

T3 — Kiểm thử đối kháng

T3 tấn công kết quả: các trường hợp biên, hành vi lạm dụng, điều kiện race, đầu vào kỳ quặc, giả định mong manh, tình trạng bảo mật, đường dẫn rollback và hành vi thất bại.

Điểm mấu chốt nằm ở quy tắc khởi động lại: nếu T3 phát hiện vấn đề cấu trúc, vòng lặp phải chạy lại như sau:

T3 → T1 → sửa chữa ở B/M/I → T2 → T3

Sự đứt gãy cấu trúc phải được sửa chữa một cách có cấu trúc, chứ không phải vá tạm như một lỗi cục bộ.

BlastLoop không phải là gì?

Để tránh hiểu nhầm, tài liệu của BlastLoop nêu rõ một số giới hạn:

• Không phải công cụ kiểm tra sự thật. Đây là framework viết code và kiểm thử, không phải cỗ máy xác minh chân lý.

• Không phải GitHub Spec Kit. Spec Kit đi theo luồng spec → plan → tasks → implement → converge. BlastLoop là nhiều tầng viết code kết hợp với một vòng kiểm thử theo giai đoạn.

• Không phải một "phong cách agent" cạnh tranh. BlastLoop có thể hoạt động song song với Spec Kit, vibe coding, prompt triển khai cục bộ hoặc kiểm thử red/blue. Những phương pháp đó có thể nằm bên trong một tầng hoặc một lớp kiểm thử của BlastLoop.

• Không phải sơ đồ tổ chức đa agent. Bản công khai này không định nghĩa các tầng quản lý hay hệ thống phân cấp bot.

• Không chỉ là kiểm thử red/blue. Kiểm thử đối kháng chỉ là T3, không phải toàn bộ phương pháp.

Bắt đầu sử dụng trong vòng chưa đầy 5 phút

Quy trình khởi động được thiết kế tối giản:

1. Clone repo vào dự án mà bạn muốn agent hỗ trợ.
2. Hướng agent đến file AGENTS.md.
3. Nạp một prompt xây dựng dựa trên độ cao của công việc:
   • Hình dạng hệ thống hoặc repo → prompts/blast.md
   • Hệ thống con hoặc lát cắt tính năng → prompts/mid.md
   • File cục bộ hoặc thay đổi đơn vị → prompts/inner.md
4. Để agent viết code ở đúng độ cao đó.
5. Chạy vòng kiểm thử theo thứ tự: prompts/t1-structural.md, prompts/t2-bug-ops.md, prompts/t3-adversarial.md.

Nếu T3 phát hiện vấn đề cấu trúc, khởi động lại qua T1, định tuyến sửa chữa về Blast, Mid hoặc Inner, rồi chạy lại T2 và T3.

Ý nghĩa với cộng đồng lập trình viên Việt Nam

Với các đội ngũ phát triển phần mềm tại Việt Nam đang ngày càng ứng dụng AI agent vào quy trình làm việc, BlastLoop mang đến một góc nhìn đáng tham khảo: tốc độ chỉ có giá trị khi đi kèm kỷ luật cấu trúc.

Thay vì để agent viết code tràn lan rồi hậu kiểm một cách hỗn loạn, phương pháp này đề xuất một khung tư duy rõ ràng — phân tầng trách nhiệm, kiểm thử theo thứ tự và quan trọng nhất là không bao giờ vá lỗi kiến trúc bằng các bản sửa cục bộ. Đây là nguyên tắc mà bất kỳ nhóm kỹ thuật nào cũng có thể áp dụng, dù dùng công cụ AI nào.

Framework được phát hành theo giấy phép MIT, phiên bản 1.0.0, với đầy đủ tài liệu về quy tắc bàn giao (docs/HANDOFFS.md) và so sánh với các phương pháp lân cận (docs/COMPARISON.md).