I don't review the code. I play the result.

July 2026 · growordie · behind the scenes

Ten years as a software engineer, and an AI wrote every line of this one. Here is the honest split of who did what, and why I think the half I did is the half that matters.

Let me tell it the honest way, because the magical version is a lie. I kicked off loops, AI agents running on their own in a cycle, gave them a rough idea of the game I wanted, and they wrote the whole thing. All of it. The netcode, the collision math, the server, every single line. I have not written one line of this game, and I mean that literally. What I want to be just as clear about is the other half of that sentence: none of it shipped itself. The code existed; a game that real people could actually play did not, not yet.

Everything between those two things was me, and none of it was code. I created the Fly.io accounts and stood up the infrastructure. I bought the domain. I did the first deploy, and every deploy after it. When a loop wedged itself or wandered off, I was the one who unblocked it and pointed it back at the goal. I decided what we built next and what we would not touch. So the accurate version of the story is not "I walked away and a game appeared." It is: I never wrote a line of this game, and I did nearly everything else it took to put it in front of players.

I have shipped software for a living for about a decade. I know what it usually costs to hand-build a real-time multiplayer server, and here is the strange part: I did not pay that cost, and the thing that paid it was not a person. So my first reaction to reading through what existed was not pride, it was a small, specific vertigo: I was looking at something that worked, that I had shipped and owned, and that I had not written and did not fully understand.

Ten years in, on ground I had never walked

Here is the part I have to be honest about, because it is the whole point. I never sat down and read the code back. The decisions had been made in minutes, in a corner of engineering I have never really lived in, and they were calls I could not have made that fast, or in some cases at all. Reading them line by line was never how I was going to get my footing. So I did something else: I set out to understand how the thing actually works, not to audit how it was written.

A spatial hash for collision. Area of interest, so each player only receives the sliver of the world their camera can see. A hand packed binary protocol instead of JSON on the wire. Swept collision so a fast head cannot tunnel clean through a body between two ticks. I know these words now. I did not really know them then, not in my hands, not the way you know a thing you have shipped and debugged at 2am. Real-time web gaming is just not my domain. I have spent my ten years elsewhere, and it turns out ten years of engineering does not automatically transfer to a corner of the field you have never lived in.

That is an uncomfortable thing to write on your own game's blog. But it is the truth, and the interesting question is what you do next.

My instinct was never to rewrite it. It was to understand it well enough to advise.

I never reached to rewrite it

You might expect the reflex, for someone with my background, to be reclaiming it: slow down, open the engine, rewrite each subsystem by hand until I can defend every line. That was not my reflex, and pretending it was would be its own kind of lie. Mine was to understand it. Not to rebuild it so it would feel like mine, but to grasp how it works well enough to advise on it, to challenge the calls, and to steer where it goes. The instinct was to become the advisor, not to retake the keyboard.

And the more I understood, the easier that call was to hold. In this specific domain, real-time multiplayer, the AI (I have been building with Fable) reasons faster and, I will just say it, better than I do. Not vaguely better. It reaches for the right structure before I have finished framing the problem. When I sat with the choices it had made, once I actually understood them, they were the choices I would want to have made if I were three levels deeper in this field than I am. So insisting on doing it slowly by hand would not have made the game better. It would have made it later, and worse, and it would have been ego dressed up as rigor.

So I made a deliberate call: let Fable make the fast technical decisions in the domain it out-reasons me in, and move myself to the seat where I am actually the strongest person in the room. Call it PM. Call it technical advisor, the challenger, the EM. The label matters less than the honesty of it. For these decisions, today, I trust Fable more than I trust myself, and pretending otherwise would just cost the product.

So what do I actually do all day

This is where the story stops being "the AI built my game" and becomes something I am genuinely proud of, because the answer is: a lot, just not the part you would guess.

