PlayersEngine is built by one person, but it isn't typed by one person. Most of the code is written with an AI coding assistant in the loop — for me that's Claude Code, but everything in this entry applies to the category. This isn't an ad and it isn't a doom piece. It's a description of the workflow I've converged on after months of daily use, including the parts that don't work.
The split: I plan, we execute, I judge
The single biggest lesson: AI assistance doesn't compress engineering, it compresses typing. The work moved, it didn't shrink. My days now divide into three distinct modes:
- Planning — mine alone. Before any feature, I write a short design doc: what we're building, what it must not do, edge cases, how it can fail, what it costs at scale. The assistant can critique these docs usefully, but the decisions have to be mine, because I'm the one who'll live with them.
- Execution — shared, heavily weighted toward the assistant. Given a good plan, it produces in an hour what used to take me a day.
- Judgment — mine alone again. Review the work, test it, decide whether it ships.
When projects go wrong with AI tools — and mine has, repeatedly — it's almost always because mode one got skipped. A vague prompt produces confident, plausible, wrong code. The doc-first habit isn't bureaucracy; it's the thing that makes the speed safe.
What it's genuinely great at
- Boilerplate and breadth. Route handlers, validation schemas, test scaffolding, config plumbing — the 60% of backend work that is pattern application, done instantly and usually correctly.
- Consistency. I keep convention files in the repo — naming, error handling, logging rules — and the assistant follows them more reliably than I do at 11 p.m.
- Tedious refactors. Renames and signature changes across a monorepo, the kind of mechanical change humans botch out of boredom.
- Tests. It will happily write the unglamorous edge-case tests I would have rationalized skipping.
Where it fails
- Cost blindness. It optimizes for code that works, not code that's cheap to run at scale. Left alone it will reach for the query that reads a thousand records to answer a question about one. Every data-access pattern gets audited by me, every time.
- Knowing what not to build. Ask for a feature and you get the feature — plus settings, abstractions and generalizations nobody asked for. Scope discipline stays human.
- Confident wrongness. The failure mode isn't obviously broken code; it's plausible code with a subtle flaw, delivered in the same assured tone as the correct stuff. The tone carries zero information. Only testing the work does.
Reviewing code you didn't type
My rule is borrowed from teams I've worked on: nothing merges that I couldn't defend line by line in a code review. In practice: small diffs only — if the change is too big to review properly, it was too big to ask for. Read every line, and rewrite or reject anything too clever to skim. Run the tests, then poke the thing by hand anyway, because tests written by the same author as the code share the same blind spots. And when something smells off, ask the assistant why it chose that approach — explaining flushes out hidden assumptions, exactly like with a human pair.
That discipline costs real time. It's still a fraction of what typing everything myself cost, and the alternative — merging code I don't understand into a platform only I maintain — is a loan against future me with loan-shark interest.
The meta-lesson: it amplifies your process
If I had to compress months of this into one sentence for another solo developer, it's this: an AI assistant amplifies whatever process you already have. If your habit is to think first, write things down and test ruthlessly, you'll go dramatically faster. If your habit is to improvise and hope, you'll produce impressive quantities of improvised hope. The tool doesn't supply discipline; it compounds whichever direction you were already heading. That's also why the written design docs matter beyond planning — they've become the project's memory. When I return to a service I haven't touched in two months, the doc tells both of us — me and the assistant — what the constraints were, and the conversation picks up where the thinking left off instead of starting from an archaeology dig.
The honest summary
An AI pair programmer turns a solo founder into a small team where one member is fast, tireless, well-read, occasionally and convincingly wrong, and entirely without stakes. The other member has to be the one with taste, context and accountability. Keep those roles straight and it's the biggest force multiplier I've ever used. Swap them and you're shipping a stranger's code with your name on it.