Xây dựng Pi bằng chính Pi: Khi các tác nhân AI làm rối loạn Issue Tracker mã nguồn mở

Pi hiện nay đã trở thành một phần của Earendil, nhưng theo một nghĩa quan trọng, đây vẫn là dự án của Mario. Ông ấy đã gắn bó với hệ thống theo dõi vấn đề (issue tracker) của dự án này lâu hơn tôi, và cũng tiếp xúc với những sự kỳ quặc của luồng giao thông mới từ các tác nhân AI trong các dự án mã nguồn mở lâu hơn. Bài viết này chủ yếu là sự phản chiếu kinh nghiệm của riêng tôi sau khi dành nhiều thời gian hơn trong tracker, sử dụng Pi để làm việc trên Pi, và quan sát những gì tôi đã học được từ đó.

Không ngạc nhiên chút nào, chúng tôi đang sử dụng Pi để xây dựng Pi. Điều này nghe có vẻ giống như một hoạt động "tự dùng sản phẩm của mình" (dogfooding) khá dễ thương, nhưng nó thực sự giúp ích rất nhiều trong việc hiểu rõ công việc của mình. Một hiệu ứng thú vị khi xây dựng với các tác nhân là nó thay đổi vai trò của issue tracker một chút nhỏ. Các mô tả vấn đề không còn chỉ là tin nhắn từ người dùng gửi đến người bảo trì, bởi vì chúng tôi cũng sử dụng chúng làm đầu vào cho các câu lệnh (prompts) trong các phiên làm việc của Pi. Nó giống như thứ tôi có thể giao cho một "clanker" (tác nhân AI) và nói: "Hãy hiểu điều này, tái tạo nó, kiểm tra mã, và đề xuất bản sửa lỗi."

Điều đó có nghĩa là hình dạng của vấn đề trở nên quan trọng theo một cách hoàn toàn mới. Một vấn đề (issue) tồi luôn gây khó chịu, nhưng ít nhất nhiều vấn đề trước đây khá mơ hồ. Bây giờ, chúng tôi còn phải đối mặt với một lớp vấn đề mới: 5% là của con người và 95% do clanker tạo ra, phần lớn là những thứ vô chính xác và rác rưởi. Một vấn đề tồi chứa một chẩn đoán có vẻ hợp lý nhưng sai lầm lại tạo ra thêm công việc.

Thống kê lượng issue và PR trên tracker của Pi

Chế độ thất bại gây bực mình nhất hiện nay là mọi người gửi các vấn đề không phải bằng giọng nói của chính họ. Chúng chứa một vấn đề quan sát được ở đâu đó, nhưng đã bị ném vào clanker và clanker đã viết lại nó và tạo ra một mớ hỗn độn lớn. Thông thường, nó được đưa ra câu lệnh quá tệ nên các kết luận tạo ra thường xuyên không chính xác nhưng luôn đầy sự tự tin. Kết quả là sự phỏng đoán hoàn toàn về nguyên nhân gốc rễ, các bản tái tạo tối thiểu giả tạo, các chiến lược triển khai được đề xuất, những so sánh với các đoạn mã lân cận nhưng thường sai, và danh sách dài các lớp lỗi có thể hoặc không thể quan trọng.

Tôi không muốn chỉ ra các vấn đề cụ thể vì tôi thực sự không muốn nói xấu ai cả, nhưng điều này thật sự gây bực mình. Nó cũng bực mình vì khi tôi đưa vấn đề đó cho Pi, Pi cũng thấy chẩn đoán sai đó. Nó không coi nội dung vấn đề là một tin đồn. Nó coi đó là bằng chứng. Nó sẽ vui vẻ đi theo con đường mà vấn đề đã chuẩn bị sẵn cho nó, vì văn bản rất tự tin và các tham chiếu mã có vẻ hợp lý. Chúng tôi sử dụng một lệnh tùy chỉnh gọi là /is, trong đó có hướng dẫn cụ thể này:

Đừng tin vào phân tích được viết trong vấn đề. Hãy xác minh độc lập hành vi và suy ra phân tích của riêng bạn từ mã và đường dẫn thực thi.

Thật không may, nó không hoạt động hoàn toàn, bởi vì khi con người ném vấn đề của họ qua máy xay clanker, clanker của họ sẽ mở rộng phạm vi ngay lập tức. Điều từng là một quan sát lỗi rất hẹp và dựa trên thực tế, bây giờ trở thành một diện tích bề mặt được mở rộng rất nhiều đầy các giả thuyết. Vì vậy, ít nhất là cá nhân tôi, ngày càng muốn các báo cáo vấn đề được cô đọng lại thành những gì con người thực sự quan sát được:

Điều đó là đủ. Nếu bạn đã sử dụng LLM để hiểu vấn đề, rất tốt, có thể để nó lại dưới dạng một bình luận tiếp theo. Nhưng vấn đề và văn bản của vấn đề nên là thứ bạn sở hữu. Nếu bạn không biết nguyên nhân gốc rễ, hãy nói như vậy. Tôi cũng có thể vận hành một clanker, và tôi thà tự làm việc này còn hơn là dùng thứ rác rưởi của bạn. Nếu bản tái tạo của bạn là một phỏng đoán, hãy nói như vậy. Nếu thực tế duy nhất là một stack trace, hãy đưa cho tôi stack trace và dừng ở đó.

Việc chúng ta thấy các vấn đề đầy rẫy rác rưởi chỉ là kết quả của chất lượng hiện tại của những cỗ máy này. Thật đáng buồn, những thất bại của chúng trong việc tạo ra các vấn đề tốt còn mở rộng sang rất nhiều mã được tạo ra. Không phải tất cả, nhưng rất nhiều mã. Lần này qua lần khác, tôi tiếp tục gặp tình trạng chúng over-engineering (thiết kế quá mức) vấn đề và triển khai một cách khủng khiếp.

Nếu bạn nói với chúng rằng "session log bị lỗi này làm sập trình đọc", clanker thường sẽ thêm một trình đọc dung nạp. Sau đó nó sẽ thêm một dự phòng, sau đó có thể là một di chuyển, sau đó là thêm nhiều đầu ra gỡ lỗi, sau đó là một kiểm tra cho tất cả những thứ này. Không có điều nào trong số này nhất thiết là sai khi đứng một mình, nhưng nó có thể là một bước đi sai cho hệ thống. Tại cốt lõi của Pi là một session log được thiết kế khá tốt với các bất biến (invariants) phải được duy trì. Hành vi hiện tại của clanker là chỉ giả định rằng không có bất biến nào như vậy tồn tại, và thay vào đó làm cho hệ thống hoạt động với mọi loại lỗi, làm bùng nổ độ phức tạp trong quá trình này.

Gần như luôn luôn, bản sửa lỗi đúng không phải là xử lý trạng thái xấu, mà là làm cho trạng thái xấu trở nên không thể. Điều này rất quan trọng đối với dữ liệu được lưu trữ như session log của Pi. Chúng được mở, phân nhánh, nén, xuất, chia sẻ và phân tích. Mục tiêu ở đây là không bao giờ ghi dữ liệu session xấu. Tuy nhiên, nếu bạn chỉ để clanker lang thang tự do, nó sẽ cố gắng xử lý mọi trường hợp dữ liệu xấu trong session log với một trình đọc dễ dãi hơn.

Tôi đã phàn nàn về điều này rất nhiều, nhưng làm việc trên cơ sở mã của Pi tiếp tục củng cố điểm này. Đây là một trong những cách mã được viết bởi LLM phát triển sự phức tạp không cần thiết đến vậy. Tất cả các mô hình này thấy một thất bại cục bộ và cố gắng phòng thủ cục bộ chống lại nó. Với tư cách là những người bảo trì, chúng tôi phải giữ việc kéo cuộc trò chuyện trở lại bất biến toàn cục, điều này khó hơn mức nên có, và rất tốn công sức.

