Copilot Viết Nó, Nhưng Ai Sở Hữu Nó? Khoảng Trống Quản Trị Mà Các Nhóm Kỹ Thuật Có Thể Bỏ Qua

Một kỹ sư mở Copilot để giúp soạn mã cho trang web của khách hàng. Trong vài giây, họ nhận được đoạn mã mà trước đây sẽ mất thời gian đáng kể để viết thủ công. Đối với nhiều nhà phát triển web và doanh nghiệp tối ưu hoá website, việc tự hỏi: đoạn mã này có đáng tin cậy không? Có an toàn không? Có nên xem xét trước khi triển khai không?  Tất cả những câu hỏi này đều nằm trong một vấn đề chung: Ai sẽ chịu trách nhiệm về việc mã hỗ trợ bởi AI? Và quan trọng nhất, ai sở hữu lợi nhuận năng suất?

Nếu AI cho phép một đội kỹ thuật hoàn thành nhiều công việc hơn trong cùng một khoảng thời gian, thì mọi người đều có thể hưởng lợi nhiều hơn từ giá trị kinh tế đó. Điều này có thể là lập trình viên tiết kiệm thời gian, nhà tuyển dụng nhận được giá trị cao hơn từ giờ làm việc đã tiết kiệm, hoặc khách hàng nhận được những gì họ đã trả tiền với thời gian dư thừa. Bất kể lợi ích từ thời gian tiết kiệm như thế nào, điều quan trọng nhất vẫn là cách công việc được quản trị và định giá.

AI và Lập Trình Đang Trở Thành Không Thể Tránh

Các công cụ lập trình AI đang nhanh chóng thu hút sự chú ý và tiến vào phát triển chính thống. Theo 2025 Stack Overflow Developer Survey, 84% người trả lời đã hoặc dự định sử dụng công cụ AI trong quy trình phát triển của họ.

Mặc dù việc tích hợp AI vào quy trình làm việc của các nhà phát triển web ngày càng phổ biến, vẫn còn sự do dự về độ tin cậy của nó. Cuộc khảo sát cùng báo cáo rằng 46% không hoàn toàn tin tưởng vào độ chính xác của kết quả AI, và khoảng 66% cho rằng các giải pháp AI “gần đúng, nhưng chưa hoàn hảo” là nguồn gây khó chịu.

Cuộc tranh luận về lập trình AI đang hình thành hiện nay tập trung nhiều hơn vào độ tin cậy của nó hơn là liệu đoạn mã đó có tạo ra giá trị nhiều hơn và ai chịu trách nhiệm đảm bảo điều đó.

AI Đang Phá Vỡ Mối Quan Hệ Giữa Giờ Làm Việc và Kết Quả

Tiền công cho phát triển phần mềm luôn dựa trên giả định rằng kết quả kỹ thuật gắn liền với nỗ lực kỹ thuật. Tuy nhiên, AI sinh ra hiện đang làm phức tạp phương trình này.

Một thí nghiệm có kiểm soát với 95 nhà phát triển cho thấy những người tham gia có quyền truy cập GitHub Copilot đã hoàn thành một nhiệm vụ máy chủ HTTP JavaScript cụ thể nhanh hơn 55,8% so với những người không có quyền truy cập.

Điều này cho thấy AI có thể tăng tốc phát triển, có thể mà không làm giảm chất lượng. Tuy nhiên, các con số này chỉ thành công vì thí nghiệm dựa trên một nhiệm vụ lập trình rất cụ thể. Mặc dù nhiệm vụ được hoàn thành nhanh hơn, nhưng không có nghĩa là Copilot làm cho toàn bộ tổ chức kỹ thuật tăng năng suất 55,8%.

Một nghiên cứu khác minh họa ý tưởng này. Một thử nghiệm liên quan đến 96 kỹ sư phần mềm toàn thời gian của Google cho thấy các nhà phát triển sử dụng AI hoàn thành một nhiệm vụ cấp doanh nghiệp trong khoảng 96 phút, so với 114 phút đối với những người không dùng. Ước tính điều chỉnh của các nhà nghiên cứu cho thấy khoảng giảm 21% thời gian hoàn thành. Tuy nhiên, nghiên cứu không khám phá chất lượng mã AI, cũng không đề cập đến các câu hỏi công bằng liên quan đến việc phụ thuộc vào công nghệ.

Cũng có bằng chứng cho thấy AI làm chậm thời gian lập trình. Một nghiên cứu ngẫu nhiên của METR đã tham gia 16 nhà phát triển nguồn mở có kinh nghiệm, họ làm việc trên 246 vấn đề thực tế trong các kho mà họ quen thuộc. Sử dụng các công cụ có sẵn vào đầu năm 2025, bao gồm Claude Sonnet 3.5 và 3.7, cũng như Cursor Pro, họ mất khoảng 19% thời gian lâu hơn để hoàn thành nhiệm vụ, mặc dù nhiều người cho rằng các công cụ này sẽ tiết kiệm thời gian.

