登録して招待リンクを共有すると、動画再生報酬と紹介報酬を獲得できます。

cv usk
@cv_usk
AI / Software Research Notes AI Agent, LLMOps, MLOps, Software Architecture 投稿は個人の意見です。
参加 May 2026
286 フォロー中    469 ファン
Harness Engineering Practices P14. Independent Self-Critique Pass (Separate Generator and Critic Context) 🎯 Point Do you trust an agent that reviews its own code and says "looks good"? Reviews only function when separated from the author. 📝 Overview After implementation, critique the diff against the spec in a separate context (ideally with a different role prompt). To avoid the "I just wrote it so it must be correct" bias, the generator and critic must not share context. 🔍 Explanation For the same reason human code reviews are performed by someone other than the author, agent self-critique requires context separation. When generation and critique happen in the same context, the "why I wrote it this way" bias carries directly into critique, making problems easier to miss. In a separate context — ideally a different prompt or model instance — showing only the diff and spec enables a fresh-perspective review. This adds computational cost, but the defect-prevention payoff is significant. 🛠 How to Practice - After implementation, launch a separate context (new conversation session) and provide only the diff and spec for review - Give critics focused roles ("spec divergence," "security risks," "regression potential," etc.) - Where possible, use different models or prompts for generation and critique to ensure perspective diversity - Have critique results output in structured format so the harness can auto-decide actions (send fix instructions, report to humans) 💼 Use Cases - Issue-to-PR agents running a self-review with a different prompt before completion - Autonomous bug fixing: validating fix soundness in a separate context - Code generation: running security-focused reviews as a separate agent ⚠ Pitfalls A critic designed to "flag everything" produces a flood of trivial comments, creating infinite implement-fix-critique-fix loops. Give critics focused roles: "spec divergence," "security risks," "regression potential." Low-quality critics also risk unnecessarily modifying correct implementations. #HarnessEngineering# #CodeReview#
もっと見る