Nothing Is Certain

A few months ago I built a content workbench for the learning team at work. It was a good idea, well-executed. The content people adopted it quickly and started doing more, and better, work than before. By any reasonable measure, it was a success.

It was also the first project I handed over that didn’t feel like mine. I had created the initial site and shaped the concept, but the building itself had been Claude’s work as much as it had been anyone’s. Other engineers carried it forward from there. The impact was real. The sense that I had built something was not. That distinction used to not exist.

Something had changed, and I was only starting to understand what.

The Ratio Flipped and Nobody Sent a Memo

For most of my career, engineering was roughly 20 percent hard thinking and 80 percent execution. We spent our days wrestling with syntax, boilerplate, and the tedious connective tissue of the happy path. Deep, concrete knowledge of languages and frameworks was what separated a senior engineer from a junior one. You earned your seniority by knowing the platform in your bones, the quirks, the edge cases, the patterns that only revealed themselves after years of daily contact.

That ratio has inverted. We now live in a world of 80 percent hard thinking and 20 percent execution. Andrej Karpathy calls this the Loopy Era, a time of AI agents operating in closed loops, writing, testing, failing, self-correcting. The name is apt. What it doesn’t capture is how disorienting it feels to be the person standing next to the loop, watching it spin.

Much of what made a senior engineer senior is dissolving. The deep platform knowledge, the muscle memory of syntax, the hard-won familiarity with a framework’s rough edges. What remains is the abstract work: problem thinking, scaffolding, architecture. The role has quietly shifted from builder to something closer to a principal engineer or a PM. You are managing a team of eager, careless, medium-talent workers who will construct a catastrophe at the speed of light if your instructions aren’t precise. They never get tired. They never push back. They also never ask whether the thing they’re building is worth building. That question is yours now, and yours alone.

Engineers need to learn to step outside the loop of those AI models, or they become the bottleneck in their own workflow. It is a surreal thing, watching an agent do what you did for a decade. If your identity was “coder,” that identity is eroding. If it was “problem solver,” you are probably thriving. Most of us were some mixture of both, and the ground between those two identities is where the vertigo lives.

A Teacher That Might Also Be a Replacement

I have been writing Flutter for six years. Not for work, for myself. Side projects, personal apps. I built Activities Matter and Colloquies and several internal tools along the way. I have more than a decade of experience in tech, and I was able to transfer much of that knowledge into Flutter, genuinely enjoying the journey of learning a new platform on my own terms. No mentor, no team. Just stubbornness and curiosity.

Then, around December 2025, something shifted. Sonnet and Opus through Claude Code started writing better Flutter code than me.

Not just faster. Better. The AI introduced patterns and concepts I hadn’t encountered, architectural approaches I wouldn’t have reached on my own. The strange thing is that I learned from it. The tool that threatened to make my skills irrelevant was also, in the same moment, making me a stronger developer. My teacher and my potential replacement arrived in the same package.

I still write Flutter. I enjoy it more now, if I’m honest. With AI it feels like having a small team supporting me in what has always been a solo adventure as an app developer. But I’ve become deliberate about where I focus. I review selectively, mostly plans and logic. UI and actual implementation are trivial at this point. The work that matters is upstream of the code.

The days I forget that are the days that feel hollow. Not because the output is bad, but because, as with the content workbench, I can’t feel that I did the work. I become QA for my own AI. I’m verifying rather than creating. Those are the moments where I remind myself why I started the side projects in the first place and return to something more mindful and deliberate. The craft is still there, but it takes intention to reach it.

The Lowest Price Wins the Argument

There is a broader version of this hollowing-out happening at scale, and it has a familiar shape. I think of it as the Amazon-ification of software.

