Kỹ sư phần mềm: Rủi ro không dùng và dùng sai AI

Không phải AI thay thế bạn, mà là người dùng AI

Mình viết bài này dành cho các kỹ sư phần mềm AI đang đứng trước câu hỏi này: một bên chưa áp dụng AI vào công việc, một bên đã áp dụng nhưng sai cách.

Mấy hôm nay công ty mình rục rịch triển khai khung năng lực phát triển cho nhân sự, nhưng không phải là một khung năng lực thông thường, mà là khung đánh giá năng lực trong việc áp dụng AI vào công việc hằng ngày.

Nghe thì đơn thuần thì là một cái khung năng lực thôi, nhưng nó sẽ là một phần trong những tiêu chí để đánh giá xếp loại tăng lương, xếp loại cuối năm, thưởng…

Về cơ bản thì mình đồng ý với việc anh chị em kỹ sư phần mềm nên áp dụng triệt để AI vào công việc, cái này sẽ tối ưu hóa hiệu suất hơn cho công việc, thời gian bàn giao sản phẩm nhanh hơn đáng kể, chất lượng sản phẩm cũng được đẩy mạnh.

Trước đây, kể cả khi chưa có AI Agent, việc đảm bảo chất lượng sản phẩm khi code đối với mình là một yếu tố then chốt. Mình ít khi để lọt bug vớ vẩn và càng không muốn để lọt bất kỳ bug nào trước khi bàn giao sang QC.

Giờ khi áp dụng Spec Driven Development vào trong công việc thực tế rồi, thì tỉ lệ lỗi gần như không tồn tại, chưa kể tốc độ và chất lượng sản phẩm được nâng lên cực mạnh.

Tuy nhiên, có một nghịch lý tồn tại song song, đó là mình thấy chưa hẳn là quá nhanh.

Quá nhanh ở đây được hiểu là kiểu mọi người cứ luôn nghĩ rằng cứ prompt 1 vài đoạn, AI gen code, test, sau đó bàn giao QC rồi tưởng như thế là nhanh. Thực tế là chất lượng sản phẩm lúc này khá kém, ít tỉ mỉ, không trau chuốt.

Hướng đi đúng không phải là làm nhanh, làm vội và rồi coi đó là kết quả của sự thành công khi áp dụng AI, mà phải là dùng AI nhưng hỗ trợ công việc và đem lại giá trị thực sự:

• Trace bug trên production nhanh , chính xác hơn, xử lý vấn đề, phân tích root cause chuẩn
• Chất lượng sản phẩm bàn giao ít bug, ít issue, ít bị QC reopen task hơn
• Tốc độ triển khai nhanh nhưng chất lượng đi kèm phải ngon tương xứng

Dạo gần đây khi làm SDD nhiều, mình ít phải code hơn rồi, vì mình đã lập riêng cho bản thân một nhóm agent team hỗ trợ mình trong công việc, giờ mình chỉ đóng cái vai là Engineering Manager thôi.

Tất nhiên là mình phải review và rà soát kỹ hơn, có thể là đọc đi đọc lại để xem xét Claude viết có sai không, follow đúng nghiệp vụ chưa, còn miss các case test nào không, ngoài ra còn để tránh một số vấn đề ảo giác khi làm việc với AI.

Tình cờ, bài post mình chia sẻ trên Linkedin cũng được khá nhiều người quan tâm. Cái ảnh này là trong lần làm việc với Claude Code, mình review kỹ thì thấy nó đọc workflow mình định nghĩa trước nhưng lại làm sai.

Nhiệm vụ khi áp dụng AI triệt để vào công việc quả thực không hề ít đi, mà phải là nhiều hơn gấp nhiều lần, lúc này nhiệm vụ của mình đa phần sẽ như này:

• Cùng AI Agent phân tích tài liệu, đọc findings của agent rồi phán xét cái nào thực sự là vấn đề, cái nào false positive.
• Đưa ra quyết định trade-off cuối cùng, agent có thể list ra 5 options nhưng chỉ mình mới biết cái nào phù hợp với bối cảnh của sản phẩm/nghiệp vụ/team.
• Review spec trước khi để agent tiến hành triển khai.
• Verify lại kết quả, agent nói rằng “done” nhưng chưa chắc đúng ý của mình đâu, cứ phải kiểm tra thực tế.
• Kiểm tra những gì agent đã bỏ sót, domain knowledge, business rules ngầm định.

