99% of Our Code Is AI-Written. Here's What That Actually Means.

A few weeks ago I went back through three months of pull requests on the repo I work in most. I was looking for the last time a human had written more than five lines of a change by hand. I didn't find one.

That's where engineering at TinyFish is today, eight months after we decided to take AI-driven coding seriously instead of treating it as a novelty.

Where I actually started

My own relationship with AI-assisted coding goes back further than these eight months. Years ago, back when ChatGPT was still on GPT-3.5, I was already building real projects almost entirely through it: typing a specific question into a chat window, copying the answer into my editor, and finding out fast whether it worked. My first serious project, a Chrome extension, came together entirely through that loop, ask a narrow question, test what comes back, repeat until it works.

That early period taught me something most of the industry is only now catching up on: the bottleneck for building things well has moved. What matters is how precisely you ask, how fast you test what comes back, and whether you keep iterating past the first wrong answer. That's still, in a far more automated form, exactly how I work today.

When the agent fails, that's on me

The single mindset shift that mattered more than any individual tool came later, once coding agents were part of my daily workflow. Early on, when an agent failed at something, my instinct was to blame the agent. It couldn't do the task, so that was its problem. The shift that actually changed my output was flipping that around: if an agent didn't accomplish something, that was on me. I hadn't scoped the task well, or the prompt was ambiguous, or I'd asked for three things at once instead of one.

Once I started treating every failure as a signal to fix my own process instead of proof of a tool's limits, my results changed immediately, well before any underlying model got meaningfully better. This sounds obvious written down. It wasn't obvious to me at the time, and I don't think it's obvious yet to a lot of engineers picking this up for the first time. How an agent fails tells you more about how to work with it than how it succeeds.

Most tools have a shelf life, and that's fine

Once I was fully committed, the next problem was volume: frameworks, prompt packs, and skills arriving faster than anyone could evaluate them. This was six to eight months ago, before any shared playbook existed. Everyone on the team was independently discovering what worked, and the noise, especially around smaller skill libraries and prompt collections, was real.

My filter for what to actually adopt came down to two things. First, whether something had real traction in the community, not just a clever demo. Second, and more useful in practice, watching how fast a tool's value decayed as the underlying coding agent improved.

That second point is the one I'd pass on to any team starting this now. A skill or framework that patches a real gap in a coding agent's behavior is valuable right up until the agent's own harness absorbs that behavior natively. I installed a batch of memory-management skills early on that I never once saw trigger in real work, and eventually stopped bothering with them. I also relied on a smaller, lighter framework for months, specifically because it filled a genuine gap, until Claude Code's own harness absorbed what it did and the separate tool became dead weight. Some skills fire when they shouldn't, and in those cases plain Claude Code on its own default behavior outperforms the skill sitting on top of it.

The one exception that's held up the longest is Superpowers, which we rolled out company-wide early in this process. It's strong on planning discipline and ships a debugging workflow that's still useful in practice. I still have it installed, and it still fires occasionally, mostly in planning mode. Whether it keeps earning its keep as the base models improve is a real open question, not a hedge. Tools in this category are supposed to become unnecessary. That's what progress here looks like, and I'd rather watch a tool get absorbed into the harness than defend it out of habit.

What "99%" actually means

Here's the number that tends to get people's attention: about 99% of the code in our most active repo is now written by AI rather than typed out by a human.

That number means nothing without context. Before any of this, every line was written by hand, every line was reviewed by another human, and reviewing was almost always faster than writing. Review coverage was close to complete by default.

That's flipped. About 30% of AI-written code gets at most a glance from me. For the rest, review has moved from coverage to triage: I'm the backstop where a review agent's judgment runs out, mostly architecture and placement. Anything reversible and low-stakes, I let go entirely. That's calibration, and it's held up for months without incident.

This is highest on our most experimental, fastest-moving surfaces. Infrastructure code, where mistakes are more expensive and harder to walk back, has moved slower, though the direction of travel is the same.

The plainest version of the number: of the pull requests I've personally reviewed over the last three months on my most active project, zero had more than five lines written by a human.

