Chi phí của việc 'đồng ý' đã thay đổi trong kỷ nguyên AI

Chi phí viết mã nguồn đã giảm; nhưng chi phí để duy trì nó thì không. Một khuôn mẫu để quyết định những thay đổi nào thực sự rẻ trong kỷ nguyên AI.

Ngày 17 tháng 7 năm 2026

6 phút

Phần đắt đỏ nhất của một yêu cầu tính năng nhỏ trước đây thường là việc viết mã. Giờ đây, đó thường là cuộc họp để quyết định xem có nên viết mã đó hay không.

Đó là một sự thay đổi thực sự, và nó âm thầm phá vỡ nhiều bản năng kỹ thuật. Các kỹ sư học được từ sớm rằng hầu hết các "yêu cầu nhỏ" không hề nhỏ: chúng cần các bài kiểm thử (tests), kế hoạch triển khai, người suy nghĩ thấu đáo về các trường hợp biên (edge cases) và chịu trách nhiệm về hành vi của tính năng sau khi phát hành. Một thay đổi mất hai giờ có thể trở thành sự xao nhãng kéo dài hai tuần nếu nó chạm vào phần sai của hệ thống. Vì vậy, chúng tôi từ chối. Điều này có thực sự cần thiết không? Nó có thuộc về bản phát hành này không? Nó có thay đổi hợp đồng mà chúng ta đã đồng ý không? Tôi sẽ không từ bỏ bản năng đó.

Nhưng nó dựa trên một giả định đang âm thầm bị phá vỡ, đó là việc viết phiên bản mã đầu tiên là bước đắt đỏ nhất. Đối với một loại thay đổi cụ thể, điều đó không còn đúng nữa. Nếu bạn có thể phân biệt những thay đổi đó với phần còn lại, bạn có thể thay thế câu hỏi "cái này có nằm trong phạm vi không?" bằng một câu hỏi mà bạn có thể trả lời trong ba mươi phút thay vì một cuộc tranh luận kéo dài hai ngày.

Cuộc tranh luận thường tốn kém hơn bản vá (patch)

Đây là một mô hình mà tôi liên tục thấy. Ai đó yêu cầu một thay đổi nhỏ như hiển thị dấu thời gian last_active_at vốn đã tồn tại trong backend lên một trang cài đặt. Nhóm dành bốn mươi phút trong một chuỗi thảo luận. Một người nói nghe có vẻ rủi ro. Ai đó nhớ lại một quá trình di chuyển dữ liệu liên quan từ hai năm trước. Ai đó nhắc đến thời hạn. Cuối cùng, chúng tôi đi đến kết luận "có lẽ mất một hoặc hai ngày, có thể hơn," với độ tự tin thấp, chủ yếu vì chưa ai thực sự thử làm nó.

Quy trình đó có ý nghĩa khi việc thử nghiệm là phần đắt đỏ nhất. Bạn phải dừng công việc đang làm, nạp ngữ cảnh vào đầu, thực hiện thay đổi bằng tay, viết các bài kiểm thử, sau đó khám phá các hệ quả bậc hai và bậc ba. Khi lần thử đầu tiên trở nên rẻ, việc bảo vệ ranh giới có thể tốn kém hơn là vượt qua nó.

Một tác nhân (agent) có thể tạo ra bản vá đầu tiên đó trong thời gian chuỗi thảo luận bắt đầu nóng lên. Nó không miễn phí và chắc chắn không tự động chính xác. Nhưng nó đủ rẻ để bước đi thông minh thường là ngừng đoán mò và nhìn vào một bản diff thực tế.

Bản vá đầu tiên là một cách kiểm tra giá, không phải sản phẩm

Sai lầm là coi bản vá được tạo ra là sản phẩm bàn giao. Không phải vậy. Nó là một công cụ thăm dò. Nó biến một cuộc tranh luận trừu tượng về phạm vi thành một sản phẩm cụ thể mà bạn có thể chất vấn:

Đó là những câu hỏi tốt hơn là "cái này có cảm giác như bị lan man phạm vi (scope creep) không?" vì giờ đây bạn đang tranh luận dựa trên bằng chứng thay vì cảm tính. Nếu trường last_active_at trả về một bản diff bốn dòng với một bài kiểm thử đạt yêu cầu, hãy phát hành nó. Cuộc tranh luận mới là phần đắt đỏ. Tuy nhiên, nếu yêu cầu tương tự đó quay lại và chạm vào middleware xác thực, bạn đã biết rằng yêu cầu đó chưa bao giờ là nhỏ. Không chỉ vậy, bạn đã biết điều này trong ba mươi phút thay vì hai ngày.

Đây không phải là để AI quyết định. Đây là việc sử dụng AI để làm cho sự phán đoán của con người trở nên rẻ hơn và có cơ sở hơn.

Rẻ để viết không có nghĩa là rẻ để duy trì

Đây là cái bẫy, và nó là sự khác biệt quan trọng nhất của kỷ nguyên AI. Một thay đổi không rẻ chỉ vì mã nguồn được tạo ra rẻ. Nó chỉ rẻ nếu con người có thể tự tin xem xét và chịu trách nhiệm về kết quả đó.

