AI viết code ngày càng giỏi, giá trị của lập trình viên nằm ở đâu?

AI có thể giúp viết code nhanh hơn rất nhiều, nhưng làm ra phần mềm và tạo ra một sản phẩm có giá trị kinh tế là hai chuyện khác nhau. Mình muốn nhìn lại chuỗi giá trị ngành phần mềm, từ Outsourcing, Software Product đến SaaS, để hiểu AI đang thay đổi điều gì và người làm kỹ thuật nên chuẩn bị ra sao.

Mình bắt đầu viết code từ năm 2009. Trong nhiều năm làm phần mềm, có những vấn đề mình phải dành hàng ngày để giải quyết, đọc tài liệu, thử đi thử lại, debug đến khi tìm được nguyên nhân. Có những hệ thống mất hàng tháng để xây dựng và nhiều năm để hoàn thiện.

Bây giờ, với AI coding agent, mình có thể mô tả một yêu cầu và nhận lại hàng trăm dòng code chỉ sau vài phút. Một số công việc trước đây mất nhiều ngày, giờ có thể dựng bản đầu tiên ngay trong một buổi. AI còn có thể đọc codebase, viết test, giải thích lỗi và đề xuất thay đổi trên nhiều file cùng lúc. Trải nghiệm lập trình vì thế đã khác đi khá nhiều so với vài năm trước.

Những kỹ năng từng đòi hỏi nhiều thời gian luyện tập nay có thể được AI hỗ trợ thực hiện rất nhanh. Mình nghĩ cảm giác chới với của một số lập trình viên cũng bắt đầu từ đây, khi công việc họ đã dành nhiều năm để thành thạo bỗng được công cụ thực hiện trong thời gian ngắn. Mình muốn thử nhìn vấn đề từ góc độ kinh tế của ngành phần mềm, với một khái niệm khá quen thuộc trong quản trị chiến lược: chuỗi giá trị (Value Chain). Ngay cả trước khi có AI, coding vốn đã là một công đoạn trong quá trình tạo ra và kinh doanh sản phẩm phần mềm, nhưng người dành nhiều năm làm công đoạn này đôi khi dễ nhìn cả sản phẩm qua lăng kính chuyên môn của mình.

1. Một sản phẩm phần mềm tạo ra giá trị như thế nào?

Giả sử bạn xây dựng một phần mềm quản lý bán hàng cho các cửa hàng nhỏ. Trước tiên, bạn cần biết các cửa hàng đang gặp vấn đề gì, chẳng hạn quản lý tồn kho bằng Excel, không biết chính xác mặt hàng nào còn trong kho hoặc gặp khó khăn khi đối soát đơn hàng từ nhiều kênh bán. Bạn phải tìm hiểu cách họ vận hành, xác định vấn đề nào cần ưu tiên và thiết kế những chức năng cần thiết. Sau những bước đó, bạn mới bắt đầu lập trình.

Khi code đã chạy, sản phẩm vẫn còn khá nhiều việc cần hoàn thiện. Phần mềm phải được kiểm thử, triển khai, bảo trì và bảo vệ dữ liệu. Bạn cũng cần tìm khách hàng, hướng dẫn họ sử dụng, xử lý lỗi phát sinh và cải tiến sản phẩm dựa trên phản hồi thực tế. Những công đoạn này đều ảnh hưởng đến kết quả kinh doanh của sản phẩm.

Nếu không tìm được khách hàng, sản phẩm có thể không tạo ra doanh thu. Nếu người dùng không hiểu cách sử dụng, một sản phẩm đầy đủ chức năng vẫn có thể bị bỏ đi. Nếu hệ thống thường xuyên gặp lỗi, khách hàng có thể ngừng sử dụng dù các chức năng ban đầu được xây dựng rất tốt. Coding là một mắt xích quan trọng, nhưng kết quả cuối cùng phụ thuộc vào cả chuỗi hoạt động.

Hình 1. Chuỗi giá trị phần mềm từ nghiên cứu thị trường, thiết kế, phát triển đến phân phối, vận hành và giữ chân khách hàng. Coding được tô sáng để thể hiện vị trí của nó trong toàn bộ chuỗi.

Trong mô hình Value Chain của Michael Porter, doanh nghiệp được phân tích thành những hoạt động có liên quan đến nhau, từ tạo ra sản phẩm, đưa sản phẩm đến khách hàng cho đến dịch vụ sau bán. Lợi thế cạnh tranh hình thành từ cách doanh nghiệp tổ chức các hoạt động đó, kiểm soát chi phí và tạo ra giá trị mà khách hàng sẵn sàng trả tiền. Áp dụng cách nhìn này vào ngành phần mềm, mình thấy có ba khái niệm thường bị trộn lẫn khi đánh giá một sản phẩm hoặc công việc kỹ thuật.

Giá trị sử dụng là lợi ích phần mềm mang lại cho người dùng. Một hệ thống quản lý tồn kho tốt có thể giúp cửa hàng hạn chế thất thoát, tiết kiệm thời gian và quyết định nhập hàng chính xác hơn. Giá trị kinh tế được tạo ra liên quan đến lợi ích giải pháp mang lại so với nguồn lực phải bỏ ra, và lợi ích ấy có thể lớn hơn nhiều so với chi phí xây dựng. Giá trị mà doanh nghiệp nắm giữ là phần lợi ích doanh nghiệp có thể chuyển thành doanh thu và lợi nhuận, sau khi tính đến chi phí, cạnh tranh và điều kiện thị trường.

