I joined a used-car export company as the only engineer.
There was no existing codebase. No engineering team. Just a mandate: build an internal operations platform for sales, inventory, and back-office work — and get it into production.
Four months later, the system was live.
Over 75 working days, I opened 153 pull requests.
This is how I structured the process.
The problem with "AI-assisted" development
Most discussions about AI-assisted development focus on code generation speed.
That misses the harder question:
Who decides what to build, and who signs off that it works?
If you hand those decisions to AI, you get fast output with no clear ownership. If you keep every decision entirely with yourself, you become the bottleneck — one person trying to do every kind of thinking at once.
I drew a different line.
The boundary
On the human side:
- Requirements: what the system should do, and what it should not do
- Acceptance criteria: what "done" actually means
- Production judgment: whether something is safe to ship
On the AI side:
- Implementation: writing code that satisfies the criteria
- Code review: flagging issues and suggesting alternatives
- Repetitive testing: generating test cases and running assertions
This sounds clean on paper.
The hard part is holding the line.
When Claude Code suggests an approach, it is tempting to accept it and move on. But that is exactly where judgment can slip.
The question is not only "does this code work?"
The better question is:
Does this solve the right problem?
That question stays on the human side.
What the workflow actually looked like
Every feature started as a GitHub Issue.
Not a vague task. A scoped description with acceptance criteria written in plain language — clear enough that I could read it the next morning and still know exactly what "done" meant.
From there:
- Claude Code drafted the implementation.
- I reviewed the pull request, not mainly for syntax, but for whether it matched the Issue.
- Claude Code generated test cases against the acceptance criteria.
- I made the final call on whether to merge.
The PR count climbed quickly because the Issues were small and specific.
A 153-PR codebase does not mean 153 features. It means 153 well-scoped units of work, each with a clear start and end.
What AI handles well
AI worked well for tasks where the expected output could be checked against a clear standard:
- Boilerplate and scaffolding
- Cloud Run configurations
- Argo CD manifests
- Pub/Sub wiring
- GitHub Actions workflows
- Error diagnosis from stack traces
- First-draft implementations where the shape of the solution was already clear
- Test generation against explicit acceptance criteria
The common thread is verifiability.
When the standard is clear, AI can move very fast.
What AI handles poorly
AI was much weaker at the parts that required business judgment.
It should not decide scope.
"Should this be in the system at all?" is not an AI question.
It should not judge operational readiness.
"Is this safe to cut over to production?" requires business context, operational risk awareness, and responsibility.
It also does not reliably notice what is missing.
The system does not know what it does not know about your domain.
These are the moments where solo engineers lose time if they treat AI judgment as equivalent to their own.
The numbers in context
153 pull requests over 75 working days is roughly two PRs per day.
That includes days with meetings, training, firefighting, and production support.
It is not a speed record.
It is a measurement.
I started tracking because I wanted to know whether this process was actually faster — not just whether it felt faster.
The production cutover happened in month four.
The system is running.
The measurement held.
What this means for teams
Most AI adoption conversations ask:
How much faster can one person go?
I think the more interesting question is:
What happens when an entire team holds this boundary consistently?
Implementation gets faster.
Review gets faster.
Repetitive testing gets faster.
But judgment stays where it belongs.
The bottleneck shifts from writing code to deciding what to write.
That is where the bottleneck should be.
The tooling matters. But the real change is not the tool.
The real change is the operating model.
AI-native development is not about letting AI take ownership.
It is about designing a workflow where AI accelerates execution, while humans keep responsibility for direction, judgment, and production risk.
That boundary is what made 153 PRs in 75 working days possible.
And more importantly, it is what made the system shippable.
Top comments (0)