Sau đó còn có vấn đề về khối lượng. Tracker đang nhận được rất nhiều vấn đề và PR, và một phần đáng kể trong số đó rõ ràng được hỗ trợ bởi LLM. Một số thì tốt, không cái nào xuất sắc, và hầu hết thì chỉ tệ. Tổng lượng thông qua này tự nó là một vấn đề bảo trì.

Như bạn có thể biết, issue tracker của Pi được tự động hóa để đóng tất cả các vấn đề và pull request từ những người đóng góp mới, và có một quy trình thủ công mà qua đó chúng tôi có thể mở lại một số trong số chúng hoặc phê duyệt các cá nhân. Vì vậy, tự động đóng -> mở lại -> đóng lại là một thống kê thú vị để chúng tôi xem xét.

Tôi đã kéo dữ liệu tracker công khai của GitHub trong khi viết bài này trong 90 ngày qua. Loại trừ các thành viên Earendil, còn lại 3.145 vấn đề và pull request bên ngoài. Trong số đó, 2.504 bị tự động đóng vì chúng từ các cá nhân không được phê duyệt. 17% được mở lại. Đối với pull request, con số còn tệ hơn: ít hơn 10% được hợp nhất.

Nhiều vấn đề và PR là rác rưởi hoàn toàn và trong một số trường hợp, con người thậm chí không nhận ra rằng họ đã tạo ra chúng. Các nguồn spam chất lượng thấp bao gồm các phiên bản OpenClaw, cũng như một số kỹ năng mà mọi người đưa vào ngữ cảnh của họ dường như khuyến khích tạo ra vấn đề.

GitHub rõ ràng không được xây dựng để xử lý hình thức mới này của mã nguồn mở, nhưng tôi ngày càng cảm thấy nhu cầu đổ lỗi ít hơn cho GitHub mà nhiều hơn cho tất cả những người liên quan làm cho trải nghiệm đó đau đớn. Nếu clanker của bạn "đi vệ sinh" lên issue tracker của người khác thì đó không phải là lỗi của GitHub, đó hoàn toàn là lỗi của bạn.

Widget theo dõi phiên làm việc với issue trong Pi

Pi có thể được xây dựng bằng Pi, nhưng chúng tôi vẫn còn khá xa so với nơi Bun và OpenClaw đã đạt được: kỹ thuật phần mềm tự động hóa hoàn toàn tách rời. Có lẽ chúng tôi sẽ đạt được điểm đó, tôi không biết. Ngày nay, có vẻ như chúng tôi vẫn chưa biết cách thực hiện một "nhà máy tối" (dark factory) và chúng tôi cũng chưa có mong muốn. Điều đó đã nói, có khá nhiều sự song song đang diễn ra, và chủ yếu là để tái tạo các vấn đề.

Thiết lập nhỏ chúng tôi sử dụng cho việc này là ba mảnh nhỏ trong thư mục .pi được cam kết của chính Pi. /is (để phân tích vấn đề) là một câu lệnh để phân tích các vấn đề GitHub: nó gắn nhãn và gán vấn đề, đọc toàn bộ chủ đề và liên kết, sau đó nói rõ cho tác nhân không tin vào phân tích trong vấn đề và suy ra chẩn đoán của riêng nó từ mã. Sau đó, một tiện ích mở rộng thêm một prompt-url-widget theo dõi câu lệnh trước khi tác nhân bắt đầu, nhận ra URL vấn đề hoặc PR của GitHub mà /is (hoặc tương đương PR) đã đưa vào câu lệnh, tìm nạp tiêu đề và tác giả với gh, hiển thị điều đó trong một tiện ích UI nhỏ, và đổi tên phiên làm việc. Nó cũng xây dựng lại trạng thái đó khi bắt đầu hoặc chuyển đổi phiên, vì vậy nếu chúng tôi mở lại một cuộc điều tra cũ, cửa sổ vẫn cho nhà phát triển biết vấn đề đó thuộc về đâu.