Ba khái niệm này có liên quan chặt chẽ nhưng không đồng nhất. Một kỹ sư có thể viết ra hệ thống rất phức tạp, có giá trị kỹ thuật cao, nhưng nếu sản phẩm không giải quyết nhu cầu đủ lớn hoặc không tiếp cận được khách hàng, giá trị kinh tế thu về có thể hạn chế. Ngược lại, một ứng dụng chỉ có vài chức năng đơn giản vẫn có thể kinh doanh tốt nếu giải quyết đúng vấn đề, dễ sử dụng và có cách tiếp cận khách hàng hiệu quả. Độ khó kỹ thuật cần được xem xét cùng với lợi ích thực tế và cách doanh nghiệp kiếm tiền từ sản phẩm.

Tất nhiên, có những sản phẩm mà năng lực kỹ thuật chính là yếu tố tạo ra khác biệt lớn nhất. Cơ sở dữ liệu, hệ thống hạ tầng, bảo mật hay phần mềm đòi hỏi độ tin cậy đặc biệt cao là những ví dụ như vậy. Cũng không có công thức cố định để tính coding đóng góp bao nhiêu phần trăm vào giá trị của một sản phẩm. Vì thế, khi đánh giá một công việc kỹ thuật, mình nghĩ cần phân biệt mức độ khó của công việc với giá trị kinh tế mà doanh nghiệp có thể nắm giữ.

2. Ba mô hình kinh doanh phần mềm, ba cách tạo ra và nắm giữ giá trị

Ngành phần mềm có nhiều mô hình kinh doanh, nhưng trong bài này mình chọn ba mô hình tương đối phổ biến để phân tích: Software Outsourcing, Software Product và SaaS. Cả ba đều cần năng lực phát triển phần mềm, nhưng cách tạo doanh thu, cấu trúc chi phí và những yếu tố quyết định lợi nhuận lại khác nhau khá nhiều. Cùng một năng lực coding có thể mang ý nghĩa kinh tế khác nhau tùy doanh nghiệp đang bán giờ công, bán sản phẩm hay cung cấp dịch vụ liên tục.

Hình 2. Chuỗi giá trị của Outsourcing, Software Product và SaaS. Mỗi mô hình có những công đoạn quan trọng khác nhau trong việc tạo và nắm giữ giá trị.

Software Outsourcing: Bán năng lực thực hiện

Với Outsourcing, khách hàng thường đã có một nhu cầu hoặc dự án cần triển khai. Doanh nghiệp phần mềm cung cấp đội ngũ, chuyên môn và quy trình để xây dựng giải pháp theo hợp đồng. Giả sử một công ty nhận dự án trị giá 2 tỷ đồng để phát triển hệ thống quản lý nội bộ trong sáu tháng. Công ty phải tính toán nguồn lực triển khai, chi phí nhân sự, quản lý dự án, kiểm thử, hỗ trợ và những rủi ro có thể xảy ra.

Coding có thể chiếm phần lớn thời gian lao động trực tiếp, nhưng lợi nhuận còn phụ thuộc vào cách công ty tìm dự án, đàm phán giá, ước lượng công việc, quản trị phạm vi và sử dụng nhân lực. Một đội ngũ lập trình rất tốt nhưng liên tục ước lượng sai, không kiểm soát được thay đổi yêu cầu hoặc phải sửa lỗi quá nhiều vẫn có thể khiến dự án thua lỗ. Chất lượng kỹ thuật giúp doanh nghiệp thực hiện hợp đồng, còn năng lực quản lý giúp doanh nghiệp duy trì hiệu quả kinh tế của hợp đồng đó. Khi nhìn từ góc độ này, giá trị của một công ty Outsourcing gắn khá chặt với cách họ tổ chức nguồn lực và thực hiện cam kết với khách hàng.

Software Product: Bán sản phẩm do mình sở hữu

Với Software Product, doanh nghiệp tự nghiên cứu, xây dựng và thương mại hóa sản phẩm. Ví dụ, một công ty phát triển phần mềm kế toán dành cho doanh nghiệp nhỏ phải tìm hiểu nhu cầu thị trường, xây dựng chức năng, lựa chọn cách định giá, phân phối sản phẩm và hỗ trợ khách hàng. Sau khi phần mềm hoàn thiện, họ có thể bán cùng một sản phẩm cho nhiều khách hàng mà không cần phát triển lại từ đầu cho từng người.

Đây là một lợi thế kinh tế đáng kể của sản phẩm phần mềm. Chi phí xây dựng ban đầu có thể lớn, nhưng chi phí cung cấp thêm một bản sao thường tương đối thấp so với nhiều loại hàng hóa vật lý. Dĩ nhiên, doanh nghiệp vẫn phải chi tiền cho vận hành, hỗ trợ, cập nhật và phân phối. Khi đó, quyền sở hữu tài sản trí tuệ, khả năng đáp ứng nhu cầu thị trường, thương hiệu và kênh phân phối trở thành những yếu tố đáng quan tâm.

