In 2005 Derek Sivers published a short table that founders have been quoting to each other ever since. Ideas score from −1 (awful) to 20 (brilliant). Execution is priced from $1 (none) to $10,000,000 (brilliant). Multiply the two and you have what a business is worth. His point was the bottom row: a brilliant idea with no execution comes to $20. “Ideas are worth nothing unless executed,” he wrote. “They are just a multiplier.”
He was right, and the reason he was right was price. Execution, for anything involving software, meant engineers, and engineers meant either years of learning, a technical co-founder willing to take the risk, or a budget most people with an idea didn’t have. So ideas were plentiful and the ability to realise them was not. Most of them died in notebooks, and the ones that lived mostly belonged to people who could already code or already raise money.
The execution term has moved, unevenly, and the move changes what an idea is worth. AI hasn’t made software free, and the evidence says so. What matters is telling the part that got cheap from the part that didn’t, because a founder who confuses the two pays for it later.
What actually got cheaper
The strongest evidence on who gains from AI coding tools comes from three field experiments run by Microsoft, Accenture and an unnamed Fortune 100 company, analysed by Cui, Demirer and colleagues and published in Management Science. Across 4,867 developers, randomly given access to an AI coding assistant or not as part of normal work, those with access completed 26% more tasks (with a wide standard error of about ten points). The detail that matters here is in the abstract: less experienced developers adopted the tool more and gained more from it.
That is the good news, and it is genuinely good. The distance between “I can describe what I want” and “I have something that runs” has collapsed. A founder with no engineering background can now open a tool like Lovable or Replit, describe a product in plain language and have a clickable, working version by the evening. In our evidence review we found that 84% of developers now use or plan to use these tools; plenty of the people using them were never developers at all.
Two limits belong next to that finding. The field experiments measured completed tasks, not whether the resulting software was secure or maintainable, and they studied code-completion tools from the 2022–2023 generation, not today’s agents. What they show is that AI raises the floor. They don’t show where the ceiling is, or what’s underneath the floor.
Where DIY builds break
What’s underneath became visible in March 2025. Matt Palmer and Kody Low, two engineers at Replit, scanned 1,645 web apps built with Lovable and found that 170 of them let anyone read their users’ data: names, email addresses, financial information and API keys, according to Semafor’s reporting. The cause, recorded as CVE-2025-48757, was database access rules that had never been switched on. Replit competes with Lovable, which is worth knowing, but the flaw is recorded in the US National Vulnerability Database and Lovable acknowledged it was “not yet where we want to be in terms of security.”
- 170 / 1,645
- Lovable apps exposing user data, 2025
- 45%
- Veracode: AI code with a known flaw
- 95%+
- Veracode: AI code that compiles and runs
It’s the same pattern Veracode found across more than 150 models: code that runs almost every time and contains a known security flaw nearly half the time. Nothing about those 170 apps looked broken. They demoed perfectly. That is what makes the failures of a DIY build dangerous: almost none of them are visible at the point where a founder decides it’s done.
The ones we see most often:
Data without rules. The Lovable case in one line. A database that answers any question from anyone works exactly like a secure one until someone asks.
Secrets in the wrong place. API keys shipped inside the app, where any visitor can read them and spend your credit. The exposed keys in the Lovable apps were for AI services, billed by use.
A data model built for the demo. The first schema that makes the screens work is rarely the one that survives real customers, multiple teams or a second product. Changing it later, with live data, is where most rebuilds start.
No tests, so every change is a gamble. Without an executable definition of “working”, each new feature risks quietly breaking an old one. The GitClear data in our evidence review, with code churn nearly doubling since AI tools arrived, is what that looks like at scale.
Code nobody else can read. A codebase only its generating session understands can’t be handed to your first hire or survive due diligence. We made that argument at length in Code was always written for people.
None of these are exotic. Every one of them is something an experienced engineer checks without being asked, because they have been paged at three in the morning for it before.
The multiplier moved to experience
On 24 September, at Rails World in Austin, David Heinemeier Hansson went further than most. He traced the idea of the “10x programmer” back to a 1968 study and argued that the gap “between the worst programmer without these tools and the best programmer with them” is now around 1,000×. He said 37signals has gone “pencils down” on hand-written code, and that he wrote around 150,000 lines in August against a historical 30,000 a year.
Those are a practitioner’s estimates from a stage, not measurements, and they should be read that way. The 1968 study, by Sackman, Erikson and Grant, set out to compare programming online with programming offline and found, almost by accident, that differences between individuals swamped everything else: roughly 20:1 in coding time and 25:1 in debugging time between best and worst, in Steve McConnell’s summary, from a study with known methodological flaws. Jared Norman’s response to the keynote put the problem neatly: somewhere between the paper and the stage, 28:1 became 1,000:1. Lines of code, meanwhile, have never been a good measure of anything but lines of code.
So the number is not evidence. The direction is worth taking seriously, though, and it reconciles with the Cui result rather than contradicting it. At the level of a single task, AI narrows the gap: the less experienced developer closes more tickets than before. At the level of a product, it widens it, because the part AI doesn’t do is knowing what to build, in what order, and what to check before it ships. An experienced engineer directing agents gets the speed and keeps the judgement. An inexperienced one gets the speed and the 45%.
The Google trial in our evidence review found the largest gains on well-scoped work in codebases the tool can hold in view. A new product, specified properly before the first line is written, is exactly that kind of work. That is why a small senior team can now take on a scope that used to need a much larger one, and deliver it sooner, without the product being a demo in disguise. Whether the multiple is ten or a thousand, nobody has measured. For a founder, what matters is that solid execution is no longer reserved for companies that can afford a department.
Ideas are the currency again
The obvious objection deserves a full hearing. If anything can be built quickly, anything can be copied quickly. A clever product idea that would once have been protected by eighteen months of engineering is now protected by a weekend. On that reading, AI has made ideas worth less, not more, and Sivers’ $20 looks generous.
For the idea as a sentence, that is right. “Uber for dog walkers” is worth nothing, and it’s worth less every month. But that was never the idea worth having. The valuable version is the understanding underneath it: who has this problem, how they cope with it today, why the existing tools fail them, what they’d pay, and where to find the first hundred of them. None of that is in a model’s training data, because it lives in the heads of people who have done the job, worked in the industry or lived with the problem. It can’t be prompted into existence, and it can’t be copied by someone who has only seen your landing page.
Go back to the table. Sivers was right that an idea is a multiplier. What’s changed is the price of the thing it multiplies. For decades, good execution was scarce and expensive, so most multipliers never got used; the founder with the deepest understanding of a problem often lost to the one with the biggest engineering budget. Now good execution is within reach of far more founders, and the multiplier is back in play. Niche problems benefit most: a market too small to justify a team of ten at the old cost of building can be worth serving at the new one.
In a world where anything can be built, ideas are the new currency. More precisely: the problem you understand better than anyone else is.
How we work with this
Our process starts from the founder’s understanding, not ours. A Blueprint turns what you know about the problem into a written specification, a prototype and a fixed price in two weeks, so the scope is settled before the speed starts. After that, senior engineers direct the AI and decide what ships, and the unglamorous checks above, access rules, secrets, data model, tests and backups, happen whether or not anyone asks for them. The speed is the tools’. The judgement is the part we’re paid for.
Sources
- Sivers, Ideas are just a multiplier of execution (2005)
- Cui, Demirer, Jaffe, Musolff, Peng & Salz, The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers, Management Science (2025); abstract via Microsoft Research
- Semafor, The hottest new vibe coding startup Lovable is a sitting duck for hackers (2025)
- Palmer, CVE-2025-48757 (2025)
- Veracode, Spring 2026 GenAI Code Security Update
- Heinemeier Hansson, Rails World 2026 opening keynote (2026); quotations via Jared Smith’s write-up
- Norman, What About Rails? (2026)
- Sackman, Erikson & Grant, Exploratory experimental studies comparing online and offline programming performance, Communications of the ACM (1968); ratios via Steve McConnell’s summary
- Our earlier posts: What the research says about AI-assisted development and Code was always written for people