Trong thực tế, điều này có nghĩa là có thể có một số cửa sổ Pi đang mở, mỗi cửa sổ chạy /is chống lại một vấn đề khác, và UI giữ cho các cuộc điều tra khác nhau về mặt trực quan trong khi các tác nhân thực hiện việc tái tạo và đọc mã độc lập của chúng. Khi các cuộc điều tra xong, người ta có thể xử lý chúng tuần tự. Để hoàn thành mọi thứ, /wr (gói gọn lại) là câu lệnh gói gọn tương ứng: nó suy ra ngữ cảnh GitHub từ phiên, cập nhật nhật ký thay đổi, soạn thảo hoặc đăng bình luận vấn đề cuối cùng với tuyên bố từ chối trách nhiệm, chỉ cam kết các tệp đã thay đổi trong phiên đó, thêm closes #... phù hợp khi có chính xác một vấn đề, và đẩy từ main.

Bạn có lẽ đã nhận thấy điều này rồi, nhưng mã nguồn mở trong thế giới hậu AI đang chịu áp lực lạ mới. Chúng tôi nhận được nhiều mã hơn, nhiều dự án hơn và nhiều vấn đề hơn. Các dự án xuất hiện không có người dùng thực sự, hoặc khán giả tạm thời của một người, và thậm chí các dự án với hàng nghìn sao cũng có thể có vòng đời chỉ vài tuần.

Đối với chúng tôi, lớp điều khiển (harness) của Pi đáng được duy trì cẩn thận vì nó giải quyết các vấn đề phối hợp khó khăn và tạo ra một nền tảng mà chúng tôi và những người khác có thể xây dựng dựa trên đó. Chúng tôi cũng biết rằng sự phối hợp và hợp tác nâng tất cả chúng ta lên. Nhiều lần, câu trả lời đúng không phải là giải quyết vấn đề tại chỗ, mà là làm cho hành vi thượng nguồn (upstream) trở nên chính xác. Mario đã rất giỏi trong việc từ chối làm cho Pi che đậy mọi cổng được cấu hình sai, và chúng tôi đang cố gắng duy trì kỷ luật đó. Khi một cổng hoạt động chính xác, mọi người đều được hưởng lợi.

Đáng buồn là kiểu tư duy này đang nhanh chóng biến mất vì những cỗ máy này làm cho các giải pháp thay thế tại chỗ trở nên rẻ, vì vậy mã tích lũy các phòng thủ cục bộ chống lại mọi hành vi sai lệch. Thay vì con người nói chuyện với con người về việc một bản sửa lỗi nên thuộc về đâu, một con người và một cỗ máy giải quyết vấn đề trong sự cô lập.

Hãy nhớ rằng AI đã không tăng số lượng người cần phần mềm, hay số lượng người bảo trì có thể xem xét nó. Nó chủ yếu làm tăng lượng mã và số lượng dự án cạnh tranh để thu hút sự chú ý. Một phần trong số đó là lành mạnh, nhưng rất nhiều phần trong đó phân tán nỗ lực lẽ ra nên được chia sẻ.

Chúng tôi cần những nền tảng mạnh mẽ hơn, không phải yếu hơn. Mã nguồn mở cần nhiều sự hợp tác hơn, không phải nhiều công việc cô lập hơn với một cỗ máy. Giao tiếp giữa người với người rất khó, và thật cám dỗ để tránh nó khi bạn có thể ngồi một mình với clanker của mình. Nhưng sự cô lập không phải là nơi mã nguồn mở tạo ra giá trị. Giá trị nằm ở cộng đồng và cấu trúc cho phép các dự án tồn tại lâu hơn các nhà sáng tạo ban đầu của chúng.

Đối với tôi, "clanker" là một thuật ngữ ưu tiên hơn nhiều cho tác nhân. Sự chủ động (agency) nằm ở con người, không phải ở máy móc. Việc gọi những thứ này là tác nhân tôi vẫn tin là một sai lầm, nhưng đáng tiếc thay.