From one horse to five

Eight months ago, working with a coding agent felt like riding a single horse. You could run one at a time, and you had to stay close to it, watching how fast it was going and in what direction, correcting course constantly. Today it's closer to running a small stable. I can point five agents at four different repos, headed in genuinely different directions, and manage them the way you'd manage a small team rather than operate a single tool.

What actually changed is how much control and trust I extend before something needs my direct attention. In practice, I've become something like an engineering manager for a team that happens to be made of models. I still have to brief them clearly and correct them when they drift. I no longer have to sit next to any one of them.

Where this goes

Two predictions, and one is a lot more certain than the other.

The more certain one: the mechanical part of engineering, the part that's mostly typing out well-understood patterns, is heading toward commoditization the way electricity did. Nobody generates their own power by hand anymore; it's just there, and everyone builds on top of it. A large share of what currently counts as software engineering, standing up a UI, wiring basic logic, is on the same path. The judgment that used to separate a senior engineer from a junior one, architecture sense, knowing what will and won't scale, knowing where the sharp edges are, is exactly the kind of tacit knowledge now getting absorbed into the models and the harnesses built around them. I'd expect most of that mechanical layer to be handled well by coding agents within the next year, not the next five.

The less certain one, and the more interesting one, is whether this changes the actual shape of software and not just who writes it. Software has already gone through several rounds of this kind of compression. Assembly gave way to object-oriented languages once teams got large enough to need shared abstractions instead of raw memory management. Object-oriented languages gave way to higher-level languages, open-source libraries, and eventually entire platforms and APIs, each round pushing what used to be someone's full-time job into something you just import or call. Every one of those transitions was gated less by whether the technology worked and more by whether people trusted it. Open source wasn't trusted at first either: somebody else's code, a bug you didn't write, a stranger to blame. It took years of use before pulling in a library became the default instead of the exception.

AI-written code is going through the same cycle now, just much faster, and capability was never really the constraint. What's missing is some version of the endorsement open-source libraries eventually earned: a way to look at a large, AI-generated module and trust it's solid without reading every line yourself. Once that exists, I'd expect entire services, not just functions or files, to become buildable blocks that small teams pull in wholesale. That changes who gets to build ambitious things. Projects that used to need an organization the size of NASA start to become possible for a five-person team.

The part I'm not sure about

There's a piece of this I keep turning over on my own, past where the industry-wide version of this argument usually stops.

If coding agents keep absorbing the judgment that used to require a senior engineer, does software engineering just become a higher-level version of the same thing, still built from code, just written by something other than a human? Or does the fundamental unit change shape?

I lean toward the second answer, mostly because of something I already notice today. The code coming out of these agents, even when it's good, often isn't something a human would want to sit down and read end to end. It's correct, it does its job, but it isn't written for a human reader the way a senior engineer writes for the next senior engineer who inherits the file. That works as long as a human is still checking the shape of things at a higher level, which is what I do now. It stops working once volume keeps scaling the way it has for us. At some point I'd expect a different fundamental representation to emerge, something people can still inspect and reason about and build on top of, but that isn't source code in the sense we mean it today. What that looks like, I don't know yet. I don't think anyone does. But I'd bet on it existing before I'd bet on today's code, at today's volume, staying human-reviewable indefinitely.

None of this shrinks the job. Every previous round of this kind of compression in software history left the field needing more engineers, working on harder, more ambitious problems. Assembly gave way to languages gave way to APIs gave way to platforms, and at each step the field ended up needing more people, pointed at bigger problems. I don't see a reason this round is different. The five agents I'm running today across four repos aren't a replacement for a team. They're the reason a team can go after something bigger than four people could otherwise build.

That's the part I'm most confident about, more than any single number in this post. How fast the mechanical layer fully commoditizes, what a non-code representation of software might look like: I'm watching that in real time along with everyone else. Eight months ago I wouldn't have predicted we'd be here. I'm not going to pretend I know exactly where we'll be eight months from now. I just know which direction to keep pushing.