A Piece of My Mind as a New Era Begins

I have spent more than fifteen years making a living from code. I still get a thrill from taking an idea that exists only in someone’s head and turning it into something they can use. That part has not changed. What has changed, especially over the past year, is how much of the code I type myself.

I have worked on backend systems in Scala, Ruby and Java, and built smaller things in Go, Flutter, JavaScript and PHP. I have spent hours with API documentation open beside a failing test, searching Stack Overflow, reading someone else’s code and trying to understand why a system behaved differently from the diagram. I have planned services on AWS and Google Cloud and run applications on Ubuntu virtual machines in places where a managed service was not the answer.

It is easy to romanticise that work from a distance. Up close, it also means deadlines, difficult reviews, debugging late into the day and the uncomfortable knowledge that a consulting fee rarely reflects every hour of thought behind a solution. Billing, payments, integrations and automation do not forgive a vague understanding of the problem. A senior engineer will challenge your design. A client will ask why the feature is late or why it does not fit the way their team actually works. Both questions can make the product better, even when they are hard to hear.

The best part has often been the team. A group of engineers who know when to lead and when to listen can feel like an orchestra. The result depends on people paying attention to one another, not only playing their own part well.

Then the way I worked began to change

In 2025 I started pairing with coding agents. At first, they helped with parts of the work I already knew: writing code, researching an unfamiliar library, suggesting tests, checking a change. In 2026 I have been working alongside engineers who use these tools every day. An agent can move through a task quickly enough that the bottleneck becomes my own attention.

I thought I might simply get hours back. Instead, I found myself spending many of them reviewing generated code. There is a difference between watching a change appear and understanding what it will do in a real system. A passing test does not tell me whether we asked the right question. A tidy diff does not tell me whether a payment edge case, a data migration or a user’s consent has been handled well.

That forced a difficult question: where should I spend the attention I have? I cannot give every generated line the same depth of review and still make good progress. I am learning to review according to the cost of being wrong. Changes to payments, permissions, private data and migrations deserve close reading and strong evidence. For smaller changes, focused tests, a clear diff and a working demonstration may tell me enough. Whatever the tool wrote, I still own the decision to ship it.

This is a change in method, and I do not think we have settled on the best method yet. We need better ways to state a problem, give an agent useful boundaries, test behaviour, see what changed and recover when it goes wrong. The work has moved closer to asking, judging and building the whole thing.

Why the keynote stayed with me

I watched DHH’s opening keynote at Rails World 2026 after years of following what he and the people at 37signals have built. His optimism about agents felt like fresh air. It made me think about why I started programming in the first place.

I did not start because I wanted to produce the largest number of lines. I wanted to make things that reached people and solved a problem. Code was the material I learned to work with. It still matters deeply to me, but the end product matters more.

The keynote’s “pencils down” idea has stayed in my head. I take it as an invitation to reconsider which parts of the work need my hands and which need my judgement. I still want to understand the systems I build. Understanding is how I spot a plausible mistake, ask a better question, and know when an answer is too easy. I also want to enjoy the extra room these tools can create for trying an idea and seeing it in someone’s hands.

At times it feels as though I am retiring from an old definition of programmer and becoming more of a maker. I still programme. I still care about a good API and a well-shaped piece of code. My attention now has to cover the problem, the people affected, the tools doing some of the work, and the evidence that the result is sound.

What I want to keep

I have five things I do not want to bargain away as the tools improve:

1. Understand the why. Before choosing a model, framework or agent, I want to know whose problem we are solving and what would count as a useful result.
2. Make time for fundamentals. Databases, networks, language behaviour, security and design still explain why systems fail. Fast code generation makes that knowledge more valuable to me.
3. Spend attention where it counts. The Pareto principle is a useful reminder to look for the work with the largest effect. It is a guide for choosing what to examine, not a promise that every project obeys an exact 80/20 split.
4. Ship what matters. A feature earns its place when it works for its users. I want to see it running, hear what people struggle with and improve it, rather than stopping at a convincing demo.
5. Put some saved time back into my craft. I want to read more deeply, practise the skills that compound and learn the parts of a system that an agent cannot understand on my behalf.

I am grateful that I learned to build software before this shift. Those years of reading code, being questioned and making mistakes give me something to bring to it. I am also glad to be here for what comes next. There is more to learn about working with agents, and probably more of our habits to change. For me, the point is still the same: take an idea seriously enough to make it useful to someone.