Bạn có thể sở hữu code của một phần mềm rất tốt mà vẫn không bán được nhiều. Khách hàng cần biết đến sản phẩm, tin tưởng nó và có lý do để chọn nó thay vì các phương án khác. Nếu thị trường chưa có nhu cầu đủ lớn hoặc sản phẩm chưa tiếp cận đúng người mua, chất lượng code khó tự giải quyết được vấn đề doanh thu. Vì thế, năng lực phát triển sản phẩm cần đi cùng khả năng hiểu thị trường và đưa sản phẩm đến khách hàng.

SaaS: Bán giá trị được cung cấp liên tục

SaaS có nhiều điểm tương đồng với Software Product, nhưng mô hình kinh doanh dựa nhiều hơn vào cung cấp dịch vụ phần mềm liên tục, thường dưới dạng thuê bao. Hãy lấy ví dụ một SaaS quản lý công việc có giá 199.000 đồng mỗi tháng. Nếu có 1.000 khách hàng trả tiền, doanh thu thuê bao hàng tháng trước các khoản giảm trừ sẽ là 199 triệu đồng. Tuy nhiên, để duy trì doanh thu ấy, doanh nghiệp phải đảm bảo hệ thống hoạt động ổn định, hỗ trợ khách hàng, cải thiện trải nghiệm và có lý do để người dùng tiếp tục trả tiền.

Nếu khách hàng sử dụng một tháng rồi rời đi, doanh nghiệp có thể gặp khó khăn dù số lượng đăng ký mới khá cao. Ngược lại, nếu khách hàng ở lại nhiều năm, chi phí thu hút ban đầu có thể được phân bổ trên thời gian dài hơn, tạo điều kiện cải thiện hiệu quả kinh tế của sản phẩm. Vì vậy, SaaS thường phải theo dõi những chỉ số như Customer Acquisition Cost (CAC), Churn Rate, Customer Lifetime Value (LTV), Gross Margin và Net Revenue Retention (NRR). Phát triển phần mềm tốt giúp doanh nghiệp có sản phẩm để bán, còn khả năng vận hành và giữ chân khách hàng quyết định phần lớn câu chuyện kinh doanh tiếp theo.

Nhìn lại ba mô hình, coding đều là nguồn lực cần thiết nhưng được sử dụng theo những cách khác nhau. Outsourcing quan tâm nhiều đến hiệu quả thực hiện hợp đồng, Software Product cần biến tài sản phần mềm thành sản phẩm có thị trường, còn SaaS phải liên tục cung cấp giá trị để duy trì doanh thu. Sự khác biệt này giúp giải thích vì sao cùng một công nghệ AI có thể tạo ra những tác động kinh tế rất khác nhau giữa các doanh nghiệp phần mềm.

3. AI làm thay đổi đường cong giá trị như thế nào?

Khi nghiên cứu chuỗi giá trị, có một mô hình khá thú vị gọi là Smile Curve, thường được dùng để minh họa cách giá trị gia tăng phân bố giữa các công đoạn trong một ngành. Trong hình dạng điển hình, các hoạt động đầu chuỗi như nghiên cứu, thiết kế và sở hữu công nghệ có thể tạo ra giá trị gia tăng cao. Những hoạt động cuối chuỗi như thương hiệu, phân phối và dịch vụ khách hàng cũng có thể tạo ra giá trị lớn, trong khi một số công đoạn sản xuất được tiêu chuẩn hóa ở giữa chuỗi chịu áp lực cạnh tranh về giá. Mình thử áp dụng cách nhìn này vào ngành phần mềm trước và sau khi AI xuất hiện.

Hình 3. Mô hình minh họa sự dịch chuyển khả năng khác biệt hóa và nắm giữ giá trị trong chuỗi phần mềm. Đường cong là giả thuyết chiến lược, không phải dữ liệu đo lường thực tế.

Trước AI, biến một yêu cầu thành phần mềm hoạt động đòi hỏi tương đối nhiều nguồn lực có chuyên môn. Muốn phát triển sản phẩm, doanh nghiệp phải tuyển dụng hoặc thuê người biết lập trình, xây dựng hệ thống, kiểm thử và triển khai. Kỹ năng coding có mức độ khan hiếm nhất định, tạo ra lợi thế đáng kể cho người sở hữu năng lực này. Chi phí để chuyển một ý tưởng thành sản phẩm chạy được vì thế cũng là rào cản với nhiều cá nhân và doanh nghiệp nhỏ.

AI đang làm thay đổi một phần rào cản đó. Người có hiểu biết về sản phẩm và biết sử dụng AI có thể tạo prototype nhanh hơn, còn lập trình viên có thể giao coding agent viết phần code ban đầu, bổ sung test, refactor hoặc tìm hiểu codebase mới. Những tác vụ kỹ thuật lặp lại, dễ mô tả đang thuận tiện hơn để tự động hóa. Trong nhiều tình huống, chi phí để tạo ra một đơn vị đầu ra phần mềm có thể giảm xuống.

Về mặt kinh tế, khi một loại năng lực trở nên dễ tiếp cận hơn, lợi thế cạnh tranh dựa riêng vào độ khan hiếm của nó có thể suy giảm. Điều này đặc biệt dễ thấy với các chức năng phổ thông như CRUD, dashboard cơ bản, landing page, biểu mẫu quản trị hoặc tích hợp tương đối tiêu chuẩn. Nếu nhiều đối thủ xây dựng được chức năng tương tự với chi phí thấp hơn, khách hàng sẽ có thêm lựa chọn. Doanh nghiệp khó duy trì mức giá cao chỉ vì một chức năng trước đây cần nhiều ngày lập trình.

