<@U06R4QFGHQQ> here’s our docs on the verification...
# proj-agent
l
@quiet-night-61895 here’s our docs on the verification stack: https://www.notion.so/Agent-Verification-Stack-2fb7be798a1780e7875fe3406191f63d @chilly-france-44439 could you give all-company edit or at least comment access to it (and maybe @calm-artist-7206 too if he’s interested?)
q
Thanks I'm now able to see!
Have we looked at MaintainBench or (slightly less relevant) CodeClash? https://github.com/IAAR-Shanghai/MaintainCoder https://codeclash.ai/
So far what I'm seeing in the Notion is it’s very agent-centric, there are mentions of that make the codebase support verification but it's less fleshed out, so that's where I might be able to help connect the dots.
c
@chilly-france-44439 could you give all-company edit or at least comment access to it (and maybe @calm-artist-7206 too if he’s interested?)
Of course, thank you, I'd love to
c
@calm-artist-7206 could you share your notion email? 🙂
c
c
> there are mentions of that make the codebase support verification but it's less fleshed out, so that's where I might be able to help connect the dots. would appreciate comments there 🙏 In general, I view the verification stack as a set of fundamental concepts we maintain in the SDK that produce "verification signals": • Critic - critic model we just shipped • Sub-agents (?) - that could be triggered by a skill (codereview-roasted), plugins, etc • Codebase supported verifications: pre-commit, unit tests, etc And hook is the mechanism to "reject the agent" by combining this suite of signals 🙂 I'll spend sometime next week to better think through this question and update that notion. Feedbacks are welcomed before that 🙏
c
I'd just add on a side note, I do think verification is the big next bottleneck - that is, because code review is. I have tried and am trying a lot of things, some dumb, some who knows. (OK, OK, many dumb 😹) Once the deterministic verification has done all it could, there is IMHO a significant leftover that affects long running tasks, significant refactorings, code with architecture impact, that are not obvious, not contained in it, and not contained in the current review skills. Yet! Multiple LLMs for reviewer agent(s), particularly at least a different LLM than the one of the agent who implemented, can help. We're not really doing that yet (I think?) but I think we kinda need to. I know I've surprised folks repeatedly with my mean OpenHands-GPT-5.2 roasted. 😅 It finds things that Claudes don't, and that alone IMHO warrants trying to add it to the mix (though I think the roasted prompt is a bit too strong for it)
👍 1
q
So I’m trying to understand the scope of this “stack”. For instance is the review skills piece going to be specific skills, advice for writing them, or a way of evaluating them? Is guidance on testing useful or is it just “agent should run whatever tests exist”?
l
@chilly-france-44439 maybe you could take a pass through the doc and create a TL;DR at the top that starts with the content of my comment?
c
FYI the blog on the verifier, part I, seems to have a broken citation block
l
thx