AI viết code ngày càng giỏi, lập trình viên còn tạo ra giá trị ở đâ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 việc 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 phải 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.

Điều này làm thay đổi đáng kể trải nghiệm của người lập trình. 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 mà một số lập trình viên đang trải qua cũng bắt đầu từ đây. Nếu một phần lớn công việc chuyên môn của mình có thể được thực hiện nhanh đến như vậy, giá trị nghề nghiệp của mình sẽ nằm ở đâu?

Mình muốn thử tiếp cận vấn đề từ góc độ kinh tế của ngành phần mềm, thông qua một khái niệm khá quen thuộc trong quản trị chiến lược: chuỗi giá trị (Value Chain).

Có một điều thú vị là ngay cả trước khi AI xuất hiện, việc viết code đã chỉ 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. Chúng ta dành nhiều năm để trở nên giỏi hơn ở công đoạn này, nên đôi khi dễ nhìn toàn bộ sản phẩm qua lăng kính của công việc mình đang làm.

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

Hãy tưởng tượng 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ỏ.

Để bắt đầu, bạn cần biết các cửa hàng đang gặp vấn đề gì. Có thể họ đang 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 tiếp tục tìm hiểu cách họ vận hành, xác định vấn đề nào cần ưu tiên giải quyết, thiết kế các chức năng cần thiết rồi mới bắt đầu lập trình.

Khi viết code xong, vẫn còn khá nhiều việc phải làm. Phần mềm cần được kiểm thử, triển khai, bảo trì và bảo vệ dữ liệu. Bạn cần tìm khách hàng, hướng dẫn họ sử dụng, xử lý những vấn đề phát sinh và cải tiến sản phẩm theo phản hồi thực tế.

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 có đầ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ù những chức năng ban đầu được xây dựng rất tốt.

Như vậy, việc lập trình là một mắt xích quan trọng trong một chuỗi hoạt động lớn hơn.

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 các hoạt động có liên quan đến nhau, từ việc 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 những 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 vào ngành phần mềm, chúng ta có thể phân biệt ba khái niệm thường bị trộn lẫn.

Giá trị sử dụng là lợi ích mà 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à ra 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 mà giải pháp mang lại so với nguồn lực phải bỏ ra. Phần mềm có thể tạo ra lợi ích lớn hơn nhiều so với chi phí xây dựng nó.

Giá trị mà doanh nghiệp nắm giữ là phần lợi ích doanh nghiệp có khả năng chuyển thành doanh thu và lợi nhuận, sau khi tính đến chi phí, cạnh tranh và các điều kiện thị trường.

Ba khái niệm này liên quan chặt chẽ nhưng không đồng nhất.

Một kỹ sư có thể viết ra một 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ể rất 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ể trở thành sản phẩm 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ả.

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, chẳng hạn cơ sở dữ liệu, hệ thống hạ tầng, bảo mật hay những phần mềm có yêu cầu độ tin cậy đặc biệt cao. Không có một công thức cố định để tính coding đóng góp bao nhiêu phần trăm vào giá trị sản phẩm.

Điều mình muốn nhấn mạnh là mức độ khó của công việc kỹ thuật và khả năng nắm giữ giá trị kinh tế cần được đánh giá riêng.

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. 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à các yếu tố quyết định lợi nhuận lại có nhiều khác biệt.

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ủa doanh nghiệp còn phụ thuộc vào khả năng tìm kiếm dự án, đàm phán giá, ước lượng công việc, quản trị phạm vi, sử dụng nhân lực và kiểm soát chất lượng.

Một công ty lập trình 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ể lỗ.

Trong mô hình này, kỹ năng lập trình là một nguồn lực sản xuất quan trọng. Tuy nhiên, năng lực tổ chức nguồn lực và thực hiện hợp đồng mới quyết định doanh nghiệp chuyển được bao nhiêu doanh thu thành lợi nhuận.

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ỏ. Họ 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 được hoàn thiện, doanh nghiệp 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à lợi thế kinh tế quan trọng 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, vẫn có các chi phí vận hành, hỗ trợ, cập nhật và phân phối.