Cùng nhau, các nghiên cứu này phá vỡ kỳ vọng rằng AI cho phép các nhà phát triển làm việc nhanh hơn. Thay vào đó, nó làm cho thời gian và giá trị của nhà phát triển trở nên khó dự đoán hơn đối với các doanh nghiệp cung cấp dịch vụ web và khách hàng nhận được.

Vấn Đề Định Giá Mà Không Ai Nhắc Đến

Mô hình Thời Gian & Vật Liệu (T&M) là một mô hình phổ biến trong phát triển web để mua phần mềm, vì nó giải quyết một vấn đề lặp lại trong ngành: một dự án đang phát triển.

Với mô hình này, thay vì yêu cầu mọi tính năng hoặc nhiệm vụ phải được xác định trước khi phát triển bắt đầu, khách hàng có thể trả tiền cho thời gian kỹ thuật khi dự án tiến triển và thay đổi.

Tuy nhiên, AI đang tạo ra những trục trặc trong mô hình đã được kiểm chứng này. Khi tiền công gắn trực tiếp với giờ kỹ thuật, thời gian phát triển hiệu quả hơn có thể dẫn đến ít giờ tính phí hơn cho khách hàng. Nếu AI hỗ trợ cùng kết quả trong thời gian ngắn hơn, công nghệ này có thể tạo giá trị cho khách hàng, nhưng việc giảm giờ tính phí đồng nghĩa với doanh thu ít hơn cho nhà cung cấp.

Giải pháp không phải là khuyến khích các nhà phát triển làm việc chậm hơn. Mô hình T&M hiện đang đối mặt với một vấn đề cấu trúc về cách định giá và khuyến khích được thiết kế. Việc sử dụng mức lương theo giờ để xác định giá trị có thể gây hạn chế. Người mua có thể biết chính xác chi phí mỗi giờ kỹ thuật nhưng vẫn không chắc chắn về tổng khoản đầu tư cần thiết để đạt được kết quả mong muốn.

Khi AI thay đổi năng suất kỹ thuật, câu hỏi có thể chuyển từ:

“Giá của một giờ lập trình viên là bao nhiêu?” → “Điều gì xảy ra với giá trị khi cần ít giờ lập trình viên hơn?”

Kết quả của METR làm phức tạp câu hỏi này. Nếu các nhà phát triển tin rằng họ có thể tiết kiệm thời gian trong khi thực tế họ lại mất nhiều thời gian hơn, thì việc áp dụng AI hay năng suất được cảm nhận không đủ để chứng minh giá trị tài chính. Đó là lý do tại sao các tổ chức cần một khung quản trị có thể đo lường những gì thực sự đã xảy ra.

Khoảng Trống Quản Trị Có Bốn Chủ Sở Hữu

Thảo luận về quản trị trong phát triển hỗ trợ AI cần đi xa hơn các chính sách quy định công cụ nào mà các nhà phát triển có thể sử dụng.
Có ít nhất bốn loại quyền sở hữu mà các tổ chức kỹ thuật nên xác định.

1. Ai sở hữu mã nguồn?

AI có thể tạo ra một triển khai, nhưng không thể trở thành lý do để phát triển không có trách nhiệm. Ai đó vẫn phải chịu trách nhiệm kiểm tra, thử nghiệm và phê duyệt mã cho đến khi nó đạt tới giai đoạn sản xuất.

2. Ai chịu rủi ro?

Mã nhanh hơn chỉ có giá trị nếu nó không gây ra vấn đề ở nơi khác. Một nghiên cứu thực nghiệm về mã do AI tạo ra đã xác định các lỗ hổng bảo mật trong 29,5% các đoạn Python được kiểm tra và 24,2% các đoạn JavaScript. Nghiên cứu cũng xác định các lỗ hổng bao phủ 43 danh mục trong Common Weakness Enumeration.

Tuy nhiên, nghiên cứu phát hiện rằng việc đưa các cảnh báo phân tích tĩnh trở lại Copilot Chat có thể khắc phục tới 55,5% các vấn đề bảo mật đã xác định. Nghiên cứu cho thấy AI có thể tạo ra và giải quyết các vấn đề mã, nhưng các tổ chức cần có quy trình để xác định cách xác thực kết quả của nó.

