Tối ưu AI Agent Workflow: Tại sao tôi liên tục đổi model trong lúc code?

Một thói quen rất phổ biến mà tôi thấy ở nhiều anh em developer khi mới dùng các AI coding tool (như Cursor, Copilot, hay các Agent UI) là: Luôn set mặc định model xịn nhất, nặng nhất (dòng Pro/Opus/Large) và dùng nó cho 100% mọi công việc.

Tâm lý chung rất dễ hiểu: "Mình muốn code xịn nhất, ít lỗi nhất, tại sao phải dùng model yếu hơn?"

Nhưng thực tế, việc cố chấp dùng model Pro cho mọi thứ giống như việc bạn bắt một ông Staff Engineer ngồi hì hục gõ boilerplate cho 50 cái file Unit Test vậy. Nó chạy được, nhưng vô cùng lãng phí, và quan trọng nhất: Nó làm chậm flow làm việc của bạn.

Trong bài viết này, chúng ta sẽ nhìn lại cách phân bổ resource khi làm việc với AI, và tại sao kỹ năng "chuyển đổi model giữa chừng" lại là thứ quyết định bạn có đang dùng AI hiệu quả hay không.

Lầm tưởng lớn nhất: "Đổi model giữa chừng sẽ làm mất context"

Nhiều người ngại đổi từ Pro sang Flash khi đang làm dở một tính năng vì sợ con AI mới sẽ "mất trí nhớ" và không hiểu những gì con AI trước vừa làm.

Thực ra, đây là một sự hiểu lầm về cách các hệ thống AI Agents hoạt động.

Khi bạn chat với một model, "trí nhớ" của nó không nằm ở trong bản thân con AI, mà nằm ở chuỗi lịch sử hội thoại (context). Khi bạn bấm nút chuyển từ mô hình Pro sang Flash, hệ thống đơn giản là bốc toàn bộ lịch sử chat từ đầu đến giờ, gói lại, và ném cho con Flash đọc.

Nó giống như việc bạn đang pair-programming với một ông Senior. Giữa chừng ông ấy đi họp, một cậu Junior nhảy vào thay. Điểm khác biệt duy nhất là cậu Junior này có siêu năng lực: đọc và hiểu toàn bộ lịch sử công việc, document, và code bạn đã chat với ông Senior trước đó chỉ trong 0.1 giây.

Context không hề mất đi. Thứ duy nhất thay đổi là năng lực xử lý và tốc độ của người đang ngồi pair với bạn.

Latency (Độ trễ) là một Feature

Chúng ta thường chỉ đánh giá AI qua việc nó code có đúng hay không (IQ), mà quên mất Latency (độ phản hồi).

Khi bạn đang ở trong trạng thái "flow state", việc phải chờ một model Pro rặn ra từng dòng code trong 20-30 giây cho một file CSS vớ vẩn là một cực hình. Lúc này, tốc độ quan trọng hơn sự hoàn hảo. Đó là lúc các dòng model nhỏ (Flash/Flash Lite) tỏa sáng.

Vậy khi nào dùng cái nào? Tôi thường chia mental model của mình ra làm 2 vai trò:

1. Architect (Dòng Pro) - Chậm, chắc, và tư duy sâu

Đây là những model có khả năng xâu chuỗi thông tin tốt, ít bị ảo giác (hallucination) khi context phình to, và có khả năng "nhìn" hệ thống ở góc độ tổng thể.

Nên dùng khi:

• Thiết kế hệ thống & Lập kế hoạch (Implementation Plan): "Tôi muốn build tính năng giỏ hàng có support offline sync. Hãy phân tích các edge case và lên list các file cần tạo."
• Gỡ những con bug "tâm linh": Loại bug mà bạn biết chắc không phải do syntax, mà do race condition, memory leak, hoặc side-effect lằng nhằng giữa 4-5 file khác nhau.
• Khởi tạo project từ đầu: Khi các quyết định architecture ban đầu (chọn thư viện nào, chia folder struct ra sao) sẽ ảnh hưởng đến toàn bộ dự án về sau.

