← Posts

Giá trị của Software Developer khi code ngày càng rẻ

AI làm code rẻ và nhanh hơn. Nhưng code nhanh hơn không có nghĩa developer nhàn hơn. Vậy nếu viết code không còn là phần đắt nhất, giá trị của developer nằm ở đâu?

Dạo này code rẻ thật.

Một task trước đây ngồi cả buổi, giờ quăng cho coding agent có khi vài phút đã ra một đống code nhìn khá ổn. CRUD, test, refactor, scaffold… mấy phần mechanical work nhanh hơn thấy rõ.

Nhưng có một chuyện hơi ngược đời.

Code nhanh hơn không có nghĩa developer nhàn hơn.

Có khi ngược lại :v

Làm được nhanh hơn → expectation cao hơn → task nhiều hơn → deadline ngắn hơn. Chưa kể code AI tạo ra vẫn phải đọc, test, review và cuối cùng có người phải chịu trách nhiệm khi nó lên production.

Thế nếu viết code không còn là phần đắt nhất, developer được trả tiền cho cái gì?

Minh họa: Giá trị cốt lõi của software developer trong thời đại AI

Tôi đi đọc thêm DORA, METR và một số nghiên cứu về AI coding assistant để xem cảm giác này có đúng không.

Câu trả lời khá thú vị: AI đang làm công việc thay đổi, nhưng không đơn giản là “developer nhanh hơn 2x”.

Code rẻ hơn, nhưng software chưa chắc rẻ hơn

DORA 2025 mô tả AI như một bộ khuếch đại. Team có nền tảng tốt có thể được khuếch đại theo hướng tốt; hệ thống vốn có vấn đề thì AI cũng có thể giúp tạo output nhanh hơn… để rồi review và debug nhiều hơn.

Trong phân tích tháng 3/2026, hơn 80% người làm công nghệ được khảo sát tin rằng AI làm họ năng suất hơn. Nhưng thời gian tiết kiệm ở code generation thường lại chuyển sang audit và verification.

Một nghiên cứu năm 2026 của Annie Vella và Kelly Blincoe cũng thấy 82% người tham gia báo cáo dành ít thời gian hơn cho việc viết code. Nhóm tác giả gọi phần việc mới là supervisory engineering work: hướng dẫn, đánh giá và sửa output của AI.

Tức là phần creation giảm, nhưng supervision + verification lại tăng.

METR còn có một kết quả khá vui. Trong thử nghiệm với 16 developer giàu kinh nghiệm năm 2025, developer nghĩ AI giúp họ nhanh hơn, nhưng trong bối cảnh cụ thể của nghiên cứu đó thời gian hoàn thành task lại tăng 19%.

Không nên lấy con số này rồi kết luận “AI làm developer chậm hơn”. Chính METR cũng cảnh báo như vậy. Các cập nhật năm 2026 cho thấy câu chuyện đang tiếp tục thay đổi và rất khó nhét vào một con số duy nhất.

Với tôi, điểm đáng chú ý không phải AI nhanh hơn bao nhiêu phần trăm.

Mà là:

Chi phí tạo code đang giảm nhanh hơn chi phí hiểu và chịu trách nhiệm cho code đó.

Và từ đây tôi thấy giá trị của developer nằm nhiều hơn ở ba chỗ.

Biết phải build cái gì

Software hiếm khi bắt đầu bằng một specification hoàn chỉnh.

Thường là mấy câu kiểu:

“Làm dashboard theo dõi user.”

“Chỗ này phải scale được.”

“Flow này chậm, tối ưu đi.”

Đó mới là input, chưa phải bài toán.

Developer vẫn phải bóc tiếp: user thật sự cần gì, constraint nào quan trọng, failure nào chấp nhận được, scope nào nên bỏ, và đôi khi câu hỏi quan trọng nhất là:

Có thật sự cần build thêm cái này không?

AI rất ngon khi problem đã được đóng khung rõ. Nhưng problem sai thì AI chỉ giúp mình đi sai nhanh hơn thôi.

Tôi thích cách nhìn đơn giản này:

5.000 dòng code giải sai vấn đề
<
500 dòng code giải đúng vấn đề

Và khi code trở nên rẻ, có thêm một cái bẫy: over-engineering cũng rẻ theo.

Agent có thể tạo interface, repository, service, abstraction, factory… trong vài phút. Diff nhìn rất hoành tráng, test vẫn xanh. Nhưng có khi bài toán chỉ cần một function và một query.

Ngày trước thêm complexity còn hơi ngại vì phải tự code. Giờ prompt một phát là có :v

Codebase thì vẫn phải trả lãi cho đống complexity đó trong nhiều năm.

Nên biết thứ gì không cần build có khi ngày càng đáng tiền.

Biết code nào không nên ship

AI có thể đưa ra mười phương án kiến trúc rất nhanh.

PostgreSQL hay Redis. Monolith hay microservice. Sync hay async. Build hay buy.

Nhưng cuối cùng vẫn phải có người hiểu context đủ sâu để nói:

