For more than fifteen years I've seen teams skip product discovery. Not on purpose. There was always a reason. End of quarter, a customer on the phone, someone at the top with a gut feeling. It was never about believing discovery didn't matter.
With coding agents I think the reason to stay on course is even stronger. Because the agent will build whatever you describe. Fast and without complaints or critical questions. The questions I used to see pushed to the next quarter I now see skipped in every prompt. Who is this really for? Did they ever say so? And what would have to be true for it to matter to them? These questions are still just as real. But skipping them early on is cheaper than ever.
So I built the thing I wanted for myself. I'll get to what it is further down. First what it told me about my own work, since that's the part I hadn't planned on writing about.
The row
The tool keeps a decision log, every decision dated and with the alternatives that lost. It also has a small script that prints one row about the builder: decisions made before the first source file, how many of those cited evidence from outside the builder's own head, and how many ideas were killed before any code existed. That's what the tool is for, discovery before code, and the row is how you'd know if it happened.
I ran it on the tool itself after 126 sessions.
first source file 2026-05-02 | decisions before it: 4 of 912 | citing outside evidence: 1 | kills before code: 0
A decision is a dated entry in the log with the alternatives that lost. Outside evidence is a source that isn't me. A kill is an idea recorded and then dropped before any code for it existed. The script reads the log and the canvas files and counts; it can't tell whether a decision was good, only whether it was made and when.
Four decisions before I wrote code, one of them citing anyone other than me, and nothing killed. I'd spent fifteen years watching other people do this and I'd done it myself, on the tool that's supposed to make it visible. I honestly didn't expect that, and I don't have a good explanation for it beyond the ones I used to hear from the teams.
The row is new. The corrections behind it aren't, and the fixes came from those, one at a time, months before the script existed. The repository holds 124 pre-registered tests now, 65 of them from this September, each with a prediction frozen and committed before the data. The strategy work has a kill date. None of that came from good intentions. It came from the log showing the same skip often enough that a rule got written.
One builder and one row isn't much, I know. But the file where the agent logs its own corrections has three hundred entries now, and most of them aren't about code. They're about what we thought we knew. A prediction we froze against a bar the project's own ledger said we'd miss. A test we designed and then didn't run for eighty-nine days. A comment that broke an interviewing rule two days after we'd written the rule down. Discovery doesn't get skipped once, in a meeting. It gets skipped a bit at a time, and an agent that's happy to build doesn't push back on that unless something makes it.
What it is
Mycelium is a harness in front of the coding agent. It won't let the agent write code until the questions before the code have answers. Purpose first, then strategy, then opportunities, then a spec, and then code. Iterative, of course, improving all the time all the way. Every answer has a confidence number and a source, and when the source is my own opinion it says so, so the agent can weigh it as one and not as a fact.
It runs as a plugin in Claude Code. It also runs in opencode and on Mistral's Vibe, since the mechanism is files and hooks rather than a model. The README said "Claude Code harness" in its first line until this morning. Writing this down is what got it fixed.
The loop back to the customer
Listen to any podcast this year on specs and agents and you'll hear the same shape. Intent before requirements. Two loops, one from the spec to the pull request and one that has to come back to the customer. And then the honest bit, where the first loop is getting fast and nobody really says how the second one closes.
I don't think it closes with a better spec. A spec says what should exist. The loop back to the customer asks whether anyone wanted it, and that's a different document with a different owner, and it goes stale at a different speed. What I've found is that it closes the same way the first loop does, with mechanisms rather than intentions. A gate that won't move the work from discover to deliver on my opinion alone. Somebody outside the room has to have said something first. A kill criterion with a date on it, written before there's any evidence. The one on my strategy work reads, with two pointers to other fields cut: "TWO KILLS, read from 2026-11-05 on the counts as they stood at the end of 2026-11-04. KILL-TAKEUP: ten offers made and at most one taker. KILL-NO-MOVE: at least four takers have been asked after their fourteen days, and not one reports a contact. Anything between the lines is stop, not a continue: this bar cannot stay open past its date." A prediction committed to git before the data, so nobody can move the goalposts, me included. None of that is clever, and all of it is the kind of thing a team says it does. The log is where you find out whether it did.
Where it stands
A man I've never met, not a developer, installed it, ran the discovery loop in about ten minutes on a Lisp interpreter he was building on Vibe with Mistral, and left the canvas and the decision log in his repository on purpose. I only know because the files are public. That's the reach so far, one person, and I'm aware of it.
What I don't know is whether a team wants this. I built it for one person because I was one person. The next thing is a few conversations with a product trio about how they'd share a canvas, and I haven't had those yet, so I'm not going to guess at the answer here.
The script that printed my row ships with the tool, as /mycelium:count. The tool is at github.com/haabe/mycelium. If you run it on your own repo I'd like to see what it says, even if it's the same as mine.
