Detail: Hướng tới kỷ nguyên 'Codebase tự lái' và giải pháp AI Agent mới

Các agent có thể thực hiện những trò chơi "oneshot" (một lần là xong) thực sự thú vị. Với các cơ chế bảo vệ (guardrails) phù hợp, agent có thể thực hiện các quá trình di chuyển (migration) cực kỳ ấn tượng trong các codebase phức tạp, thậm chí là viết lại toàn bộ bằng ngôn ngữ mới. Nhưng về cơ bản, mọi công việc phần mềm "thực thụ" vẫn cần các kỹ sư con người điều phối quy trình. Làm thế nào để chúng ta đạt đến trạng thái mà phần lớn công việc được xử lý thay cho chúng ta mà không cần sự chú ý của con người?

Có vẻ như các agent nên có khả năng tự xây dựng toàn bộ hệ thống phần mềm. Tại sao thực tế lại diễn ra kém hiệu quả như vậy? Chúng ta sẽ cần những nguyên lý cơ bản (primitives) mới nào để làm cho mọi thứ vận hành trơn tru? Điều này có thể tiến xa đến đâu?

Điều gì sẽ đến sau thời kỳ "tokenmaxxing"?

Rất nhiều tổ chức kỹ thuật đã dành nửa đầu năm nay để đẩy càng nhiều công việc càng tốt cho các đội quân agent và các vòng lặp đối kháng (adversarial loops). Kết quả khá đáng thất vọng: những núi code đáng ngờ, nhưng không có cơn sóng thần nào về phần mềm đột phá. ROI (tỷ suất hoàn vốn) trên tất cả các token đó chỉ ở mức tạm bợ là cùng.

Xét theo chu kỳ cường điệu (hype cycle), chúng ta đang ở trong "vực thẳm của sự vỡ mộng" (trough of disillusionment). Chúng ta đang tìm cách hiện thực hóa tầm nhìn không tưởng mà chúng ta đã có vài tháng trước, thứ mà thực tế vẫn chưa vận hành được.

Điều gì sẽ xảy ra tiếp theo? Trong mọi chu kỳ áp dụng công nghệ khác, câu trả lời luôn là: tìm ra các phương pháp tốt nhất (best practices), xác định xem chiếc búa mới sáng bóng của chúng ta phù hợp với loại đinh nào thay vì dùng nó để đóng vít, và sau đó tạo ra những khối xây dựng mà chúng ta không nhận ra là cần thiết cho đến khi thực sự cầm trên tay món đồ chơi mới đó.

Một phương pháp chẩn đoán mà chúng ta có thể sử dụng để đạt được điều đó là tự hỏi: khi phần mềm chủ yếu tự vận hành, các kỹ sư sẽ làm gì?

Một câu trả lời phổ biến là: thiết lập các Vòng lặp (Loops)! Chúng ta từng viết code, sau đó chúng ta viết prompt, và giờ đây chúng ta thiết lập các vòng lặp agent và viết /goal rất nhiều.

Tôi nghĩ điều này sai lầm. Hiện tại, việc thiết lập một vòng lặp phần mềm khả thi tạo ra thay đổi tích cực mà không đốt tiền là một công việc khổng lồ, nhưng chủ yếu là vì hệ thống công cụ (toolchain) chưa sẵn sàng. Khi chúng ta có các mảnh ghép phù hợp, những vòng lặp này sẽ dễ thiết lập, dễ tin tưởng và tiết kiệm chi phí. Đây sẽ không phải là nơi chúng ta dành thời gian.

Thay vào đó, công việc kỹ thuật giá trị nhất sẽ là có những ý tưởng hay. Những ý tưởng quan trọng vẫn đến từ bên ngoài nhà máy phần mềm. Thực tế, mục đích của toàn bộ cỗ máy này là giảm thiểu những thứ chúng ta phải suy nghĩ mà không mang lại lợi ích cao.

Những phần nào nên tự vận hành?

Ngoài lĩnh vực "có ý tưởng hay", chúng ta nên cố gắng chuyển công việc codebase sang GPU. Ví dụ, liệu các agent có thể xử lý toàn bộ các mối quan tâm này không?

