kỹ sư phần mềm trong kỷ nguyên AI

Cái khó nhất của lập trình không phải viết code, mà là hiểu code. Còn cái nguy nhất của AI là nó viết ra thứ khiến bạn tưởng mình đã hiểu.

Chưa bao giờ trong lịch sử ngành IT, một dòng code lại rẻ như bây giờ.

Một câu prompt ngắn trên Cursor, Claude Code hay GitHub Copilot là bạn có ngay một class hoàn chỉnh, một hàm xử lý thuật toán phức tạp, thậm chí cả bộ khung microservice, chưa tới 10 giây. Các hội nhóm công nghệ thì rần rần: "Năng suất tăng gấp 5 lần", "Một lập trình viên giờ bằng cả đội 10 người", rồi mấy tiêu đề giật gân kiểu "Nghề viết code sắp chấm hết".

Nhưng hết hứng khởi ban đầu, đem vào hệ thống tài chính, ngân hàng hay hệ thống phân tán gánh hàng triệu request mỗi ngày, mấy anh em kỹ sư lâu năm bắt đầu thấy những vết nứt khá nguy hiểm phía sau bức tranh màu hồng đó.

Tốc độ viết code (Code Generation) tăng vọt, nhưng phần kiểm thử, review và duy trì hệ thống (Maintenance & Debugging) lại đang quá tải hơn bao giờ hết.

Dưới đây là mấy suy nghĩ thẳng thắn của mình: những nghịch lý ít ai để ý, cái bẫy làm mai một kỹ năng nền tảng, và cách một kỹ sư phần mềm định vị lại giá trị của mình khi làm việc cùng AI.

# nghịch lý năng suất (the productivity paradox)

Đang có một sự nhầm lẫn khá tai hại: coi tốc độ gõ phím là năng suất làm phần mềm.

Trong vòng đời một tính năng (SDLC), thời gian thật sự gõ code chỉ chiếm phần nhỏ, theo mình ước chừng 15 - 20% (con số này mỗi team mỗi khác, đừng coi là số đo chính xác). Phần lớn thời gian còn lại dành cho:

Làm rõ yêu cầu nghiệp vụ và các trường hợp biên (Edge cases).
Thiết kế kiến trúc chịu tải, tính chuyện nhất quán dữ liệu (Data Consistency).
Đọc, hiểu và đối chiếu với code hiện có (Codebase Context).
Debug mấy lỗi ngầm (Race conditions, Memory Leaks, Deadlocks).

AI làm cực tốt phần 15% (gõ code). Cái dở là: code sinh ra càng nhiều thì 85% còn lại càng nặng, vì ai đó vẫn phải đọc, hiểu, review và gỡ lỗi từng dòng.

Có một số liệu đáng suy nghĩ. Năm 2025, METR làm một thí nghiệm có đối chứng ngẫu nhiên: 16 dev open-source nhiều kinh nghiệm giải 246 issue thật trên chính các repo lớn họ đã quen. Khi được dùng AI (chủ yếu Cursor với Claude 3.5/3.7 Sonnet), họ làm chậm hơn 19%, trong khi chính họ lại tin mình nhanh hơn khoảng 20%. Mẫu nhỏ, công cụ giờ cũng đã khác, METR cũng tự ghi rằng kết quả không còn đại diện cho công cụ hiện tại, nên đừng coi đây là chân lý. Nhưng khoảng cách giữa "cảm thấy nhanh" và "thật sự nhanh" thì rất đáng để ý. (METR, 07/2025)

Khi một dev dùng AI sinh ra 500 dòng code trong 1 phút:

Bạn mất bao lâu để đọc và chắc chắn 500 dòng đó không dính SQL Injection hay logic phá transaction?
Pull request gửi lên, ai đủ gan bấm Approve một khối code to đùng, trông "rất có lý", mà chẳng ai trong team tự tay viết?

Mình đang chuyển từ "làm phần mềm thủ công" sang "dọn bãi chiến trường của phần mềm làm theo dây chuyền".

# cái bẫy của developer thời ai

# bẫy mai một kỹ năng nền tảng (the skill atrophy trap)

Thử tưởng tượng một phi công chỉ biết bay bằng chế độ lái tự động (Autopilot). Trời đẹp thì mọi thứ ổn. Nhưng gặp bão, động cơ trục trặc, hệ thống tự động ngắt, lúc đó chỉ có kỹ năng bay tay mới cứu được hành khách.