Tuy nhiên, cần tách giá trị của hoạt động coding khỏi lợi thế cạnh tranh dựa vào coding. AI có thể làm tăng tổng lượng phần mềm được tạo ra, đồng thời giúp nhiều ý tưởng trước đây quá đắt trở nên khả thi. Nhu cầu về hệ thống đáng tin cậy, bảo mật và vận hành lâu dài cũng không tự động giảm xuống. Áp lực lớn hơn có thể nằm ở khả năng định giá cao cho những thao tác lập trình mà công cụ và thị trường ngày càng dễ tiếp cận.

Từ góc nhìn đó, mình nghĩ lợi thế cạnh tranh có thể dịch chuyển sang những năng lực khác trong chuỗi. Ở đầu chuỗi là hiểu ngành, xác định đúng vấn đề, thiết kế giải pháp và ra quyết định kiến trúc phù hợp. Ở cuối chuỗi là dữ liệu, hệ sinh thái, kênh phân phối, quan hệ khách hàng và khả năng tạo ra kết quả kinh doanh mà người dùng cần. Đồng thời, AI tạo thêm áp lực kiểm chứng vì lượng code được sinh ra nhanh hơn, buộc doanh nghiệp có cách đảm bảo hệ thống chạy đúng, an toàn và bảo trì được.

Đây là cách mình lý giải sự dịch chuyển giá trị khi AI tham gia sâu hơn vào phát triển phần mềm. Hình dạng đường cong có thể rất khác nhau giữa các loại sản phẩm và doanh nghiệp, đặc biệt khi năng lực kỹ thuật chuyên sâu vẫn là yếu tố khác biệt chính. Các đường cong trong bài chỉ là mô hình phân tích, chưa được đo lường để khẳng định tỷ trọng giá trị của từng công đoạn. Chúng hữu ích ở chỗ giúp đặt coding vào bối cảnh kinh tế rộng hơn khi đánh giá ảnh hưởng của AI.

4. AI đã làm lập trình viên năng suất hơn bao nhiêu?

Nhìn tốc độ AI sinh code, rất dễ có cảm giác công việc lập trình đã nhanh hơn nhiều lần. Nhưng thời gian để hoàn thành một thay đổi phần mềm còn phụ thuộc vào loại nhiệm vụ, kinh nghiệm của người thực hiện, công cụ và môi trường làm việc. Có những nghiên cứu ghi nhận mức tăng năng suất đáng kể, cũng có thử nghiệm cho kết quả ngược lại. Mình nghĩ nên xem từng kết quả trong đúng điều kiện nghiên cứu của nó.

Năm 2023, Sida Peng và các cộng sự nghiên cứu tác động của GitHub Copilot đến năng suất lập trình viên. Kết quả cho thấy nhóm sử dụng AI hoàn thành bài tập xây dựng HTTP server bằng JavaScript nhanh hơn 55,8% so với nhóm không sử dụng. Đây là mức cải thiện đáng chú ý, nhưng được đo trên một nhiệm vụ cụ thể trong môi trường thực nghiệm. Cũng trong năm 2023, McKinsey công bố nghiên cứu cho thấy AI tạo sinh có thể giảm đáng kể thời gian viết code, tạo tài liệu và refactoring, với mức cải thiện thay đổi theo độ phức tạp của nhiệm vụ và kinh nghiệm người sử dụng.

Đến tháng 7/2025, tổ chức METR công bố thử nghiệm có đối chứng với 16 lập trình viên có kinh nghiệm, thực hiện 246 nhiệm vụ trên các dự án mã nguồn mở mà họ đã quen thuộc. Trong điều kiện nghiên cứu đó, nhóm được phép sử dụng AI mất nhiều thời gian hơn khoảng 19% để hoàn thành công việc. Đáng chú ý, chính những lập trình viên tham gia vẫn cảm thấy AI giúp họ làm nhanh hơn. Kết quả này cho thấy cảm nhận về tốc độ và thời gian thực tế hoàn thành công việc có thể khác nhau.

Tháng 2/2026, METR tiếp tục công bố kết quả cập nhật. Nhóm nghiên cứu nhận thấy các công cụ mới có dấu hiệu cải thiện năng suất, nhưng dữ liệu gặp hạn chế về lựa chọn người tham gia và cách đo lường, nên chưa thể kết luận đáng tin cậy về mức tăng tốc. Mình nghĩ các kết quả này vẫn có thể cùng tồn tại với trải nghiệm AI viết code rất nhanh. Code được sinh ra nhanh chỉ giúp giảm thời gian ở một phần của quy trình phát triển.

Một lập trình viên còn phải hiểu hệ thống hiện tại, xem xét tác động của thay đổi, kiểm tra logic, xử lý lỗi, tích hợp với những thành phần khác và đảm bảo triển khai an toàn. Báo cáo DORA 2025 của Google, dựa trên khảo sát gần 5.000 chuyên gia công nghệ cùng dữ liệu nghiên cứu định tính, đưa ra nhận định rằng AI có xu hướng khuếch đại năng lực sẵn có của tổ chức. Những đội ngũ có quy trình, nền tảng và thực hành kỹ thuật tốt thường có điều kiện tận dụng AI hiệu quả hơn. Vì vậy, cùng sử dụng AI nhưng kết quả của hai đội ngũ có thể khác nhau đáng kể.

