What Happens When AI Writes Most of Your Code. A Real Project, Honest Results.

One developer. An AI execution partner. Five weeks. Here’s what we learned.

The pitch sounds almost too good: one developer, an AI agent as the execution partner, and a production-ready B2B SaaS at the end of it.

We didn’t set out to prove a point about AI-assisted development. We set out to build a platform a multi-tenant investment analytics tool for the energy storage market, replacing fragmented Excel workflows with live scenario modeling and real market data.

What we learned in the process changed how we think about AI in software development. Not because the AI was impressive. Because the failure mode was subtle and almost invisible until we built a system to prevent it.

The Setup

The client needed a production-ready B2B SaaS delivered fast. The domain was complex: energy storage investment decisions, regulatory data from multiple transmission system operators, NPV/IRR analytics, org-level access control.

The team: one Senior developer. The execution partner: Claude Code.

The stack was deliberate — Next.js 15 frontend, FastAPI backend, PostgreSQL with TimescaleDB, Celery and Redis for data pipelines, Keycloak for authentication. Not chosen for novelty. Chosen because each piece had documented justification and locked-in rationale before a single line of code was written.

That last part turned out to be everything.

The Real Risk in AI-Assisted Development Isn’t Bad Code

Most conversations about AI in development focus on code quality. Will the AI write something buggy? Will it miss edge cases? Will it generate something that looks right but isn’t?

These are real concerns. But they’re not the primary failure mode we encountered.

The real risk is drift.

In a traditional development workflow, architectural decisions accumulate in a developer’s head. They remember why a particular pattern was chosen, what the constraints were, what was considered and rejected. That context is implicit but present.

In an AI-assisted workflow with multiple sessions, that context resets. Every new session starts fresh. And without something binding that context in place, the AI re-litigates the same decisions from scratch — sometimes arriving at different answers, sometimes subtly inconsistent with what came before.

167 commits. Five weeks. Multiple sessions per day. Without a solution to the drift problem, the architecture would have fragmented.

The Solution: A Rulebook That Wasn’t a Document

The answer we arrived at was a binding architecture rulebook a structured file that traveled with every session, enforcing the decisions that had already been made.

Not documentation in the traditional sense. Documentation describes what was built. This enforced what could be built and what couldn’t.

Stack decisions were locked with their justifications. Scope boundaries were explicit. Feature rules prevented regressions. The Senior developer’s role shifted from writing code to maintaining the contract between intent and execution — reviewing what the AI produced against a written standard, not against memory.

The result: zero architectural drift across the entire build. Every session started with the same constraints. Every feature was consistent with the ones before it.

One developer. An AI execution partner. A rulebook that held them together.

What the AI Actually Did Well

Code generation within defined boundaries was genuinely fast. Given a clear specification and a constrained architectural context, the AI produced working code that required review but not reconstruction.

The volume of output was the real advantage. Tasks that would have taken days — data ingestion pipelines for six years of market data, regulatory computation workflows, multi-tenant authentication flows — moved in hours when the AI was handling execution and the human was handling judgment.

Documentation that typically gets deferred also happened. The architecture was documented as it was built, not reconstructed afterward. Methodology documentation was written to auditor standard — something that rarely happens in fast-paced development environments.

What Required the Human

The scope decisions happened before the AI touched anything. Reverse-engineering the incumbent platform, defining what was in the MVP and what was deliberately deferred, establishing the feature boundaries that kept the project focused — none of this was AI work.

Regulatory specifics required domain knowledge that no amount of context could fully transfer. Per-TSO capacity distribution calculations based on public regulatory data, built to produce auditable numbers — that required a human who understood both the regulatory framework and its implementation implications.

And the architecture rulebook itself required authorship. The AI enforced the contract. A human wrote it.

The Senior developer’s judgment was present in every commit — not in writing every line, but in defining what every line had to satisfy.

What We Delivered

A production-ready multi-tenant B2B SaaS in five weeks. Live market data, full investment workflows, a regulatory differentiator no competitor currently offers and a codebase the client owns end-to-end.

The Model, Honestly

AI-assisted development at this level works. The output was real, the timeline was real, the quality held.

But the conditions matter more than the tooling.

A binding architectural contract prevented drift. CTO-level oversight at every critical decision point prevented shortcuts from compounding. A Senior developer who understood the domain prevented the AI from optimizing the wrong things.

The AI was fast. The human was the reason fast was also right.

That’s the model. Not AI replacing the developer. One developer, operating at a different level of leverage, because the execution layer was handled.

The question for any team considering this isn’t “can we use AI agents?” It’s “do we have someone senior enough to write the contract the AI will execute against?”

If yes — the output is real.

Wamisoftware builds software products for startups and enterprise clients. We work on complex technical challenges where architecture and execution quality both matter.