I Have Barely Written Code by Hand in Two Years. I Have Never Built More.

This Sounds Like the Wrong Metric Until You Sit Inside the Shift

If I total up how much code I have physically typed by hand over the last two years, I suspect it is barely 100 lines.

That sounds absurd at first. It can also sound like a bad thing.

For a long time, writing code by hand felt inseparable from being a serious engineer. If you were not manually producing large amounts of source code, it was easy to feel like you were somehow one level removed from the craft.

But my experience has been the opposite.

Even before I jumped to the unparalleled power of Claude Code in its current form, I was already a heavy user of Windsurf. At the end of 2025, one month of Windsurf's own statistics showed it had written over 1 million lines of code across various projects of mine.

In the same period where hand-typed code nearly disappeared, I have been able to:

• build more software than I ever have before
• ship at a higher level of quality than I used to think realistic
• attempt things that previously would have felt too broad, too time-expensive, or too risky
• and go much deeper into technical areas I would not have had the time, confidence, or bandwidth to explore in the older model

That is the part I think a lot of people still misunderstand.

The important shift is not that I somehow stopped engineering. The important shift is that manual typing stopped being the centre of engineering leverage.

This Is Not a No-Code Story

I am not claiming that code no longer matters. And I am definitely not claiming that deep technical understanding no longer matters.

If anything, my view is the reverse.

The more agent-native the system becomes, the more important these things become:

• judgement
• system design
• decomposition
• interface clarity
• verification quality
• architectural taste
• and the discipline to keep multiple workstreams coherent

So when I say I have barely written code by hand, I do not mean:

• I stopped caring what the code does
• I no longer inspect it closely
• I outsourced engineering thought to a machine
• or quality somehow takes care of itself

I mean that the scarce resource moved.

It moved away from keystroke production and toward directing an agent-native system well.

What Replaced Manual Typing

What replaced most of the hand-written code was not laziness. It was a different operating model.

The practical loop now looks much more like:

• define a clear planning anchor
• break work into coherent tracks
• let agents execute where the boundaries are clean
• review, reshape, and converge the outputs aggressively
• test and harden the result
• capture the new truth in docs, rules, and system memory

That is still engineering. It is just engineering with a different centre of gravity.

The job becomes less about typing line after line in a serial flow and more about:

• choosing the right workstreams
• setting constraints that keep those workstreams aligned
• spotting weak assumptions early
• protecting interface boundaries
• demanding real proof instead of decorative output
• and keeping product, engineering, and business movement connected

That is why I increasingly think the important breakthrough is not an AI assistant that helps someone write code faster. It is the rise of agent-native systems that change what one experienced engineer can direct at all.

That is the argument behind The Operating Envelope of a Solo Engineer Has Changed and AI Coding Assistants Are Not the Story. Agent-Native Systems Are..

This post is the more personal version of that argument. It is what the shift feels like from inside the work.

The Strange Result: Less Manual Coding, More Ambitious Software

One of the things that becomes obvious very quickly in this model is that manual typing was never the whole job. It was just the most visible part.

Once that layer compresses, a lot of capacity appears elsewhere.

That capacity can be spent on:

• broader product scope
• more aggressive quality work
• deeper test coverage
• stronger documentation
• more architectural cleanup
• better release preparation
• more polished user-facing surfaces
• and more thoughtful integration between technical and business work

In other words, you do not just build the same product faster. You often build a more coherent and more ambitious version of the product because the system can now sustain work that used to be too wide for one person to manage comfortably.

This is why I am increasingly suspicious of discussions that reduce the whole shift to productivity gains.

Productivity is part of it. But it is not the deepest part.

The deeper part is that the shape of possible work changes.

Things that once felt like sequential trade-offs start becoming overlapping tracks:

• hardening while building
• documenting while integrating
• preparing launch assets while tightening product flows
• auditing test quality while shipping new surfaces
• moving across multiple repositories without losing the thread

That is a very different engineering reality from one person manually moving down a queue of code tasks.

The More Surprising Effect Was Learning

The biggest surprise for me has not actually been throughput. It has been range.

I have been able to go much deeper into parts of the technical domain that, in a previous model, I probably would have admired from a distance or deferred until some later phase that never quite arrived.

That is because the cost of exploration changed.

In the older model, getting into a new technical area often meant:

• paying a large setup cost just to become dangerous enough to start
• accepting that the rest of the product might stall while you disappeared into that area
• and carrying a high risk that the investment would not pay off

