Zendesk: Khi AI tạo sinh làm mã nguồn trở nên dồi dào, "khả năng hấp thụ" chính là nút thắt mới

Zendesk gần đây đã đưa ra lập luận rằng AI tạo sinh (Generative AI) đã thay đổi yếu tố giới hạn trong việc phát triển phần mềm. Thay vì việc viết mã nguồn, thách thức lớn nhất hiện nay chuyển sang cái mà họ gọi là "khả năng hấp thụ" (absorption capacity). Đây được định nghĩa là năng lực của tổ chức trong việc xác định rõ vấn đề, tích hợp các thay đổi vào hệ thống rộng lớn hơn, xác minh tính chính xác của chúng và chuyển hóa việc triển khai thành giá trị tin cậy.

Trong bối cảnh mã nguồn trở nên dồi dào nhờ AI, thách thức chính không còn là sản xuất code nhanh chóng nữa. Thay vào đó, vấn đề nằm ở việc đảm bảo rằng việc tạo mã nhanh chóng không vượt quá khả năng về tính nhất quán của kiến trúc, năng lực xem xét (review) và quy trình giao hàng.

Khả năng hấp thụ trong kỷ nguyên AI

Mã nguồn dồi dào và sự thay đổi của nút thắt

Trong một bài đăng trên blog kỹ thuật của Zendesk, Bence A. Tóth đã xây dựng lập luận này thông qua các so sánh từ nông nghiệp và sản xuất. Ông cho rằng việc cải thiện một phần của hệ thống không nhất thiết làm tăng tổng thông lượng nếu vẫn còn một ràng buộc khác tồn tại. Trong phần mềm, AI tạo sinh đã giảm chi phí sản xuất mã nguồn đến mức việc triển khai không còn là ràng buộc hẹp nhất nữa.

Thuật ngữ "khả năng hấp thụ" của Tóth bao gồm công việc cần thiết để chuyển đổi mã được tạo ra thành kết quả đáng tin cậy. Điều này bao gồm việc quyết định những gì nên được xây dựng, đồng bộ hóa việc triển khai với kiến trúc xung quanh, thiết lập sự tin cậy thông qua xác minh và xác định xem sự thay đổi kết quả có thực sự cải thiện kết quả cho khách hàng hay không.

Bốn giải pháp thực tế để tối ưu hóa khả năng hấp thụ

Bài viết đề xuất bốn phản hồi thực tế để các đội ngũ phát triển thích nghi với thực tế mới:

• Chia sẻ trách nhiệm định hình vấn đề: Việc định hình vấn đề nên trở thành trách nhiệm chung giữa đội ngũ sản phẩm và kỹ thuật thay vì là sự chuyển giao một chiều. Các yêu cầu mơ hồ hiện nay có thể tạo ra các triển khai có vẻ hợp lý nhưng sai lệch ở quy mô lớn, do đó sự hợp tác là chìa khóa.
• Giảm chi phí tạo sự tự tin: Các nhóm nên củng cố các vòng lặp xác minh, bao gồm tín hiệu CI (Continuous Integration), phân tích tĩnh, kiểm tra bảo mật, khả năng quan sát (observability), triển khai theo giai đoạn và phản hồi sản phẩm nhanh chóng sau khi triển khai.
• Kiến trúc như một giàn giáo: Kiến trúc và quy ước kỹ thuật nên đóng vai trò là nền tảng hỗ trợ cho việc giao hàng được hỗ trợ bởi AI. Điều này bao gồm các ranh giới rõ ràng, đặt tên nhất quán, mẫu mã, Hồ sơ quyết định kiến trúc (ADR) nhẹ nhàng và các rào chắn được thực thi trong CI.
• Đo lường thông lượng thay vì đầu ra: Các nhóm nên ưu tiên các chỉ số như thời gian dẫn (lead time), thời gian xếp hàng xem xét, tỷ lệ thất bại thay đổi, số lần hoàn tác và tải sự cố, thay vì chỉ tập trung vào số dòng mã, khối lượng pull request hay số lượng token.

AI khuếch đại cấu trúc hiện có

Tóth lập luận rằng AI sẽ mở rộng quy mô bất kỳ cấu trúc nào đã tồn tại trong cơ sở mã và quy trình giao hàng. Trong các hệ thống có ranh giới mô-đun rõ ràng, các bất biến được tài liệu hóa và một số nhỏ đường dẫn triển khai được hiểu rõ, AI có thể tăng tốc công việc trong khi vẫn dễ dàng điều hướng và xác minh.

Ngược lại, trong các hệ thống có quy ước mơ hồ hoặc kiến trúc bị trôi dạt, sự tăng tốc tương tự có thể khuếch đại sự không nhất quán, tăng gánh nặng xem xét và làm suy yếu niềm tin vào các thay đổi có thể trông đúng ở cục bộ nhưng làm suy giảm hệ thống nói chung.

Đối với các kiến trúc sư và lãnh đạo kỹ thuật, hàm ý là lợi thế cạnh tranh có thể không thuộc về các nhóm tạo ra nhiều mã nhất, mà thuộc về những nhóm có thể "hấp thụ" an toàn nhiều thay đổi ý nghĩa hơn mà không làm suy giảm chất lượng kiến trúc hay quy trình giao hàng.