Dạo gần đây mình phải review hơi nhiều, nên mình quyết định nâng cấp Skills /analyze-ba bằng cách tạo ra thêm một agent độc lập. Nó sẽ chịu trách nhiệm review nếu hoàn thành công việc ở một vài phase nhất định (không phải tất cả các phase).

Agent độc lập này sẽ chủ động verify lại kết quả sau khi thực thi dựa theo các loại tài liệu chuẩn đã tạo, trao đổi và đưa ra phản hồi với main agent nếu phát hiện làm sai tài liệu (tức là cho phép nó trao đổi với nhau).

Sau đó, main agent sẽ tiến hành xử lý lại nếu có vấn đề. Khi nào làm đúng thì agent làm nhiệm vụ review, mới đưa sang cho mình review tổng. Như vậy sẽ đỡ công phải review thủ công từng task mà agent implement.

Rủi ro kỹ sư phần mềm gặp khi không áp dụng AI

Nếu không bắt đầu sớm, khoảng cách sẽ tự nó giãn ra sau mỗi sprint và đến lúc nhận ra thì đã khá muộn.

• Người dùng AI tốt trong team làm được 3x, bạn vẫn 1x, khoảng cách năng suất ngày càng rõ hơn sau mỗi sprint
• JD tuyển dụng đã bắt đầu ghi “AI proficiency required”, không còn là “preferred” nữa
• Không phải bị AI thay thế, mà bị đồng nghiệp cùng team, cùng vị trí nhưng biết dùng AI thay thế

Rủi ro nếu áp dụng không đúng

Nhưng áp dụng AI không đúng cách còn để lại hậu quả nặng hơn là không áp dụng, vì nó tạo ra cảm giác đang làm tốt trong khi thực tế thì không.

• Ảo tưởng tốc độ: ship nhanh nhưng bug nhiều, QC reopen liên tục, net productivity thực ra là âm
• Lệ thuộc AI quá mức, đến khi AI sai thì không nhận ra vì không còn đủ context để verify
• Hallucination chui vào production: agent nói “done” là tin, không review kỹ, lỗi nghiệp vụ ngầm định rất khó trace
• Junior gen code bằng AI mà không hiểu tại sao, sau 2–3 năm vẫn junior, chỉ thâm niên nhiều hơn
• AI-generated code chạy được nhưng không ai thực sự hiểu, đến lúc cần maintain hoặc debug production thì không ai dám đụng vào

Kỹ sư phần mềm dùng AI đúng cách sẽ như thế nào?

Không có một công thức cố định, nhưng có một điều mình thấy khá rõ sau một thời gian làm SDD: nhiệm vụ không hề ít đi, nó chỉ thay đổi chất.

Thay vì ngồi code, mình phải đọc kết quả của agent và phán xét nó có đúng không, thay vì tự viết spec thì phải review spec agent đã draft, thay vì debug từng dòng thì phải hiểu đủ để biết AI đang sai ở đâu.

Kỹ sư phần mềm AI giỏi không phải là người dùng AI nhiều nhất, mà là người biết khi nào nên tin AI, khi nào phải tự làm, và luôn đủ context để có thể verify được kết quả trước khi bàn giao.

Lý do mình viết bài này khá đơn giản: mình đang thấy có nhiều người bị tụt lại, và có người thì đang dùng AI theo kiểu tạo thêm vấn đề hơn là giải quyết, cả hai đều đáng tiếc như nhau.

Xem thêm các bài viết nổi bật bên dưới:

• Spec Driven Development: Workflow với Claude Code
• Tôi đã xoá hơn 3 triệu ảnh rác từ hệ thống legacy
• Xác thực giao dịch trong hệ thống tài chính
• Đồng nghiệp tôi vừa mới Golive và bùm, race condition
• Tổng hợp dữ liệu cho 1 triệu tài khoản trong 4 phút
• Xử lý lỗi lệch múi giờ khi dùng Mapstruct
• Có CodeRabbit làm tôi review code cũng nhàn hơn
• Lỗi trên môi trường Staging mà không ai chịu sửa đến cùng
• Filter Spring và pha xử lý bug nhớ đời
• Những thói quen tốt trong ngành phát triển phần mềm
• Rest API: Cách Ngăn Chặn Duplicate Request Hiệu Quả
• Sức mạnh của AI CLI – trợ thủ đắc lực cho dân lập trình
• Những điều khó đỡ trong ngành phần mềm #1
• “Bàn lùi” – hay là tư duy trách nhiệm bị hiểu nhầm?
• Hãy học cách báo bug có tâm