Register and share your invite link to earn from video plays and referrals.

cv usk
@cv_usk
AI / Software Research Notes AI Agent, LLMOps, MLOps, Software Architecture ๆŠ•็จฟใฏๅ€‹ไบบใฎๆ„่ฆ‹ใงใ™ใ€‚
Joined May 2026
286 Following    469 Followers
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#
Show more