#Techlead

Năm 2026, AI agents đang bùng nổ và nhiều người vội vã tuyên bố "prompt engineering đã chết". Sai hoàn toàn. Chain of Thought, flipping roles — những kỹ thuật cơ bản đó vẫn còn sống, chỉ là giờ chúng ta không chạy 1 luồng nữa, mà chạy song song 40 luồng cùng lúc. Bài này là câu chuyện về sự tiến hóa đó. Hôm rồi tôi ngồi cà phê với một ông bạn — tôi gọi anh là Khoa cho tiện — senior developer 6 năm, đang chuyển sang làm AI engineer ở một startup khá hot trong nước. Anh mở màn bằng một câu khiến tôi suýt đổ cà phê: "Anh ơi, prompt engineering giờ chết rồi. Giờ phải học AI agents mới là đúng hướng." Tôi nhìn anh, hỏi: "Chết theo nghĩa nào?" Anh giải thích: "Thì giờ người ta build hệ thống multi-agent rồi, AI tự lo với nhau, mình chỉ cần thiết kế workflow là xong. Ai còn ngồi viết prompt thủ công nữa?" Tôi im lặng một lúc, rồi hỏi ngược: "Thế mấy cái agent đó nó tự nhiên biết làm việc không? Hay vẫn cần ai đó chỉ cho nó cách nghĩ?" Anh Khoa dừng lại. Ừ nhỉ.

Hầu hết developer đang dùng AI chỉ một cách: giao việc và chờ kết quả. Nhưng có hai cách hiệu quả hơn nhiều - và một trong số đó có thể thay đổi hoàn toàn cách bạn làm việc. Bài này là framework tôi dùng để tự đánh giá mình đang khai thác AI đến đâu. Tuần trước tôi ngồi cà phê với một anh bạn - senior developer 8 năm kinh nghiệm, tôi gọi là anh Hưng cho dễ. Anh vừa xong một sprint khá nặng, và câu đầu tiên mở miệng là: "Mày ơi, giờ tao làm việc với AI nhiều lắm, năng suất tăng rõ rệt." Tôi gật đầu, hỏi tiếp: "Bạn đang dùng theo cách nào?" Anh Hưng giải thích: ChatGPT để viết unit test. GitHub Copilot để gợi ý code. Claude để explain stack trace. Ổn đấy. Tôi hỏi tiếp: "Còn ngoài ra?" Anh im lặng một lúc. "Ngoài ra là... mình hỏi nó trả lời, xong mình copy, sửa lại, done." Câu đó làm tôi nghĩ nhiều. Không phải vì anh Hưng dùng AI sai - mà vì câu đó mô tả chính xác cách phần lớn developer giỏi đang bỏ lỡ hai phần ba giá trị của AI.

Câu trả lời không phải là "có" hay "không" - mà là "code để làm gì". Technical leader cần code đủ để giữ credibility, hiểu trade-off, và không bị sold bởi solutions không phù hợp. Nhưng nếu bạn vẫn code như developer, bạn đang làm sai vai trò. Năm 2019, tôi được promote lên tech lead cho một dự án lớn. Tuần đầu tiên, tôi vẫn code 8 tiếng một ngày như developer. Tôi nghĩ đó là cách đúng - lead by example, lead from the front, v.v. Sau 3 tháng, team tôi frustrated. Không phải vì tôi code tệ. Mà vì: Architecture review bị chậm - tôi bận code feature Họ không có ai unblock khi bị stuck - tôi đang "in the zone" Planning meeting không có đủ context từ stakeholders - tôi không có thời gian 1:1 với business Code review của tôi cực kỳ opinionated về style thay vì về design Một senior dev trong team - người mà tôi trust nhất - nói thẳng với tôi: "Anh Son, anh đang là developer giỏi nhất trong team. Nhưng team cần tech lead, không cần developer giỏi nhất." Câu đó như một gáo nước lạnh.

Lên CEO không có nghĩa là ngừng học kỹ thuật - nhưng cách học phải thay đổi hoàn toàn. Tôi không còn đọc từng dòng tutorial, tôi học theo chiều rộng trước, sâu khi cần thiết, và luôn kết nối kiến thức mới với bài toán thực của công ty. Tháng 9 năm ngoái, trong cuộc họp với team engineering, một junior dev hỏi tôi: "Anh Son, anh có biết về Temporal workflow không? Em đang nghiên cứu cho dự án mới." Tôi dừng lại. Temporal. Tôi nghe tên rồi, nhưng chưa đủ để có ý kiến kỹ thuật. Và trong đầu tôi lúc đó có hai lựa chọn: giả vờ biết (không nên), hoặc thừa nhận và học nhanh (đúng hơn). Tôi nói: "Anh chưa deep dive vào Temporal. Em brief cho anh 5 phút, rồi mình xem fit không với dự án này." Sau cuộc họp đó, tôi dành 2 tối để đọc về Temporal. Không đủ để code được, nhưng đủ để có quan điểm architectural, đủ để hỏi câu hỏi đúng, đủ để không bị "sold" bởi một giải pháp không phù hợp. Đó là cách tôi học công nghệ mới ở tuổi này - ở vai trò này.