Letting Go of the Microscope

Somewhere along the way, I stopped obsessing over the line-to-line details.

Not because they stopped mattering, but because they stopped being where the real leverage lives.

Earlier in my career, I lived in the microscope. I cared deeply about the exact structure of a function, the purity of an abstraction, the elegance of an implementation that only another engineer might ever notice, if anyone at all. I could spend hours refactoring something that already worked purely because it didn’t feel quite right yet.

That phase mattered greatly. It built taste. It built discipline. It built the mental models I still rely on today. Digging into the smallest details taught me how systems actually behave, not just how they appear to behave.

But lately, much faster than I expected, something has shifted.

The Abstraction Has Moved Up

I find myself thinking less about how something is implemented, and far more about what is possible to build at all.

What systems can exist now that simply were not feasible before. What products can be shipped, tested, killed, or scaled in a matter of weeks instead of months. The syntax and structure of “the thing” fades slightly into the background. The outcome comes into sharper focus.

This feels familiar. We have seen this before.

Assembly gave way to C.
C gave way to higher-level languages like Java and Python.
Frameworks replaced boilerplate.
Cloud platforms replaced racks of hardware.

Every time the abstraction moved up, people worried we were losing something fundamental.
And every time, the abstraction won, because it allowed builders to think at the level where real value was created.

This feels like that moment again. Only the leap feels steeper.

LLMs Changed the Centre of Gravity

Large language models did not just make writing code faster. They changed where attention should go.

For the first time, implementation detail is rarely the hardest part. The hard part is deciding what to build, how pieces fit together, where the edge cases live, and whether the thing should exist at all. Code has become abundant. Judgment has not.

I still care deeply about good code. I still care about systems that make sense, that hold up under pressure, that can be maintained by someone other than their original author. But the highest leverage no longer comes from perfecting individual lines. It comes from understanding systems, constraints, and outcomes.

The game has moved up a layer.

Engineers Aren’t Being Replaced

There is a growing narrative that software engineers are on borrowed time. That code will soon be fully generated, systems fully automated, and human builders gradually removed from the loop. In January of this year, Anthropic’s CEO Dario Amodei boldly stated that AI models will do “most, maybe all”, of what software engineers do within 6 to 12 months.

I do not buy that. Not even slightly.

If anything, the opposite feels more plausible. As code becomes cheaper to produce, the value of judgment increases. The value of taste increases. The value of understanding trade-offs, constraints, security, performance, and long-term maintainability increases.

Tools can generate code. They cannot assume responsibility for systems. They cannot own outcomes. They cannot sit with boundless ambiguity and decide what should exist in the first place.

Even the companies building the most advanced AI systems continue to hire engineers aggressively. That alone should tell you something. If the people closest to the technology still need experienced builders, it is because building real systems has never been just about typing code. Another example, Cognition AI, creators of the “AI coworker”, “Devin”, still have many job listings for engineers on their site. Shouldn’t Devin be taking these roles?

Automation Expands the Surface Area

We are already seeing AI agents that can scaffold large portions of applications. Some can generate entire services. Some can debug, refactor, and deploy.

And yet the companies building these tools are still hiring engineers at scale. Not out of habit, but necessity. Because someone still needs to define the architecture, verify the outputs, understand the edge cases, and own the result.

Automation increases the surface area of what can be built. It does not remove the need for people who understand what they are building.

If anything, it raises the bar. More can be built, faster. Which means more decisions, more responsibility, and more room for things to go very, very wrong if handled carelessly.

Building Products, Not Just Software

Building products today is easier than it has ever been. Building them at meaningful speed is no longer a fantasy.

But that speed only appears if you embrace the tools without surrendering your judgment. If you insist on staying glued exclusively to the lowest-level details, you are optimising the wrong thing. If you blindly trust generated output without understanding it, you are doing something even worse.

The role of the engineer is not shrinking. It is widening.

We are no longer just implementers or skilled typists. We are integrators, architects, product thinkers, decision-makers and founders. The tools handle more of the mechanical work. That simply means the human part of the job becomes more important, not less.

A Hard Line

None of this is a call to blindly trust machines or ship unverified code.

I care deeply that code is secure, performant, and human-verified before it ever reaches production. Committing code you do not understand, test, or validate is reckless. That does not change just because a model produced it.

Using these tools well requires stronger engineering fundamentals, not weaker ones. You still need to know when something is wrong. You still need to know how systems fail. You still need to be able to reason about what you are shipping.

The abstraction has moved up. Responsibility has not moved anywhere.

The Real Shift

The real shift is not that engineers are becoming obsolete.
It is that the scope of what a single engineer can build is expanding rapidly.

The tools are better. The feedback loops are shorter. The cost of experimentation is collapsing. That should not feel threatening. It should feel like leverage.

The role is not disappearing. It is expanding.

The engineers who thrive over the next decade will not be the ones who reject these tools, nor the ones who blindly trust them. They will be the ones who use them aggressively while remaining deeply responsible for what they ship.

Code got cheap.
Judgment didn’t.