Trong một phân tích công bố tháng 3/2026, DORA tiếp tục chỉ ra rằng thời gian tiết kiệm ở khâu tạo code có thể chuyển sang kiểm tra, đánh giá và xác minh kết quả. Một thay đổi được tạo rất nhanh nhưng khó review, thiếu test hoặc gây lỗi trên production chưa chắc giúp toàn bộ quy trình phát triển hiệu quả hơn. Vì thế, khi đánh giá năng suất AI, mình muốn quan sát thời gian từ lúc xuất hiện nhu cầu đến khi giải pháp hoạt động ổn định và tạo ra giá trị. Tốc độ sinh code là một chỉ số hữu ích, nhưng chưa đủ để đại diện cho kết quả của cả quy trình.

Hình 4. AI có thể giảm thời gian tạo code, nhưng hiệu quả cuối cùng còn phụ thuộc vào kiểm chứng, tích hợp, triển khai và vận hành.

5. Vì sao lập trình viên có thể cảm thấy chới với?

Để thành thạo một kỹ năng kỹ thuật, người làm lập trình thường phải đầu tư nhiều năm. Từ học ngôn ngữ lập trình đầu tiên, hiểu cấu trúc dữ liệu, framework, database đến thiết kế một hệ thống hoàn chỉnh, mỗi giai đoạn đều cần thực hành và tích lũy kinh nghiệm. Khi dành phần lớn thời gian làm việc để giải quyết các bài toán coding, xem đây là năng lực cốt lõi của bản thân là điều rất tự nhiên. Mỗi lần xử lý được bug khó, tối ưu truy vấn phức tạp hoặc hoàn thiện hệ thống lớn, lập trình viên cũng nhận được sự ghi nhận về chuyên môn.

Khi AI bắt đầu thực hiện nhanh những công việc ấy, cảm giác về giá trị nghề nghiệp có thể bị ảnh hưởng. Theo mình, một phần nguyên nhân đến từ ba khái niệm mà người làm kỹ thuật dễ đánh đồng trong quá trình phát triển nghề nghiệp. Chúng liên quan đến độ khó của công việc, thời gian cần để thực hiện và giá trị mà thị trường sẵn sàng trả tiền. Phân biệt chúng giúp nhìn rõ hơn phần nào trong chuyên môn đang chịu ảnh hưởng của AI.

Việc khó không đồng nghĩa với giá trị kinh tế cao

Một thuật toán khó có thể đòi hỏi rất nhiều kỹ năng để xây dựng. Nhưng nếu nó giải quyết một vấn đề nhỏ mà ít người quan tâm, giá trị kinh tế tạo ra có thể không lớn. Trong khi đó, một tính năng đơn giản như tự động gửi thông báo thanh toán có thể giúp doanh nghiệp giảm đáng kể công việc thủ công và cải thiện khả năng thu hồi công nợ. Độ khó kỹ thuật và lợi ích kinh doanh có liên quan trong một số trường hợp, nhưng không phải lúc nào cũng tỷ lệ thuận.

Việc mất nhiều thời gian không đồng nghĩa với giá trị cao

Trước đây, bạn có thể mất ba ngày để phát triển một tính năng. Nếu AI giúp hoàn thành tính năng đó trong ba giờ với cùng chất lượng, khách hàng vẫn có thể nhận được lợi ích tương đương. Thời gian lao động giảm xuống trong khi giá trị sử dụng được giữ nguyên, và đây là một trong những nguồn tạo ra năng suất của công nghệ. Thứ thay đổi trực tiếp là chi phí sản xuất và cách doanh nghiệp có thể định giá công việc.

Trong mô hình bán giờ công, năng suất cao hơn có thể gây áp lực lên cách tính giá dựa trên thời gian lao động. Với mô hình bán sản phẩm, chi phí phát triển thấp hơn có thể giúp doanh nghiệp thử nghiệm nhiều ý tưởng hoặc cải thiện biên lợi nhuận. Kết quả thực tế vẫn phụ thuộc vào mức độ cạnh tranh và khả năng chuyển phần chi phí tiết kiệm được thành lợi thế kinh doanh. Cùng một cải thiện về tốc độ coding vì thế có thể mang lại tác động rất khác nhau cho từng mô hình.

Làm ra một thứ không đồng nghĩa với thị trường sẽ trả tiền cho nó

Đây là chuyện mà những người xuất thân từ kỹ thuật, bao gồm cả mình, cần thường xuyên tự nhắc. Khi các chức năng chính đã chạy ổn định, một sản phẩm có thể mang lại cảm giác gần hoàn thành. Nhưng xét theo vòng đời kinh doanh, sản phẩm ấy có thể vẫn đang ở giai đoạn rất sớm. Những công đoạn như kiểm chứng nhu cầu, tìm khách hàng, định giá và giữ chân người dùng còn đang ở phía trước.

Người làm sản phẩm cần biết ai thực sự cần giải pháp, họ đang giải quyết vấn đề bằng cách nào và có sẵn sàng trả tiền để thay đổi cách làm hiện tại hay không. Sau đó là cách tiếp cận khách hàng, thuyết phục họ dùng thử và xây dựng sản phẩm đủ tốt để họ tiếp tục sử dụng. Viết thêm code có thể cải thiện chức năng, nhưng chưa chắc giúp tìm ra câu trả lời cho những vấn đề này. AI làm quá trình xây dựng nhanh hơn, nên khoảng cách giữa sản phẩm chạy được và sản phẩm có thị trường cũng dễ lộ rõ hơn.

