AI-assisted development: a reality check
Two real randomized controlled trials, three years apart, pointing in opposite directions — and what actually explains the difference
4 min read
"AI means a solo founder can build in weeks what used to take months" is one of the most repeated claims in 2026 SaaS content, and it's exactly the kind of claim this course's methodology exists to check rather than repeat. The honest answer is more interesting than either the hype or a flat debunking: two of the best-designed studies on this question, both genuine randomized controlled trials rather than surveys or vendor claims, found opposite effects — and the difference between them tells you more about when AI assistance actually helps than either headline number does on its own.
The 2023 finding: a large, real speedup — on a narrow, well-defined task
A field experiment run with GitHub Copilot (published by Microsoft and MIT-affiliated researchers, Peng et al., 2023) had software developers implement an HTTP server in JavaScript as fast as possible, randomly assigning some access to Copilot and others not. The Copilot group finished 55.8% faster on average — about 1 hour 11 minutes versus 2 hours 41 minutes for the control group — with less-experienced and older programmers benefiting most. [Established] — this is a genuine randomized controlled trial with a clearly disclosed methodology, published as a peer-reviewed working paper (arXiv 2302.06590).
The task matters as much as the result: implementing a well-specified, self-contained HTTP server is close to ideal conditions for a code-completion tool — a bounded, well-documented problem type the model has almost certainly seen thousands of similar examples of in training, with no existing codebase context to reconcile against and no ambiguity about what "done" means.
The 2025 finding: a real slowdown — on realistic, messy work
A 2025 randomized controlled trial from METR — the same organization that runs frontier-model capability evaluations for AI labs — took a very different task: 16 experienced open-source developers (roughly five years' average experience with the specific, large, mature codebases they were tested in) completed 246 real issues from their own repositories, randomly assigned to allow or prohibit AI tool use (primarily Cursor and Claude 3.5/3.7 Sonnet) for each task. Allowing AI tools increased completion time by 19% — the opposite of the expected direction. [Established] — a genuine RCT with disclosed methodology, published as a preprint (arXiv 2507.09089); the paper's authors themselves flag that some experimental artifacts can't be entirely ruled out, but the effect held up across their robustness checks.
The more striking finding isn't the 19% number itself, it's the gap between measured and perceived result: before the study, the developers predicted AI would make them about 24% faster; after finishing, having just been measurably slower, they still believed AI had made them about 20% faster. The paper attributes the actual slowdown to workflow friction — prompting, reviewing AI-generated suggestions, and correcting output the developer didn't fully trust — costing more time than it saved, in a context (a codebase the developer already knows deeply, with established conventions an AI tool has to be steered to follow) where the tool's suggestions were less reliably correct than in a from-scratch, well-specified task.
Reconciling the two, mechanistically
These aren't contradictory findings about "does AI help with coding" — they're consistent findings about a variable most AI-coding content skips past: AI code assistance helps most on bounded, well-specified, low-context-dependency work, and helps least (or actively hurts) on work embedded in an existing system the AI has to be correctly steered through, where verifying its output costs real expert time. A solo founder building a new SaaS product from scratch sits closer to the first condition in the earliest weeks — new project, few existing conventions to violate, mostly self-contained features — and drifts toward the second condition as the codebase grows, integrations accumulate, and "does this change break something three files away" becomes a real question requiring real verification time. [Directional] — this reconciliation is this course's own inference connecting two disclosed studies, not itself a finding either paper states; it's offered as the most defensible read of why two credible RCTs three years apart point opposite ways, not as an independently measured claim.
What this actually means for your timeline
The honest, sourced version of "AI speeds up solo SaaS development" is: probably true and meaningful in the earliest, greenfield weeks of a new product — closer to the 2023 study's conditions — and much less reliably true, possibly false, once the product has real complexity and existing conventions to maintain — closer to the 2025 study's conditions. Neither study measured a solo founder building and maintaining a SaaS product over months, which is its own gap this course won't paper over: nobody has yet run the specific RCT that would answer your exact question, and any specific "AI cuts SaaS build time by X%" figure you encounter for that exact scenario is extrapolating past what's actually been measured. [Speculative] for any such extrapolated figure.
The practical takeaway that does hold up: don't let AI-assisted velocity in the first two weeks of a greenfield build convince you the same multiplier applies once you're six months in with real users, real integrations, and a codebase that isn't fresh anymore. Budget your timeline on your own historical pace for maintenance-and-integration work, and treat any AI-driven speedup there as a bonus to verify for yourself, not a plan to bank on.
Up next
Pricing models
Per-seat, usage-based, and flat rate — and the one question that actually determines which fits
4 min