I play. Constantly. Nobody feels a game through a diff, you feel it with your hands, and so I am the one who notices that a turn feels a hair too sluggish at size, that a death reads as unfair, that the arena feels lonely or mean or good. I set the taste and the direction: what growordie is, what it refuses to be, which ideas are on-brand and which are clever but wrong. I challenge. When a technical choice gets made I push on it, I ask what breaks it, I make it justify itself, and sometimes that pressure changes the answer. And I own the thing. The product is mine, the calls about where it goes are mine, the responsibility when it is bad is mine.

And here is the part that surprised me most, the way I actually keep up with the engineering: I do not sit and read the raw code. That is the honest truth, and for a while it embarrassed me. What I do instead is question and choose. I ask why a decision was made, I make it justify itself, I pick between the options, I decide what we build next and what we refuse to. And my window into the technical decisions, the way I genuinely understand what is running under the hood, is these articles. The animated engine tour, the write-up of the bot that films the game, the deep dives on the spatial hash and the binary protocol: a real reason they exist is that I had them written so I could understand my own game without reading its source. A clear explanation of the swept collision check is how I learned the swept collision check. The blog quietly became my technical dashboard. If you have read those and thought "this founder really knows his netcode," the truth is I know it now because I made us explain it, in plain prose, to me.

The senior role did not disappear. It moved.

And I think code review is quietly ending, at least where I sit

Let me push on something, and I want to flag right up front that this is my opinion, from my seat, in an early-stage startup, and not a law I am handing to anyone. The line-by-line peer review, the ritual where another engineer reads your diff and signs off before it can merge, is starting to feel to me like a thing of the previous era. In my experience, in this particular context, it is losing its point.

Here is the reasoning, and you are welcome to disagree with it. Code review earned its place catching mistakes and spreading knowledge across a team of humans producing code at human speed. When most of the code is produced fast by something that reasons the domain better than I do, and when the genuinely scarce thing is direction and taste rather than one more pair of eyes on a for-loop, sitting a senior down to approve every line reads to me less like diligence and more like a comfort blanket from a workflow we have half outgrown. The bug that hurts a small startup is almost never "line 74 is subtly wrong." It is "we built the wrong thing, beautifully."

So if I started a new project tomorrow, I do not think I would run it on pull-request approvals. I think I would run it the way I run this one: question hard, choose deliberately, curate the direction and the product, and let the fast execution be fast. Keep all the pressure on the "should we, and is this the right shape" questions, and take it off the "is this line correct" question, because that second one is exactly the part I am now comfortable trusting the machine with, and checking by playing the result rather than by reading the diff.

I could be wrong, and I know how this sounds. I am not saying review is worthless or that people who review carefully are stuck in the past. In a big org, in regulated or safety-critical code, on a large team of humans, review clearly still earns every minute it costs. I am saying that here, at this size, for this kind of work, I would rather spend a senior's scarce judgment on where we are going than on approving how we got each line there. If that makes you want to argue with me, good. That is exactly the conversation I would like to be having.

The part I want to get exactly right

It would be easy to tell this story two dishonest ways. One is the hype version: "the AI does everything, humans are obsolete, I just watch." That is not true and it undersells what building this actually takes. The other is the defensive version: "AI is a toy, real engineers do it by hand." That is not true either, and I have a working multiplayer game that says so.

The real thing is quieter and, I think, more durable. It is a partnership with a clear division of labor. The fast technical execution, the stuff that is genuinely better reasoned by a machine that has read more real-time networking than I ever will, gets delegated, and I am glad to delegate it. But the direction, the taste, the judgment about what is worth building, the ownership of the outcome, those stay with me. The human keeps the wheel. The AI is an extraordinary driver on the straights, and I am the one deciding where we are going and whether we like it when we get there.

What shifted for me is not "senior engineer becomes unnecessary." It is that the senior job stops being "personally make every technical decision" and becomes "set the direction, keep the taste, challenge hard, own the product, and close your own knowledge gaps as fast as you can." That is a job I want. It is arguably a harder one. And I would not have believed how much I would enjoy it until I watched a game I never wrote get all the way to real players, carried there by the half of the work that was mine.

If you want to see the machine those decisions produced, take the animated tour of the engine, the same one I used to teach myself how it works. Or skip all of that and just go play growordie, which is the only review that has ever really mattered to me.