Ở đây, quyền sở hữu tài sản trí tuệ, khả năng đáp ứng thị trường, thương hiệu và kênh phân phối trở nên quan trọng.

Bạn có thể sở hữu code của một phần mềm rất tốt, nhưng điều đó chưa đảm bảo sẽ có nhiều người mua. Khách hàng còn phải biết đến sản phẩm, tin tưởng nó và có lý do để lựa chọn nó thay vì những phương án khác.

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 việc cung cấp dịch vụ phần mềm liên tục, thường thông qua 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. Nhưng để duy trì doanh thu đó, doanh nghiệp cần đảm bảo hệ thống hoạt động ổn định, hỗ trợ khách hàng, liên tục cải thiện trải nghiệm và thuyết phục người dùng tiếp tục trả tiền.

Giả sử khách hàng sử dụng sản phẩm 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 sử dụng 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, doanh nghiệp SaaS phải quan tâm đến các chỉ số như Customer Acquisition Cost (CAC), Churn Rate, Customer Lifetime Value (LTV), Gross Margin và Net Revenue Retention (NRR).

Đối với SaaS, phần mềm được viết ra mới chỉ là điểm bắt đầu của quá trình kinh doanh lâu dài.

Nhìn lại ba mô hình, chúng ta thấy năng lực coding có thể được sử dụng theo nhiều cách khác nhau, nhưng doanh thu và lợi nhuận của mỗi mô hình phụ thuộc vào cả chuỗi hoạt động. Đây là nền tảng để hiểu vì sao AI có thể tạo ra tác động khác nhau lên từng loại 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ác khá thú vị gọi là Smile Curve, thường được sử dụng để minh họa sự phân bố giá trị gia tăng giữa các công đoạn trong một ngành.

Trong hình dạng điển hình của đường cong này, 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, việc 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 một 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.

AI đang làm thay đổi điều đó.

Một người có hiểu biết về sản phẩm và khả năng sử dụng AI tốt có thể tạo prototype nhanh hơn. Lập trình viên có thể sử dụng coding agent để viết phần code ban đầu, bổ sung test, tái cấu trúc hoặc tìm hiểu một codebase mới.

Những công việc kỹ thuật có tính lặp lại và dễ mô tả đang trở nên thuận tiện hơn để tự động hóa. Chi phí để tạo ra một đơn vị đầu ra phần mềm trong nhiều tình huống có khả năng giảm xuống.

Về mặt kinh tế, khi việc cung cấp một loại năng lực trở nên dễ dàng hơn, lợi thế cạnh tranh dựa riêng trên sự khan hiếm của năng lực đó có thể suy giảm.

Điều này đặc biệt dễ thấy ở 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 các tích hợp tương đối tiêu chuẩn.

Nếu nhiều đối thủ có thể xây dựng 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ì công việc lập trình mất nhiều thời gian.

Tuy nhiên, cần phân biệt giá trị của hoạt động coding vớ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. Nhiều ý tưởng trước đây quá đắt để thực hiện nay có thể trở nên khả thi. Nhu cầu về hệ thống phần mềm đáng tin cậy, bảo mật và có thể vận hành lâu dài cũng không tự động giảm xuống.

Phần chịu áp lực lớn hơn là khả năng định giá cao chỉ dựa trên việc thực hiện 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.

Khi đó, lợi thế cạnh tranh có thể dịch chuyển sang các năng lực khác.

Ở đầu chuỗi, đó là khả năng hiểu ngành, xác định đúng vấn đề, thiết kế giải pháp và đưa ra những 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 những kết quả kinh doanh mà người dùng thực sự cần.

Ngoài ra, AI cũng làm tăng yêu cầu đối với hoạt động kiểm chứng. Khi lượng code được tạo ra nhanh hơn, doanh nghiệp phải có cách đảm bảo hệ thống hoạt động đúng, an toàn và có thể bảo trì trong thời gian dài.