Không nên dùng khi: Bạn chỉ đang cần sinh ra một đống boilerplate code. Việc đợi model Pro gõ từng dòng sẽ làm đứt mạch suy nghĩ của bạn.

2. Coder / Executer (Dòng Flash) - Nhanh, thực dụng, và vâng lời

Flash model không được sinh ra để thiết kế hệ thống. Nếu bạn quăng cho nó một cục code spaghetti và bảo "Refactor lại cho chuẩn SOLID", nó có thể sẽ làm mọi thứ rối tung lên. Nhưng bù lại, nó cực kỳ nhanh.

Nên dùng khi:

• Thực thi một plan đã có sẵn: "Dựa vào plan ở trên, hãy viết file CartService.ts".
• Tác vụ lặp đi lặp lại: Viết unit test, thêm JSDoc, parse data từ JSON sang CSV.
• Nghiên cứu và đọc tài liệu (Research): Khi bạn cần AI đọc qua 10 cái file logs dài ngoằng hoặc search web để tìm cú pháp của một thư viện. Tốc độ của Flash cho phép nó lướt qua một lượng lớn thông tin và trả về kết quả gần như ngay lập tức.
• UI/UX Tweaks: "Căn giữa cái div này", "Đổi màu nút thành đỏ". Những tác vụ này Flash làm dư sức, và nó xong trước khi Pro kịp khởi động luồng suy nghĩ.

3. Data Scraper (Dòng Flash Lite)

Nếu bạn chỉ cần AI làm những việc rập khuôn như: format lại một file JSON lộn xộn, dịch vài resource string sang tiếng Nhật, hoặc extract Regex, hãy dùng Flash Lite (hoặc các model siêu nhỏ tương đương). Nó tiết kiệm tài nguyên đến mức tối đa và response time gần như bằng 0.

Chiến thuật "Chuyển đổi linh hoạt" trong thực tế

Nếu áp dụng góc nhìn trên, workflow lập trình hàng ngày của bạn sẽ không còn phụ thuộc vào một model duy nhất nữa, mà sẽ là một sự kết hợp. Dưới đây là cách tôi thường làm khi implement một tính năng tầm trung:

1. Bước 1 - Lập bản vẽ (Dùng Pro): Tôi ném requirement vào và dùng Pro model để thảo luận về architecture. Mục tiêu của bước này không phải là ra code, mà là ra một cái file plan.md cực kỳ chi tiết, trong đó define rõ interface, các file cần đụng tới, và logic core.
2. Bước 2 - Thợ xây múa búa (Đổi sang Flash): Tôi chuyển sang model Flash. Chỉ vào cái plan.md vừa rồi và nói: "Làm phần 1". Flash nhả code ra rào rào. Chạy thử nghiệm nghiệm, bảo nó fix vài lỗi vặt. Tốc độ lúc này là trên hết.
3. Bước 3 - Cấp cứu (Quay lại Pro): Nếu trong lúc dùng Flash mà lòi ra một cái bug lạ, Flash sửa 2 lần không được (điều rất hay xảy ra vì Flash suy luận logic sâu khá kém), tôi lập tức stop nó lại. Đừng bắt Flash làm việc quá sức của nó. Tôi đổi lại sang model Pro, dán cái lỗi vào: "Phân tích kỹ cho tao xem tại sao cái setup ban đầu lại fail ở đây".

Điểm mấu chốt

Sự ra đời của hàng loạt model AI không phải để chúng triệt tiêu lẫn nhau, mà để phục vụ cho các bài toán khác nhau về Cost - Latency - IQ (Chi phí - Độ trễ - Sự thông minh).

Lần tới, khi bạn thấy mình đang ngồi chờ mỏi mòn để AI viết một cái regex kiểm tra email hoặc bọc một cái API call vào try/catch, hãy nhớ rằng: Bạn đang bắt một vị giáo sư đi làm việc của một thực tập sinh. Hãy mạnh dạn chuyển sang model nhỏ hơn, và bạn sẽ thấy flow code của mình mượt mà hơn rất nhiều.