Một meme đang lên trong r/vibecoding nói khá đúng một nghịch lý mới: sau một vòng dùng LLM để thay người viết code đơn giản, nhiều team lại bắt đầu nghĩ tới chuyện thuê junior developer để giảm tiền token cho các việc “cơ bản”. Nghe buồn cười, nhưng đây là tín hiệu đáng chú ý: bài toán AI coding đang chuyển từ “có thay được người không” sang “đặt AI và con người ở đâu thì kinh tế nhất”.
Vì sao chuyện này đáng bàn
Trong giai đoạn đầu, nhiều team nhìn AI coding như một cách tăng tốc gần như miễn phí: mô tả yêu cầu, nhận code, sửa vài vòng, ship. Nhưng khi dùng ở quy mô thật, chi phí không chỉ là subscription hay token.
Nó còn gồm:
- thời gian prompt và review lại output;
- chi phí context dài, retry, hallucination, test fail;
- rủi ro tạo ra code khó bảo trì;
- thời gian senior phải đọc lại những phần đáng ra rất đơn giản;
- chi phí vận hành nếu agent chạy tự động quá nhiều bước.
Với những task nhỏ, rõ ràng, lặp lại nhiều lần, dùng model xịn cho mọi thứ có thể giống việc thuê kiến trúc sư để đóng đinh kệ sách. Làm được, nhưng không chắc là cách rẻ nhất.
“Junior developer” không chỉ là người viết code rẻ hơn
Điểm thú vị trong meme là nó đẩy anh em về một sự thật cũ: junior không chỉ thay token. Nếu được giao việc đúng, junior còn tạo ra tài sản dài hạn cho team.
Một junior tốt có thể:
- gom các task nhỏ thành checklist có cấu trúc;
- viết test case cơ bản trước khi đẩy sang AI hoặc senior;
- đọc lỗi, tái hiện bug, chuẩn hóa ticket;
- làm các thay đổi UI hoặc CRUD lặp lại;
- học domain của sản phẩm qua thời gian;
- phát hiện chỗ spec mơ hồ mà AI thường đoán bừa.
LLM mạnh ở tốc độ sinh output. Con người mạnh ở việc chịu trách nhiệm, học bối cảnh dài hạn, và biết khi nào không nên làm tiếp.
Cách chia việc thực tế hơn
Thay vì hỏi “AI hay junior”, mình nghĩ câu hỏi đúng hơn là “task này nên đi qua pipeline nào”. Một cách chia đơn giản:
1. Việc lặp lại, rủi ro thấp
Ví dụ: đổi copy, thêm field đơn giản, refactor nhỏ có test rõ.
Nên dùng AI trước, nhưng phải có guardrail:
- yêu cầu diff nhỏ;
- bắt buộc chạy test/lint;
- không cho tự ý đổi kiến trúc;
- review nhanh bởi người có trách nhiệm.
2. Việc đơn giản nhưng cần hiểu sản phẩm
Ví dụ: chỉnh flow onboarding, sửa logic khuyến mãi, thay đổi dashboard nội bộ.
Nên để junior hoặc operator kỹ thuật nắm context, sau đó dùng AI như pair programmer. Lý do: phần khó không phải code, mà là hiểu “đúng hành vi mong muốn”.
3. Việc mơ hồ, có ảnh hưởng kiến trúc
Ví dụ: thiết kế permission, billing, sync dữ liệu, migration lớn.
Không nên đẩy thẳng cho AI. Senior cần chia nhỏ, viết spec, xác định rủi ro, rồi mới dùng AI cho từng mảnh.
Checklist trước khi đốt token
Trước khi đưa một việc vào AI coding agent, anh em có thể hỏi nhanh:
- Task này có mô tả đầu ra rõ chưa?
- Có test hoặc cách kiểm chứng chưa?
- Nếu AI làm sai, ai chịu trách nhiệm review?
- Dùng model nhỏ hơn có đủ không?
- Có template, snippet, script nội bộ nào rẻ hơn không?
- Đây là việc một junior nên học để tăng năng lực team không?
Nếu 3 câu đầu chưa rõ, vấn đề không nằm ở model. Vấn đề nằm ở quy trình.
Kết luận
Vibe coding không làm junior biến mất. Nó làm vai trò junior thay đổi. Junior ít nên bị dùng như “máy gõ code”, mà nên được đặt vào các việc hiểu sản phẩm, chuẩn hóa yêu cầu, kiểm chứng output, và biến những lần sửa lặp lại thành playbook.
Còn LLM cũng không nên bị dùng như một cái búa đắt tiền cho mọi cây đinh. Team tốt sẽ có ma trận phân việc rõ: cái gì cho AI, cái gì cho junior, cái gì bắt buộc senior thiết kế.
Nếu nhìn theo hướng đó, “thuê người để tiết kiệm token” không hẳn là bước lùi. Nó là dấu hiệu thị trường đang tỉnh táo hơn: automation hiệu quả nhất khi biết phần nào không nên tự động hóa.
Top comments (0)