Mình cho rằng đây là một cách giải thích hợp lý về sự dịch chuyển giá trị, dù hình dạng đường cong có thể rất khác nhau giữa các loại phần mềm.

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

Nếu AI có thể viết code trong vài giây, liệu điều đó có nghĩa công việc lập trình được hoàn thành nhanh hơn tương ứng?

Các nghiên cứu thực tế cho thấy câu trả lời phụ thuộc khá nhiều vào loại công việc, kinh nghiệm của người thực hiện, công cụ và môi trường làm việc.

Năm 2023, một nghiên cứu của Sida Peng và các cộng sự về GitHub Copilot cho thấy nhóm lập trình viên 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ột kết quả đáng chú ý, nhưng nó được đo trên một nhiệm vụ cụ thể trong môi trường thực nghiệm.

McKinsey cũng công bố nghiên cứu năm 2023 cho thấy AI tạo sinh có thể giảm đáng kể thời gian thực hiện một số công việc như viết code, tạo tài liệu và refactoring. Mức cải thiện thay đổi theo độ phức tạp của nhiệm vụ và kinh nghiệm của người sử dụng.

Đến tháng 7/2025, tổ chức METR công bố một 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. Kết quả khá bất ngờ: 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.

Điều thú vị là chính những lập trình viên tham gia vẫn cảm thấy AI giúp họ làm việc nhanh hơn.

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 những hạn chế về lựa chọn người tham gia và cách đo lường, nên chưa thể đưa ra kết luận đáng tin cậy về mức độ tăng tốc.

Mình nghĩ những kết quả này không mâu thuẫn với trải nghiệm AI viết code rất nhanh. Chúng nhắc chúng ta rằng thời gian tạo ra code chỉ là một phần của thời gian hoàn thành công việc.

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 phần khác và đảm bảo sản phẩm có thể 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 một nhận định quan trọ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.

Trong một phân tích được 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ể được chuyển sang việc kiểm tra, đánh giá và xác minh kết quả. Một thay đổi được tạo ra nhanh nhưng khó review, thiếu test hoặc gây ra lỗi trên production chưa chắc làm cho toàn bộ quy trình phát triển hiệu quả hơn.

Vì vậy, khi sử dụng AI, mình nghĩ chúng ta nên đo thời gian từ lúc xuất hiện nhu cầu đến khi một giải pháp hoạt động ổn định và tạo ra giá trị, thay vì chỉ đo tốc độ sinh code.

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, chúng ta thường phải đầu tư nhiều năm. Từ việc học ngôn ngữ lập trình đầu tiên, hiểu các cấu trúc dữ liệu, framework, database đến thiết kế một hệ thống hoàn chỉnh, tất cả đều cần thực hành và tích lũy kinh nghiệm.

Khi một người dành phần lớn thời gian làm việc để giải quyết các bài toán coding, việc 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 giải quyết được một bug khó, tối ưu một truy vấn phức tạp hoặc hoàn thiện một hệ thống lớn, chúng ta đều nhận được sự ghi nhận về năng lực chuyên môn.

Nhưng trong quá trình đó, mình nghĩ có ba thứ rất dễ bị nhầm lẫn.

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, chúng ta 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 có thể vẫn 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. Đây chính là một trong những nguồn tạo ra năng suất của công nghệ.

Điều thay đổi 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, điều này tạo ra áp lực trực tiếp. Trong mô hình bán sản phẩm, việc giảm chi phí phát triển có thể giúp doanh nghiệp thử nghiệm nhiều ý tưởng hơn hoặc cải thiện biên lợi nhuận, tùy vào mức độ cạnh tranh.

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

Đây có lẽ là điều 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.

Chúng ta thường cảm thấy một sản phẩm đã gần hoàn thành khi các chức năng chính chạy ổn định. Nhưng xét theo vòng đời kinh doanh, sản phẩm có thể vẫn đang ở giai đoạn rất sớm.

Có ai thực sự cần nó không? Họ đang giải quyết vấn đề bằng cách nào? Họ có sẵn sàng trả tiền không? Làm sao để tiếp cận họ? Sản phẩm có đủ tốt để họ tiếp tục sử dụng hay không?