Danh sách này còn kéo dài. GitHub Copilot đã mang đến cho chúng ta tính năng tự động hoàn thành các dòng code, và các agent sẽ mang đến tính năng tự động hoàn thành cho toàn bộ sản phẩm.

Những nguyên lý cơ bản còn thiếu (Missing Primitives)

Nếu điều này muốn thành công, bộ công cụ phát triển (dev stack) sẽ cần một số nguyên lý cơ bản mới. Đây đều là những điều kiện tiên quyết:

Chúng ta vẫn cần hầu hết các nguyên lý từ kỷ nguyên trước, ví dụ như APM (nhưng sẽ được truy vấn chủ yếu bởi các agent đọc log, thay vì các giao diện người dùng nhiều widget), CI (nhưng với hàng đợi merge tốt hơn) và A/B testing (nhưng có thể vận hành bởi agent).

Làm thế nào để xây dựng một dev stack mà agent có thể hiểu được?

Nơi các đội ngũ kỹ thuật cần nỗ lực nhiều nhất hiện nay là tạo ra các môi trường phát triển trên cloud thực sự tốt, giúp các agent dễ dàng kiểm thử code theo mọi cách cần thiết trước khi có thể biết liệu nó có lỗi hay không. Tại thời điểm này, yếu tố hạn chế đối với các dev agent chính là môi trường mà chúng vận hành, chứ không phải bản thân các mô hình hay bộ khung (harnesses).

Nói cách khác: các agent đủ giỏi để làm nhiều việc hơn nếu chúng được vận hành trong môi trường đủ tốt. Nhưng chúng tạo ra lỗi ở những nơi chúng không thể nhìn thấy: các điều kiện tranh chấp (race conditions) mà agent không có cách hệ thống để tái hiện, các truy vấn chậm chạp nơi chúng thiếu hiểu biết về cấu trúc dữ liệu. [3]

Ở những nơi agent có điểm mù, chúng sẽ mắc lỗi, điều này làm giảm niềm tin, dẫn đến việc công việc cần được xem xét kỹ lưỡng hơn, từ đó hạn chế khả năng chúng ta bàn giao công việc.

Vì vậy, khoản đầu tư quan trọng nhất mà một đội ngũ kỹ thuật có thể thực hiện ngay bây giờ là làm cho môi trường phát triển của họ cực kỳ thân thiện với agent. Nhưng hiện tại, đó là một cái hố không đáy của những công việc vặt và các giải pháp tình thế mà không có cách nào để định lượng hiệu quả. Cần có những ý tưởng hay và kỹ thuật tập trung để khắc phục những khoảng trống trong môi trường phát triển này. Một thiết lập dev cục bộ với dữ liệu kiểm thử đại diện là một mục tiêu luôn thay đổi. Những trừu tượng hóa mới phù hợp để viết các bài kiểm thử tốt là rất khó để nghĩ ra. Và cứ thế. Công việc này đầy thách thức!

Công việc này cũng đặc thù theo từng codebase, và nó vẫn là một nghệ thuật mà rất ít người có thể làm tốt. Đó là một lý do tại sao rất nhiều nhà máy phần mềm gây thất vọng. Chúng ta cần những cách tốt hơn nhiều để thực hiện kiểu đầu tư này.

Điều đó có nghĩa là có rất nhiều đòn bẩy trong việc giúp các đội ngũ chuẩn bị sẵn sàng hệ thống công cụ dev cho agent. Làm thế nào một đội ngũ kỹ thuật biết đâu là "quả thấp dễ hái" (low-hanging fruit)? Làm thế nào họ ưu tiên công việc để làm cho nhà máy của mình vận hành tốt hơn? Làm thế nào họ biết mình đang làm tốt? Nếu chúng ta có thể biến điều này thành một môn khoa học thay vì một nghệ thuật, và giúp các đội ngũ kỹ thuật tiến bộ một cách có phương pháp, các nhà máy sẽ bắt đầu vận hành trơn tru.

Đây là dự đoán tốt nhất của chúng tôi về con đường phía trước:

Nói cách khác: Kế hoạch bí mật của Detail là tạo ra một sản phẩm tự khởi động công việc của chính nó, sau đó sử dụng công việc đó để giúp các đội ngũ kỹ thuật biết nên đầu tư vào đâu và các khoản đầu tư đó đang hiệu quả như thế nào.

