Chúng ta đang sống trong một giai đoạn mà chỉ cần vài câu prompt, một component phức tạp, một thuật toán, thậm chí cả một file CI/CD có thể xuất hiện sau vài giây. AI không còn là câu chuyện của tương lai. Nó đã bước thẳng vào quy trình làm việc hằng ngày của kỹ sư phần mềm.
Vấn đề không nằm ở bản thân công nghệ.
Vấn đề nằm ở ranh giới rất mỏng giữa hai cách dùng:
- Dùng AI như công cụ mở rộng năng lực tư duy
- Dùng AI như bộ não thay thế cho chính mình
Nếu đi lệch về vế thứ hai, cái giá phải trả không phải là một bug nhỏ. Cái giá là sự teo lại của năng lực phản biện, tư duy hệ thống và bản lĩnh kỹ thuật.
Một Sự Dịch Chuyển Đáng Lo Trong Cách Giải Quyết Vấn Đề
Trước đây, khi gặp một bug khó hoặc một feature mới có nhiều ràng buộc, quy trình của kỹ sư thường diễn ra như sau:
- Đọc documentation hoặc RFC
- Tìm nhiều nguồn tham khảo
- So sánh các hướng tiếp cận
- Tự dựng mental model về luồng dữ liệu và hành vi hệ thống
- Thử, sai, debug, sửa, rồi mới kết luận
Quy trình đó chậm. Nó mệt. Nhưng nó ép bộ não phải hoạt động đến nơi đến chốn.
Ngày nay, nhiều người đã rút quy trình đó xuống còn:
- Copy lỗi vào AI
- Paste yêu cầu
- Nhận code trả về
- Chạy local thấy ổn
- Merge
Mọi thứ nhanh hơn rất nhiều, nhưng tốc độ đó thường được mua bằng việc cắt bỏ giai đoạn "tiêu hóa kiến thức". Kỹ sư nhận được kết quả, nhưng không thật sự hấp thụ được cấu trúc tư duy tạo ra kết quả đó.
Lỗ Hổng Nằm Ở Những Câu Hỏi Không Còn Được Đặt Ra
Đoạn code có chạy được hay không chưa bao giờ là thước đo đủ tốt cho chất lượng kỹ thuật.
Điều quan trọng hơn là những câu hỏi mà kỹ sư có còn đặt ra nữa hay không:
- Tại sao giải pháp này đúng?
- Có phương án nào phù hợp hơn với hệ thống hiện tại không?
- Trade-off về hiệu năng, khả năng bảo trì, độ phức tạp vận hành là gì?
- Điều gì sẽ xảy ra nếu lượng người dùng tăng gấp mười hoặc gấp một trăm?
Khi các câu hỏi đó biến mất, sản phẩm có thể vẫn được giao đúng hạn, nhưng người làm ra nó lại không trưởng thành tương ứng.
Đó là trạng thái nguy hiểm nhất: năng suất nhìn có vẻ tăng, còn năng lực thực tế thì đứng yên hoặc đi lùi.
Giá Trị Của Kỹ Sư Không Nằm Ở Việc Gõ Code
Nếu định nghĩa công việc của software engineer chỉ là viết ra code để tạo feature, chúng ta đang tự hạ thấp vai trò của chính mình.
Viết code chỉ là bước cuối cùng của chuỗi giải quyết vấn đề.
Giá trị thật sự nằm ở:
- Bóc tách một yêu cầu mơ hồ thành một bài toán có thể triển khai
- Hiểu kiến trúc hiện tại đủ sâu để biết nên mở rộng hay nên tái cấu trúc
- Dự đoán technical debt mà một quyết định hôm nay sẽ để lại trong 6 tháng hoặc 2 năm tới
- Cân bằng giữa delivery speed, maintainability, performance và reliability
AI có thể sinh ra một hàm nhanh hơn con người. Nhưng nó không chịu trách nhiệm cho hệ quả dài hạn của quyết định kỹ thuật đó trong chính codebase của bạn.
Hai Kiểu Người Đang Xuất Hiện Rõ Ràng
Khi AI trở thành công cụ đại trà, thị trường kỹ sư bắt đầu tách thành hai nhóm.
Người Dùng AI
Nhóm này xem AI như một cỗ máy ra đáp án. Họ đưa đề bài, lấy kết quả, vá vào hệ thống và tiếp tục vòng lặp tiếp theo.
Điểm yếu lớn nhất của cách làm này là họ gần như không sở hữu lời giải. Nếu bị hỏi sâu hơn trong code review, khi sự cố production xuất hiện, hoặc khi cần scale giải pháp lên một bối cảnh phức tạp hơn, họ không còn điểm tựa tư duy để xử lý.
Người Cộng Tác Với AI
Nhóm này xem AI là một copilot hoặc một sparring partner.
Họ vẫn là người giữ tay lái:
- Tự dựng mô hình bài toán trước
- Dùng AI để mở rộng góc nhìn hoặc tăng tốc phần thực thi
- Bắt AI giải thích vì sao một lựa chọn được đưa ra
- So sánh câu trả lời với ngữ cảnh thực tế của hệ thống
- Sẵn sàng refactor hoặc bác bỏ hoàn toàn gợi ý của AI
Khác biệt cốt lõi không nằm ở việc có dùng AI hay không. Khác biệt nằm ở ai là người đang điều khiển quá trình tư duy.
Checklist 4 Bước Để Dùng AI Mà Không Đánh Mất Chất Kỹ Sư
Đây là bộ kiểm tra ngắn mà tôi cho rằng kỹ sư nên tự áp dụng trước khi merge bất kỳ đoạn code nào do AI hỗ trợ tạo ra.
1. Mental Model First
Đừng mở AI ngay ở giây đầu tiên.
Hãy dành 10 đến 15 phút để:
- Tự phân tích requirement
- Xác định vùng lỗi hoặc ràng buộc của feature
- Vẽ nhanh data flow hoặc call flow nếu cần
- Đọc lại docs chính thức hay code liên quan trong hệ thống
Nếu bản thân chưa hiểu bài toán, bạn sẽ không thể đánh giá chất lượng câu trả lời của AI.
2. Hỏi Có Chiều Sâu, Không Xin Đáp Án
Prompt tốt không chỉ là prompt rõ. Nó phải mang tính kỹ thuật.
Thay vì hỏi:
Viết giúp tôi tính năng này.
Hãy hỏi:
Tôi đang cân nhắc hướng X để giải quyết bài toán Y trong bối cảnh Z. Trade-off của hướng này là gì và có lỗ hổng kiến trúc nào cần lưu ý không?
Cách hỏi này buộc AI đóng vai trò phản biện, thay vì vai trò làm bài hộ.
3. Review Ngược Lại Đoạn Code AI Sinh Ra
Đừng đối xử với output của AI như chân lý.
Hãy tự kiểm tra:
- Độ phức tạp thời gian và bộ nhớ
- Các vấn đề quen thuộc như N+1 query, blocking I/O, race condition, memory leak
- Khả năng phát sinh lỗ hổng bảo mật như SQL injection, XSS hoặc lộ dữ liệu
- Tính phù hợp với coding conventions và kiến trúc hiện tại
Nếu bạn không giải thích được tại sao đoạn code đó tồn tại, bạn chưa nên đưa nó lên production.
4. Giữ Quyền Sở Hữu Cuối Cùng
AI có thể viết nháp. Kỹ sư phải là người chịu trách nhiệm cuối cùng.
Trước khi merge, hãy tự hỏi:
- Tôi có dám giải thích đoạn này với tech lead trong buổi review không?
- Tôi có biết nên debug từ đâu nếu production lỗi lúc 2 giờ sáng không?
- Tôi có hiểu vì sao chọn giải pháp này thay vì hai phương án còn lại không?
Nếu câu trả lời là không, thì vấn đề không nằm ở AI. Vấn đề là chúng ta đang ký tên vào một quyết định kỹ thuật mà mình chưa thực sự sở hữu.
AI Nên Là Đòn Bẩy, Không Phải Nạng Chống
AI có thể giải phóng kỹ sư khỏi rất nhiều việc lặp lại:
- viết boilerplate
- gợi ý test cases
- tóm tắt tài liệu dài
- tạo skeleton cho một ý tưởng mới
Đó là giá trị thật và rất lớn.
Nhưng nếu để AI nghĩ thay, phân tích thay, phản biện thay và quyết định thay, chúng ta sẽ biến một công cụ tăng lực thành chiếc "bánh xe lăn" cho tư duy.
Ngành phần mềm không thưởng lớn nhất cho người gõ code nhanh nhất. Nó thưởng cho người hiểu hệ thống sâu nhất, ra quyết định tỉnh táo nhất và chịu trách nhiệm tốt nhất với hậu quả của những quyết định đó.
AI nên giúp chúng ta leo cao hơn.
Nó không nên khiến chúng ta quên mất cách tự đứng bằng chính đôi chân kỹ thuật của mình.