Khi thời gian và công sức cần thiết cho nhiều tác vụ lập trình giảm xuống, ba khái niệm trên càng đáng được xem xét riêng. Một công việc từng khó và mất nhiều thời gian có thể trở nên dễ thực hiện hơn, trong khi lợi ích mà sản phẩm mang lại cho khách hàng chưa chắc thay đổi. Ngược lại, một vấn đề kinh doanh có giá trị lớn vẫn cần người hiểu bối cảnh để tìm giải pháp phù hợp. Đây cũng là lý do mình muốn nhìn nghề lập trình qua toàn bộ chuỗi giá trị thay vì chỉ qua công đoạn viết code.

6. Đường cong giá trị thay đổi khác nhau với Outsourcing, Software Product và SaaS

Hình 5. Minh họa sự dịch chuyển lợi thế cạnh tranh ở ba mô hình kinh doanh. Các đường cong mang tính giả thuyết phân tích, không thể dùng để suy ra tỷ trọng lợi nhuận của từng công đoạn.

Với Outsourcing, AI có thể giúp cùng một đội ngũ hoàn thành khối lượng công việc lớn hơn. Tuy nhiên, nếu doanh nghiệp và khách hàng vẫn tính giá hoàn toàn theo số giờ lao động, năng suất tăng lên có thể gây ra những vấn đề về định giá. Doanh nghiệp cần xem xét cách chuyển lợi thế năng suất thành lợi nhuận hoặc phát triển dịch vụ có giá trị cao hơn. Các hợp đồng dựa trên kết quả cũng là một hướng có thể cân nhắc khi có điều kiện đo lường phù hợp.

Với Software Product, chi phí phát triển ban đầu thấp hơn giúp nhiều người có thể tham gia thị trường. Đây là cơ hội cho những nhóm nhỏ và nhà phát triển độc lập, đồng thời cũng làm tăng số lượng sản phẩm cạnh tranh. Khi các chức năng phổ biến có thể được sao chép nhanh, lợi thế từ sở hữu một tính năng đơn lẻ có thể giảm đi. Hiểu thị trường, xây dựng thương hiệu, sở hữu IP và đưa sản phẩm đến khách hàng vì thế trở thành những năng lực đáng đầu tư.

Với SaaS, AI giúp doanh nghiệp xây dựng và cải tiến sản phẩm nhanh hơn, thậm chí triển khai những chức năng trước đây quá đắt để thực hiện. Nhưng khách hàng vẫn cần một sản phẩm ổn định, giải quyết được vấn đề và có lý do để tiếp tục sử dụng. Doanh nghiệp còn phải quản lý chi phí vận hành, hỗ trợ và duy trì chất lượng dịch vụ. Những khoản chi cho mô hình AI, inference, hạ tầng và hoạt động của agent cũng có thể làm thay đổi cấu trúc chi phí SaaS.

Nhìn chung, AI vừa mở thêm cơ hội vừa làm tăng áp lực cạnh tranh trong cả ba mô hình. Năng lực phát triển phần mềm nhanh hơn chưa đảm bảo doanh nghiệp sẽ kiếm được nhiều tiền hơn. Với Outsourcing, bài toán nằm nhiều ở tổ chức nguồn lực và định giá; với Software Product, đó là khả năng cạnh tranh trên thị trường; còn SaaS phải quan tâm đến hiệu quả kinh tế trong suốt thời gian cung cấp dịch vụ. Phần năng suất tăng thêm có trở thành lợi nhuận hay lợi thế cạnh tranh hay không còn tùy cách doanh nghiệp vận hành toàn bộ chuỗi giá trị.

7. Lập trình viên nên phát triển theo hướng nào?

Mình không nghĩ tất cả lập trình viên đều phải trở thành founder, product manager hay chuyên gia kinh doanh. Ngành phần mềm vẫn cần những người có chuyên môn kỹ thuật rất sâu, nhất là với các hệ thống phức tạp và yêu cầu độ tin cậy cao. Tuy nhiên, hiểu rõ hơn những công đoạn trước và sau phần công việc mình phụ trách sẽ giúp lập trình viên đánh giá tốt hơn giá trị của các quyết định kỹ thuật. Có năm hướng mà bạn có thể bắt đầu phát triển, tùy công việc hiện tại và định hướng nghề nghiệp của mình.

1. Tập tìm hiểu bài toán trước khi tìm giải pháp

Khi nhận một yêu cầu phát triển, bạn có thể dành thêm thời gian tìm hiểu người sử dụng thực sự cần gì. Ví dụ, khách hàng yêu cầu xây dựng dashboard theo dõi đơn hàng, nhưng điều họ cần có thể là phát hiện sớm những đơn đang giao chậm. Nếu bắt đầu ngay từ chọn thư viện biểu đồ và thiết kế giao diện, bạn có thể bỏ qua nhu cầu này. Một hệ thống cảnh báo đúng thời điểm đôi khi hữu ích hơn dashboard phức tạp.

Hiểu bài toán cũng giúp bạn trao đổi với những người phụ trách sản phẩm và nghiệp vụ hiệu quả hơn. Thay vì chỉ thảo luận các chức năng phải xây dựng, bạn có thể tìm hiểu quyết định nào người dùng đang cần đưa ra và thông tin nào giúp họ quyết định. Từ đó, các lựa chọn kỹ thuật sẽ có cơ sở rõ ràng hơn. Đây là kỹ năng có thể rèn luyện ngay trong công việc phát triển hằng ngày.