We look at companies like Amazon or Walmart and see a model that works on paper: lowest prices, maximum efficiency, absolute market dominance. We also see the human cost, the workers on food stamps, the warehouses optimized for throughput rather than dignity. Amazon doesn’t just compete with smaller businesses. It watches what sells on its own platform, copies the successful products, and launches its own line. Customers don’t have loyalty to the original brand. They buy the Amazon version because the price is lower. The small business that proved the market gets pushed out of the market it proved.

And yet the lowest price wins the argument for most consumers, most of the time. I know this because I am one of those consumers. I critique the race to the bottom from a position of comfort, then choose the cheapest option myself when it’s my money. I buy IKEA furniture. As a student, a lower-priced bed and bookshelf was a no-brainer, and the logic never fully left. It is difficult to hold moral high ground when your feet are on the same floor as everyone else’s. And the uncomfortable truth is that lower prices are often what enable more people to have better lives in the first place. The critique and the benefit sit right next to each other, impossible to fully separate.

If we apply this logic to software, the trajectory is visible already. Code gets cheaper. Apps get faster to build. Products get more efficient, more abundant, and more interchangeable. We already see it. Apps look the same and feel the same. Real products too: cars, phones, furniture. When everybody optimizes for everyone, the result is bland. Not broken. Not ugly. Just indistinguishable. The efficiency is real and the soul is missing.

We still watch humans play chess. Machines won that war decades ago, conclusively and permanently. Yet millions of people still care about the weight of a person making a choice under pressure, the trembling hand, the clock running down, the decision that could have gone either way. That caring is not rational. It might be the most important thing about us.

The Things That Don’t Compress

Napoleon Bonaparte famously waited three weeks to open his mail. By the time he broke the seals, many of the urgent problems had resolved themselves or become irrelevant. In the Loopy Era, there is wisdom in this. Half of what feels urgent is noise. A new protocol drops, a new CLI agent launches, and the discourse insists you must learn it now or be left behind. Wait a few weeks. See what survives.

But there is a difference between filtering noise and losing signal. Some things resist compression, and those things are worth paying attention to.

I train for triathlons. It is, by a wide margin, the most humbling part of my life compared to the AI-accelerated world of software. There is no autocomplete for your lungs. No agent that swims your laps or runs your miles. If I haven’t trained, I am slow, and no tool on earth changes that. The body doesn’t care about my productivity stack. It only knows what I have actually, physically done.

There is something clarifying about that directness. In a world where so much of my work has become abstract, orchestration, intent, architecture, the blunt physicality of training reminds me what effort used to feel like. Not effort as in “I worked hard on this prompt.” Effort as in my legs hurt and I kept going.

Cooking my own dinner is the smaller version of the same impulse. I wrote about this before, and the feeling hasn’t changed. It is not efficient. A meal kit or a delivery app would save me thirty minutes. But those thirty minutes are mine in a way that optimized time never is.

The Oscillation

Some days this all feels fine. The tools are better, the work is more interesting, the possibilities are wider than they have ever been. I look at what I can build now compared to five years ago and it feels like a genuine expansion of what one person can do.

Other days it is pure dread. The title on my contract says Engineering Manager, but I don’t have direct reports anymore. I spend my time helping people use AI and shaping what our next AI-native teams might look like. The role is real and valuable and completely undefined. Anything is possible. Nothing is certain.

I don’t know how to resolve the contradiction between loving the craft and watching the craft become something I don’t always recognize. Between benefiting from the same optimization I critique. Between feeling more capable than ever and less sure of what that capability is for.

I suspect the answer, if there is one, lives somewhere in the willingness to stay with the uncertainty rather than rushing to resolve it. To be mindful about the speed. To keep choosing, deliberately, the things that don’t compress, even when faster options exist. Not because the slow way is better on some absolute scale, but because the act of choosing it is itself the point.

The loops will keep getting faster. The mail will keep arriving. Some of it will matter and most of it won’t, and the hard part is that you can’t always tell which is which in the moment.

I’m still figuring it out. I suspect I will be for a while. And yes, despite everything, I’m still cooking my own dinner tonight.