jkalichman

Thanks so much for stopping here! This is a really great question.

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...

A bit more context on why we built this:

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/