The security researcher who wasn't talking about you
Dr. Karsten Nohl is a German security researcher, best known for publicly exposing critical vulnerabilities in GSM and SS7 mobile infrastructure — systems that decide how billions of phone calls are routed. He does not work in developer productivity. He has no connection to any side project tool. He was describing enterprise AI security pipelines when he said this (translated from the German original, source):
"A realistic goal cannot be to replace humans 100%. Instead: let the machine do 90% of the work — and still keep a human in the loop at every important decision point. The same person who used to do the work now supervises the machine."
And, more pointedly:
"A great many AI experiments are going wrong right now — precisely because people glue all sorts of AI agents together, feed sensible data in at the front, get a wrong result out at the back, and conclude that none of this works."
He was talking about production security infrastructure. Not side projects. That is exactly what makes it useful: the model arrives from a domain with no stake in yours.
It is not a marketing frame. It is a response to a specific observed failure: fully automated pipelines producing confident, wrong output, because nobody was watching at the junctures that mattered.
The measurement that makes this concrete
In July 2025, METR published a randomised study of experienced open-source developers on real tasks from their own repositories, with and without AI tools. The developers expected to be faster. They were 19% slower (arXiv:2507.09089).
Not beginners. Not toy problems. Experienced engineers on their own code.
The number itself is less interesting than the gap it exposes: the developers in that study predicted a speed-up and got a slow-down. They could not tell, from the inside, which one was happening. That is the failure mode Nohl was describing, moved from a security pipeline into your editor.
Why this is not a willpower problem
Kahneman's planning fallacy (1979) is the reason your estimate was never going to hold: people systematically underestimate how long their own projects take and overestimate how motivated they will be later. You plan under best-case assumptions and execute in an ordinary week.
A side project is the ideal environment for that effect. No deadline anyone else cares about. Nobody checking. No consequence for letting a week slip. The only accountability is self-generated, and self-generated accountability is the weakest kind there is.
There is a second mechanism on top of it. Reviewing a plan, reading architecture notes, scanning a generated task list — that all feels like work, and it is the cheapest possible mode to be in. You are present without being engaged, and the project does not move.
So the planning problem is solved. Planning was never the expensive part. What is left is the Tuesday at 7pm when you have forty-five minutes, the project is 90% done, and you open something else instead. Nothing external marks the difference between "Day 4 happened" and "Day 4 did not." With no marker, there is no loss to register, and the project stays almost finished indefinitely.
What 90/10 looks like when you build it
The 90% is continuity you do not have to generate yourself: a prompt that arrives on its own, calibrated to your project, your stack, and what you reported yesterday. Its job is not motivation. Its job is to remove the decision of what to work on, so the forty-five minutes go into the work instead of into the question.
The 10% is judgment at the points that decide whether the project goes live or quietly stops — not every day, but at the milestones. Did you build what you said you would build? Is the scope still coherent? Does this go forward, or does it get recalibrated?
That split has a consequence people miss: the machine reads everything, and the human reads what counts. Daily check-ins feed the next prompt. The proof you submit at a milestone gets read by a person before the sprint continues. Inverting that — a human skimming every daily note, a machine approving the milestone — gets you the worst of both.
An accountability system is not a motivation system. It is checkpoint structure, which is precisely what AI tools do not ship with.
The obvious objection: a community already does this
It is a fair objection and worth taking seriously, because the loudest alternatives in this space are peer-based: cohorts, public build logs, accountability groups.
Here is where it breaks. Five thousand followers will not notice you stopped on Day 4. A group notices absence in aggregate, not yours in particular. And a dashboard tracks, but it never asks. What changes behaviour is not visibility, it is a specific person who will read a specific thing you owe them on a specific day — and who notices when it does not arrive.
Peer pressure and a reader are not the same instrument. One scales and does not bind. The other binds and does not scale. If you already have a co-founder or a team lead reading your work, you have the 10% and you do not need to buy it.
One instantiation of the model
I build this as a product, so treat the rest as disclosed interest.
It is a structured sprint over 13, 21 or 30 days, for developers with a full-time job whose side project is stuck. Which of the three fits depends on where you actually are: just an idea, started but stalled, or almost over the line. Five click questions at mvpbuilder.io/go tell you which one, and then there is a free thirty-minute call where a human reads your project and both sides decide whether it fits.
The 90%: each evening, a prompt for the next day, calibrated from your project context and your last check-in.
The 10%: at each milestone of your module — day 13 for the shortest, up to days 13, 21 and 30 for the longest — you submit proof, and I read it before the sprint continues. Not a dashboard summary. The thing itself.
The honest part: no paying customer has completed a sprint yet. I would rather you read that here than find it out later. The manual review is the part I am validating, and it does not scale — that is the point of running it by hand first.
The realistic input is three to five hours a week, spread across several days rather than saved up for Sunday. Days you miss cannot be filed later.
The question worth sitting with
If you have been building with AI tools and the project still is not live, the uncomfortable question is not whether the tools are good enough. They are good enough. The architecture question is what is missing around them.
A plan is not a checkpoint. A generated task list is not a deadline. A repository full of working code is not something anyone can use yet.
If the 90% is already in place and Day 4 still gets skipped, the question is not whether AI is useful. It is whether anyone is watching.
FAQ
Are experienced developers actually slower with AI tools?
In METR's July 2025 randomised study, experienced open-source developers working on real tasks in their own repositories were 19% slower with AI tools than without (arXiv:2507.09089). The striking part is that the same developers predicted they would be faster — the slow-down was not visible from the inside.
What is the 90/10 model for AI-assisted development?
Described by security researcher Dr. Karsten Nohl for enterprise AI pipelines: let the machine do roughly 90% of the work, and keep a human in the loop at every important decision point. Applied to a side project, the 90% is automated daily continuity — a calibrated prompt that arrives without you deciding to open the project — and the 10% is human judgment at the milestones that determine whether the project goes live or stalls.
What is the planning fallacy and why does it hit side projects hardest?
The planning fallacy (Kahneman, 1979) is the systematic tendency to underestimate how long your own projects take and to overestimate your future motivation. Side projects are the worst case: no external deadline, nobody watching, and no consequence for slipping a week. The result is a project that stays almost finished — not because the developer lacks skill, but because nothing external marks the difference between a day that happened and a day that did not.
What is MVP Builder?
MVP Builder is a structured sprint over 13, 21 or 30 days for developers with a full-time job whose side project is stuck. Five click questions suggest which module fits, followed by a free thirty-minute call where both sides decide. During the sprint, an AI-calibrated prompt for the next day arrives each evening, and at every milestone of your module a person reads the proof you submit before the sprint continues. The realistic input is three to five hours a week, spread across several days.
Top comments (0)