AI coding nhanh hơn, nhưng bộ não thì không: giữ mental model khi làm việc với agent

AI coding đã nhanh hơn rất nhiều. Model tốt hơn, agent có thể chạy song song, tự review code, sửa bug và tiếp tục làm việc khi chúng ta rời máy.

Nhưng có một nghịch lý: viết ít code hơn không đồng nghĩa với việc mệt ít hơn.

Khi phải quản lý nhiều agent, tool, model, task dang dở và những quyết định chỉ tồn tại trong đầu, người lập trình có thể tiêu tốn nhiều năng lượng hơn trước. Bottleneck đã chuyển từ implementation sang cognitive load.

Bài viết “AI Coding Got Faster. My Brain Didn’t.” của Kevin Ma đưa ra một nguyên tắc đơn giản:

Giảm số lượng quyết định mà bộ não phải đưa ra.

Bài viết này không phản đối coding agent. Nó gợi ý một cách dùng agent bền vững hơn: để AI xử lý phần implementation, còn con người giữ được focus và bản đồ của hệ thống.

Sơ đồ hand-drawn-system-architecture: AI xử lý implementation, còn con người giữ mental model để bảo toàn sự rõ ràng của hệ thống.

Khi bộ não trở thành orchestration layer

Mỗi agent đang chạy lại tạo thêm một context cần theo dõi: agent này đang làm gì, dựa trên assumption nào, branch nào cần review, task nào đã xong nhưng chưa verify. Khi số lượng task tăng, con người vô tình trở thành lớp điều phối thủ công cho toàn bộ hệ thống.

Vấn đề không phải agent chạy song song luôn xấu. Vấn đề là parallelism không có giới hạn sẽ chuyển chi phí từ CPU sang não người.

1. Chạy ít thứ song song hơn

Tác giả thường chỉ giữ một coding task chính, đôi khi là hai. Khi agent đang làm việc, anh không lập tức khởi động thêm task coding chỉ vì có vài phút rảnh.

Khoảng trống đó có thể dùng để đọc, suy nghĩ hoặc đơn giản là không nạp thêm context mới. Đây là một thay đổi quan trọng: không tối đa hóa số phút bận rộn; tối ưu hóa khả năng suy nghĩ rõ ràng.

Một queue task rõ ràng thường tốt hơn một workspace đầy agent đang chạy nhưng không ai còn nhớ chính xác chúng đang làm gì.

2. Dùng ít tool và model hơn

Việc liên tục thử tool mới và đổi model theo từng task tạo ra rất nhiều quyết định nhỏ:

Nên dùng tool nào?
Model nào tốt hơn?
Có nên chuyển sang model mới không?
Tool này có thực sự hơn workflow hiện tại không?

Một cách thực tế hơn là xây một bộ mặc định nhỏ, mỗi tool và model giữ một vai trò ổn định. Setup hoàn hảo không quan trọng bằng setup đủ tốt, dễ nhớ và đáng tin cậy.

3. Đừng mở project mới chỉ vì AI làm việc đó quá dễ

AI đã làm giảm mạnh chi phí bắt đầu một sản phẩm: từ một ý tưởng, chúng ta có thể tạo repo, yêu cầu agent dựng MVP và có một thứ chạy được chỉ sau một giờ.

Nhưng nếu lặp lại quá nhiều lần, kết quả có thể là:

nhiều repo → nhiều MVP → nhiều task dang dở → không sản phẩm nào đủ chiều sâu

AI làm giảm chi phí bắt đầu, nhưng không làm giảm giá trị của focus. Một sản phẩm được cải thiện qua usage thực tế, feedback người dùng và doanh thu thường đáng giá hơn mười prototype mới chỉ dừng ở demo.

4. Dành thêm thời gian cho program design

AI có thể tạo ra một feature chạy được dù phần thiết kế bên dưới chưa đủ rõ. Trước khi giao implementation, con người vẫn cần suy nghĩ về:

• ranh giới giữa các module,
• interface,
• data flow,
• state transition,
• error handling,
• call path giữa các thành phần,
• và các trade-off quan trọng.

Nếu những thứ này chưa rõ, hệ thống dễ rơi vào vòng lặp:

sửa bug A → phát sinh bug B → sửa B → hỏng C → tiếp tục dò từng triệu chứng

Một vài giờ làm rõ cấu trúc có thể tiết kiệm nhiều ngày debug. Tốc độ không chỉ đến từ việc viết code nhanh; nó còn đến từ việc biết chính xác code cần được viết ở đâu và vì sao.

