Một năm trước, tôi coi các trợ lý lập trình AI như một dạng autocomplete xịn. Hôm nay, một agent chạy bộ test của tôi, phân loại exception trên production, soạn bản vá và mở pull request — còn công việc của tôi đã chuyển từ viết từng dòng code sang review và định hướng. Dưới đây là những gì tôi rút ra để cú chuyển đổi đó trở nên hiệu quả thay vì hỗn loạn.
Một ngày làm việc thực tế trông ra sao
Một buổi sáng cụ thể, mới gần đây: một cảnh báo Sentry nổ trong đêm vì lỗi 500 ở một màn hình admin. Trước cả ly cà phê đầu tiên, tôi dán link issue vào agent và bảo nó điều tra. Nó đọc stack trace, tìm ra controller, nhận thấy một lệnh save không kiểm tra kết quả, theo sau là một path helper bị gọi với id nil — một mẫu lỗi nó từng gặp trong codebase này, vì các mẫu bug lặp lại của chúng tôi được ghi sẵn trong file hướng dẫn dự án. Nó soạn bản vá, thêm regression spec, chạy bộ test và trình ra một diff. Tôi đọc diff, chỉnh lại một thông báo lỗi, rồi merge. Tổng thời gian: chừng mười hai phút, phần lớn là thời gian tôi ngồi đọc.
Đó mới là hình hài trung thực của sự thay đổi: không phải “AI viết code hộ tôi”, mà là phần cơ học ở giữa công việc — định vị, tái hiện lỗi, soạn thảo, kiểm chứng — bị nén về gần bằng không, để lại những quyết định cần phán đoán cho tôi.
Agent thực sự giỏi ở đâu
- Thay đổi cơ học ở quy mô lớn. Đổi tên, migrate API, áp một rule lint lên cả trăm file. Agent làm trong vài phút thứ trước đây tốn cả một buổi chiều tỉ mẩn đến phát chán.
- Bản nháp đầu tiên cho việc được đặc tả rõ. Nếu tôi mô tả được thay đổi một cách chính xác — đầu vào, đầu ra, các trường hợp biên — bản nháp thường đúng đến 80–90%.
- Đọc code lạ. Câu hỏi “giải thích luồng xác thực chạy qua app này như thế nào” được trả lời nhanh hơn, và thường tốt hơn, so với hỏi một đồng nghiệp.
- Triage. Cho một stack trace và quyền truy cập repo, agent thường tìm ra dòng gây lỗi, commit đưa lỗi vào và một nguyên nhân gốc hợp lý trước khi tôi kịp đọc xong cảnh báo.
Đâu là chỗ chúng còn hỏng
- Các quyết định sản phẩm chưa được đặc tả. Agent sẵn sàng bịa ra hành vi ở những chỗ yêu cầu im lặng — và bịa một cách đầy tự tin.
- Chuỗi ngữ cảnh ngầm kéo dài. Những quy ước sống trong đầu cả team chứ không nằm trong repo sẽ bị vi phạm.
- Biết lúc nào nên dừng. Nếu bị bỏ mặc, agent có thể “sửa” đến mức phình thành một thay đổi lớn hơn nhiều so với thứ bạn muốn.
Các thất bại này chung một nguyên nhân gốc: agent tối ưu cho một nhiệm vụ trông-có-vẻ-hoàn-thành, mà trông hợp lý không đồng nghĩa với đúng. Chính vì thế, thói quen quan trọng hơn công cụ.
Những thói quen quyết định
Đòn bẩy lớn nhất là viết mọi thứ ra nơi agent nhìn thấy được: quy ước trong file hướng dẫn dự án, các mẫu bug lặp lại, quy trình deploy, lý do đằng sau những quyết định không hiển nhiên. Mỗi mẩu tri thức truyền miệng bạn viết ra sẽ biến một lớp sai lầm của agent thành một lớp năng lực của agent. Tác dụng phụ: tài liệu của bạn cũng tốt lên cho chính con người.
Đòn bẩy thứ hai là kỷ luật review. Tôi review code của agent như review code của một kỹ sư junior nhanh nhẹn và hăng hái: mặc định happy path chạy được, rồi đi săn những nhánh không vui — input nil, collection rỗng, ghi đồng thời, cái nhánh mà test không phủ tới. Diff của agent lúc nào trông cũng sạch; chính vì vậy mà việc review phải mang tính đối kháng.
Thứ ba là giới hạn phạm vi. Nhiệm vụ nhỏ, ranh giới rõ thì thành công; “cải thiện hiệu năng của app” sẽ đẻ ra một thay đổi lan man mà bạn không dám merge. Tôi đã học được cách giao cho agent đúng cỡ việc mà tôi sẽ giao cho một thành viên mới trong tháng đầu tiên của họ.
Vài lưu ý thực tế
Hai ghi chú nhàm chán nhưng quan trọng. Thứ nhất, chi phí: quy trình dùng agent ngốn token nhiều hơn hẳn so với chat, nên hãy để mắt tới hóa đơn trong tháng đầu và học xem việc nào đáng để tự động hóa. Thứ hai, secrets: một agent có quyền chạy shell đọc được mọi thứ mà shell của bạn đọc được. Giữ credentials production ngoài repository và ngoài môi trường bạn thả agent vào.
Công cụ sẽ còn tiếp tục tốt lên. Còn những thói quen này, tôi ngờ rằng, sẽ theo được sang bất kỳ công cụ nào.