Nothing Is Certain

A few weeks ago I built a content workbench for the didactic team at work. It was a good idea, well-executed. They 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. Those 80 percent execution was our limit let us properly think and reflect our plan.

That ratio has inverted. We now live in a world of 80 percent hard thinking and 20 percent execution. And somehow we are not doing less work. At a recent hackathon I was helping several teams with their AI-assisted projects, unblocking one group, guiding another, jumping to the next the moment I finished a thought. After a few hours I felt like I’d done a full day of deep architectural work. The problems are bigger and more abstract now, but we still carry the old productivity mindset, the one that measured us by output, features shipped, tickets closed. That metric made sense when execution was the bottleneck. Now execution is nearly free, and quality is the only thing that matters. It is easy to produce something with AI. It is hard to produce something good. Meanwhile the old rhythm is gone. Writing code used to have a meditative quality to it, your cursor moving across the screen, music in the background, the quiet focus of a flow state. That was where your brain recovered between hard decisions. There is no equivalent rest now. You finish one act of thinking and immediately start the next. The pace is relentless, and it is draining us in ways we haven’t built language for yet.

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. The loop moves so fast that the temptation is to hover, to stay close, to try to direct every cycle. I suspect the real skill is the opposite: letting go, letting the agent find its own state, and reviewing only once it settles. As an engineering manager, I learned a version of this. I didn’t know every line of code my team was writing. That was the point. My job was the space between the code: the engineer who wasn’t communicating well with colleagues, the one making the same architectural mistake for the third time, the moments where a conversation could change someone’s trajectory. There was deep satisfaction in that work because the investment compounded. You helped someone grow, and they carried what they learned into every project after. They became better engineers, and some of that was yours.

AI agents don’t work like that. There is no compounding. Every session starts from zero. Worse, the agent you learned to work with yesterday might not be the one you’re working with tomorrow. Sonnet today, Opus next week, GPT the week after. Each has different strengths, different failure modes, different ways of misunderstanding you. It is less like managing a team and more like onboarding an endless rotation of short-term contractors who are brilliant, unreliable, and gone before you learn their habits. You cannot invest in that relationship the way you invested in a person. The systems stay brittle because nothing accumulates. And the discomfort runs deeper than workflow. If your identity was “coder,” that identity is eroding. If it was “the person who makes other engineers better,” that role is quieter now, aimed at a thing that doesn’t remember your guidance. Most of us were some mixture of builder, mentor, and problem solver, and the ground between those 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.