Show HN: An "Evidence Loop" for steering the agents what to build
Fellow builders, my name is Julian - I'm a PhD candidate in Behavioural Science at LSE, where I focus on Human-AI Alignment (specifically the field of Machine Psychology), and we built Dipio AI around a problem I think is becoming more important as coding agents get better: implementation is getting dramatically cheaper, but knowing what is worth building isn't.
Dipio applies behavioral science methodologies to AI-led user research, turning evidence from user conversations and behavior into agent-native specs (e.g., spec-kit, etc.). Your coding harness can access them directly through Dipio MCP, or through the platform as an evidence-backed, ready-to-implement feature specs.
I wrote more about the idea we call the “Evidence Loop” here: https://www.dipio.ai/blog/evidence-loop
I’d particularly appreciate criticism of the underlying thesis: are we solving the "how to build" problem much faster than the "what to build" problem? Also, any criticism in general is welcomed, don't hold yourself - I have a hard skin, and most importantly I value a lot the feedback from such a great community like this one!
(
3 comments
| on HN
)
A lot of the recent signals point in the same direction: back in Dec 2025, Boris Cherny said 100% of his Claude Code contributions "over the previous 30 days" were written by Claude, and as Garry Tan recently mentioned - YC has already seen companies with 95% AI-generated codebases.
We’re getting very good at the "how".
But most of the systems around software development still optimize for shipping faster and more reliably. They don’t really answer the more basic question: was this worth building?
That’s the idea behind what we call the Evidence Loop:
real users (or synthetic copy of it) → evidence → spec → agents build → observe what happens → start the loop again.
We’re also researching Synthetic Twins. We’ve published peer-reviewed work (currently in press). I don’t think synthetics should replace real users; the interesting part is using them to explore hypotheses cheaply, then bringing those hypotheses back to real users and real behaviour.
Longer term, the bet is simple: agents shouldn’t just get a ticket saying “build X.” They should have access to the evidence explaining why X should exist at all.
Thank you!
Julian
DM's are welcomed: https://www.linkedin.com/in/j16h/
Several factors contribute to this:
1/ We pin down the exact behaviour first: who does what, where, by when. That precise behaviour is the target everything serves.
2/ We interview doers and non-doers. That’s how we handle conflicting feedback: we don’t average it away, the gap between the two groups is the insight - what doers have that non-doers lack is exactly what to fix. We can also triangulate the behaviour with user's action they do in the product - for that we experiment with product analytics integrations, such as amplitude & posthog for now.
3/ We diagnose the real barrier by applying behavioral science framework - COM-B. Every interview is coded into six buckets: capability, opportunity, motivation.
4/ The barrier tells us what to build (e.g. what type of intervention works the best, based on behavioral science principles). Different barriers need different fixes: let's say, if people don’t know how, you teach them; if it’s too inconvenient, you remove friction. Behavioural science already maps each barrier to the type of solution that works for it, so the fix isn’t a guess. The barrier itself points to a specific, concrete thing to build.
5/ Finally, every recommendation traces back to real customer voice and interviews. The line from “customer said X” to “so we’re building Y” is fully visible, end to end.
We have a blog post on it here: https://www.dipio.ai/blog/behaviour-change-design
Plus, there is a great source for all-behavioral science, including COM-B model https://thedecisionlab.com/reference-guide/organizational-be...