A few months ago a friend asked me how I was shipping so much. I had four projects in active rotation — a Rust framework, a CI runner, a programming language with a verifier, and a website that hosts arcker.org and was about to host two more domains. He’d been watching the GitHub activity. The math wasn’t adding up.

I had a half-honest answer ready: I write fast, I have help. True, but it elided the thing I’d been avoiding saying clearly, even to myself.

The actual answer is that AI is writing most of the code — most of the keystrokes, almost none of the decisions. I write briefs, I pick directions, I argue about choices, I review what comes back, I reject the variants that don’t fit the philosophy. The keystroke-level production is not mine. The judgment is.

That makes me one specific shape of engineer in 2026. The shape I’d like to describe, because it’s neither of the two shapes the public conversation is currently fixated on.

The shape most discourse paints

Three years into the current AI cycle, the loudest two positions are:

  • AI is replacing engineers — a panic narrative, usually from people selling a tool or a course. The argument is structural: a sufficiently capable model can do what a junior developer does, therefore the discipline is dying. The argument moves the same way every time.
  • AI is producing slop — a hostile narrative, usually from competent engineers reading derivative pull requests. The argument is empirical: the code coming out of AI-assisted workflows is shallow, copies common patterns badly, hallucinates APIs that don’t exist, and breaks under real scrutiny. The complaints are accurate. The PRs they describe really do exist.

Both positions are talking about the same kind of input: a developer who lets AI generate code without bringing much of their own to the conversation. AI as primary author. When that’s the shape, both positions are right at different ends of it.

There’s a third position, less discussed.

The yes/no amplifier

AI is not creating vision. It is not creating taste. It is not creating accumulated experience. What it does is externalize whatever you bring to it.

Bring nothing, you get derivative output. The hostile camp is correctly describing what they see when an engineer with no prepared design lets a model write code; the result really is shallow. The model is doing the only thing it can do — interpolate from training data toward what someone with that input might want next. That output is also what the panic camp points at when it claims engineers are replaceable, because if that’s the level of input, then yes, sure, the work is replaceable.

Bring twenty years of un-built ideas, accumulated taste, architectural reflexes, and a refusal to ship work you wouldn’t sign — and the same model finally lets you externalize them.

That’s it. That’s the rule. AI is a yes/no amplifier on whatever is already in your head.

What that looks like in practice

These are personal projects, built on my own time, published under my own name. None of them resemble each other.

lithair is a Rust framework where the source covers the wire — what a binary will do is described in the source, not deferred to a framework layer that does it for you. The bet there is twenty years old; the implementation became possible eighteen months ago.

cidx is a CI runner where the same byte string runs locally and in CI. The frustration was older than the tool by a decade. The fix was specific enough that I could only describe it because I’d held it that long.

A third project I haven’t shipped yet. Same shape: a problem I’ve been chewing on for years, finally externalized.

And one more, which is a different case. A language project, still in private development, that didn’t exist in my head before I started working this way. The idea emerged from the practice itself, recognizable to reflexes that did predate the tools. I mention it because it complicates the rule. The reservoir doesn’t only externalize old ideas; it also catches new ones the formed judgment can identify when they appear — ideas that would have passed me by without it.

None of these projects is derivative of what the model trained on. They couldn’t be. The model has never seen them — they either weren’t written down anywhere outside my head, or didn’t exist before the work itself. The AI is executing on a brief that comes from years of formed judgment, whether that brief was prepared in advance or recognized as it emerged.

Why I needed it

I’d been doing this work mentally for a long time. The blocker wasn’t ideas. It wasn’t taste. It wasn’t direction.

It was throughput. Externalizing a coherent system — a framework, a language, a runner — into committed code, with tests, with documentation, with a sustainable release shape — takes more time than I had after my day job. I’d start, get part of the way, lose momentum, return to a half-finished branch six months later and not remember why I’d made certain choices, and start again.

The throughput gap closed eighteen months ago. Suddenly the next sentence of code arrived in seconds rather than minutes. The drafting cost on a new module dropped by a factor I can’t quantify precisely but that I felt in my shoulders.

That’s the entire shift. Not what I want to build. Not how good my taste is. Just whether I get to ship the thing or whether it stays in my head.

I needed this. Not as a luxury. As an enabling necessity.

Where this goes

The current debate locks at the wrong level. Is AI replacing engineers or producing slop is a question about the artifact. The question that decides who’s still in the room two years from now is about the practice: when production stops being the bottleneck, what is a senior engineer actually for?

The answer the work has been pointing me at: the senior engineer is the one who holds the system in their head, refuses what doesn’t fit, decides what the next thing should be, and knows — with the kind of conviction you can’t fake — when an output is wrong even if it compiles. That’s a more interesting job than the one I was hired to do ten years ago. It’s also a much harder one to bluff.

For organizations the implication is specific. The teams intact in two years won’t be the ones whose senior people refused the tools, and they won’t be the ones whose junior people produced volume without supervision. They’ll be the ones that took the judgment work seriously enough to make it the actual job — explicitly, with structure, on purpose.

That’s the part I want to keep working on. It’s also why I think the current accusation — you, AI user, are the problem — is misdirected. The accusation aims at the production layer, which is about to be settled. The thing that won’t settle itself, the thing that’s going to determine who builds reliable software in 2028, is whether we knew how to grow the judgment that the production layer requires. I’d rather we started arguing about that one.

That’s the shape of work I’m describing — one specific configuration in 2026, the one where what was in your head finally gets to leave. Everything else is downstream.