2. Đi sâu hơn vào tư duy hệ thống và kiến trúc

AI có thể giúp tạo code, nhưng vẫn cần người chịu trách nhiệm về cách các thành phần hoạt động cùng nhau. Bạn nên hiểu sâu hơn về thiết kế dữ liệu, transaction, concurrency, phân quyền, bảo mật, tích hợp, khả năng mở rộng và vận hành. Các vấn đề này thường liên quan đến nhiều thành phần và nhiều tình huống xảy ra trong thực tế. Một đoạn code chạy đúng trong trường hợp thông thường chưa đảm bảo toàn bộ hệ thống sẽ hoạt động đúng.

Ví dụ, AI có thể tạo API nhận đơn hàng từ một nền tảng thương mại điện tử khá nhanh. Nhưng hệ thống phải xử lý thế nào khi cùng một đơn hàng được gửi hai lần, khi thanh toán thành công nhưng cập nhật tồn kho thất bại, hoặc khi một request bị retry sau khi timeout? Đó là những bài toán liên quan đến tính toàn vẹn dữ liệu và thiết kế hệ thống. Khả năng nhận diện, thiết kế và kiểm chứng những tình huống này có giá trị lớn khi phần mềm được đưa vào vận hành thực tế.

3. Sử dụng AI như một hệ thống làm việc có kiểm chứng

Mình nghĩ học cách sử dụng AI coding agent nên trở thành một phần trong quá trình phát triển nghề nghiệp của lập trình viên. Ngoài kỹ năng giao nhiệm vụ cho AI, bạn cần biết chuẩn bị ngữ cảnh, mô tả tiêu chí chấp nhận, thiết kế test, review thay đổi và đánh giá kết quả. Một cách thực hành khá hữu ích là xác định rõ điều kiện hoàn thành trước khi yêu cầu AI triển khai. Nhờ đó, bạn có cơ sở cụ thể để kiểm tra kết quả thay vì chỉ nhìn vào phần code được tạo ra.

Ví dụ, khi xây dựng chức năng thanh toán, bạn có thể xác định trước các điều kiện: một giao dịch chỉ được ghi nhận một lần, thanh toán thiếu không được đánh dấu hoàn tất, webhook gửi lại không làm thay đổi số dư hai lần và mọi cập nhật phải có dấu vết đối soát. Sau đó, AI có thể tham gia viết code và test dựa trên những điều kiện này. Kết quả cuối cùng vẫn phải được kiểm chứng để đảm bảo hệ thống xử lý đúng các tình huống đã đặt ra. Cách làm ấy giúp bạn đánh giá chất lượng theo hành vi của hệ thống thay vì số dòng code hoàn thành.

4. Hiểu vòng đời kinh doanh của sản phẩm

Nếu đang làm trong một doanh nghiệp phần mềm, bạn có thể thử tìm hiểu những gì xảy ra với sản phẩm sau khi triển khai. Khách hàng tìm đến công ty bằng cách nào, vì sao họ chọn sản phẩm, chi phí phục vụ một khách hàng là bao nhiêu và người dùng thường bỏ cuộc ở bước nào? Những vấn đề nào khiến họ phải liên hệ hỗ trợ, hoặc tính năng nào được phát triển nhưng ít người sử dụng? Các thông tin ấy giúp bạn hiểu rõ hơn bối cảnh phía sau những yêu cầu kỹ thuật.

Nếu làm SaaS, bạn có thể tìm hiểu thêm về CAC, churn, retention và LTV. Nếu làm Outsourcing, hãy quan tâm đến cách dự án được ước lượng, định giá và quản lý lợi nhuận. Bạn không nhất thiết phải trực tiếp phụ trách những công việc này, nhưng hiểu chúng sẽ giúp đưa ra các quyết định kỹ thuật phù hợp hơn với mục tiêu chung. Đôi khi một lựa chọn kiến trúc, quy trình triển khai hoặc cách thiết kế tính năng có thể ảnh hưởng đến chi phí vận hành và trải nghiệm khách hàng về lâu dài.

5. Bắt đầu đo kết quả thay vì chỉ đo đầu ra kỹ thuật

Một lập trình viên có thể hoàn thành 20 ticket trong một sprint. Con số này hữu ích cho theo dõi công việc, nhưng chưa cho biết các thay đổi ấy mang lại lợi ích gì. Bạn có thể thử kết nối công việc kỹ thuật với những kết quả cụ thể hơn như giảm thời gian xử lý đơn hàng, giảm số lỗi, tăng tỷ lệ hoàn thành quy trình, giảm chi phí vận hành hoặc cải thiện thời gian phản hồi của hệ thống. Những chỉ số này giúp nhìn thấy tác động của thay đổi sau khi phần mềm được đưa vào sử dụng.

Tất nhiên, không phải công việc kỹ thuật nào cũng có thể gắn trực tiếp với doanh thu. Độ ổn định, bảo mật, khả năng bảo trì và trải nghiệm của đội ngũ phát triển đều là những kết quả đáng quan tâm. Một thay đổi giúp hệ thống ít lỗi hơn hoặc giúp đội ngũ triển khai an toàn hơn cũng có giá trị, dù khó quy đổi ngay thành số tiền cụ thể. Mình muốn hướng đến cách đánh giá công việc dựa trên mối liên hệ giữa phần kỹ thuật đã thực hiện và kết quả cuối cùng mà sản phẩm cần đạt.

