Cách tôi sử dụng Hội đồng AI (AI Councils) để giải quyết các vấn đề kỹ thuật mơ hồ

Một trợ lý AI thì hữu ích. Nhưng nó là chưa đủ đối với các kiến trúc phần mềm phức tạp.

Nếu bạn sử dụng AI cho nhiều việc hơn là chỉ tự động hoàn thành mã (autocomplete), bạn sẽ thấy một quy luật. Một mô hình duy nhất đề xuất một giải pháp. Nó trông có vẻ ổn. Bạn triển khai nó. Rồi ba ngày sau, bạn phát hiện ra một lỗi kiến trúc nghiêm trọng.

Đây không phải là thất bại của mô hình. Đó là thất bại trong quy trình của bạn. Một mô hình đơn lẻ hiếm khi tự thách thức các giả định của chính nó.

Để giải quyết các vấn đề mơ hồ, bạn cần một Hội đồng AI (AI Council). Đây không phải là một nền tảng mới. Đó là một quy trình làm việc (workflow) nơi nhiều ngữ cảnh AI khác nhau cùng xem xét một đề xuất từ các vai trò khác nhau.

Mục tiêu là biến việc sử dụng AI thành một quy trình kỹ thuật có sự kiểm soát.

Đây là quy trình làm việc:

• Phát biểu vấn đề (Problem Statement): Bạn xác định phạm vi vấn đề. • Agent Kiến trúc sư (Architect Agent): Một agent dựa trên nguồn dữ liệu (source-grounded) tạo ra một đề xuất kèm theo các sự đánh đổi (trade-offs). • Phê bình từ Hội đồng AI (AI Council Critique): Các vai trò AI khác nhau xem xét đề xuất. • Tổng hợp phản hồi (Feedback Synthesis): Một agent đánh giá tất cả phản hồi và xác định các điểm xung đột. • Sổ ghi chép phản đối (Objection Ledger): Bạn theo dõi tất cả các ý kiến phản đối, mức độ nghiêm trọng và cách giải quyết chúng. • Sự quản trị của con người (Human Governance): Bạn quyết định xem kế hoạch đã sẵn sàng chưa hay cần thêm một vòng nữa. • Agent Thực thi (Executor Agent): Một ngữ cảnh riêng biệt triển khai kế hoạch. • Agent Kiểm định (Auditor Agent): Một ngữ cảnh thứ ba kiểm định mã nguồn dựa trên đặc tả ban đầu.

Sức mạnh đến từ việc phân tách vai trò. Đừng chỉ hỏi "bạn nghĩ sao?". Hãy gán các vai trò cụ thể cho các phiên làm việc AI khác nhau:

  • Người tư duy hệ thống (System Thinker): Đánh giá các rủi ro hệ thống và các ranh giới.
  • Người phản biện (Critical Reviewer): Thách thức các giả định và tìm ra các lỗ hổng logic.
  • Người đơn giản hóa (Simplifier): Tìm ra những sự phức tạp không cần thiết.
  • Người xem xét các phương án thay thế (Alternatives Reviewer): Đề xuất các cách tiếp cận khác nhau.

Phần quan trọng nhất là Sổ ghi chép phản đối (Objection Ledger). Nếu không có nó, các phản hồi sẽ chỉ là những ý kiến mơ hồ. Một cuốn sổ ghi chép buộc bạn phải giải quyết mọi mối quan ngại. Bạn đánh dấu các ý kiến phản đối là Mở (Open), Được chấp nhận (Accepted), Bị bác bỏ (Rejected), hoặc Đã giải quyết (Resolved). Điều này tạo ra một hồ sơ quyết định có thể kiểm chứng được.

Bạn không trở thành nút thắt cổ chai của việc sao chép-dán. Agent dựa trên nguồn dữ liệu sẽ thực hiện việc tổng hợp. Bạn đóng vai trò là Người quản trị (Governor). Bạn không làm các công việc thủ công. Bạn nắm giữ các chốt kiểm soát.

Bạn làm chủ các quyết định:

  • Khi nào nên ngừng lặp lại.
  • Khi nào nên phê duyệt đặc tả (spec).
  • Khi nào nên chấp nhận rủi ro cuối cùng.

Hãy sử dụng cách này cho các đợt tái cấu trúc (refactor) rủi ro cao hoặc kiến trúc chưa rõ ràng. Đừng dùng nó cho các lỗi nhỏ nhặt. Chi phí vận hành (overhead) chỉ xứng đáng khi cái giá của một thiết kế sai lầm là rất lớn.

Hãy bắt đầu nhỏ thôi. Sử dụng một người phản biện và một người đơn giản hóa. Bạn sẽ thấy giá trị của nó ngay lập tức.

Nguồn: https://dev.to/j3nnning/how-i-use-ai-councils-to-solve-ambiguous-engineering-problems-4dii