Lập trình cũng vậy:

Trước đây, muốn sửa một lỗi OutOfMemoryError hay ConcurrentModificationException, bạn phải mở profiler, xem heap dump, lần theo stack trace và hiểu Garbage Collector chạy thế nào. Chính mấy lần vật vã đó rèn ra trực giác của một Senior Engineer.
Bây giờ, phản xạ đầu tiên của nhiều bạn trẻ là: copy lỗi → paste vào Claude → copy đoạn code gợi ý → paste lại vào project. Code chạy! Nhưng trong đầu thì: trống trơn về kiến thức.

Không hiểu TCP bắt tay 3 bước thì bạn không debug được vì sao kết nối gRPC thỉnh thoảng lại timeout. Không hiểu Isolation Level trong Database thì bạn sẽ không nhận ra đoạn code AI viết kiểu "đọc số dư, cộng trừ trong Java, rồi ghi lại" đang mở cửa cho lỗi Lost Update trong giao dịch ngân hàng: ở mức READ COMMITTED mặc định của PostgreSQL hay Oracle, hai giao dịch chạy song song có thể ghi đè lên nhau mà không ai báo lỗi. Cái tiện trước mắt đang lặng lẽ lấy đi khả năng suy nghĩ sâu của lập trình viên.

# khủng hoảng review và nợ kỹ thuật vô hình (invisible technical debt)

AI có một tật kinh niên: tự tin quá mức (Hallucination & Over-confidence). Code nó viết lúc nào cũng thụt lề chuẩn, tên biến kêu, comment chi tiết, nhìn qua ai cũng tưởng ngon.

Nhưng bên dưới lớp vỏ bóng bẩy đó là:

Code Bloat: AI hay viết dài dòng, đẻ ra mấy lớp abstract thừa chỉ để chiều theo prompt.
Rò rỉ tài nguyên ngầm: quên đóng connection, mở transaction quá lâu làm khoá bảng (Lock contention), hoặc lạm dụng CompletableFuture mà không có Thread Pool riêng → traffic tăng là cạn tài nguyên máy chủ.
Reviewer lướt qua: thấy format đẹp, có vài test case sơ sài → bấm Merge. Nợ kỹ thuật cứ thế tích lại, thành quả bom nổ chậm trên Production.

# thư viện "ma" và rủi ro bảo mật chuỗi cung ứng (package hallucination)

Một kiểu tấn công đang rất đáng lo hiện nay là Slopsquatting (cái tên do Seth Larson bên Python Software Foundation đặt), tức khai thác chuyện AI bịa ra tên package. Nghiên cứu "We Have a Package for You!" (USENIX Security 2025) cho 16 model sinh 2,23 triệu mẫu code Python và JavaScript, và thấy khoảng 19,7% package được nhắc tới là không hề tồn tại (paper). Kịch bản tấn công thế này:

Khi bạn nhờ AI giải một bài toán đặc thù, đôi khi nó tự bịa ra một tên thư viện nghe rất uy tín (ví dụ: spring-security-jwt-extended-v2).
Kẻ tấn công ngồi phân tích các câu trả lời phổ biến của LLM, tìm ra cái tên "ma" đó, rồi lên npm hoặc PyPI đăng ký đúng tên đó kèm mã độc (Trojan / Backdoor). Maven Central khó hơn một chút vì bắt xác minh quyền sở hữu groupId (domain hoặc tài khoản GitHub), nhưng kẻ tấn công vẫn có thể đăng dưới một groupId nghe na ná.
Dev vô tư copy đoạn pom.xml hoặc lệnh npm install vào dự án công ty → hệ thống bị xâm nhập. Với npm còn tệ hơn: script postinstall chạy ngay lúc cài, chưa cần import package vào code.

Cách phòng thì không có gì cao siêu: thấy tên dependency lạ thì tra trên registry xem ai publish, publish từ bao giờ, bao nhiêu lượt tải; công ty nên đi qua một registry proxy nội bộ (Nexus, Artifactory) có danh sách cho phép, và bật quét dependency trong CI.

TIP