Những câu hỏi này thường không thể được trả lời bằng việc viết thêm code.

AI xuất hiện khiến sự khác biệt giữa ba khái niệm trên trở nên rõ hơn. Khi thời gian và công sức cần thiết cho nhiều hoạt động lập trình giảm xuống, chúng ta có thêm lý do để nhìn lại cách bản thân tạo ra giá trị trong toàn bộ hệ thống.

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. Nhưng nếu doanh nghiệp và khách hàng vẫn tính giá hoàn toàn theo số giờ lao động, việc tăng năng suất có thể tạo 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, dịch vụ có giá trị cao hơn hoặc các hợp đồng dựa trên kết quả 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ó khả năng 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ừ việc sở hữu một tính năng đơn lẻ có thể giảm đi. Khả năng 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 trở nên đáng quan tâm hơn.

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í tạo ra những chức năng trước đây quá đắt để triển khai. Nhưng sản phẩm vẫn phải giữ chân người dùng, đảm bảo chất lượng dịch vụ và có mô hình chi phí phù hợp. Những khoản chi cho mô hình AI, inference, hạ tầng và hoạt động của agent còn có thể làm thay đổi cấu trúc chi phí của SaaS.

Mình nghĩ AI làm gia tăng cả cơ hội lẫn cạnh tranh ở cả ba mô hình. Khả năng 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. Lợi ích cuối cùng còn phụ thuộc vào việc doanh nghiệp có chuyển năng suất đó thành giá trị khách hàng và lợi thế cạnh tranh được hay không.

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. Chúng ta vẫn cần những người có chuyên môn kỹ thuật rất sâu, đặc biệt ở các hệ thống phức tạp và có yêu cầu độ tin cậy cao.

Nhưng mình nghĩ mỗi người nên mở rộng cách nhìn về công việc, để hiểu rõ hơn những gì đang diễn ra trước và sau công đoạn mình phụ trách.

Có năm hướng mà bạn có thể bắt đầu.

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, hãy dành 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. Thay vì bắt đầu ngay từ việc chọn thư viện biểu đồ, bạn có thể hỏi họ đang cần đưa ra quyết định gì từ dashboard này.

Có thể mục tiêu thực sự là phát hiện đơn hàng giao chậm. Trong trường hợp đó, một hệ thống cảnh báo đúng thời điểm có thể hữu ích hơn một dashboard phức tạp.

Khả năng hiểu bài toán giúp chúng ta tránh xây dựng những thứ không thật sự cần thiết.

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 ra code, nhưng vẫn cần người chịu trách nhiệm về cách các thành phần của hệ thống hoạt động cùng nhau.

Bạn nên hiểu các vấn đề như 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.

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ử tương đối nhanh. Nhưng hệ thống phải làm gì 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? Khi một yêu cầu bị retry sau khi hết thời gian chờ?

Đây là những vấn đề liên quan đến tính toàn vẹn dữ liệu và thiết kế hệ thống. Khả năng kiểm soát chúng tạo ra giá trị rất lớn khi phần mềm được đưa vào sử dụng 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ĩ việc học AI coding agent ngày nay nên trở thành một phần của quá trình phát triển nghề nghiệp.

Nhưng ngoài kỹ năng giao việc cho AI, chúng ta cần biết chuẩn bị ngữ cảnh, mô tả tiêu chí chấp nhận, thiết kế test, xem xét thay đổi và đánh giá kết quả.

Một cách thực hành khá hữu ích là trước khi yêu cầu AI triển khai, bạn viết rõ điều kiện để coi công việc hoàn thành.

Ví dụ, khi xây dựng chức năng thanh toán, các điều kiện có thể bao gồm: 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 được 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, nhưng kết quả phải được kiểm chứng theo những điều kiện đã thống nhất.

Cách làm này giúp chuyển sự chú ý từ số dòng code sang hành vi đúng của hệ thống.

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