Một bản diff dài một nghìn dòng về mặt kỹ thuật thì đạt yêu cầu nhưng không ai muốn chịu trách nhiệm thì không phải là một thay đổi rẻ. Đó là một chi phí bị trì hoãn. Vì vậy, ranh giới trong trường hợp đó không phải là "một tác nhân có thể viết cái này không?" mà là "một người có thể xác thực nó không?"

Rất nhiều thay đổi vẫn xứng đáng bị từ chối thẳng thừng ngay cả khi mã nguồn rất đơn giản. Điều này bao gồm bất cứ thứ gì làm thay đổi hợp đồng sản phẩm, tạo ra gánh nặng hỗ trợ, hoặc chạm vào quyền riêng tư, thanh toán, hoặc tuân thủ. AI làm giảm chi phí tạo ra một ứng viên. Nó không làm gì để giảm chi phí duy trì ứng viên đó.

Đưa kỷ luật phạm vi đến gần hơn với bằng chứng

Theo truyền thống, kỷ luật phạm vi diễn ra trước khi triển khai, vì triển khai là thứ đắt đỏ cần bảo vệ. Giờ đây, một phần kỷ luật đó có thể chuyển sang giai đoạn xem xét. Điều đó không có nghĩa là bỏ qua việc lập kế hoạch. Nó có nghĩa là phải chính xác về việc lập kế hoạch nào thực sự mang lại hiệu quả.

Trước khi tranh luận lại một thay đổi nhỏ, hãy yêu cầu một nỗ lực có giới hạn. Các ràng buộc chính là điểm mấu chốt.

Tạo ra bản vá nhỏ nhất có thể. Giữ nó sau feature flag hiện có. Không thay đổi hợp đồng công khai. Thêm hoặc cập nhật các bài kiểm thử. Liệt kê mọi tệp bạn đã chạm vào và nêu rõ bất kỳ điều gì rủi ro.

Nếu tác nhân không thể tạo ra một bản vá sạch dưới các ràng buộc đó, yêu cầu đó lớn hơn bạn nghĩ, và bạn biết nó mang lại chi phí sở hữu thực sự trước khi bất kỳ ai cam kết thực hiện. Nếu nó làm được, điều đó cũng cho bạn biết điều gì đó. Dù thế nào đi nữa, bạn đã thay thế câu hỏi "cái này có nằm trong phạm vi không?" bằng "đây là chi phí của nó. Chúng ta có muốn trả không?"

Kỹ năng mới là định giá sự không chắc chắn

Những kỹ sư giỏi nhất trong thế giới có sự hỗ trợ của AI sẽ không phải là những người nói đồng ý với mọi thứ, và họ cũng không phải là những người phản xạ nói không. Họ sẽ là những người có thể định giá sự không chắc chắn một cách nhanh chóng. Họ sẽ biết khi nào một yêu cầu là một quyết định sản phẩm khoác lên mình chiếc áo triển khai, khi nào việc xem xét sẽ khó hơn việc viết, và khi nào một thay đổi đủ nhỏ để câu trả lời có trách nhiệm nhanh nhất là cứ thử làm nó.

Điều cuối cùng đó thực sự mới mẻ. "Thử làm rồi xem" trước đây có nghĩa là kéo một lập trình viên ra khỏi công việc khác. Giờ đây, đối với đúng loại nhiệm vụ, nó có nghĩa là giao cho một tác nhân một nhiệm vụ có giới hạn và sử dụng kết quả để đưa ra quyết định tốt hơn. Ít thời gian đoán mò hơn, nhiều thời gian giám sát hơn. Ít thời gian coi việc triển khai là một hộp đen hơn, nhiều thời gian đánh giá các sản phẩm cụ thể hơn.

Lan man phạm vi (scope creep) vẫn là có thật. Nhưng "không, vì bất kỳ mã mới nào cũng quá đắt" là một lập luận yếu hơn nhiều so với hai năm trước. Chi phí sản xuất mã nguồn đã giảm. Chi phí để hiểu, xem xét và duy trì nó thì không. Vì vậy, câu hỏi đáng đặt ra đã chuyển từ "đây có phải là thêm việc không?" sang "chi phí thực sự nằm ở đâu?". Và đôi khi, đối với một thay đổi nhỏ, có giới hạn, chi phí thực sự chỉ là việc tìm ra câu trả lời.

Chi phí của việc nói đồng ý đã thay đổi. Chi phí của việc nói không cũng nên thay đổi theo.

Viết bởi

Dalia là một kỹ sư phần mềm trong nhóm Copilot Agent Control Plane của GitHub, xây dựng lớp quản trị subagent cho khách hàng của Copilot.

Các bài viết liên quan

Chúng tôi cũng có bản tin (newsletter)

Khám phá các mẹo, hướng dẫn kỹ thuật và các phương pháp tốt nhất trong bản tin hai tuần một lần dành riêng cho các nhà phát triển của chúng tôi.

Địa chỉ email của bạn