Nếu chúng ta có thể khởi động một kho dữ liệu công việc hữu ích cho bất kỳ codebase nào – trong trường hợp này là các lỗi mà đội ngũ kỹ thuật muốn sửa – chúng ta có thể sử dụng nó để xác định các cách có ROI cao nhằm làm cho bất kỳ codebase nào trở nên tốt hơn cho agent. Chúng ta có thể đánh giá mức độ sẵn sàng của một repo đối với agent. Các kỹ sư có thể tập trung giải quyết các khoảng trống quan trọng trong môi trường phát triển của họ cho đến khi hầu hết các lỗi cấp thấp có thể được xử lý tự động, và sau đó các kỹ sư có thể tập trung vào công việc thực sự có giá trị cao: có những ý tưởng hay cho các tính năng và tìm ra các trừu tượng hóa giúp đơn giản hóa việc triển khai.

Đó là cách chúng ta sẽ đạt đến "cao nguyên năng suất" (plateau of productivity) và đó là cách các đội ngũ kỹ thuật giỏi nhất sẽ vận hành trong sáu tháng tới. Không phải là tokenmaxxing, chắc chắn không phải là cấm AI, mà là sử dụng một quy trình như thế này để nâng cao khả năng sẵn sàng của agent và dần dần bàn giao ngày càng nhiều công việc hơn.

Chúng tôi đang ra mắt một phần của điều này hôm nay, nhưng bạn sẽ thấy những ý tưởng này tiếp tục thành hình trong sản phẩm của chúng tôi khi chúng tôi xây dựng hướng tới tầm nhìn này.

Điều này không mới.

Công nghệ tiến bộ bằng cách bàn giao các mối quan tâm cấp thấp cho các hệ thống quản lý chúng thay cho chúng ta.

Trong những năm 2010, chúng ta đã chuyển phần mềm lên cloud, và giờ đây chúng ta không cần phải suy nghĩ về việc nó chạy ở đâu, về mặt vật lý, hay thậm chí là dịch vụ nào đang chạy trên instance ảo nào. Một đội ngũ kỹ thuật nhỏ hơn, tập trung hơn có thể xây dựng một sản phẩm phần mềm thành công ngay bây giờ. Chúng ta được sống trong mặt phẳng logic trong khi các nền tảng xử lý phần còn lại. Nhưng chúng ta đã trải qua một quá trình chuyển đổi tương tự rất lộn xộn lúc ban đầu, và chúng ta đã phải tìm ra rất nhiều nguyên lý cơ bản còn thiếu trên đường đi.

Từng có thời gian, việc thiết lập CI và CD là một dự án kéo dài nhiều tháng, nhưng giờ đây khi đã có các nguyên lý phù hợp và công cụ trưởng thành, đó chỉ là công việc của một buổi chiều, trừ khi bạn đang di chuyển một hệ thống mainframe ngân hàng hoặc thứ gì đó tương tự. Một quá trình chuyển đổi tương tự sẽ xảy ra với các "vòng lặp".

Chúng tôi đang tuyển dụng! Và nếu bạn muốn tham gia cùng chúng tôi, hãy thử tại: https://detail.dev/

[1] Nếu "gu thẩm mỹ" (taste) từng thực sự là một yếu tố khác biệt, thì bây giờ không còn nữa. Nhưng những ý tưởng hay thì có.

[2] Một số lĩnh vực ứng dụng đã được hiểu khá rõ. Đối với một trang web thương mại điện tử, bạn sẽ muốn có email nhắc nhở giỏ hàng bị bỏ quên, các widget "N người dùng khác đang xem sản phẩm này!", một mức giá gốc bị gạch bỏ bên cạnh mức giá thấp hơn, và tất cả những thứ tương tự. Các agent nên chạy các kịch bản này thay cho chúng ta.

[3] Các agent cũng tạo ra khối lượng lớn code phòng thủ không cần thiết, xuất phát từ mong muốn bảo vệ trước mọi sự mơ hồ có thể hình dung được mà không biết rủi ro nào là thực tế.