Nhiệm vụ: Hệ thống lập kế hoạch mới

Sau vài giờ thử nghiệm với hệ thống lập kế hoạch mới, tôi đã hiểu rõ hơn đáng kể về cả những hạn chế của lần triển khai hiện tại lẫn những giới hạn của chính phương pháp phát triển thông qua AI agent. Agent đã thực hiện thành công một số giải pháp, tuy nhiên nhìn chung hệ thống vẫn chưa đáp ứng được các yêu cầu của tôi, và việc tiếp tục khắc phục cục bộ các vấn đề riêng lẻ không còn hiệu quả nữa.

Đặc biệt rõ ràng là nỗ lực thoái lùi và đơn giản hóa hệ thống. Agent đã được chỉ định rõ ràng những phần nào của việc triển khai nên được xóa hoặc đơn giản hóa, nhưng cùng với đó nó cũng ảnh hưởng đến các yếu tố khác lẽ ra phải được giữ lại. Điều này cho thấy một hạn chế quan trọng: agent có khả năng làm việc với các đoạn mã riêng lẻ và các phụ thuộc cục bộ, nhưng kém hơn trong việc duy trì ranh giới giữa việc đơn giản hóa có mục tiêu và sự phá vỡ hành vi liên kết. Khi hệ thống bao gồm nhiều hệ thống con liên kết với nhau, các thay đổi hợp lý ở cấp độ cục bộ có thể làm hỏng các liên kết chưa được mô tả rõ ràng trong ngữ cảnh hiện tại.

Từ đây rút ra một kết luận tổng quát hơn về việc phát triển phần mềm với AI. Nếu agent bắt đầu liên tục sửa chữa hậu quả của những thay đổi trước đó của chính nó, việc tiếp tục chu kỳ đó sẽ nhanh chóng dẫn đến sự tích lũy mã nguồn, các giải pháp tạm thời và các phụ thuộc ẩn. Tại một thời điểm nào đó, vấn đề không còn nằm ở một lỗi cụ thể nào nữa, mà là sự mất đi một mô hình hệ thống đơn giản và có thể kiểm chứng. Nỗ lực giao cho agent việc tái cấu trúc sâu (deep refactoring) trong trạng thái này mang theo rủi ro làm gia tăng thêm độ phức tạp: nó có thể tối ưu hóa chính xác các khu vực riêng lẻ mà không hiểu rõ những thuộc tính nào của toàn bộ hệ thống cần phải được giữ nguyên không đổi.

Do đó, cần phải suy nghĩ lại về các giai đoạn phát triển. Có lẽ đối tượng kiểm soát chính nên chuyển từ việc triển khai bên trong sang hành vi bên ngoài của hệ thống: các yêu cầu, bất biến (invariants), kịch bản, bài kiểm tra (tests) và mối liên hệ giữa các hệ thống con. Nếu việc triển khai không còn thỏa mãn các yêu cầu này và agent không thể nhanh chóng đưa nó trở lại trạng thái chính xác, việc không tiếp tục vòng lặp sửa chữa (repair-loop) vô tận, mà thay vào đó là chốt lại hành vi mong muốn, đơn giản hóa mô hình và xây dựng lại mã nguồn từ đầu có thể sẽ có lợi hơn. Nói cách khác, trong quy trình này, mã nguồn nên được xem như một hiện vật có thể thay thế hơn là một tài sản cần phải bằng mọi giá bảo tồn và sửa chữa dần dần.

Thử nghiệm này rất hữu ích ở chỗ nó vạch ra giới hạn của việc tái cấu trúc bằng AI cục bộ: agent gặp khó khăn trong việc tự xác định đâu là điểm dừng của việc đơn giản hóa được phép và bắt đầu sự phá vỡ các liên kết hệ thống. Giai đoạn công việc tiếp theo nên được xây dựng dựa trên đặc tả hành vi rõ ràng hơn và ranh giới của các hệ thống con, chứ không phải dựa trên việc tiếp tục sửa chữa phần mã đã tích tụ.