Những bài học thực tế từ việc xây dựng AI Dev Harness

Tôi đã dành nhiều tháng xây dựng một khung tích hợp không phụ thuộc vào mô hình để thực hiện công việc phần mềm thực tế với các tác nhân lập trình (coding agents). Cuối cùng, các tính năng lại ít quan trọng hơn tôi nghĩ rất nhiều. Điều thực sự tạo nên khác biệt là một số ít ý tưởng đã thay đổi cách tôi nghĩ về việc xây dựng với các tác nhân, thay vì chỉ đưa ra lời nhắc cho chúng.

Đây là những ý tưởng có trọng lượng nhất. Ba ý tưởng đầu tiên thực sự đã thay đổi mô hình tư duy của tôi. Phần còn lại là những điều thực tế bạn có thể bắt đầu áp dụng gần như ngay lập tức.

1. Đóng băng tiêu chí chấp nhận trước khi tác nhân bắt đầu

Và đặt nó ở nơi mà nó không thể chỉnh sửa.

Đây có lẽ là sự thay đổi lớn nhất đối với tôi. Nghe có vẻ hiển nhiên khi nhìn lại, nhưng tôi đã không thực sự đánh giá đúng mức độ quan trọng của nó cho đến khi tận mắt chứng kiến nó hoạt động.

Nếu tiêu chí chấp nhận có thể thay đổi sau khi công việc đã hoàn thành, chúng sẽ dần dần dịch chuyển về phía những gì đã được tạo ra. Tác nhân không cố ý gian dối, mà nó chỉ đơn giản là đánh giá công việc so với một mục tiêu vẫn có thể di chuyển. Nếu cột mục tiêu có thể di chuyển, cuối cùng chúng sẽ di chuyển.

Đó không phải là vấn đề về lời nhắc, mà là vấn đề về cấu trúc, vì vậy giải pháp cũng phải mang tính cấu trúc.

Viết tiêu chí chấp nhận trước. Lưu chúng bên ngoài không gian làm việc có thể chỉnh sửa, và tự động chặn mọi nỗ lực chỉnh sửa chúng. Bây giờ tác nhân đang làm việc hướng tới một hợp đồng mà nó không thể thương lượng lại. Nhiệm vụ không hoàn thành vì tác nhân nói là nó đã xong. Nó hoàn thành vì nó đáp ứng hợp đồng ban đầu.

2. Không ai nên tự chấm điểm công việc của mình

Mô hình đã viết mã là người phán xét tồi tệ nhất để quyết định xem mã đó có chính xác hay không. Vào thời điểm nó hoàn thành, nó đã tự thuyết phục mình rằng giải pháp đó có ý nghĩa.

Vì vậy, hãy phân chia trách nhiệm.

Hãy để các script xác định (deterministic scripts) xác minh mọi thứ mang tính cơ học. Một script không thể tự tạo ra một mã thoát thành công. Hãy coi mô hình lập trình như một kỹ sư, chứ không phải là người đánh giá. Sau đó, chuyển kết quả cho một người đánh giá có ngữ cảnh mới, một người chưa từng chứng kiến mã được viết, để đánh giá thiết kế, ý định và chất lượng tổng thể.

Sự phân tách đơn giản đó phát hiện ra nhiều vấn đề hơn tôi mong đợi, và nó thực sự rẻ để thực hiện.

3. Thực thi rất dễ. Hiệu chỉnh mới là phần khó.

Nhận thức này đã thay đổi cách tôi nghĩ về toàn bộ khung tích hợp.

Hầu hết các hệ thống tác nhân, bao gồm cả các phiên bản trước đây của tôi, xử lý mọi nhiệm vụ gần như giống nhau. Một sửa lỗi gõ một dòng trải qua cùng một quy trình như một thiết kế lại kiến trúc lớn. Điều đó hoặc là lãng phí thời gian, hoặc là quá rủi ro.

Chìa khóa là nỗ lực tương xứng.

Đầu tiên, hãy phân loại công việc. Đó là một thay đổi nhỏ mà không có gì phụ thuộc vào, hay là cơ sở hạ tầng cốt lõi mà mọi thứ đều phụ thuộc vào? Đó là logic kinh doanh hay mã tiện ích chung?

Sau đó, để phân loại đó quyết định mức độ đánh giá nó sẽ nhận được, mô hình nào nên xử lý nó, và mức độ tự chủ nó được phép.

Việc thực thi được đưa vào là dễ dàng. Việc làm cho nỗ lực phù hợp mới là nơi giá trị thực sự bắt đầu nhân lên.

Phần thực tế

Khi những ý tưởng lớn hơn đó đã được đặt đúng chỗ, một vài thực hành nhỏ hơn đã phát huy tác dụng gần như ngay lập tức.

• Đặt các quy tắc của bạn vào khung tích hợp, chứ không phải vào lời nhắc. Một lời nhắc nói "đừng chỉnh sửa trong repo chính" chỉ là lời khuyên. Cùng một quy tắc được thực thi như một lệnh gọi công cụ bị chặn sẽ trở nên không thể bỏ qua. Các quy tắc quan trọng không nên dựa vào việc mô hình chọn cách cư xử.
• Giữ trạng thái bên ngoài cuộc trò chuyện, và sử dụng một worker mới cho mỗi nhiệm vụ. Lưu trữ hồ sơ nhiệm vụ bên ngoài, sử dụng các cây làm việc (worktrees) biệt lập, và xử lý các thay đổi thông qua một hàng đợi merge (merge queue). Một khi trạng thái nằm bên ngoài cuộc trò chuyện, giới hạn ngữ cảnh không còn là ràng buộc lớn nhất của bạn nữa. Các nhiệm vụ trở nên song song, có thể tiếp tục, và dễ dàng suy luận hơn nhiều.
• Đánh giá chéo giữa các nhà cung cấp tốt hơn đánh giá cùng một nhà cung cấp. Các mô hình có thể dễ dàng bỏ qua lỗi của chính mình hơn là của người khác. Sử dụng một mô hình từ một nhà cung cấp khác là một cách đơn giản và hiệu quả để giảm sự thiên vị đó.

Tại sao các nguyên tắc này hoạt động

Không có ý tưởng nào trong số này phụ thuộc vào một mô hình cụ thể. Chúng nói về kỹ thuật khung tích hợp. Các giao thức, xác minh, quy trình đánh giá, và phân tách trách nhiệm.

Mô hình đứng đầu bảng xếp hạng sẽ liên tục thay đổi.

Nhưng các nguyên tắc có lẽ sẽ không thay đổi.

Giá trị lâu dài không nằm ở mô hình, và cũng không nằm ở các tính năng. Nó nằm ở giàn giáo (scaffolding) bạn xây dựng xung quanh chúng.