A Year of Shipping Real Software With AI Coding Agents

For the last year I've been building a production web app: the system that runs my kickboxing school, used every evening by members and coaches across several locations. A bit over a thousand commits. Most of them written together with an AI coding agent in my terminal.

This isn't a "10x developer" post. AI didn't make the hard parts disappear. It moved them. Here's where they went.

1. The agent is exactly as good as the context you give it

At the start I treated the agent like a very fast autocomplete: describe the task, get code. The code compiled and was often subtly wrong for this project. It ignored conventions, re-invented helpers that already existed, and made architecture decisions I'd already rejected.

What fixed it wasn't better prompts. It was documentation the agent reads before every session: what the project is, the stack, the conventions, the decisions and why they were made. Writing that down felt like overhead. It turned out to be the best investment of the year. As a side effect, the project is now better documented than anything I wrote in my agency days, because the documentation is actually being read, every single day.

Documentation used to be for the next developer. Now the next developer shows up every morning.

2. Small tickets beat big prompts

"Build the booking system" produces a plausible-looking mess. "Add a waiting list to bookings, here's the ticket, here are the edge cases" produces something I can review in ten minutes.

So my workflow became boring on purpose: every change is a ticket, a branch, a merge request, a review, a merge. The same discipline you'd use in a team, because effectively I am running a team now. One member is extremely fast, never tired, and occasionally very confidently wrong.

3. "Done" means I've seen it work

The most dangerous sentence an agent says is "I've implemented the feature." Implemented isn't working.

So every feature has to prove itself: tests that pass, and screenshots of the actual UI in light and dark mode, on a phone-sized screen and a desktop. I have a separate QA agent whose only job is to click through the app like a user and report what it sees, including the parts nobody asked about. It finds things I'd only have found when a coach called me at 17:45.

4. When code gets cheap, architecture gets expensive

Generating code is now nearly free. That sounds like it makes design less important. It's the opposite.

When the agent writes a feature, it copies whatever pattern it finds nearby. If the nearest example is a 400-line API route doing validation, business logic and database calls all at once, you get another one. And then another. So I spent real time refactoring toward clear boundaries: thin routes, business logic in plain functions you can test, storage and third-party services behind interfaces. Not for the sake of purity, but because a codebase with good examples teaches the agent to write good code. The structure is the prompt.

5. Keep the dangerous buttons human

The agent can write code, run tests, open merge requests and read logs. What it never does is ship on its own initiative: production deploys are a manual step that only happens after I've looked at what's going out and said "go".

That isn't distrust for its own sake. When something breaks in production, real people can't book their training, and someone has to be accountable. That someone should have read the diff.

6. Rituals beat memory

Long sessions drift. The agent forgets what we decided two hours ago, and honestly, so do I. What helped was turning recurring routines into small reusable commands: a morning stand-up that summarizes open tickets and what changed since yesterday, an end-of-day stand-down that writes down what's done and what's next, a triage routine for errors from the logs.

None of this is clever. It's what a good team lead does, written down so it happens every time.

7. Write for humans, especially the changelog

My users are coaches, not developers. So every release gets a changelog entry in plain language: what's new, what changed, what's fixed, in the words they'd use. The agent drafts it, I rewrite it.

It's become the most useful document in the project. It forces every change to answer one question: what does this do for a person? If I can't explain a feature in one sentence to a coach, it usually isn't finished.

What's still hard

• Confident wrongness. The agent rarely says "I don't know." The answers that cost the most time were the ones that sounded right.
• Review fatigue. Reading code you didn't write is tiring, and it's tempting to skim. The bugs live in the parts you skim.
• Scope creep. Ask for one fix and you may get three "improvements". Small tickets and a clear "only change what's asked" help, but you still have to watch for it.
• Messy real-world data. No agent knows that years of hand-entered data contain every formatting mistake humans can make. You find out in production, and you learn to validate at every boundary.

The actual takeaway

AI didn't replace the skills that matter. It made them matter more: knowing what to build, breaking it into pieces, recognizing good code, and taking responsibility for what ships. Typing was never the bottleneck. Thinking was, and still is.

The difference is that one developer with good habits can now build and run what used to take a small team. That's not magic. It's a lot of discipline, documented well, with a very fast collaborator.