NIST’s SP 800-218A phản ánh nguyên tắc này bằng cách mở rộng Khung Phát Triển Phần Mềm An Toàn của nó với các thực hành tốt nhất nhằm giải quyết AI sinh ra và các mô hình nền tảng đa mục đích.

3. Ai sở hữu lợi nhuận năng suất?

Các thỏa thuận thương mại từ đầu là thiết yếu để xác định ai nên nhận được lợi ích về hiệu quả. AI có thể giúp khách hàng chi tiêu ít hơn, cho phép các đội ngũ cung cấp nhiều phần mềm hơn, hoặc không mang lại lợi ích tài chính nào vào cuối dự án.
Điều vẫn không thay đổi là nhu cầu về quy trình minh bạch và việc giao hàng chất lượng, công việc đã được thống nhất.

4. Ai chịu trách nhiệm ưu tiên?

AI có thể làm cho việc tạo tính năng trở nên rẻ hơn và nhanh hơn, nhưng không thể quyết định liệu những tính năng đó có cần thiết hay không.
Thực tế, việc tăng khả năng phát triển có thể làm cho việc ưu tiên trở nên quan trọng hơn. Khi các đội có thể xây dựng và thử nghiệm nhanh hơn, vẫn cần có người xác định kết quả nào biện minh cho ngân sách sẵn có, và ý tưởng nào nên bị loại bỏ.

Quản Trị AI Đang Trở Thành Vấn Đề Tài Chính

Những câu hỏi này làm cho quản trị AI ngày càng trở nên liên quan. Hãy tưởng tượng hai đối tác phát triển tính phí theo giờ tương tự nhau.

Một đã tích hợp AI vào quy trình kỹ thuật mạnh mẽ và đạt được kết quả yêu cầu nhanh hơn đáng kể, trong khi đối phương mất thời gian lâu hơn. So sánh chỉ mức phí theo giờ của họ không cho người mua nhiều thông tin về quy trình họ sẽ thực hiện.

Người mua sẽ cần đánh giá:

• Tổng khoản đầu tư dự kiến
• Trách nhiệm đối với việc vượt ngân sách
• Kiểm soát chất lượng đối với công việc do AI tạo ra
• Cách chia sẻ lợi nhuận hiệu suất

Mô hình T&M vẫn có thể hữu ích cho cả hai bên nếu họ có ý thức chấp nhận sự không chắc chắn trong dịch vụ. Các thỏa thuận giá cố định cũng có thể hoạt động khi yêu cầu và kết quả giao hàng ổn định.

Nhưng AI cũng khiến các cấu trúc thay thế đáng xem xét. Một cách tiếp cận là thiết lập một ranh giới tài chính tối đa trong khi giữ phạm vi linh hoạt. Khi đó, các tính năng có thể được ưu tiên dựa trên giá trị kinh doanh trong mô hình đó.

Nếu kỹ thuật trở nên hiệu quả hơn, lợi nhuận có thể chuyển thành khả năng sản phẩm bổ sung thay vì thời gian tính phí thêm. Các khuyến khích thương mại nên thúc đẩy cùng kết quả như các khuyến khích kỹ thuật, tạo ra phần mềm hữu ích hơn một cách hiệu quả nhất có thể.

Cuộc Trò Chuyện AI Giống Nhau

Các nhà lãnh đạo kỹ thuật cần hiểu cách các khuyến khích thương mại ảnh hưởng đến việc giao hàng. Các bộ phận tài chính và mua sắm cần có đủ khả năng nhìn thấy trong kỹ thuật hỗ trợ AI để đánh giá liệu hiệu quả được tuyên bố có mang lại giá trị đo lường được hay không.

Điều đó có nghĩa là quản trị AI trưởng thành không thể dừng lại ở danh sách mô hình đã được phê duyệt, các kiểm soát bảo mật, chính sách dữ liệu, hay yêu cầu kiểm tra mã. Nó cần giải quyết trách nhiệm, rủi ro tài chính, ưu tiên và quyền sở hữu lợi nhuận năng suất.

Nhưng có một câu hỏi về quyền sở hữu thứ hai có thể ảnh hưởng lớn hơn tới ngân sách công nghệ: Ai sở hữu giá trị được tạo ra hoặc mất đi khi AI thay đổi tốc độ xây dựng phần mềm?

Các tổ chức xác định liệu kỹ thuật nhanh hơn thực sự tạo ra sản phẩm tốt hơn, kiểm soát đầu tư và đạt được kết quả kinh doanh đo lường được sẽ là những người có thể vượt lên trước các đối thủ.

Nếu đội phát triển của bạn áp dụng AI vào ngày mai, mô hình quản trị và thương mại hiện tại của bạn có thể cho bạn biết liệu nó đã làm cho việc giao hàng có giá trị hơn không?