#Softwareengineering

AI không giải phóng thời gian - nó mở rộng kỳ vọng. Bạn làm nhanh hơn, nhưng sẽ phải làm nhiều hơn, kiểm tra nhiều hơn, và học thêm liên tục để không bị bỏ lại. Nhưng cũng có cách để không bị AI "ăn thịt" mà vẫn tận dụng được nó. Ông bạn tôi - một PM khá giỏi, 8 năm kinh nghiệm - nhắn tin lúc 11 giờ đêm thứ Sáu. Nội dung: "Anh ơi, sao em dùng Copilot rồi mà còn bận hơn trước vậy?" Tôi cười, vì câu đó chính xác là điều tôi muốn nghe để viết bài này. Trước đó vài tháng, cả team ông bạn tôi được trang bị GitHub Copilot, Microsoft 365 Copilot, và một đống AI tool khác. Ban đầu ai cũng hào hứng. Code review nhanh hơn. Email draft xong trong 2 phút. Document có AI tóm tắt. Cuộc họp có transcript tự động. Hai tháng sau, ông ấy đang ngồi 11 giờ đêm thứ Sáu hoàn thiện nốt phần requirements mà AI vừa generate ra nhưng sai đủ kiểu cần phải sửa lại từ đầu. Chào mừng đến với "AI productivity paradox" - cái nghịch lý mà hàng triệu người đang trải qua nhưng ít ai nói thẳng ra.

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.

Năm 25 tuổi tôi nghĩ học nhiều công nghệ nhất là cách tiến xa nhất. Sai hoàn toàn. Đây là 5 bài học mà nếu biết sớm hơn, tôi đã đỡ mất rất nhiều thời gian - và cả tiền.

Nói "không bao giờ compromise clean code" là dễ. Thực tế khó hơn nhiều. Bài này là framework tôi dùng sau 20 năm để quyết định: thỏa hiệp cái gì, không thỏa hiệp cái gì - và làm thế nào để không bị debt giết sau này.