Trình biên dịch từng được kỳ vọng sẽ chấm dứt nghề lập trình — và vì sao điều đó vẫn chưa xảy ra
Bài viết điểm lại lịch sử 70 năm của những lời hứa "tự động hóa lập trình", từ FORTRAN năm 1954 đến các coding agent hiện nay. Tác giả cho rằng AI không xóa sổ nghề lập trình mà đẩy con người lên một nấc thang mới: quyết định cần xây gì, viết đặc tả và kiểm chứng kết quả. Đi kèm là những con số đáng chú ý về năng suất, chất lượng mã nguồn và tác động lên lao động trẻ.

Trình biên dịch từng được kỳ vọng sẽ chấm dứt nghề lập trình
Cứ mỗi khi một công cụ mới xuất hiện, lại có người tuyên bố nghề lập trình sắp kết thúc. Điều đó đã xảy ra từ năm 1954 với FORTRAN, và lặp lại với trình biên dịch, IDE, Stack Overflow, npm, GitHub Copilot, cho đến các coding agent hôm nay.
Bài viết mới đây trên Hacker News gợi lại một câu chuyện thú vị: mỗi nấc thang công nghệ đều lấy đi một phần việc thủ công, nhưng nghề lập trình lại tiếp tục phình to. Câu hỏi đáng bàn không phải là "AI có giết nghề lập trình không", mà là "nấc thang này khác gì những nấc trước".
Bài học từ năm 1954: khi FORTRAN được cho là sẽ "xóa sổ việc lập trình"
Ngày 10/11/1954, nhóm nghiên cứu của IBM hoàn tất báo cáo sơ bộ về một ngôn ngữ mới tên là FORTRAN. Trong đó có một câu đầy tự tin: FORTRAN "về cơ bản sẽ loại bỏ việc viết mã và gỡ lỗi".
Thời đó, trình hợp dịch và trình biên dịch được gọi chung là "lập trình tự động". Bạn mô tả điều mình muốn, máy sẽ viết chương trình.
FORTRAN ra mắt năm 1957 và thật sự đã loại bỏ một kiểu lập trình: gần như không ai còn dịch công thức thành lệnh máy bằng tay. Nhưng gỡ lỗi vẫn sống khỏe, và số lập trình viên tăng lên chứ không giảm.
Một ví dụ khác đáng nhớ là năm 1981, khi công ty Anh D.J. "AI" Systems bán một công cụ sinh chương trình BASIC có tên The Last One — "chương trình cuối cùng bạn cần mua". Tên gọi chính là toàn bộ chiêu quảng cáo. Nhưng nó không phải là chương trình cuối cùng.
Vì sao nấc thang AI lần này lại khác
Điểm khác biệt lớn nhất không phải là bản chất, mà là tốc độ. GitHub Copilot ra bản xem trước tháng 6/2021. Đến năm 2025, theo khảo sát của Stack Overflow, 84% lập trình viên đã dùng hoặc đang có kế hoạch dùng công cụ AI. Chỉ bốn năm để một thứ lạ lẫm trở thành mặc định.
Nhưng tốc độ phổ cập không đồng nghĩa với sự hài lòng:
- Tỷ lệ lập trình viên có thái độ tích cực giảm từ 77% (2023) xuống 60% (2025), chỉ nhích lên 62% năm 2026.
- Năm 2025, 46% lập trình viên không tin vào độ chính xác của đầu ra AI, so với 33% tin tưởng.
- 66% chọn nỗi bực bội lớn nhất là "giải pháp AI gần đúng nhưng không đúng hẳn".
Đó là kiểu sai đắt tiền, vì bạn phải đọc từng dòng để tìm chỗ chưa đúng. 45% cho biết gỡ lỗi mã do AI sinh ra mất nhiều thời gian hơn.
Cảm giác nhanh không phải là phép đo
Nghiên cứu gây tranh cãi nhất của giai đoạn AI là thử nghiệm của METR đầu năm 2025. Mười sáu lập trình viên mã nguồn mở giàu kinh nghiệm làm 246 issue thật trong chính kho mã của họ, mỗi việc được gán ngẫu nhiên "được dùng AI" hoặc "cấm dùng AI".
Trước khi bắt đầu, họ dự đoán AI giúp giảm 24% thời gian. Khi xong việc, họ tin rằng mình đã nhanh hơn 20%. Nhưng đồng hồ nói ngược lại: dùng AI mất thêm 19% thời gian.
METR sau đó thử làm lại với quy mô lớn hơn nhưng thất bại, một phần vì nhiều lập trình viên từ chối tham gia nhóm không có AI. Đây có lẽ là cách một thử nghiệm "thất bại rất đặc trưng của năm 2026".
Bài học rút ra không phải là "AI làm chậm mọi người", mà là: nếu muốn biết AI có giúp đội bạn nhanh hơn không, hãy đo đạc như mọi thứ khác, đừng dựa vào cảm giác.
Khi viết mã trở nên rẻ, hàng đợi dịch chuyển về phía review
Dữ liệu từ Faros AI năm 2025 trên hơn 10.000 lập trình viên cho thấy các đội ứng dụng AI mạnh hoàn thành nhiều task hơn 21% và merge nhiều pull request hơn 98%, nhưng thời gian review tăng 91%.
Đến năm 2026, với 22.000 lập trình viên, bức tranh còn rõ hơn:
- Số task hoàn thành mỗi người tăng 34%.
- Thời gian review trung vị tăng gấp năm lần.
- 31% pull request được merge mà không qua review nào.
- Tỷ lệ sự cố trên mỗi pull request tăng hơn gấp ba.
Mã rẻ hơn, nhưng đọc mã lại đắt hơn — và một số đội đã âm thầm ngừng đọc. Trong khi đó, Veracode kiểm tra hơn 100 mô hình ngôn ngữ với 80 bài toán lập trình và phát hiện 45% kết quả có lỗ hổng bảo mật.
Nỗi lo lớn nhất: thế hệ kỹ sư tiếp theo đến từ đâu?
Phần dữ liệu khiến tác giả bài viết bận tâm nhất là về lao động trẻ. Nghiên cứu của Erik Brynjolfsson và cộng sự tại Stanford, dùng dữ liệu lương từ ADP, cho thấy việc làm của lập trình viên 22–25 tuổi giảm gần 20% so với đỉnh cuối năm 2022. Nhóm lập trình viên lớn tuổi hầu như không thay đổi.
Kỹ sư giỏi trưởng thành từ việc làm những ticket nhỏ nhàm chán trên các đội thật, để production sập một lần, rồi được người đi trước giải thích vì sao. Nếu agent làm hết các ticket đó, kỹ sư kế cận sẽ đến từ đâu?
Đây là câu hỏi chưa có lời giải rõ ràng. Giả thuyết hợp lý: các đội làm tốt vào năm 2035 sẽ là những đội vẫn tuyển người mới trong năm 2026 và trao cho họ một kiểu học nghề khác — review việc của agent bên cạnh một kỹ sư cấp cao, sở hữu trọn vẹn một hệ thống nhỏ, và viết đặc tả cùng kiểm thử để agent dựa vào.
Năm dự đoán cho năm 2031
Bài viết đưa ra một số dự báo đáng chú ý:
- Đội nhỏ hơn nhưng nhiều hơn: Theo Jared Friedman của Y Combinator, một phần tư lô Winter 2025 có kho mã khoảng 95% do AI sinh. Nhưng Cục Thống kê Lao động Mỹ vẫn dự báo tăng trưởng 10% cho nhóm việc lập trình viên và kiểm thử từ 2025 đến 2035, nhờ hiệu ứng Jevons — thứ gì rẻ đi thì ta muốn dùng nhiều hơn.
- Đặc tả và kiểm thử trở thành nguồn gốc: Mã nguồn dần giống đầu ra của trình biên dịch — có thể mở ra xem nhưng hiếm khi sửa tay.
- Phần mềm cho một người dùng: Khi một công cụ chỉ tốn một buổi tối thay vì một quý, người ta sẽ làm phần mềm như làm bảng tính ngày nay — giải quyết một vấn đề, xong thì bỏ.
- Đọc mã trở thành một nghề: Vai trò kiểu "kỹ sư kiểm chứng" sẽ xuất hiện trên các trang tuyển dụng.
- Mọi thay đổi đều được dán nhãn: Pull request sẽ ghi rõ ai hoặc cái gì viết, ai kiểm tra, và điều gì thực sự đã được xác minh.
Góc nhìn cho đội ngũ công nghệ Việt Nam
Với các startup và đội phát triển phần mềm tại Việt Nam, bài học thực tiễn khá rõ ràng. Chi phí viết mã đang giảm nhanh, nhưng chi phí review và chịu trách nhiệm thì tăng. Những đội coi AI là công cụ tăng tốc đơn thuần mà không đầu tư vào quy trình kiểm chứng, viết test và đọc mã sẽ dễ rơi vào tình trạng "nợ kỹ thuật tốc độ cao".
Đồng thời, việc tuyển dụng và đào tạo lập trình viên mới càng trở nên quan trọng hơn bao giờ hết. Nếu chỉ dựa vào agent để xử lý các task nhỏ, doanh nghiệp có thể tiết kiệm trước mắt nhưng sẽ thiếu hụt kỹ sư có khả năng đưa ra quyết định kỹ thuật trong vài năm tới.
FORTRAN đã loại bỏ một kiểu lập trình. Nó không loại bỏ lập trình viên, mà tạo ra nhiều người hơn, giải bài toán khó hơn. AI nhiều khả năng cũng vậy — nhanh hơn, lộn xộn hơn, và đặt phần khó nhất trở lại bàn làm việc của con người: quyết định điều gì nên tồn tại và kiểm chứng rằng nó đúng.


