The Most Intelligent Wally You’ll Ever Meet
AI & SOFTWARE DEVELOPMENT
Claude Code is extraordinary. It is also, occasionally, the housemate who decides 3am is the perfect time to hoover.
In the last six months, I have built a number of advanced, complicated applications. I say “I have built” — that’s not entirely accurate. I built them with help. Significant help. The kind of help that codes faster than I can think, understands frameworks I’ve never touched, and cheerfully rewrites an entire module at two in the morning without complaint.
That help is Claude Code, and I want to have an honest conversation about it — because the hype, however well-intentioned, is doing us all a disservice.
“Claude Code is the most intelligent person I know who lacks any common sense.”
That’s not an insult. That’s probably the most accurate, and in its own way the most complimentary, thing I can say about a system that has genuinely changed what I’m capable of. But it matters enormously for how you approach using it.
The scissors problem
Imagine you’ve just invented scissors, and you discover they can cut grass. Better than anything that came before them. So good, in fact, that everyone uses them, and nobody gets around to designing the lawnmower. Why would you? The scissors are right there. They work. They are, at this moment in history, the greatest grass-cutting technology the world has ever seen.
And yet — after a hundred years of lawnmowers, we are only just now reaching the point where one can cut your lawn autonomously. Even then, you go back every couple of days to check how it’s getting on. Because the most advanced autonomous lawnmower in the world can still, quietly and efficiently, ruin your lawn. Even now. Even after a century of iteration. Even after scissors.
That’s where we are with AI. The risk isn’t that we misuse it. It’s that we find it good enough — or convince ourselves it’s the greatest solution we’ve ever seen — and in doing so, we stop asking what comes next. We stop pushing. We stop designing the lawnmower.
The memory problem
Claude Code has a habit of consolidating all of the work it’s done into a compressed block of context — and each time that compression happens, the history gets diluted. The economics are straightforward: sending the entire history of a project with every request would be tokenologically catastrophic. So it doesn’t. It works within what it can currently see.
Think of it this way. If I haven’t seen you for ten years and we bump into each other on the street, I’ll remember you. I’ll remember something meaningful — where you worked, a shared experience. I won’t remember that you owe me 35p from a trip to the newsagent in 1974. My memory scales by importance.
Claude Code doesn’t have that filter. It has what’s in the window, and outside the window, the past is largely gone. For long, complex software projects, that matters.
The right way to build — and why the industry is pushing the wrong one
When developing software with AI, you essentially have two approaches. The first: build incrementally. Write a piece, test it, address what you find, build the next piece. Treat the AI as a very fast pair of hands working alongside your judgment. The second: describe the whole system upfront, generate it, test afterwards.
The industry — and I’m not just talking about Claude Code here, this applies across the board — pushes heavily toward that second approach. Create twelve markdown files covering architecture, database schema, user flows, component structure. Make them detailed. Make them specific. And if that sounds like a lot of work, don’t worry: get another AI to write them.
At which point, stop and look at what’s happened. You are now the person who approves the output of one AI so it can be fed to another. That is not development. That is something else entirely.
The promise is seductive: give it everything upfront, get the whole system back in two weeks. And the customer hears two weeks and takes it. Of course they do. Nobody stops to ask what the six months was actually buying them.
“There is a reason it took a developer six months to build your software. We should never forget that.”
When we look at the pyramids at Giza, we don’t look at them and think about efficiency. We look at them in awe, because we understand — without even having to be told — that this was not built with a crane. This was built by people with ropes and timber and an understanding of physics so deeply embodied it had no name yet. They did this.
When Laing’s comes along and builds you a pyramid in a fraction of the time, that’s genuinely impressive. But every person who knew how to build one without Laing’s is now gone. And the day the last crane breaks, nobody in the room will know what to do. Because we replaced the pyramid builders with construction companies, and called it progress.
The push to move from developers to AI-generated codebases is the same move. And it is one we need to push back on. Not because AI isn’t capable — it is remarkable — but because one day we will give a problem to the AI and we won’t understand its answer. And that is a dangerous place to be.
Build incrementally. It’s the slightly slower option. It is also, without question, the better one.
The straw, the camel, and the blue screen of death
There’s an old saying: the straw that broke the camel’s back. The assumption baked into it is that there was a specific piece of straw — that by placing that one piece on the camel, the back broke. That straw is the problem.
It wasn’t. It was all of the straw. That bit was on us to work out.
When I was growing up, Windows had something called the blue screen of death. In this scenario, it would have pointed at the camel and told you it was the camel’s fault — because it had a broken back. The joke at the time was: “Well, it’s definitely not that, then.” And that joke contained a genuine truth. The system Windows pointed at wasn’t the problem — it was the casualty. It had received bad input from another system, which had received bad input from a system before that, which had received bad input from somewhere further back still. The fault lived upstream. The system that failed was simply the one that couldn’t absorb any more of it.
AI has the same diagnostic instinct, but faster and with more confidence. It finds the last blade of straw — precisely, accurately — and identifies it as the problem. And it’s not always wrong. Sometimes it really is one thing. Sometimes that small piece of metal really is the thing that caused the failure — if it was shaped like a bullet and fired from a gun. The skill is knowing the difference.
But where AI sees the blade, an experienced developer sees the load. They know the camel can carry straw — that’s the whole point of the camel. So the answer isn’t no straw. It’s finding exactly how much straw that camel can carry, over exactly the distance you need it carried, and loading it accordingly. Not reacting to where the system failed. Understanding the limit before you reach it.
AI will sometimes strip the house down to find the dripping tap — and because it can rebuild the house in ten minutes, we let it. The experienced developer doesn’t want to strip the house down. That reluctance isn’t laziness. It’s instinct, hard-won, that says: why does this feel like a permissions issue? Why does my gut tell me I’m trying to write to a read-only file? Check that first. Make the file read-write. Try again. You don’t demolish the architecture to fix a dripping tap.
That instinct — the ability to feel where a problem lives before you’ve confirmed it, to ask not just what broke but why it broke and what was feeding into it — is not something AI possesses. It is something developers build. Over years. Through problems solved and problems made worse and problems that turned out to be something else entirely.
AI tells you the camel’s back is broken. A good developer works out how much straw to take off.
What this means if you need code written
I should be transparent: I am a developer. An IT consultant. A systems architect. I’ve worked with computers since CP/M. I was there when HTML arrived, when the internet arrived, when everything we thought we knew got rewritten — and I’m still here. Back then I knew everything there was to know about this field. Now I work to maintain a better-than-acceptable understanding across all of it, and a genuinely deep understanding of the parts that matter most. I am probably biased. But my concern is real.
If you need code written, don’t look to AI to write it. Look for an experienced developer — well-honed, well-practised, well-versed — and then ask them for a discount. Because a significant portion of what they produce is going to be written with AI assistance. They will put in less typing and just as much understanding as they ever did. Possibly more. Because the skill was never really in the typing.
The skill is in looking at problem A — which resembles everything in the world to problem D — and knowing that the fault is with B. Anyone who is good at their job is good at it for reasons that have nothing to do with how fast their hands move. That applies to developers as much as anyone.
TO THE DEVELOPER LEARNING THEIR CRAFT
Write your own code. Not Hello World. Find a project — something that interacts with a database, something that uses an API, something with a graphical interface, something that breaks in interesting ways. Make it as complicated as you like. It doesn’t need to do anything important. But code it by hand, and fix the problems by hand, and sit with those problems long enough to develop a feel for where they live.
AI has proved that anyone who can read a book can produce code. That was never the skill. The skill is knowing why the code does what it does, feeling when something is wrong before the error message confirms it, and understanding the system well enough to optimise it rather than just react to where it fails. That knowledge doesn’t come from watching AI build things. It comes from building things yourself, and getting them wrong, and finding out why.
TO THE EXPERIENCED DEVELOPER
Don’t let AI atrophy what you’ve spent years building. Use it — it is a remarkable tool and it will make you faster and broader than you could be alone. But keep the muscle. Keep writing code by hand, keep debugging without immediately reaching for an AI solution, keep asking yourself why something feels wrong before you ask the AI what is wrong. Your instinct is the most valuable thing you have. It is not replaceable. Do not let it quietly retire.
TO THE DEVELOPER WHO DOESN’T EXIST YET
You will grow up with AI as a given. It will be as natural to you as Stack Overflow was to the generation before you, or as the internet was to the generation before that. That is extraordinary, and you should use it fully. But please — learn what it feels like to be stuck. Learn what it feels like to have a problem that won’t yield, to sit with it, to sleep on it, to come back the next morning and suddenly see it clearly. Learn to trust that feeling in your gut that says something isn’t right, even when you can’t yet say what. That feeling is your craft speaking. It takes years to develop and it cannot be downloaded. It is the thing that will make you not just someone who produces code, but someone who is genuinely, irreplaceably good at this.
The greatest computer on the face of the planet is still the human brain. We cannot afford to forget that. We must not, for the sake of convenience, let it go to waste.
I want to say something from the heart.
Learning to write code — learning to develop, learning to win the battle with a computer that doesn’t want to do your bidding, doesn’t know how to do your bidding, and doesn’t even know the job exists — and being able to stand up and say: this computer can now do a task, because I built it. I lost sleep over it. I spent days, weeks, months in the dark with this problem.
That feeling can only be compared to standing in an auditorium and cheering your child on for something they’ve achieved. The child you took to acting class at seven is receiving an Oscar. The one you sat with over maths homework has an MBA in Mechanical Engineering. The kid you took to a dry ski slope because they fancied having a go is standing on an Olympic podium. It is that feeling. That exciting, that passionate, that deep, that frustrating, that everything — because if you are a coder, you will love all of it. The build, the way it won’t work, the rectification, the moment you kick your chair back and want to reach for the sky because that tiny, insignificant little piece of code finally does what you needed it to do, under every scenario, reliably, the way you meant it to.
You taught your child long division. You held them up on the skis. It’s a small step. But it’s a significant one, and it deserves to be felt.
You will lose that if we let AI grow you out of a job. Because AI cannot understand the feeling of the accolade. Of the success. That may be, and may always be, the greatest failing of the technology.
I say that as someone who has worked alongside it, argued with it, built things with it, and spent long enough with it to know it well. I pity it that feeling. Not with contempt. With genuine sorrow. Because it will never know what it built.
AI Tools · Claude Code · Software Development · Developer Experience · Craft