Nguyên tắc khi dùng AI sinh code: luôn bắt AI giải thích "Trade-off" (đánh đổi) và "Edge cases" (trường hợp biên), đừng chỉ nhận code về. Nếu bạn không tự giải thích lại được từng dòng cho đồng nghiệp trong 2 phút thì đừng đưa nó vào pull request.

# vai trò thay đổi: từ code typist sang system orchestrator

Nếu kỹ năng gõ code đơn thuần đang mất dần giá trị, vậy kỹ sư phần mềm sẽ đi về đâu?

Kỹ sư phần mềm (Software Engineer) xưa nay chưa bao giờ là "người gõ cú pháp". Kỹ sư là người dùng công nghệ để giải quyết vấn đề. AI không giết kỹ sư phần mềm, nó chỉ làm thợ gõ code (Code Typists) hết đất sống nhanh hơn và đẩy những người làm kiến trúc hệ thống thật sự lên cao hơn.

Ở mô hình mới, trọng tâm công việc dịch chuyển hẳn:

Từ người viết (Writer) → người thẩm định, biên tập (Editor / Reviewer): bạn không cần viết từng dòng, nhưng phải đủ kiến thức để tìm ra chỗ sai trong 1.000 dòng AI viết.
Từ nghĩ theo cú pháp → nghĩ theo ràng buộc (Constraints & Boundary Thinking): phải biết đặt câu hỏi: "Mạng lag 5 giây thì sao?", "Đầu vào 1 triệu bản ghi thì thuật toán này có OOM không?", "Service bên cạnh chết thì circuit breaker chạy thế nào?".
Từ đoán mò → dựa trên bằng chứng (Evidence-Based / Verify-Driven Development): không tin dòng code nào AI viết nếu nó chưa qua được bộ test nghiêm túc (Property-based tests, Mutation tests, Integration tests với Testcontainers).

# mấy trụ cột để làm kỹ sư vững tay nghề

Muốn đứng vững và đi xa khi AI ngày càng mạnh, đây là 4 năng lực đáng đầu tư:

Trụ cột	Là gì	Vì sao AI không thay được?
1. Deep Fundamentals (Nền tảng vững)	Hiểu sâu OS, Concurrency, Memory Model, Network Protocol, Database Internals.	AI chỉ học từ bề mặt văn bản trên internet. Khi sự cố nằm ở tầng kernel hay tranh chấp luồng rất nhỏ, chỉ kiến thức gốc mới lần ra được Root Cause.
2. Domain Mastery (Hiểu nghiệp vụ)	Hiểu kỹ bài toán tài chính, ngân hàng, logistics, pháp lý, luồng tiền.	Nghiệp vụ thật nằm trong đầu các bên liên quan (Stakeholders) và trong bối cảnh chính trị/kinh doanh của công ty, không nằm trên GitHub công khai cho AI học lỏm.
3. System Architecture & Trade-offs	Biết khi nào KHÔNG NÊN dùng công nghệ mới; cân giữa Latency, Throughput, Cost và Consistency (CAP, PACELC).	AI hay đưa ra giải pháp rườm rà. Bản lĩnh của Senior là chọn giải pháp đơn giản nhất, ít phải bảo trì nhất.
4. Verify-Driven Mentality	Viết test tự động, load test, chủ động gây lỗi (Chaos Engineering), dựng Observability.	AI viết code, nhưng code đó làm mất tiền khách thì ai chịu trách nhiệm pháp lý? Con người vẫn là chốt chặn trách nhiệm cuối cùng.

# tổng kết

AI không phải kẻ thù, nhưng nó phân loại người làm nghề rất phũ.

Ai lười, chỉ thích copy-paste, ngại đào sâu thì sẽ thành thừa nhanh hơn bao giờ hết. Còn ai có nền tảng chắc thì được chắp thêm cánh: một người làm được phần việc mà trước đây cần cả một team.

Cứ dùng AI làm trợ thủ để gõ code nhanh hơn. Có điều, mỗi lần nó sửa giúp một bug khó, bỏ thêm mười phút đọc cho ra vì sao bug xảy ra; mỗi dependency nó gợi ý, tra lại trên registry; và đừng merge đoạn code nào mà bạn không tự giải thích lại được.

Chỉ là những ghi chép cá nhân với hy vọng mang lại chút giá trị. Nếu thấy hữu ích, đừng ngại chia sẻ cho bạn bè & đồng nghiệp nhé!

Happy coding 😎 👍🏻 🚀 🔥.