“Làm thế nào để AI hoạt động hiệu quả trên codebase phức tạp”
Và làm thế nào để tối ưu token/quota khi dùng AI cho việc development (code nói chung).
Khoảng 3-4 tháng trở lại đây thì mình tập trung cho chủ đề này rất nhiều. Nên hôm nay mình note lại vài ý để hy vọng có thể được nghe thêm các idea khác.
—–
Đầu tiên phải nói về việc mình xài AI từ lúc prompt cơ bản, cho tới chi tiết, rồi thì rules, MCP, memory, subagents, skill, plugin… Món nào mình cũng chơi. Lúc này mindset của mình là “bộ rules chuẩn thì model nào cũng chơi được”.
Giang hồ có câu “nếu nó đang đúng, thì đừng sửa”. Đúng ở đây là nó đang đáp ứng được, chạy được và mình hài lòng với kết quả. NHƯNG đánh đổi là tokens đang tiêu tốn rất nhiều.
Sau đó là Cursor đổi cách tính phí sang token-based, Claude Code “siết” quota. Chưa kể mình làm cả local AI, nếu cứ xài cách trên thì các model nhỏ không thể hoạt động được. Vì chúng không kiểm soát tốt context và window context.
Rồi thì mình đã có một ý nghĩ khác (đúng hơn là phát hiện mang tính thay đổi):
“Nếu không có rule, model chạy được tầm 5/10 điểm. Có rules thì 8/10, nhưng x2 x3 rules hoặc nhiều tới mấy cũng không thể 10/10 điểm. Thậm chí đảo chiều, model bị giảm chất lượng đầu ra vì “ảo giác” và “confuse”.
Thời điểm này có khái niệm Context Engineering ra đời. Thật ra với mình nó cũng chỉ là game đi tìm điểm “G”: điểm tối ưu nhất của việc cân bằng lượng context size và kết quả đầu ra.
—-
Sau đó mình đã thử tháo hết rules ra, tìm hiểu nội tại của model để tinh chỉnh khi cần thiết. Kết quả là 8-9/10 nhưng token chỉ tiêu thụ có 20% thậm chí là 10% so với trước.
Bản thân mình không tin vào cái gọi là spec-driven lắm. Thật sự là việc sync giữa specs/docs/tasks <-> code là một vấn đề khá nhức đầu. Và đằng nào thì cũng phải về code mới test được (tính chất testable) chứ specs thì đúng hay sai vẫn còn tương đối khá cảm tính. Và cũng không chắc chắn rằng model nó hiểu specs như chúng ta đang hiểu và cần.
Hãy tưởng tượng bạn thuê 1 ông dev với giá 200$/tháng về, bạn mong muốn “vắt sữa” ông này để tăng tốc hoặc làm được những việc mà trước đó không thể. Nhưng việc quản trị và hướng dẫn tốn x3 x4 lần nữa thì VÔ LÝ quá!!
Bản thân các model pre-trained cũng rất khác. Ngồi tìm hiểu từng con và tối ưu hết thì đúng là “Vibe gáy” thật chứ “Vibe Code” gì nữa. Mà Vibe Code mà chơi vậy thì còn gì là Vibe nữa, đi code tay luôn như thời chưa có AI Agent cho khỏe!
—-
Một ngày đẹp trời – mình xạo đó, thật ra hôm đó mưa sấp mặt, mình hình dung thế này:
Nếu AI Agent là một chiếc xe, model là engine và controller. Người lái chính là mình. Vậy thì source code nên là con đường, hạ tầng giao thông (đèn, biển báo tín hiệu).
Các “hạ tầng” này phải hỗ trợ “chiếc xe” một hiệu quả. Tránh việc mình muốn đi A -> B mà bao nhiêu con hẻm, bao nhiêu cái biển báo mà mình còn phải khai báo luôn thì oằn quá. Viêc tuân thủ và xử lý tình huống mình delegate (hay tạm gọi là trả lại) cho model và AI. Mình chỉ đưa ra các rules tổng quát và ứng xử chung thôi.
Model nào tệ quá thì thôi cho nó nghỉ, hơi đâu mệt đầu 🥹. Trừ khi chui hẻm, leo núi, lội thác, off-road gì đó mình mới phải xắn tay vô hỗ trợ. Lúc này thì hỗ trợ “sâu”, vì nó đáng.
—-
Ôn cố tri tân!
Tới đây cũng chẳng có gì mới cả! Đơn giản là ứng dụng lại một quy tắc mình cũng rất yêu thích “Source code as docs”. Bản thân sourcebase nên tự lý giải chính nó. Chỉ là điều chỉnh sao cho hợp với cách làm việc của AI Agents thôi!
Từ đó source code dù là monorepo hay có bao nhiêu modules, chức năng, nghiệp vụ chỉ cần tuân thủ đúng các conventions cơ bản:
• Files code nhỏ gọn (150-250 dòng) là okie.
• Filename phải hỗ trợ AI Context. VD như “update.go” -> “change_product_quantity_when_order_placed.go”.
• Những dòng đầu tiên của file (dưới 10 dòng) nên là một AI Context summary ngắn gọn, hoặc flow xử lý chính.
• Module có file md ngắn gọn lý giải nhiệm vụ chính, flow chính. Nếu cần thì đọc thêm cái file… để hiểu chi tiết hơn. Sau này Anthropic họ cũng thiết kế SKILL dạng thế. Qua rồi cái thời mà context phải chứa quá nhiều thứ chưa cần đến.
Mình có cái “tật” rất để ý tụi AI Agent nó chạy. Nên khi tụi nó gọi cách bash như “ls -la”, “grep … | head …”, “cat … | head …” là mình nghĩ ngay: LÀM SAO ĐỂ AI “LIẾC” MẮT QUA LÀ BIẾT CÁC THÔNG TIN NÓ CẦN.
Và đó chính là hệ thống “chiếu sáng” và “chỉ đường” cho AI ngay trong source code.
—–
Khi AI Agents vận hành thì nó sẽ có thể phá vỡ các kiến trúc này. Bạn có thể giải quyết ngay hoặc cứ kệ nó. Thi thoảng mở các model mạnh nhất lên “trùng tu” lại một chút, kiểu bảo trì cầu đường vậy thôi.
Mình thì kiểu cứ lấy quota dư thì “trùng tu” source code. Vậy quota dư ở đâu ra?! Vì đã làm tốt những thứ trên!
Và bây giờ thì… model nào cũng okie. Có con nhanh, có con chậm, có con hay lạc đường, nhưng không sao, custom riêng nhẹ nhành xíu là lại ổn thôi.
Giờ thì nhức đầu nghĩ system design, solution, và đi combat với mấy con thinking thôi, chứ còn khi đã vào tới development phase rồi thì auto xong!
#VibeCoding #ContextEngineering
https://www.facebook.com/share/p/1BQGiRWyCC/?mibextid=wwXIfr