In an agent-native model, those costs do not disappear. But they do compress enough that more exploration becomes viable.

That changes what you can realistically learn while still shipping.

A good example is terminal UI rendering and development.

That is not a trivial area. It involves a very different set of mental models from ordinary web product work. You end up thinking about things like:

• constrained rendering surfaces
• stateful redraw behaviour
• layout under terminal constraints
• interaction design without the assumptions of the browser
• and how user experience changes when the medium itself behaves differently

In a slower, serial development model, going properly into that space would have felt expensive enough that I might have postponed it indefinitely.

In this model, I can explore it while still keeping the surrounding system moving. That has made it possible to build confidence and understanding in areas that previously would have stayed on the edge of my attention.

And that pattern is not limited to terminal interfaces. It applies across a wider range of technical surfaces:

• testing and verification systems
• release engineering
• toolchain design
• architectural governance
• system documentation as live memory
• operational quality controls
• and the interfaces between product, engineering, and business execution

This Did Not Make My Understanding Shallower. It Made It Broader and Deeper.

There is a common fear that if agents do more of the implementation work, the human will understand less.

I understand why people think that. Used badly, that absolutely can happen.

If someone treats agent output as magic and stops interrogating the system, they will become less competent, not more.

But that is not what I have experienced when the workflow is disciplined.

What I have experienced is that the reduction in manual implementation overhead creates more room for:

• asking better technical questions
• tracing systems end to end
• comparing multiple implementation paths quickly
• investigating failure modes earlier
• understanding adjacent layers of the stack
• and refining the architecture while the work is still malleable

In other words, I spend less time being a human syntax renderer and more time being a human technical director.

That has not reduced my understanding. It has increased the amount of system I can understand at once.

Why Quality Can Improve Instead of Collapse

A lot of scepticism here comes from a fair instinct.

People hear “less manual coding” and assume the result must be sloppier software. Sometimes it is.

But that usually happens when speed is used to skip discipline rather than support it.

In my experience, quality can go up because lower implementation cost creates room to invest more heavily in the things that actually protect quality:

• better tests
• stronger review
• tighter interface definition
• more documentation
• more cleanup
• faster iteration on weak areas
• and more time spent on proof instead of just output volume

This is why I do not think fast agent-native systems should relax standards. I think they need stricter ones.

When a system can move quickly, low-signal verification becomes more dangerous, not less dangerous. The answer is not to trust more loosely. It is to design better confidence systems.

The Bottleneck Moved Up the Stack

What I have learned over the last two years is that the limiting factor was never purely my ability to type code.

The real limiting factors were things like:

• how quickly I could get a coherent plan anchor in place
• how safely I could split work across boundaries
• how well I could evaluate multiple solutions
• how fast I could identify weak proof
• how cleanly I could converge parallel workstreams
• and how honestly I could distinguish between “implemented” and “ready”

Those are still hard. Maybe harder.

But they are higher-value hard problems. And they are exactly where experience matters most.

That is why I do not think this shift belongs to whoever can get the most code-shaped output out of a model.

I think it belongs to the people who can build and operate systems where:

• speed does not destroy coherence
• exploration does not destroy focus
• quality does not become ceremonial
• and broader ambition does not outrun the verification model

I Still Touch Code. It Is Just No Longer the Main Measure.

To be clear, I do still touch code.

There are moments where direct manual intervention is exactly the right thing:

• a precise fix at a critical seam
• a specific rendering tweak
• a test adjustment that needs careful intent
• a final simplifying edit
• a moment where the fastest path is just to type the change myself

So this is not a manifesto for never touching source files.

It is a statement about the ratio.

The ratio has changed so dramatically that it forced me to re-evaluate what I think engineering work actually is.

I do not think it is primarily the act of manually producing syntax anymore. I think it is the act of shaping, constraining, verifying, and directing increasingly capable systems toward coherent outcomes.

This Is Why I Am More Optimistic Than I Used to Be

The last two years have made me more optimistic about what one experienced engineer can realistically do.

Not because I think the hard parts went away. They did not.

But because the hard parts shifted upward into areas that are more leveraged and, frankly, more interesting:

• system design
• product judgement
• quality design
• technical breadth
• architectural clarity
• business translation
• and sustained learning across adjacent domains

That has made it possible to build more, learn more, and aim higher at the same time.

For me, that is the real story.

Not that I wrote less code by hand. But that writing less code by hand turned out not to reduce engineering ambition.

It expanded it.