Lãnh đạo kỹ thuật nên là người 'đốt token' nhiều nhất

Trong bối cảnh AI đang định hình lại cách phần mềm được tạo ra, các kỹ sư cấp cao và lãnh đạo kỹ thuật không thể chỉ ngồi ở vị trí quản lý và giao việc. Họ cần trực tiếp thử nghiệm, thất bại và học hỏi từ các công cụ lập trình AI — để lại một "dấu vết AI" (AI exhaust) dày đặc từ token tiêu thụ, mã nguồn, và các nguyên mẫu thất bại. Đây là cách duy nhất để đưa ra quyết định đúng đắn trong một ngành đang thay đổi từng ngày.

Bài viết gốc trên Schipper.ai lập luận rằng cách đo lường kỹ sư theo số dòng code hay token đã đốt là sai lầm, nhưng việc lãnh đạo kỹ thuật không có đủ dấu vết AI lại là một tín hiệu đáng ngờ. Khi giao diện giữa con người và phần mềm chưa ổn định, kinh nghiệm trực tiếp trở thành nguồn phán đoán duy nhất đáng tin cậy.

Vấn đề với cách đo lường cũ

Từ lâu, ngành kỹ thuật phần mềm vận hành theo nguyên tắc ổn định: một kỹ sư kỳ cựu có thể chuyển sang vai trò lãnh đạo, tập trung vào việc review code, viết tài liệu, mentoring và ảnh hưởng đến các nhóm khác. Andy Grove trong cuốn High Output Management gọi đây là đòn bẩy (leverage) — sản lượng của một lãnh đạo không chỉ nằm ở việc họ tự làm, mà còn ở những gì họ giúp tổ chức đạt được.

Kỹ sư càng cao cấp, họ càng được đánh giá dựa trên phản hồi đồng nghiệp và tác động của công việc, không phải số lượng pull request. Điều này tạo ra một mối quan hệ nghịch đảo giữa thâm niên và sản lượng kỹ thuật trực tiếp.

Nhưng AI đã thay đổi tất cả.

Thời kỳ bất ổn của lập trình với agent

Không ai biết chắc cách "đúng" để lập trình với AI agent. Các câu hỏi mở đang được tranh luận sôi nổi:

• Về code review: Kỹ sư có nên đọc toàn bộ code không? Hay chỉ review test và hành vi kết quả? Có nên dựa vào AI để giải thích thay đổi code?
• Về quản lý ngữ cảnh: Nội dung gì nên đưa vào file AGENTS.md? Kích thước cửa sổ ngữ cảnh hiệu quả là bao nhiêu?
• Về codebase: Có nên để LLM duy trì wiki cho codebase? Kế hoạch Markdown có được lưu trong repo?
• Về tự chủ: Agent nên hoạt động như copilot hay làm việc không giám sát? Có nên áp dụng spec-driven development?

Những câu hỏi này không thể trả lời bằng lý thuyết. Chúng là câu hỏi thực nghiệm. Bạn phải chạy agent trên codebase thật, đẩy chúng vào tình huống thất bại, tự dựng stack và sẵn sàng vứt bỏ sau ba tháng. Báo cáo gián tiếp hay demo không đủ.

Thâm niên không có nghĩa là ít viết code hơn

Kỹ sư dùng agent để hoàn thành công việc. Nhưng lãnh đạo kỹ thuật có sứ mệnh rộng hơn: tìm ra cách hiệu quả để cả nhóm dùng agent. Agent hoạt động tốt ở đâu? Thất bại ở đâu? Cần ngữ cảnh gì? Con người nên review phần nào?

Để trả lời, họ cần trải nghiệm thực tế. Kỹ sư staff và principal nên chạy thử nghiệm, dùng công cụ mới, và đẩy model vào các bài toán khó nhất. Dấu vết AI của họ — token, code, prototype thất bại — sẽ rất lớn.

Một số kết luận từ thử nghiệm cá nhân của tác giả bài viết:

• Cửa sổ ngữ cảnh: Ngay cả model mạnh nhất vẫn mắc lỗi khi ngữ cảnh dài. Giới hạn ở mức 50% và cảnh báo khi vượt 20%.
• Tự chủ: Agent rất "chủ động", có thể tự tạo PR, push lên nhánh chính, dựng tính năng bạn không yêu cầu. Cần định nghĩa nhiệm vụ rõ ràng từ đầu và dùng guardrails.
• Code review: Con người vẫn cần review. Agent thường "tự điền" những quyết định không có trong spec, dẫn đến code thừa thãi hoặc tệ. Nếu quan trọng, phải đọc code trước khi merge.
• Codebase dễ tìm kiếm: Agent dùng grep để hiểu codebase. Nếu code không tuân theo nguyên tắc "tên nói lên ý nghĩa", agent sẽ khó load đủ ngữ cảnh. Không nên lưu file Markdown như spec.md trong repo vì sẽ làm nhiễu.
• AI review độc lập: Dùng một agent QA từ dòng model khác với agent lập trình giúp phát hiện bug tốt hơn. Nhưng QA agent hay soi mói, nên cần con người quyết định cái gì cần sửa.

Dấu vết AI không phải là đóng góp

Tiêu thụ token nhiều không chứng minh điều gì. Nhưng thử nghiệm nghiêm túc để lại dấu vết rõ ràng. Nếu bạn test model frontier, xây harness, so sánh workflow, nghiên cứu lỗi của agent — bạn sẽ đốt token và tạo code.

Trong quá khứ, kỹ sư cao cấp có thể dựa vào phân quyền để tạo ảnh hưởng vì quy trình đã được hiểu rõ. Ngày nay, chính quy trình là thứ đang được thiết kế. Phân quyền thử nghiệm đồng nghĩa với việc từ bỏ nguồn phán đoán của chính mình. Khi thực hành có thể ổn định trở lại, điều này có thể thay đổi — nhưng không phải bây giờ.