Something changed in the way I write software, and I do not think it is going back.

A year ago the code in my editor was mostly mine. I typed it, I owned every line, and the slow part was writing it. Today a large part of it arrives already written. I describe what I want, a model reads my request and my repository, and a few seconds later there is a diff on my screen. I read it, I shape it, I keep what is good and I drop what is not. The typing stopped being the hard part. The reading became it.

That is why I am building Ziggity, a fast terminal client for Git. Not because Git needed one more interface, but because AI has turned the diff into the place where engineering now happens.

The new scarce skill is not writing code. It is knowing, fast, whether code deserves to exist.

This is not a small change. It is a change in what the job actually is.

I have shipped enough software to be suspicious of hype, so let me be precise. The machine did not replace me. It moved the work. The center of gravity of my day used to be implementation. Now it is verification. Two people I deeply respect saw this coming from opposite directions, and together they draw the whole picture.

The floor is shifting under us

Peter and the art of shipping fast

For about seven years I worked at PSPDFKit, where Peter Steinberger was my boss. He founded the company and brought me in to look after the Android app, which gave me a long, close look at how he thinks about building and shipping software. Peter has one of the sharpest product instincts I have ever met, and a bias for shipping that borders on physical.

Lately he went further than most of us dared to. He built OpenClaw, an AI agent that went from a weekend experiment to one of the most starred repositories on GitHub in a matter of months, and then he joined OpenAI. The Pragmatic Engineer profiled him under a title that says the quiet part out loud: “I ship code I don’t read”.

Read that again. A world class engineer, on record, shipping code he does not read, at what he calls inference speed. That is not laziness. It is a bet that throughput now matters more than authoring every line by hand, and that the model is good enough, often enough, to make the bet pay. I do not fully live there yet. But I understand the direction, and I think Peter is early, not wrong.

Antirez and the flood of code

From the other side comes Salvatore Sanfilippo, antirez, the creator of Redis and one of the most careful programmers alive. If Peter is the accelerator, antirez is the person checking that the car still holds the road.

He has been writing about this shift with unusual honesty. In “Coding with LLMs in the summer of 2025” he describes frontier models as tools that extend and amplify a strong programmer. In “Automatic programming” he makes the point that matters most here: the same model, on the same task, produces wildly different results depending on the human guiding it. And in “A new era for software testing” he turns to the obvious consequence, that when code arrives this fast, the way we check it has to change too.

Put those together. A capable model can produce more correct code in five minutes than a person can carefully read in an hour. The bottleneck is no longer how fast we can write. It is how fast, and how well, we can verify.

The real bottleneck moved

This is the whole thesis of the post, so let me state it plainly.

When AI writes the code, verification is the new implementation.

The scarce resource is no longer typing speed. It is judgment applied quickly. It is the ability to take a large diff you did not write, understand it, trust the parts that deserve trust, catch the parts that do not, and put your name on the result. The new frontier is not producing more code. We already have infinite code. The new frontier is keeping control of that production without quietly handing our judgment to the machine.

And that is exactly where tools matter.

Verification is the new implementation

If reading the diff is the job, then the tool that shows me the diff is my primary instrument. It should be instant, it should never block me, and it should get out of the way. That is the reason Ziggity exists: a fast terminal client for Git, built in Zig around the rhythm of reading and approving change.

I did not build Ziggity to push back against AI. The opposite. I built the kind of cockpit you want when a machine is generating a lot of code and you are the one responsible for it.

Reading at the speed of writing

Speed here is not a vanity metric. If your review tool stutters, you review less, and you trust more than you should. Ziggity is a 1.9 MB static binary that starts in about 3.6 milliseconds and sits at 8 MB of memory when idle. It drives your existing git, no libgit2, no runtime.

Long operations never block the interface. Fetch, pull, push, merge, rebase and bisect all run in the background while you keep moving.

The incoming count updates on its own while you keep reading. Nothing blocks, ever.

