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 affect how billions of phone calls are routed. He doesn't work in developer productivity. He's not affiliated with any side project tool. He was describing enterprise AI security pipelines when he said this:
"The goal can't be to replace humans 100%. Let the machine do 90% of the work — but keep a human in the loop at every critical decision point. The same person who used to do the work themselves now supervises the machine."
And then, more pointedly:
"A lot of AI experiments are failing right now — exactly because people are chaining AI agents together, feeding sensible data in the front, getting a wrong result out the back."
He was talking about enterprise security infrastructure. Not side projects. That's exactly what makes it useful — independent validation from a completely unrelated domain.
The 90/10 model he described didn't emerge from a product manager optimizing conversion rates. It came from engineers trying to figure out why fully automated AI pipelines kept producing wrong outputs with high confidence.
The answer was: no one was watching at the critical junctures.
The productivity paradox
In July 2025, METR published a study measuring experienced, professional developers on real software tasks — with and without AI tools. The finding: developers using AI tools were 19% slower on average.
Not junior developers learning to code. Experienced engineers on real work.
The follow-up findings didn't reverse this — they narrowed it. The effect is smaller than originally measured for some task types, but directionally negative for complex tasks remains the finding.
Separately, BCG documented 39% more serious errors in AI-intensive work environments. The mechanism in both cases is the same: over-trust, reduced verification, and a diffuse sense that "the AI handled it" — even when it didn't.
A developer describing this recently put it bluntly: he had 40 minutes budgeted per ticket because his manager assumed AI would speed things up. He committed to the next ticket anyway. At the end of the day, he didn't know what he had actually done.
That's not a motivation problem. That's a structural problem. And it happens to be exactly what Nohl was describing — except his engineers weren't building side projects, they were running AI pipelines with production consequences.
Your brain has already checked out
Here's the part that removes the shame.
Kahneman's Planning Fallacy (1979) shows that humans systematically underestimate how long their own projects take and overestimate their future motivation. This is not a character flaw. It's how cognition works. You plan from best-case conditions, then execute in reality.
Solo side projects are a perfect environment for this effect to compound. No deadline anyone else cares about. No one checking in. No consequence for letting the sprint slip a week. The only accountability is self-generated — and self-generated accountability is the weakest kind.
There's a secondary mechanism that makes this worse: passive monitoring. When you're watching rather than doing — reviewing a plan, reading architecture docs, scanning an AI-generated task list — the brain shifts into an energy-saving mode. You're present, but not engaged. You feel like you're working. You're not building forward momentum.
The planning problem is solved. What AI tools haven't touched is the execution problem — the Tuesday at 7pm when you have 45 minutes, the project is 90% done, and you open something else instead.
This isn't about willpower. It's about the absence of checkpoint structure. When nothing external marks the difference between "Day 4 done" and "Day 4 skipped," the brain registers no loss. The project stays 80% complete, indefinitely.
What 90/10 actually means in practice
Back to Nohl's model. He described the architecture like this:
"Each of those AI agents reports back to a person who approves — and passes it on to the next."
Applied to a side project sprint, this translates directly:
The 90% is automated daily continuity — prompts tailored to where you are in the build, what you've shipped so far, what's left. They arrive without you having to decide to open the project. They create a low-friction point of entry on the Tuesday at 7pm. They're not motivational content. They're structured questions that re-engage you with the actual work.
The 10% is human judgment at the moments that determine whether the project ships or dies. Not every day — at the milestones. Day 13. Day 21. Day 30. Did you build what you said you'd build? Is the scope still coherent? Do you move forward or do we recalibrate?
An accountability system for developers isn't about motivation. It's about creating the checkpoint structure that AI tools don't provide by default.
The 90/10 model isn't a workaround — it's the architecture. Automate the daily continuity. Preserve human judgment for the moments that determine whether the project ships or dies.
One instantiation of this model
I'm testing this as a product. It's called MVP Builder.
The structure is a 30-day sprint for developers with a full-time job. You apply with your project. Daily prompts are sent based on your stack, your tier (13, 21, or 30 days depending on where you are), and what you've built so far. At milestones, there's a checkpoint review before the next phase unlocks.
Not an AI reviewing it. Me. Because right now, at Cohort #1, the human in the loop is the founder.
That's the 10%. And it doesn't scale. That's exactly why Cohort #1 is free — the manual review is the product that I'm validating, not the automation layer.
The Gawdat objection
Mo Gawdat — former Chief Business Officer at Google X, founder of Emma AI — made a point worth taking seriously:
"If I had started Emma in 2022 it would have taken me 350 engineers and four years. It took less than three months and basically four of us."
If AI tools enable that kind of leverage, doesn't the 90/10 model become unnecessary? Can't you just ship faster and skip the checkpoint structure entirely?
Steel-man accepted. Gawdat's experience is real. But the constraint set is completely different.
Gawdat is a full-time founder with co-founders and twelve years of institutional knowledge from Google X. The developers in MVP Builder's ICP are running a side project on 5–10 hours per week, competing with a full-time job, without co-founders, without a team, and without anyone who will notice if the project stalls at 80%.
Same AI tools. Completely different execution environment.
Gawdat has the external structure built into his setup — co-founders provide daily accountability by default. A solo developer with a full-time job doesn't have that. The tools don't create it. That's the gap.
The actual question
If you've been building with AI tools and the project still isn't shipped, the uncomfortable question isn't whether the tools are good enough. They're good enough. The architecture question is what's missing.
A plan is not a checkpoint system. An AI-generated task list is not a deadline. A repo with working code is not a shipped product.
Cohort #1 is free. Application takes 2 minutes: mvpbuilder.io/pipeline
If the 90% is in place and Day 4 still gets skipped, the question isn't whether AI is useful — it's whether anyone is watching.
FAQ
Why are experienced developers slower with AI tools?
The METR study (July 2025) found experienced developers were 19% slower on real software tasks when using AI tools. The primary causes are over-trust in AI output, increased verification overhead, and reduced active engagement with the work. BCG separately documented 39% more serious errors in AI-intensive environments — consistent with a pattern where developers assume the AI handled something it didn't.
What is the 90/10 model for AI-assisted development?
The 90/10 model — described independently by security researcher Dr. Karsten Nohl in the context of enterprise AI pipelines — proposes that AI should handle approximately 90% of routine, repeatable work, while a human remains in the loop at every critical decision point. Applied to software development: automate daily continuity (prompts, reminders, task framing), preserve human judgment for milestone reviews that determine whether a project ships or stalls.
What is the planning fallacy and why does it affect side projects?
The planning fallacy (Kahneman, 1979) describes the systematic human tendency to underestimate effort and overestimate future motivation when planning personal projects. Solo side projects are especially vulnerable because there are no external deadlines, no one watching, and no consequence for slipping the timeline. The result: projects stay 80% complete indefinitely, not because the developer isn't capable, but because there's no external structure creating a meaningful difference between "done today" and "done next week."
What is MVP Builder?
MVP Builder is a structured 30-day sprint for developers with a full-time job who have a stalled side project. Participants apply with their project, receive daily prompts calibrated to their build stage and tech stack, and go through milestone checkpoint reviews at Days 13, 21, and 30 depending on their tier. Cohort #1 is free. The product tests the hypothesis that what developers need isn't a better plan — it's a checkpoint system that holds them to the one they already have.
Top comments (0)