Trong thế giới phát triển phần mềm với sự hỗ trợ của AI, việc chọn đúng “cấp độ nỗ lực” của mô hình không chỉ là vấn đề kỹ thuật, mà còn là chiến lược quản lý chi phí và hiệu suất. Bài viết này trình bày kết quả một thí nghiệm thực tế: chuyển từ GPT-5.6 Sol sang GPT-6 Astra, với kết luận bất ngờ – **nỗ lực trung bình (medium)** thường là điểm khởi đầu lý tưởng nhất.
## Tổng Quan Cuộc So Sánh: Nỗ Lực Cao, Trung Bình, Thấp Và Thế Hệ Cũ
Tôi đã tiến hành một cuộc so sánh có kiểm soát để chọn mức nỗ lực mặc định cho các tác vụ phát triển tự động của mình. Cuộc thử nghiệm bao gồm bốn điều kiện: GPT-6 Astra ở các mức **low, medium, và high**, cùng với GPT-5.6 Sol ở mức **high** làm đối chứng.
Mục tiêu không phải là chạy đua về số lượng tìm thấy lỗi hay số dòng code thay đổi. Tiêu chí đánh giá tập trung vào:
1. Khả năng tìm ra các vấn đề có hậu quả thực sự.
2. Đề xuất các giải pháp sound (hợp lý, vững chắc).
3. Chọn lọc công việc đáng để bảo trì, tránh mở rộng hệ thống một cách không cần thiết.
## Quy Trình Thí Nghiệm Chi Tiết Dùng Công Cụ Galley
Toàn bộ quá trình được thực hiện tự động bằng công cụ **Galley** (của chính tác giả), một công cụ quản lý các tác vụ phát triển không cần giám sát. Galley xử lý việc chuẩn bị môi trường, triển khai code, và xác minh. Khi một tác vụ được chạy lại (retry), nó cần bảo quản các work trước đó và tái sử dụng phần chuẩn bị vẫn còn hiệu lực.
### Bốn Điều Kiện Thí Nghiệm
Mỗi điều kiện (Astra low/medium/high và Sol high) được thực thi trên một bản sao riêng biệt của repository.
1. **Phân tích**: Tất cả đều phân tích repository để tìm lỗi, vấn đề hiệu năng và cải thiện khả năng bảo trì.
2. **Triển khai**: Tôi chọn một phạm vi triển khai chung từ các phát hiện của Astra và cung cấp cùng một kế hoạch (plan) cho cả bốn trong các worktree riêng biệt.
3. **Đánh giá**: Các phiên làm việc mới đánh giá cùng một bản sao code do Sol triển khai.
Các agent được điều khiển bởi **Codex CLI** và đọc hướng dẫn từ `codex-workflows`, bao gồm kỹ năng coding, testing, và development-judgment, cùng với các hướng dẫn và chất lượng của Galley.
## Phân Tích Kết Quả: Agent Nào Đạt “Kết Quả Tốt”?
Trong các quy trình agent tự động của mình, tôi thường thấy những gợi ý về mặt kỹ thuật có lý nhưng lại dẫn đến việc thêm quá nhiều “máy móc” phức tạp cho sản phẩm. Cuộc thử nghiệm nhằm đo lường mỗi điều kiện có thể **tránh được bao nhiêu sự mở rộng không cần thiết** mà không cần phải hướng dẫn từng quyết định.
**Ví dụ cụ thể từ giai đoạn Phân tích:** Galley cố tình cho phép người vận hành chạy lại một tác vụ đang chạy. Cả low và medium đều đề xuất hạn chế thao tác này. Trong khi đó, **high đã kiểm tra mục đích đã ghi trong tài liệu và test hiện có**, rồi loại nó khỏi các phát hiện chính thức của mình. Đối với một công cụ tự động có nút “override” thủ công rõ ràng, việc loại bỏ nút override đó là **quyết định về sản phẩm**, không phải là tối ưu hóa code đơn thuần. Chỉ các trạng thái chuyển đổi gọn gàng hơn không đủ để biện minh.
Tôi đã kiểm tra các phát hiện đối chiếu với code và test, và chỉ ghi nhận các quyết định loại trừ có chủ đích khi báo cáo hoặc lịch sử phiên làm việc hỗ trợ.
## Phát Hiện Quan Trọng: Mức Nỗ Lực Cao Xử Lý Tốt Hơn Cuộc Sống Qua Các Lần Retry
Sự khác biệt quan trọng nhất về mặt triển khai nằm ở cách xử lý các tương tác giữa các lần chạy lại và trạng thái được lưu trữ (persisted state).
**Vấn đề tự chuẩn bị bị vô hiệu hóa (Self-Invalidating Preparation):**
Trước khi agent triển khai bắt đầu, Galley có thể chuẩn bị môi trường và tạo khung test chấp nhận (acceptance-test skeleton). Các bước chuẩn bị thành công này nên được tái sử dụng nếu tác vụ chạy lại với cùng một đầu vào.
Tuy nhiên, cả bốn triển khai đều thêm “fingerprint” để phát hiện thay đổi đầu vào. Galley cũng ghi thông tin vào tác vụ trong quá trình thực thi. Việc tạo skeleton thêm một giải thích vào tiêu chí chấp nhận. Nếu bạn đưa giải thích đó vào fingerprint tiếp theo, bước chuẩn bị đã thành công trước đó sẽ **vô hiệu hóa kết quả của chính nó**.
* **Astra Low & Medium và Sol High** đã để lại phiên bản của vấn đề này trong đường dẫn tái sử dụng (reuse path).
* **Astra High** đã **tách biệt giải thích được tạo ra khỏi hợp đồng do người dùng cung cấp**. Nó theo dõi thay đổi này xuyên suốt quá trình chuẩn bị, cập nhật tác vụ và lần chạy tiếp theo.
Việc chạy chuẩn bị không cần thiết có nghĩa là thêm thời gian chờ và thêm một lần gọi model. Nó cũng có thể đẩy người sáng tạo quay trở lại các file test mà agent triển khai đã chỉnh sửa. Việc bảo tồn khả năng tái sử dụng hợp lệ là một phần của yêu cầu.
**So sánh Prismark:**.select(a => a.Id).ToList();
**So sánh Prismark:**select(a => a.Id).ToList();
Astra High cũng đưa ra các lựa chọn khác một cách khiêm tốn. Ví dụ, với các集 hợp thay đổi Git lớn, nó mở rộng một cách hiện có để truyền đường dẫn qua standard input. Với các bản ghi tác vụ bị hỏng, nó tái sử dụng logic cô lập (isolation) hiện có. Nó bao phủ nhiều hành vi hơn mà không phát minh ra một cơ chế riêng biệt cho từng trường hợp.
Tôi đang mang triển khai này vào PR Galley sau: https://github.com/shinpr/galley/pull/137
## Mức Nỗ Lực Trung Bình Tìm Thấy Lỗi Sớm Hơn
Triển khai của medium giải quyết cùng một kế hoạch và nói chung mở rộng các cơ chế hiện có. Nó để lại lỗ hổng tái sử dụng được mô tả ở trên. Tuy nhiên, với chi phí khoảng **$15.61 và 31 phút**, nó tạo ra một thay đổi đáng kể với chi phí thấp hơn so với high ($21.03 và 48 phút).
Điều thú vị xảy ra ở **giai đoạn Đánh giá (Review)**. Tất cả bốn đều đánh giá cùng một code do Sol triển khai. Do đó, sự khác biệt ở đây mô tả **khả năng đánh giá của chúng** chứ không phải triển khai của chính chúng.
Sol đã thêm cơ chế khôi phục cho các file tác vụ bị hỏng có yêu cầu (claim) đã hết hạn. **Medium đã theo dõi quá trình khởi động và tìm thấy một bước khôi phục sớm hơn:** nếu một tác vụ bị hỏng vẫn có bản ghi chủ sở hữu từ một worker bị gián đoạn, quá trình khởi động sẽ thất bại trước khi đến code khôi phục mới. Các tác vụ được xếp hàng không liên quan không bao giờ có cơ hội chạy. Medium đã tái tạo vấn đề này thông qua hàm khởi động daemon thực tế. Nó đã tìm ra một bản sửa lỗi có vẻ hoàn chỉnh ở cấp độ cục bộ nhưng để lại ứng dụng không thể khởi động.
Đánh giá của high bắt được nhiều hơn về vòng đời đầu vào và một lý do khác tại sao các thao tác chạy lại thông thường vô hiệu hóa kết quả chuẩn bị, nhưng **nó không bắt được lỗi khởi động này**. Đối với quy trình của tôi, đây là lý do để giữ một phiên đánh giá riêng biệt ngay cả khi tôi trả tiền cho high trong giai đoạn triển khai.
## Mức Nỗ Lực Thấp Có Tiết Kiệm Được Much Ở Đây Không?
Low rẻ hơn một chút so với medium trong quá trình triển khai, nhưng chi phí phân tích của nó cao hơn. **Trong tổng ba giai đoạn, medium có tổng chi phí thấp hơn.**
Đánh giá của low cũng xác định được một đường dẫn mất dữ liệu: việc tái sử dụng một file đầu vào đã chỉnh sửa thành công, nhưng một lỗi sau đó khi lưu bằng chứng có thể xóa file đó. Đề xuất sửa chữa của nó nhỏ và phù hợp: Hoàn nguyên các file được tạo bởi nỗ lực hiện tại; bảo quản các file được mang từ nỗ lực trước đó. Đánh giá lại bỏ lỡ vấn đề tái sử dụng chuẩn bị và các đường dẫn khôi phục khác.
Tôi vẫn sẽ thử low cho một chỉnh sửa nhỏ, được xác định rõ ràng. Thí nghiệm này sử dụng công việc repository rộng lớn và không thiết lập hai mức so sánh như thế nào trên danh mục nhỏ hơn đó.
## Triển Khai Của Sol Kém, Nhưng Đánh Giá Của Nó Lại Mạnh
Triển khai của Sol đã bỏ lỡ việc dọn dẹp đầu vào bị lặp lại. Nó cũng giữ lại cả hai đường dẫn lập lịch cũ và mới, với một số test vẫn chạy đường dẫn cũ. Các thay đổi trong tương lai sẽ phải duy trì hai phiên bản hành vi tương tự.
Tuy nhiên, **đánh giá của Sol đã tìm ra các vấn đề mà không có báo cáo Astra nào bao gồm**:
1. Một thất bại tái sử dụng chuẩn bị khác: setup lưu một hồ sơ môi trường đã học, nhưng fingerprint thành công của nó vẫn mô tả hồ sơ trước khi cập nhật đó. Chạy tiếp theo từ chối chính bằng chứng setup thành công của nó.
2. Một bước kiểm tra tắt (shutdown) bị thiếu trước khi lấy thêm tác vụ được xếp hàng.
3. Một kiểm tra repository từ chối các đường dẫn hợp lệ với viết hoa khác nhau trên macOS.
Một số biện pháp khắc phục cần được xem xét kỹ hơn. Sol đã xác định đúng một fallback không an toàn sang registry chung cũ, nhưng tuyên bố rằng metadata sở hữu mới là cần thiết trước khi thiết lập xem fallback đó có thể được loại bỏ thông qua một quy trình di chuyển rõ ràng hay không. Tôi đã trừ điểm cho phán đoán này: vấn đề xứng đáng được sửa, nhưng trạng thái bổ sung được đề xuất vẫn cần một lý do để tồn tại.
Kết quả triển khai của Sol sẽ là một cơ sở kém để dự đoán giá trị đánh giá của nó.
## Tổng Chi Phí Và Thời Gian: Bảng So Sánh Chi Tiết
Dưới đây là tổng chi phí (API-equivalent cost) và thời gian tổng hợp cho mỗi điều kiện, bao gồm một lần phân tích, một lần triển khai và một lần đánh giá:
| Điều Kiện | Chi phí (API tương đương) | Thời gian tổng hợp |
| :— | :— | :— |
| **Astra Low** | $26.97 | Khoảng 49 phút |
| **Astra Medium** | $25.67 | Khoảng 51 phút |
| **Astra High** | $37.23 | Khoảng 77 phút |
| **Sol High** | $31.79 | Khoảng 75 phút |
– **Medium** rẻ hơn khoảng **19%** so với Sol High.
– **High** đắt hơn khoảng **17%** so với Sol High, nhưng lại đắt hơn khoảng **45%** so với medium.
**Chi phí phụ thuộc vào số lượng token, không chỉ số request:**
– **Sol**: 238 requests, ~37.8M input tokens, ~98k output tokens.
– **Medium**: 80 requests, ~11.1M input tokens, ~50k output tokens.
– **High**: 107 requests.
Chi phí hóa đơn phụ thuộc vào khối lượng token và phân tích cache, không chỉ số lượng request. Trong tác vụ này, mức sử dụng thấp hơn của medium đã bù đắp được mức giá theo token cao hơn của Astra.
## Kết Luận Và Lựa Chọn Của Tôi: Bắt Đầu với Medium, Chọn High Khi Cần
**Mức nỗ lực trung bình (medium) sẽ là điểm khởi đầu** của tôi cho các tác vụ Galley rộng tiếp theo. Tuy nhiên, tôi sẽ **chọn ngay mức cao (high)** khi công việc liên quan đến nhiều lần chạy lại, quản lý chủ sở hữu và trạng thái được lưu trữ – những nơi mà việc bỏ sót một đường dẫn liên quan sẽ dẫn đến một vòng sửa chữa tiếp theo.
Cuộc thử nghiệm này chỉ là một lần chạy trên một repository cho mỗi điều kiện. Đánh giá được hỗ trợ bởi model và tôi đã thách thức, sửa đổi các đánh giá khi lý luận hoặc quy attribution của chúng sai. Điểm số cuối cùng không được blind (mù). **Tôi tin tưởng vào các thất bại và bản sửa lỗi cụ thể hơn là những khác biệt nhỏ về điểm số số học.**
Bước kiểm tra tiếp theo của tôi là liệu lựa chọn này có giảm bớt công việc sửa chữa tôi phải làm sau đó hay không. Tôi vẫn sẽ sử dụng một bước đánh giá (review pass) riêng biệt. Phát hiện về lỗi khởi động của medium sẽ bị mất nếu tôi giả định rằng high đã bao phủ tất cả mọi thứ.