You read a diff the way you actually think, not one forced line after another. Stage or discard single lines, split the view, and select any text with the mouse to copy it straight off the screen, over SSH too.

Drag to select, release to copy. The mouse works everywhere, even the graph and the dialogs.

Stage or discard a single line. When a model touches ten files, this is how you keep only the parts you actually approve.

Diff any two refs, in git’s own colors, with word level highlighting on the parts that changed.

And when the change is large, which with AI it often is, the history and the graph are one keypress away.

The real git log --graph DAG, so a machine generated branch topology reads at a glance.

The point of all this is simple. The faster and calmer the reading, the more of the AI’s output you can actually verify, instead of rubber stamping it.

Embrace the machine, keep the judgment

Here is where I part ways with the people who treat AI as a threat to resist. I think that fight is already lost, and losing it is fine. The future belongs to developers who can work with AI without surrendering their judgment. I would rather be in that group and be very good at it.

So Ziggity leans in. Press one key in the commit dialog and it drafts your commit message from the staged diff, a subject in your recent style and a body that explains the change. It never blocks you, it never overwrites what you typed, and the moment you start editing it steps aside.

ctrl+g drafts the subject, then the body to match. The machine proposes, you dispose.

Look at the loop in that demo. The model writes, you read, you adjust, you approve. That is verification promoted to a first class action, not an afterthought squeezed in at the end.

Ziggity ships no model and no API key of its own. It points at a command you choose, and everything about the provider and the subscription lives in that tool. The one I reach for is pi, a beautifully small terminal agent by Mario Zechner. If that name rings a bell, it should. Mario created libGDX, the framework I built games on years ago, and following his work has been one of the quiet constants of my career. pi talks to just about every provider through an API key or your existing subscription, installs in one line, and does one job extremely well. Pairing Ziggity with pi feels exactly right, two small sharp tools instead of one heavy one.

Your name is still on the commit

There is one line that does not move, no matter how much the machine writes, and it is the author line. When you commit, your name goes on it. Your responsibility goes on it. A pull request you approved is a promise you made to your team, and no model signs it for you.

A real commit editor: the AI can draft the message, but you write the final word, and the author line is yours.

This is why I keep insisting that verification is the professional act now. Anyone can generate code. Reading it well, producing high quality software with AI, and standing behind it, that is the craft that still belongs to us.

Closing: fast tools, sharp eyes

Let me pull the threads together, because they belong together.

The rise of AI did not make developers obsolete. It moved the hard part from writing to reading, from implementation to verification. Peter showed me how far throughput can go. Antirez showed me why the human in the loop is still the whole game. The synthesis is not to slow the machine down. It is to sharpen the eyes we bring to it, and to build tools worthy of that job.

It is not a coincidence that so much of this new generation of fast, careful tooling is being written in Zig. Zig is small, fast, honest about what it does, and it turns out to be a wonderful language to build with AI in the loop. The clearest proof is Ghostty, the GPU accelerated terminal by Mitchell Hashimoto, the cofounder of HashiCorp who gave us Terraform and Vagrant and then, of all things, built a terminal. Ghostty is written largely with AI, in Zig, and Mitchell is refreshingly open about how. If you want to see what serious AI assisted engineering looks like, watch him talk about how he builds Ghostty and about his agentic coding workflow. It is the same story from a master: let the machine produce, keep your judgment on top.

That is the world I want to work in. Machines that write at inference speed, humans who verify at the speed of thought, and small fast tools in between. Ziggity is my contribution to that world, and pi is the companion I trust right next to it.

Yes, the donut spins. Some things you build just because they make you smile.

If any of this resonates, try it on a repository full of AI written diffs. Ziggity is open source and lives at ziggity.dev and on GitHub. Install it, review one real change, and feel how different verification is when the tool disappears.

And if the thesis feels right, share it with one developer who is staring at bigger diffs than they can comfortably review.

Do you have questions, or suggestions? Ping me on Twitter @simonarpe and let’s talk.