I have been building software and web systems since 1995. That matters here, but not as a credential to wave around. It matters because the AI development story is easy to tell badly.
The lazy version is: AI made me faster.
The more accurate version is: AI changed the economics of certain software work when the architecture, boundaries, review process, and deployment path were already clear.
That distinction is the whole article.
The first real signal
Before taking on a much larger six-month build, I had already seen the same pattern across a series of smaller projects. Roughly 12 to 20 of them sat in the 15 to 30 hour traditional-effort range. Many landed around an 8x to 12x multiplier, especially where research was part of the job.
There was also a larger project I would normally have put somewhere around 80 to 120 hours. I completed it in about 18 hours. That was not a toy result, but it was still inside a scope where one person could hold the shape of the work in their head.
The proof point that changed my planning was a narrower business application that I would have estimated at roughly 200 hours the old way. I built it in about 25 hours.
What kind of project was it?
This is where the boundary matters.
The 200-hour project was production-grade client work. It was not a throwaway prototype. It was a real business tool, built for actual use. The easiest description is an Excel sheet made into a proper web application so it could support an existing workflow.
But it was also narrow. Small user base. Low audience risk. Clear purpose. Very little stakeholder complexity. In practice, close to an audience of one.
It also did not carry the full delivery overhead of a broader commercial build. The feedback loop was unusually light. There was no round of stakeholder review. No "while you are there" requests. No scheduled workshops. No support desk of opinions arriving in week three with helpful timing.
I would not claim I could have delivered the same thing in 25 hours with a normal feedback cycle, review process, and change requests. That would be a different project.
That does not weaken the result. It tells us what we were measuring.
The multiplier was not typing speed
Claude Code did not make me faster because I suddenly became better at typing controllers, forms, entities, templates, migrations, and tests. Typing was not the bottleneck.
The leverage came from turning well-understood software work into a managed production process:
- a defined stack
- clear conventions
- small enough scope
- fast implementation loops
- review discipline
- deployment habits I already trusted
The AI was useful because it could operate inside a structure. Without that structure, it is very easy to get a lot of code quickly and then spend the saved time discovering why the code should not have existed in that shape.
That is the old software problem with a new interface. We have been producing mess faster for decades. The tooling changes. The bill arrives with familiar handwriting.
Why I am not making this an AGI article
I am not very interested in whether this proves anything about AGI, whether one model is 7 percent ahead on a benchmark, or whether coding is dead. Those arguments rarely help me estimate, build, review, or deploy software. The useful question is simpler: what changed in the economics of building a real business application?
For me, the answer was clear by late 2025. In the right project shape, with enough engineering experience around it, the same kind of work no longer cost the same amount of time.
The boundary is the point
The strongest fit was not "all software". It was web-based business software. CRUD-heavy tools. Internal systems. Admin interfaces. Workflow applications. Places where the business rules matter more than algorithmic novelty and where the experienced developer already knows the architecture the work wants.
That is not a small category. A large amount of useful business software lives there.
But the multiplier depends on conditions. Clear scope helps. Low design uncertainty helps. Low stakeholder count helps. Existing conventions help. Production experience helps a lot.
The moment you add more people, more risk, more feedback, more legacy data, more design uncertainty, and more hidden requirements, the number changes.
The larger bet
The 200-hour to 25-hour result was enough for me to trust the direction. It was not enough to declare victory over software delivery.
The next question was harder: what happens when this method is applied to a six-month production build with real feedback, legacy data, design churn, infrastructure, security, and all the ordinary details that do not appear in the first optimistic plan?
That is the series I am writing now.
The first 8x was real. The useful work is finding out where it holds, where it degrades, and what process makes the difference.