Khi code trở nên rẻ, thứ gì còn đắt?
AI đang làm chi phí tạo code giảm rất nhanh. Nhưng build dễ hơn không có nghĩa làm product dễ hơn. Nút thắt đang dịch chuyển sang chọn đúng vấn đề, phán đoán sản phẩm, phân phối và niềm tin.
Dạo gần đây tôi có một suy nghĩ cứ lặp đi lặp lại:
Giờ code cheap. Tìm đúng thứ để làm và đưa nó đến đúng người mới khó.
Nghe hơi cực đoan, nhất là với một người làm phần mềm. Nhưng càng dùng coding agent hằng ngày, tôi càng thấy phần biến một yêu cầu thành code chạy được đang rẻ đi rất nhanh.
Một prototype trước đây mất vài ngày, giờ có thể chỉ vài giờ. CRUD, test, refactor, scaffold, đọc code cũ, viết tài liệu… AI làm được ngày càng nhiều.
Nhưng có một nghịch lý:
Build dễ hơn không có nghĩa là có user dễ hơn.
Và có lẽ đây mới là thay đổi đáng quan tâm nhất.
Code đang rẻ đi. Software thì chưa.
Trước tiên cần tách bốn thứ thường bị gom làm một:
Code → Software → Product → Business
AI đang tác động rất mạnh vào phần đầu của chuỗi. Nó giảm ma sát khi bắt đầu một task, sinh code nhanh hơn và mở khả năng xây phần mềm cho nhiều người hơn.
Nhưng code chạy được chưa chắc là software tốt. Software tốt chưa chắc là product có người cần. Và product có người dùng chưa chắc trở thành business bền vững.
DORA 2025 gọi AI là một bộ khuếch đại: nó khuếch đại cả điểm mạnh lẫn điểm yếu của hệ thống phát triển phần mềm. Trong một phân tích năm 2026, DORA ghi nhận AI giúp giảm ma sát ở giai đoạn tạo code, nhưng thời gian tiết kiệm được thường chuyển sang audit và verification.
Nói cách khác, chúng ta có thể tạo output nhanh hơn, nhưng vẫn phải trả chi phí để biết output đó có đúng hay không.
METR còn cho một kết quả đáng suy nghĩ hơn. Trong thử nghiệm ngẫu nhiên với 16 developer giàu kinh nghiệm, làm 246 task trên những repository họ đã quen thuộc, việc được phép dùng các công cụ AI đầu năm 2025 khiến thời gian hoàn thành tăng 19% trong bối cảnh nghiên cứu đó. Chính các developer lại tin rằng AI đã giúp họ nhanh hơn.
Không nên dùng nghiên cứu này để kết luận rằng “AI làm developer chậm hơn”. METR cũng nói rõ kết quả chỉ phản ánh một nhóm developer, repository và thế hệ công cụ cụ thể.
Điểm tôi quan tâm là chuyện khác:
Khả năng sinh code tăng không đồng nghĩa giá trị cuối cùng tăng theo cùng tỷ lệ.
Bạn có thể làm 10 feature nhanh gấp ba lần. Nếu tám feature chẳng ai cần thì business value không tăng ba lần.
Nút thắt đang dịch chuyển
Trong nhiều năm, engineering là một nút thắt rất thật.
Bạn có ý tưởng, nhưng để biến nó thành sản phẩm cần developer, thời gian, tiền, hạ tầng và rất nhiều công sức. Với một indie hacker hay một nhóm nhỏ, riêng việc build MVP đã có thể ngốn vài tháng.
AI đang làm nút thắt đó rộng ra.
Không phải engineering biến mất. Không phải ai cũng có thể làm một hệ thống production tốt. Nhưng khả năng tạo software cơ bản đang trở nên dễ tiếp cận hơn.
Khi một nguồn lực bớt khan hiếm, lợi thế cạnh tranh thường dịch chuyển sang những nguồn lực vẫn còn khan hiếm.
Tôi nhìn chuỗi này như sau:
Trước AI
Idea
↓
ENGINEERING ← nút thắt lớn
↓
Product
↓
Distribution
Thời AI
PROBLEM SELECTION ← nút thắt
↓
AI + Engineering
↓
Product
↓
DISTRIBUTION ← nút thắt
↓
TRUST / RETENTION ← nút thắtĐiểm khan hiếm đang dịch chuyển từ giữa chuỗi sang hai đầu của chuỗi.
Idea không hiếm. Problem đáng giải mới hiếm.
Ngày trước chúng ta hay hỏi:
Có idea nào hay để làm app không?
Bây giờ câu hỏi đó gần như quá dễ. Chỉ cần hỏi một model, vài phút sau có thể có 50 hay 100 ý tưởng.
Nhưng 100 idea không có nghĩa có một problem tốt.
Một problem đáng xây sản phẩm quanh nó thường phải trả lời được những câu khó hơn:
- Ai thực sự gặp vấn đề này?
- Nó xảy ra thường xuyên đến mức nào?
- Hiện tại họ giải quyết bằng cách gì?
- Cách hiện tại đau ở đâu?
- Họ có sẵn sàng đổi hành vi không?
- Giá trị tạo ra có đủ lớn để họ trả tiền, bỏ thời gian hoặc chấp nhận một công cụ mới không?
AI có thể giúp nghiên cứu và đặt câu hỏi. Nhưng việc nhìn thấy một vấn đề thật trong một bối cảnh thật vẫn cần tiếp xúc với người dùng, hiểu lĩnh vực và rất nhiều phán đoán.
Vì vậy tôi không còn thấy “idea generation” là một lợi thế đáng kể.
Problem selection mới là lợi thế.
Build xong rồi ai dùng?
Đây là chỗ tôi thấy đau nhất khi làm side project.
Một developer có thể rất dễ rơi vào vòng lặp:
Có idea
→ build
→ polish
→ thêm feature
→ deploy
→ ... 20 usersAI làm đoạn build → polish → thêm feature nhanh hơn rất nhiều.
Nhưng AI không tự mang 10.000 người dùng đến sản phẩm.
Distribution vẫn là một bài toán khác hoàn toàn: biết user ở đâu, nói ngôn ngữ nào, họ tin ai, kênh nào hiệu quả, thông điệp nào khiến họ thử, điều gì khiến họ quay lại.
Đó là lý do tôi ngày càng thấy một developer biết build nhưng không biết distribution giống như sở hữu một nhà máy rất nhanh nhưng không có hệ thống bán hàng.
Nhà máy càng nhanh thì tồn kho càng nhiều.
Trong AI era, “tồn kho” đó có thể là hàng chục side project rất đẹp nằm trên GitHub với vài chục user.
Moat nào còn lại khi ai cũng build được?
Một lập luận tôi thấy đáng chú ý từ Andreessen Horowitz là AI không làm các lợi thế cạnh tranh cổ điển biến mất.
Network effects vẫn tồn tại. Brand vẫn tồn tại. Dữ liệu khó có được vẫn có giá trị. Và đặc biệt là process power — hiểu sâu cách một tổ chức hay một nhóm người thực sự làm việc.
Một đối thủ có thể dùng cùng model với bạn.
Họ có thể clone giao diện của bạn.
Họ thậm chí có thể tạo một phiên bản MVP trong vài ngày.
Nhưng nếu sản phẩm của bạn đã hiểu sâu workflow, tích lũy dữ liệu phù hợp, được nhúng vào thói quen người dùng và có distribution tốt, thì “code giống nhau” không có nghĩa là “sản phẩm giống nhau”.
Đây là điểm tôi nghĩ nhiều developer dễ bỏ qua vì chúng ta có xu hướng nhìn moat bằng công nghệ.
Trong rất nhiều sản phẩm, code chưa bao giờ là moat lớn nhất.
AI chỉ làm điều đó lộ ra rõ hơn.
Vậy coding còn giá trị không?
Có. Và tôi nghĩ nói “coding không còn giá trị” là một kết luận sai.
Khi AI tạo code nhanh hơn, khả năng phân biệt code đúng với code chỉ trông có vẻ đúng thậm chí còn quan trọng hơn.
DORA ghi nhận tác động của AI lên giá trị công việc developer không chỉ có một chiều. AI có thể làm một cá nhân tạo ra nhiều tác động hơn, nhưng đồng thời cũng làm một số kỹ năng dễ tiếp cận hơn. DORA đề xuất nhìn vào outcome thay vì chỉ lượng thời gian hay output tạo ra.
Engineering judgment, kiến trúc, security, reliability, trade-off, khả năng hiểu hệ thống cũ và chịu trách nhiệm khi production có vấn đề vẫn là những thứ khó.
Điều thay đổi là:
“Tôi biết code” không còn đủ mạnh để đứng một mình như một lợi thế cạnh tranh.
Profile mới của một software builder
Nếu phải viết ngắn gọn profile tôi muốn hướng tới trong vài năm tới, trước đây có lẽ là:
10x Coder
Bây giờ tôi nghĩ nó gần với:
Problem Finder × Product Thinker × AI-native Builder × Distributor
Không nhất thiết một người phải giỏi nhất cả bốn.
Nhưng nếu chỉ tối ưu một biến là tốc độ viết code, tôi nghĩ chúng ta đang tối ưu đúng thứ đang trở nên rẻ nhanh nhất.
Developer vẫn cần engineering depth. Nhưng bên cạnh đó cần hiểu problem, user, product và distribution đủ sâu để biết cái gì đáng build.
AI sau đó trở thành đòn bẩy.
Không phải chiến lược.
Thứ gì còn đắt?
Có lẽ trong một thời gian dài, developer chúng ta quen với việc xem khả năng xây dựng là lợi thế cạnh tranh.
Tôi biết cách biến một ý tưởng thành software, còn phần lớn mọi người thì không.
AI đang làm khoảng cách đó nhỏ lại.
Điều này không làm developer kém giá trị hơn. Nhưng nó buộc chúng ta dịch chuyển lên những tầng mà chưa thể đơn giản hóa chỉ bằng một prompt: hiểu vấn đề nào đáng giải quyết, đưa ra quyết định trong điều kiện không chắc chắn, hiểu người dùng, xây niềm tin và đưa sản phẩm đến được tay họ.
Code đang trở nên rẻ. Nhưng một vấn đề đáng giải, một quyết định đúng và một kênh phân phối tốt vẫn rất đắt.
Có lẽ đó mới là nơi lợi thế cạnh tranh đang dịch chuyển tới.