5. Giữ system map trong đầu

Thời kỳ tác giả cảm thấy làm việc với AI hiệu quả nhất lại diễn ra khi model còn yếu hơn và agent ít khả năng hơn. AI vẫn xử lý phần lớn implementation, nhưng anh hiểu rất rõ architecture, module, interface, data flow, call flow và các trade-off.

Khi có bug, anh có thể hình dung đường đi của dữ liệu, phỏng đoán vùng có vấn đề và đưa cho AI context cụ thể:

Đây là behavior đang xảy ra.
Đây là cách module hoạt động.
Đây là nơi tôi nghi ngờ.
Hãy kiểm tra assumption, trace flow, sửa và test.

AI đảm nhiệm implementation. Con người vẫn giữ bản đồ của hệ thống.

Không cần đọc từng dòng, nhưng phải hiểu critical path

Giữ system trong đầu không có nghĩa là phải tự viết mọi function hoặc kiểm tra thủ công từng dòng code do AI tạo ra. Điều cần giữ là mô hình ở tầng cao hơn implementation:

• request đi qua những module nào,
• state thay đổi ở đâu,
• dữ liệu được lưu và đọc như thế nào,
• boundary nào không được phá vỡ,
• failure mode quan trọng là gì,
• và quyết định kiến trúc nào đang ràng buộc hệ thống.

Con người có thể vận hành ở một tầng cao hơn code, nhưng không nên tách khỏi hệ thống đến mức chỉ biết rằng “feature đang chạy”.

Liên hệ với context engineering và agent memory

Bài viết này chạm trực tiếp vào hai vấn đề của agent system.

Context switching là một loại chi phí

Mỗi agent task có thể được xem như một context riêng. Khi chuyển qua lại quá nhiều context, con người phải liên tục khôi phục trạng thái tinh thần. Một hệ thống agent tốt không chỉ cần tăng throughput; nó cần giảm số context mà con người phải tự quản lý.

Memory nên giữ system map, không chỉ lưu log

Với developer, memory còn có vai trò externalize bản đồ hệ thống. Memory hữu ích có thể lưu:

- kiến trúc hiện tại
- module boundaries
- quyết định và lý do
- assumption của agent
- task đang chạy
- trạng thái verification
- critical data flow
- bug history
- unresolved questions

Nếu memory chỉ là một đống conversation summary, nó có thể tạo thêm noise. Memory tốt phải giúp người và agent khôi phục mental model nhanh hơn.

Agent orchestration cần phục vụ cognitive load

Mục tiêu của multi-agent không nên chỉ là chạy nhiều việc cùng lúc. Cần hỏi thêm:

Con người có còn hiểu task graph không?
Kết quả trung gian có rõ không?
Assumption có được ghi lại không?
Có một nơi duy nhất để xem trạng thái hệ thống không?

Một orchestration system tốt là hệ thống làm giảm số quyết định cần nhớ, không phải hệ thống đẩy thêm dashboard và notification cho người dùng.

Workflow AI coding bền vững hơn

1. Chọn một task chính
2. Làm rõ behavior và acceptance criteria
3. Viết system map tối thiểu
4. Xác định module, boundary và critical path
5. Giao implementation cho agent
6. Để agent verify bằng test và trace
7. Review flow và trade-off
8. Ghi lại decision quan trọng
9. Chỉ chuyển task sau khi trạng thái đã rõ

Trước khi mở thêm một agent, nên kiểm tra:

Task này có thật sự độc lập không?
Kết quả của nó có tạo thêm context phải quản lý không?
Mình có biết chính xác output cần nhận là gì không?
Có thể đưa task vào queue thay vì chạy ngay không?

Kết luận

AI coding tốt hơn không nhất thiết là AI coding có nhiều agent nhất, nhiều tool nhất hoặc tốc độ generate code cao nhất.

Một setup tốt là setup giúp người xây dựng tập trung vào vài việc quan trọng, giảm quyết định vụn vặt, thiết kế trước khi implementation, hiểu architecture và critical path, đồng thời vẫn cảm thấy mình đang điều khiển hệ thống.

AI có thể viết code. Nhưng người xây dựng vẫn nên giữ hệ thống trong đầu mình.

Tốc độ là lợi thế của AI. Sự rõ ràng là lợi thế của con người.

Tham khảo: AI Coding Got Faster. My Brain Didn’t. — Kevin Ma. Bài được truy xuất qua X và bản mirror của nội dung bài viết.