Với hệ thống này, team này và thời điểm này, tôi chọn cách này và chấp nhận trade-off của nó.

Đó là engineering judgment.

Và sau khi AI viết xong, câu chuyện vẫn chưa kết thúc.

Code compile được chưa chắc đúng. Test xanh chưa chắc requirement đúng. Vẫn còn transaction, race condition, backward compatibility, security, data integrity, performance, observability, failure mode…

Đây là chỗ tôi không tin lắm vào câu “sau này không cần biết code, chỉ cần biết prompt”.

Không hiểu code thì lấy gì biết AI đang sai?

Càng nguy hiểm hơn khi nó sai theo kiểu trông rất đúng.

Rồi cuối cùng là production.

AI không phải người bị gọi khi migration mất data, payment charge hai lần hay service chết lúc 2 giờ sáng.

Một PR có thể được agent tạo trong vài phút. Incident do PR đó gây ra vẫn có thể kéo dài vài tiếng.

Với tôi, AI viết đoạn này chưa bao giờ là lý do để merge.

Người bấm merge vẫn đang ký tên vào quyết định kỹ thuật đó.

Biết dùng AI để khuếch đại mình

Tôi không nghĩ hướng đi đúng là cạnh tranh tốc độ gõ code với model. Kèo này thua chắc =))

AI phù hợp hơn để lấy bớt phần mechanical work và trả thời gian lại cho những thứ có leverage cao hơn.

Không chỉ là:

AI → tôi code nhanh hơn

mà còn có thể là:

AI
 ↓
CI tốt hơn
Tooling tốt hơn
Test tốt hơn
Observability tốt hơn
Workflow tốt hơn
 ↓
Cả team làm việc tốt hơn

Một developer dùng AI để tạo thêm 500 dòng code là một kiểu leverage.

Một developer dùng nó để cải thiện workflow khiến 10 người khác làm việc nhanh và an toàn hơn là kiểu leverage khác.

Tôi quan tâm kiểu thứ hai hơn.

Còn chuyện KPI?

Đây là phần tôi thấy hơi đáng ngại.

Khi code generation nhanh hơn, rất dễ có chuỗi suy luận:

code nhanh hơn
→ nhiều PR hơn
→ nhiều ticket hơn
→ nhiều story point hơn
→ năng suất hơn

Nhưng software delivery đâu chỉ có code.

problem
→ design
→ code
→ review
→ test
→ integration
→ deploy
→ monitoring
→ feedback

Tăng tốc một node không có nghĩa cả pipeline nhanh lên cùng tỷ lệ.

Nếu toàn bộ thời gian AI tiết kiệm được lập tức biến thành thêm ticket và deadline ngắn hơn thì developer có thể tạo nhiều output hơn, nhưng chưa chắc tạo nhiều value hơn.

Thậm chí còn thêm một cục cognitive load: AI sinh nhanh bao nhiêu thì mình phải đủ sức kiểm chứng nhanh bấy nhiêu.

Có lẽ đây cũng là lý do tôi không thích đo developer bằng số LOC, số PR hay story point. AI chỉ làm vấn đề cũ này lộ rõ hơn thôi.

Vậy giá trị còn lại là gì?

Nếu phải tự tóm lại cho mình:

Trước AI
Developer ≈ tư duy + kinh nghiệm + viết code

AI-assisted
Developer ≈ hiểu vấn đề
          + judgment
          + verification
          + ownership
          + leverage

Không phải công thức gì ghê gớm. Chỉ là cách tôi nhìn công việc của mình lúc này.

Coding vẫn quan trọng. Muốn review code AI thì vẫn phải hiểu code. Muốn chọn architecture thì vẫn phải hiểu system. Muốn biết agent đang hallucinate thì bản thân phải đủ kiến thức để thấy nó có mùi.

Nên tôi không nghĩ developer sẽ chuyển từ “học code” sang “học prompt”.

Có khi ngược lại.

Code càng dễ sinh, khả năng phân biệt code đúng với code chỉ trông có vẻ đúng càng đáng giá.

Có lẽ software developer chưa mất giá trị.

Chỉ có một phần công việc từng được xem là giá trị — viết ra code — đang rẻ đi rất nhanh.

Và càng dùng AI nhiều, tôi càng thấy code chỉ là đoạn giữa của công việc.

Trước nó là hiểu vấn đề.

Sau nó là chịu trách nhiệm cho thứ mình ship.

Hai đoạn đó AI vẫn chưa lấy khỏi tay mình được.

Ít nhất là hiện tại.


Tài liệu tham khảo

  1. DORA — State of AI-assisted Software Development 2025
  2. DORA — Balancing AI tensions: Moving from AI adoption to effective SDLC use
  3. Annie Vella & Kelly Blincoe — The Impact of AI Coding Assistants on Software Engineering (2026)
  4. METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
  5. METR — Update on Measuring AI Productivity Uplift (2026)
  6. METR — Task Substitution and Uplift (2026)
  7. METR — AI Usage Survey (2026)