Hình 6. Từ năng lực coding đến hiểu bài toán, kiến trúc hệ thống, AI engineering, tư duy sản phẩm và khả năng tạo ra kết quả.

8. Vậy coding có còn quan trọng?

Mình nghĩ coding vẫn quan trọng và sẽ còn quan trọng trong thời gian dài, dù cách sử dụng kỹ năng này có thể thay đổi nhiều. Một lập trình viên giỏi có lợi thế khi làm việc với AI vì họ hiểu hệ thống, biết đánh giá giải pháp và nhận ra những sai sót mà người thiếu kinh nghiệm có thể bỏ qua. Kiến thức kỹ thuật cũng giúp họ đặt ra yêu cầu chính xác hơn và kiểm chứng kết quả tốt hơn. Những lợi thế này đặc biệt có ý nghĩa khi làm việc với các hệ thống phức tạp hoặc có yêu cầu cao về độ tin cậy.

Đồng thời, AI mở ra cơ hội cho những người có kiến thức chuyên ngành nhưng trước đây thiếu kỹ năng lập trình. Một chuyên gia kế toán, giáo dục, vận hành hay marketing có thể tự tạo prototype, thử nghiệm ý tưởng và tham gia sâu hơn vào quá trình xây dựng phần mềm. Khi nhiều người có thể tạo ra sản phẩm, người làm kỹ thuật càng cần hiểu rõ năng lực nào giúp mình tạo ra khác biệt. Điều đó có thể đến từ chuyên môn sâu về hệ thống phân tán, bảo mật, dữ liệu, tối ưu hiệu năng, hoặc từ khả năng kết hợp công nghệ với kiến thức ngành và thiết kế sản phẩm.

Mỗi người có thể chọn một hướng phát triển khác nhau tùy năng lực và công việc mình muốn theo đuổi. Có người tiếp tục đi sâu vào những bài toán kỹ thuật khó, có người tham gia nhiều hơn vào thiết kế sản phẩm, cũng có người phù hợp với vai trò dẫn dắt các dự án phức tạp. Những hướng này đều có thể tạo ra giá trị khi gắn với nhu cầu thực tế. Không có một con đường duy nhất mà tất cả lập trình viên phải đi theo.

Cá nhân mình vẫn thích lập trình. Biến một ý tưởng thành thứ hoạt động được luôn là trải nghiệm thú vị, và AI khiến quá trình đó hấp dẫn hơn vì mình có thể thử nghiệm nhiều thứ mà trước đây không đủ thời gian thực hiện. Nhưng càng làm việc với AI, mình càng dành nhiều sự chú ý cho những quyết định trước và sau công đoạn viết code. Nên xây dựng cái gì, vì sao cần xây dựng, hệ thống phải tuân thủ những giới hạn nào và làm sao kiểm chứng giải pháp thực sự tốt là những vấn đề vẫn cần được giải quyết.

Nếu nhìn lại toàn bộ chuỗi giá trị, AI đang mở ra cơ hội để lập trình viên dành ít thời gian hơn cho một số thao tác thực thi và tham gia sâu hơn vào các công đoạn khác. Một người làm kỹ thuật có thể góp phần tìm hiểu vấn đề, thiết kế hệ thống, kiểm chứng chất lượng và cải thiện kết quả sau khi sản phẩm vận hành. Điều đó cũng đòi hỏi hiểu rõ hơn mối liên hệ giữa công nghệ, người dùng và cách doanh nghiệp tạo ra giá trị. Coding tiếp tục đóng vai trò quan trọng, nhưng giá trị nghề nghiệp có thể được xây dựng từ phạm vi rộng hơn nhiều so với phần code mình trực tiếp viết.

Khách hàng cuối cùng trả tiền cho vấn đề được giải quyết và giá trị mà phần mềm mang lại, chứ không dựa đơn thuần vào số dòng code đã viết. Coding góp phần tạo ra giá trị ấy, cùng với các hoạt động nghiên cứu, thiết kế, phân phối và vận hành. Khi AI thay đổi cách coding được thực hiện, mình nghĩ người làm kỹ thuật có thêm lý do để nhìn lại vị trí của bản thân trong toàn bộ chuỗi giá trị phần mềm.

Tài liệu tham khảo

Mình sử dụng các nguồn dưới đây để xây dựng phần khung lý thuyết và đối chiếu những nhận định về tác động của AI. Những đường cong giá trị trong bài là mô hình minh họa do mình xây dựng, không phải kết quả đo lường từ các nghiên cứu này.

1. Michael E. Porter, The Value Chain, Harvard Business School, Institute for Strategy and Competitiveness. Nguồn
2. Sida Peng và cộng sự (2023), The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. Nguồn
3. McKinsey (2023), Unleashing Developer Productivity with Generative AI. Nguồn
4. METR (2025), Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. Nguồn
5. METR (2026), We are Changing our Developer Productivity Experiment Design. Nguồn
6. Google DORA (2025), State of AI-assisted Software Development. Nguồn
7. Google DORA (2026), Balancing AI Tensions: Moving from AI Adoption to Effective SDLC Use. Nguồn