Signal and Noise: Volume Five
This is the fifth in an occasional series called Signal and Noise - essays on the principles that have guided 46 years of building software, and why they matter more in the age of AI.
The maxim
Great programmers are very lazy people.
I have been saying this since the late 1990s, usually to clients who looked slightly uncomfortable hearing it. It sounds like a joke. It is not a joke. It is the most accurate description I know of the instinct that drives great software engineering - and it is the instinct that is now eating the profession alive.
The automation instinct
Let me explain what I mean by lazy.
A mediocre programmer, given a repetitive task, will do the task. They will do it carefully, reliably, and they will do it again tomorrow, and the day after, and the day after that. They will become very good at doing the task. They will take pride in doing the task well.
A great programmer, given the same task, will refuse to do it twice. Not because they are incapable - because they are offended by the repetition. Something in their wiring rebels against doing manually what could be done automatically. So they write a script. They build a tool. They create an abstraction. They automate the task out of existence and move on to the next one.
This is the laziness I am talking about. Not sloth - impatience with unnecessary effort. The great programmer's deepest instinct is to make themselves redundant at the mechanical level so they can operate at the conceptual level. They do not want to type the same command twice. They want to build the system that types the command for them.
This instinct built the entire software industry. Every framework, every library, every platform, every abstraction layer - they all exist because a programmer somewhere was too lazy to do something by hand and built a tool instead. Unix pipes. Makefiles. Compilers. ORMs. CI/CD pipelines. Infrastructure as code. Every one of these is a monument to productive laziness.
The instinct always pointed in one direction: automate everything that can be automated. Push the boundary of what "can be automated" as far as it will go. Reduce the human to the irreducible core - the part that requires judgment, creativity, understanding - and let machines handle the rest.
That instinct has now reached its logical conclusion.
The ultimate automation
I have not written a line of code since November 2025.
Let that sit for a moment. I have been coding for forty-six years. I started on a ZX80 in 1980, at the age of ten. By eleven I had written and sold my first piece of commercial software - a program for the BBC Micro that taught young children to tell the time. At fourteen I wrote a suite of programs that taught and tested young musicians the aural tests for Grades I to V. It was accredited by the Associated Board of the Royal Schools of Music and I had a publishing contract with Macmillan. I had dedicated all of my spare time to this before I was sixteen. I went to Cambridge at seventeen and by nineteen had designed and built RSAMS, Rubicon's first production system.
BASIC, Pascal, Delphi, C#, TypeScript - and everything in between. Programming was not just my profession - it was my primary mode of thinking. I thought in code. I solved problems by writing code. My identity as a technologist was inseparable from my identity as a programmer.
And I have not written a single line since November.
I have, however, written an awful lot of software.
Rubicon Probity - the decision intelligence platform, the distillation engine, the agent infrastructure, the internal tools - has been built almost entirely through AI. I describe what I want. I specify the behaviour. I review the output. I direct, correct, redirect. But the actual writing of code - the syntax, the structure, the implementation - is done by AI agents that I orchestrate.
This is what they call "vibe coding," a term I find slightly embarrassing but cannot deny is accurate. I operate on vibes. On intent. On architectural judgment and domain knowledge and forty-six years of understanding what good software looks like. The AI handles the rest.
The lazy programmer's dream, fully realised. I have automated myself out of the mechanical work entirely.
The Fitzgerald tension
F. Scott Fitzgerald said that the test of a first-rate intelligence is the ability to hold two opposing ideas in mind at the same time and still retain the ability to function. I think about that quote a lot these days.
Here are my two opposing ideas:
The craft of programming is becoming worthless. The mechanical skill of writing code - knowing syntax, remembering APIs, structuring functions, debugging logic errors - is being commoditised to zero. Within five years, possibly sooner, the ability to write code by hand will have roughly the same market value as the ability to do long division by hand. Technically impressive. Economically irrelevant.
The craftsman has never been more productive. I am building more software, faster, and at higher quality than at any point in my career. My output has increased by an order of magnitude. Not because I am working harder - because the bottleneck was never my thinking. It was always the mechanical translation of thought into code. Remove that bottleneck and the throughput is extraordinary.
Both of these are true simultaneously. The craft is dying. The craftsman is thriving. And I do not know how to feel about it.
There is a grief in watching a skill you spent decades mastering become unnecessary. Real grief. I was good at writing code. I understood it deeply - not just the syntax but the architecture, the patterns, the trade-offs, the elegance of a well-designed system. That understanding still matters. But the part that expressed it - the fingers on the keyboard, the hours in the IDE, the flow state of writing a complex function - that part is gone. And I miss it.
I suspect coding will feel, for the rest of my life, the way crosswords or sudoku feel to the people who love them - intellectually stimulating, deeply satisfying, and of no commercial value whatsoever. A hobby. Something I do because the puzzle is enjoyable, not because anyone needs me to. That is a strange thing to say about a skill that has defined my professional identity since I was ten years old. But I think it is true.
At the same time, I have never been more effective. The ideas I could not previously build because the implementation would take too long - I can build them now. The architectural decisions I used to make under time pressure - I can explore multiple approaches and pick the best one. The quality I used to compromise on because the budget was running out - I can afford to get it right.
Excited and terrified. That is the Fitzgerald tension. And it is the honest position.
What survives
If the mechanical skill of coding is being commoditised, what is left? What does the programmer of 2030 actually do?
I think four things survive:
Requirements. Understanding the problem. Knowing what to build. This is the fifty-five minutes Einstein spent defining the problem before the five minutes solving it. AI can generate code. It cannot - yet - understand what a business actually needs, why the current process fails, what the users will really do versus what they say they will do. The ability to translate messy human reality into precise specifications is the most valuable skill in software. It always was. It is just more obviously so now.
Taste. Knowing what good looks like. This is the hardest thing to define and the most important. When AI generates five possible architectures, someone has to pick the right one. When it produces a user interface, someone has to know whether it works for real humans in real contexts. When it writes a test suite, someone has to judge whether the tests cover what matters. Taste is accumulated judgment. It comes from decades of seeing what works, what breaks, what scales, and what falls over at 3 AM on a bank holiday. You cannot shortcut it.
Judgment. Knowing when to stop. Knowing what not to build. Knowing when the elegant solution is wrong because the team cannot maintain it, or the infrastructure cannot support it, or the business requirement will change in six months. AI optimises for the objective you give it. Judgment is knowing whether the objective is right. This is "don't do the wrong thing faster" applied at the technical level.
Domain knowledge. Understanding the problem space deeply enough to know what questions to ask. A programmer who understands financial services compliance does not just write code - they know which edge cases will cause regulatory trouble, which data flows need audit trails, which performance characteristics matter under load. That domain knowledge took years to acquire. AI does not have it. The human who does is irreplaceable.
Notice what all four of these have in common. They are all about understanding the problem, not about implementing the solution. The lazy programmer's instinct was always right: push the mechanical work down, push the conceptual work up. AI is just the final push.
The irony
There is a deep irony in all of this that I appreciate on a personal level.
I have spent forty-six years building systems that automate human effort. That has been my entire working life - getting computers to do what computers are best at, to leave people more time to do what people are best at. I automated case management for ACAS. I automated content management for ICI. I automated reporting, data processing, workflow, compliance checking, and a hundred other processes that used to consume human hours.
And now the same principle has automated me.
Not all of me. The part that understands problems, makes decisions, directs architecture, and judges quality - that part is busier than ever. But the part that wrote code - the implementing, typing, debugging, testing part - that part has been automated by the very instinct that drove it.
The lazy programmer built tools that replaced other people's repetitive work. Then the lazy programmer's tools got good enough to replace the lazy programmer's repetitive work. The logic was always going to arrive here. I just did not expect to be alive when it did.
What this means for Rubicon
Rubicon Probity was built by a programmer who does not write code anymore. That is not a limitation - it is a proof of concept.
If one person with forty-six years of domain knowledge and a fleet of AI agents can build a production platform, it changes the economics of software delivery fundamentally. The bottleneck is no longer development capacity. It is judgment capacity. It is knowing what to build, why to build it, and what good looks like when it is built.
This is what Rubicon offers. Not AI tools - the internet is awash with AI tools. What we offer is the judgment layer. The experience to know which problems are worth solving. The taste to know what a good solution looks like. The domain knowledge to know where the edge cases hide. And the healthy, productive laziness to insist that machines do the work that machines should do, so that humans can focus on the work that only humans can do.
Great programmers are very lazy people. The laziest ones are now the most productive.
The question is not whether you can code. The question is whether you can think. Whether you can define the problem, judge the solution, and direct the machines that do the building.
That has always been the question, really. We just did not notice because we were too busy typing.