Nếu bạn đang làm trong một doanh nghiệp phần mềm, hãy thử tìm hiểu những gì xảy ra với sản phẩm sau khi được 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? Người dùng thường bỏ cuộc ở bước nào? Những vấn đề nào khiến họ liên hệ hỗ trợ?

Nếu đang 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 những quyết định kỹ thuật phù hợp hơn với mục tiêu chung.

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. Đó là thông tin hữu ích để theo dõi công việc, nhưng chưa cho biết những thay đổi ấy tạo ra lợi ích gì.

Bạn có thể bắt đầu kết nối công việc kỹ thuật với những kết quả cụ thể hơn: giảm thời gian xử lý một đơn hàng, giảm số lỗi phát sinh, 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.

Không phải mọi công việc đều có thể gắn trực tiếp với doanh thu. Những chỉ số như độ ổ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 cũng rất quan trọng.

Điều mình muốn hướng đến là khả năng nhìn thấy mối liên hệ giữa phần việc của mình và kết quả cuối cùng mà sản phẩm cần đạt được.

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ĩ là có, và sẽ còn quan trọng trong một thời gian dài. Nhưng cách chúng ta sử dụng kỹ năng đó có thể thay đổi rất 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, có khả năng đánh giá giải pháp và nhận biết những sai sót mà một người thiếu kinh nghiệm có thể bỏ qua.

Đồng thời, AI cũng 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 khả 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ể tham gia tạo ra sản phẩm, những 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ể là chuyên môn rất sâu về hệ thống phân tán, bảo mật, dữ liệu hay tối ưu hiệu năng. Cũng có thể là khả năng kết hợp công nghệ với kiến thức ngành, thiết kế sản phẩm hoặc dẫn dắt những dự án phức tạp.

Không có một con đường duy nhất cho tất cả.

Cá nhân mình vẫn thích lập trình. Việc có thể biến một ý tưởng thành thứ hoạt động được luôn là một trải nghiệm thú vị. AI còn khiến quá trình ấy trở nên 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 thấy cần dành nhiều sự chú ý hơn cho việc quyết định nên xây dựng cái gì, vì sao cần xây dựng, những giới hạn nào phải được tôn trọng và làm sao để biết giải pháp thực sự tốt.

Đó là những câu hỏi mà việc viết code nhanh hơn chưa tự trả lời được.

Nếu nhìn lại toàn bộ chuỗi giá trị, mình nghĩ AI đang mang đến một cơ hội khá lớn cho lập trình viên. Chúng ta có thể dành ít thời gian hơn cho một số thao tác thực thi, từ đó tham gia sâu hơn vào việc tìm hiểu vấn đề, thiết kế hệ thống, kiểm chứng chất lượng và tạo ra kết quả.

Khách hàng cuối cùng không trả tiền cho số dòng code mà chúng ta viết. Họ trả tiền cho vấn đề được giải quyết và giá trị mà phần mềm mang lại.

Coding là một trong những năng lực giúp tạo ra giá trị ấy. Và khi AI thay đổi cách coding được thực hiện, có lẽ đây cũng là thời điểm phù hợp để mỗi người nhìn lại mình đang đứng ở đâu 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. https://www.isc.hbs.edu/strategy/business-strategy/Pages/the-value-chain.aspx

2. Sida Peng và cộng sự (2023), The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. https://arxiv.org/abs/2302.06590

3. McKinsey (2023), Unleashing Developer Productivity with Generative AI. https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/unleashing-developer-productivity-with-generative-ai

4. METR (2025), Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/

5. METR (2026), We are Changing our Developer Productivity Experiment Design. https://metr.org/blog/2026-02-24-uplift-update/

6. Google DORA (2025), State of AI-assisted Software Development. https://dora.dev/research/2025/dora-report/

7. Google DORA (2026), Balancing AI Tensions: Moving from AI Adoption to Effective SDLC Use. https://dora.dev/insights/balancing-ai-tensions/

Định vị lõi

#ai#lap-trinh#value-chain#saas#nghe-nghiep#ai-coding-agent