Mở LinkedIn, Twitter hay các báo cáo công nghệ gần đây, các CEOs và CTOs liên tục bị bủa vây bởi những con số rất hấp dẫn:
- AI giúp tăng năng suất lập trình viên
- Agentic AI rút ngắn thời gian giao hàng
- Đội ngũ nhỏ hơn vẫn có thể ship nhiều hơn
Dưới áp lực tối ưu chi phí và cuộc đua của thị trường, một mệnh lệnh ngầm rất dễ xuất hiện trong các đội ngũ kỹ thuật:
Hãy tự động hóa bằng AI càng nhiều càng tốt. Task này sao còn chậm?
Ở chiều ngược lại, tại bàn làm việc của software engineer, cảm giác lại hoàn toàn khác.
Họ bị kẹp ở giữa hai lực kéo:
- cấp trên muốn tăng tốc
- bản năng nghề nghiệp buộc họ phải chậm lại để kiểm soát hệ thống
Đây không còn là câu chuyện chăm chỉ hay lười biếng.
Đây là xung đột giữa tốc độ kinh doanh và kỷ luật kỹ nghệ.
Nỗi Sợ Bị Thay Thế Không Còn Chỉ Là Vấn Đề Cá Nhân
Trong bài Khi AI Nghĩ Thay Kỹ Sư: Công Cụ Khai Phá Hay Chiếc "Bánh Xe Lăn" Của Tư Duy?, tôi đã nói về cái bẫy khi kỹ sư ngừng suy nghĩ và để AI nghĩ thay.
Ở thời điểm đó, rủi ro chủ yếu đến từ lựa chọn cá nhân: lười tư duy, thích kết quả nhanh, dễ nghiện cảm giác "ra code ngay".
Nhưng khi doanh nghiệp bắt đầu ép tốc độ bằng AI, cùng một cái bẫy cũ lại được hợp thức hóa dưới dạng mục tiêu vận hành.
Vấn đề lúc này nguy hiểm hơn nhiều.
Người kỹ sư không còn chỉ chống lại sự cám dỗ của tiện lợi. Họ còn phải chống lại cả áp lực KPI.
Khi một tổ chức vô tình biến kỹ sư thành người chỉ việc prompt rồi merge, họ đang đẩy chính đội ngũ của mình gần hơn tới hình mẫu "AI User" thụ động, tức là kiểu vai trò dễ tổn thương nhất trong thị trường lao động mới.
Hai Phía Đều Có Lý Do Của Mình
Muốn giải quyết xung đột, trước hết phải thừa nhận rằng cả hai phía đều có logic riêng.
Chủ Doanh Nghiệp Đang Nhìn Thấy Gì?
Họ nhìn từ lăng kính kinh tế:
- đội ngũ kỹ thuật là chi phí lớn
- đối thủ đang tăng tốc bằng AI
- thời gian ra thị trường ảnh hưởng trực tiếp đến doanh thu và lợi thế cạnh tranh
Từ góc nhìn đó, AI là một đòn bẩy kinh tế quá hấp dẫn để bỏ qua.
Họ không sai về mặt kinh doanh.
Kỹ Sư Phần Mềm Đang Sợ Điều Gì?
Họ nhìn từ lăng kính hệ thống:
- code chạy được ở local chưa nói lên điều gì
- production có tải thật, dữ liệu thật và lỗi thật
- những shortcut hôm nay rất dễ trở thành technical debt ngày mai
Trong bài Technical Debt Trong Thời Đại AI: Khi Những Dòng Code "Mì Ăn Liền" Bắt Đầu Tính Lãi, tôi đã phân tích vì sao AI có thể làm nợ kỹ thuật tích lũy nhanh hơn và khó thấy hơn.
Đó chính là thứ kỹ sư đang nhìn thấy trước khi người quản lý kịp nhìn thấy hóa đơn thật.
Họ cũng không sai về mặt nghề nghiệp.
Cạm Bẫy Của Sự Vâng Lời
Nhiều kỹ sư chọn cách im lặng làm theo vì nghĩ rằng:
- sếp muốn nhanh
- AI cho ra kết quả nhanh
- mình chỉ cần đáp ứng tiến độ là xong
Đó là một ngộ nhận nguy hiểm.
Khi hệ thống dính lỗ hổng bảo mật, mất dữ liệu, hoặc sập trên production, không ai đi hỏi AI chịu trách nhiệm.
Câu hỏi luôn quay về con người:
Ai là người đã review và merge đoạn code này?
Trách nhiệm cuối cùng luôn thuộc về kỹ sư và tổ chức, không bao giờ thuộc về mô hình.
Vì vậy, làm theo một cách thụ động không phải là an toàn. Đó chỉ là trì hoãn thời điểm phải trả giá.
Kỹ Sư Cần Học Cách Đàm Phán Bằng Ngôn Ngữ Kinh Doanh
Một phản ứng rất dễ thấy là:
AI viết code rác lắm, em không muốn dùng.
Vấn đề là câu nói này đúng về trực giác kỹ thuật nhưng yếu về mặt thuyết phục tổ chức.
Ban điều hành không mua quyết định bằng cảm xúc nghề nghiệp. Họ mua bằng rủi ro, chi phí và xác suất thiệt hại.
Nếu muốn bảo vệ chất lượng hệ thống mà vẫn giữ được sự tin cậy với business, kỹ sư phải biết dịch nỗi lo kỹ thuật sang ngôn ngữ kinh doanh.
Ba Chiến Lược Đàm Phán Thực Dụng
1. Đừng Nói "Giảm Tốc", Hãy Nói "Quản Trị Rủi Ro"
Thay vì nói:
Em cần thêm 2 ngày để xem lại code AI cho chắc.
Hãy nói:
AI giúp tăng tốc phần implementation, nhưng em cần giữ lại một phần thời gian cho audit, test và kiểm tra bảo mật. Nếu bỏ bước này, xác suất xảy ra lỗi production và chi phí khắc phục sau đó sẽ cao hơn nhiều lần phần thời gian tiết kiệm được.
Điểm mấu chốt là:
- business không mua "code đẹp"
- business mua "giảm rủi ro mất tiền"
Khi bạn đóng khung cuộc trao đổi theo ngôn ngữ risk management, cuộc tranh luận sẽ trưởng thành hơn rất nhiều.
2. Áp Dụng Mô Hình Dual-Speed Development
Không phải task nào cũng đáng được "nhấn ga" như nhau.
Bạn hoàn toàn có thể chủ động phân loại:
- Task bề nổi, lặp lại, ít rủi ro: UI boilerplate, mock data, test scaffolding, migration script đơn giản
- Task cốt lõi, hệ trọng: database design, logic dòng tiền, authentication, permission model, core services
Nhóm đầu có thể dùng AI mạnh tay để tăng tốc.
Nhóm sau phải được kiểm duyệt sâu hơn, thậm chí làm thủ công ở những phần trọng yếu.
Đây không phải thái độ bảo thủ.
Đây là cách phân bổ tốc độ theo mức độ rủi ro.
3. Đổi KPI Từ Sản Lượng Sang Độ Ổn Định
Nếu KPI chỉ đo số ticket đóng được hoặc số feature được ship, AI sẽ luôn đẩy tổ chức về phía sản lượng bề mặt.
Nhưng nếu KPI bao gồm:
- uptime
- defect density
- rollback rate
- incident frequency
- cost-to-maintain
thì tổ chức sẽ tự nhiên cân bằng hơn giữa tốc độ và độ bền.
Một đội ngũ ship 10 tính năng lỗi không hiệu quả hơn đội ngũ ship 3 tính năng ổn định.
Đôi khi điều cần thay đổi không phải là kỹ sư, mà là thước đo mà tổ chức đang dùng để đánh giá kỹ sư.
Vai Trò Thật Sự Của Software Engineer Trong Thời AI
Trong bài Học Cách "Hỏi": Kỹ Năng Tối Thượng Của Một Software Engineer Trong Kỷ Nguyên AI Agents, tôi đã viết rằng kỹ năng đặt câu hỏi tốt phản ánh độ sâu tư duy của kỹ sư.
Ở bài này, tôi muốn đẩy luận điểm đó thêm một bước:
Kỹ sư giỏi không chỉ biết hỏi AI.
Kỹ sư giỏi còn biết hỏi ngược lại chính tổ chức của mình:
- task nào thực sự cần tốc độ
- task nào cần bảo toàn ngữ cảnh và ownership
- rủi ro nào business sẵn sàng chấp nhận
- chi phí nào sẽ quay lại nếu hôm nay nhấn ga quá mạnh
Đó không còn là kỹ năng thực thi.
Đó là năng lực làm người gác cổng cho chất lượng hệ thống.
Kết
Xung đột giữa doanh nghiệp và kỹ sư trong thời AI không phải là cuộc chiến giữa người tiến bộ và người cứng đầu.
Đó là cuộc va chạm giữa hai hệ quy chiếu đều hợp lý:
- business muốn sống còn bằng tốc độ
- kỹ sư muốn hệ thống sống sót bằng kỷ luật
Người kỹ sư bản lĩnh không cực đoan ở một phía.
Họ biết khi nào nên nhấn ga cùng AI để giải phóng tốc độ.
Và họ cũng biết khi nào phải đạp phanh đủ mạnh để bảo vệ production, bảo vệ người dùng, và bảo vệ chính giá trị nghề nghiệp của mình.
Trong thời đại này, có lẽ đó mới là bản lĩnh hiếm nhất.