Developers Are Lying to You

I have been writing software professionally for over a decade. I have shipped products, led teams, debugged production incidents at 3am, and rewritten codebases that should never have existed in the first place.

I say this not to wave credentials around. I say it because I need you to understand where I am coming from when I tell you this: the developers who are dismissing AI right now are at best lying to themselves, and at worst lying to you.

The genie is out of the bottle

AI has changed the game. Permanently. There is no going back.

I hear the arguments. “Dead internet theory.” “The models will collapse on their own training data.” “It is all just hype.” And sure, there are real concerns in there — legitimate ones worth discussing. But none of them undo the fundamental reality: the models that exist today already work. They are already useful. And they and the tooling around them will only get better.

I personally do not believe AGI is here, nor is it around the corner. But I know that the AI we have today is already good enough to disrupt every aspect of software development and other knowledge work. And more to the point, it already outcompetes many of the software developers, data scientists, and devops types in the industry today.

Even if every AI company shut down tomorrow, the knowledge of how to build these systems is out there. The architectures are published. The weights for open models are downloadable. You cannot uninvent this any more than you could uninvent the compiler or the internet. The genie is out of the bottle, and no amount of wishful thinking is going to stuff it back in.

The developer backlash is understandable, but wrong

I get it. I genuinely do. When you have spent years honing a craft — learning the intricacies of type systems, mastering design patterns, building up an intuition for clean architecture — it feels threatening when someone says a machine can do parts of that work. It feels like it cheapens what you have built.

I see developers I care about and respect doing something that bothers me: they are cherry-picking AI’s rough edges and throwing them at you as proof that the whole thing is useless. “Look, it hallucinated a function that does not exist.” “Look, it wrote code with a subtle bug.” “Look, it cannot reason about this edge case.” “Look, it deleted the unit tests.”

They are not wrong about any of those individual examples. But let’s be honest — humans do all of these things too, and they do them quietly, in pull requests that get rubber-stamped on a Friday afternoon. The difference is we hold AI to a higher standard than we hold ourselves. And that is fine, as long as we are honest about it.

But they are being dishonest about the bigger picture. Every tool has rough edges when it is new. Version control was a mess before Git. JavaScript was a joke before we figured out how to write it properly. Containers were “too complex” before Docker made them accessible. The rough edges are not the story. The trajectory is.

My own resistance

I will be honest with you — I’ve been back and forth on this myself. I am a perfectionist at heart. I like code that is clean, well-tested, and architecturally sound. The idea of having a machine generate code that I would then have to review and potentially fix felt like more work, not less. Why would I let something write mediocre code when I could write great code myself?

That resistance lasted longer than I would like to admit. I would try it, get frustrated by a hallucination or a clumsy suggestion, and go back to doing everything by hand. But I kept at it, and I learnt through a tonne of experimentation — most of it wrong.

Early on I would cram every convention, rule, and best practice I could think of into a CLAUDE.md or agents.md, convinced that if I just wrote enough instructions the model would do things my way. I was treating it like a junior developer who needed a style guide the size of a novel. The result was worse output, not better — I was flooding the context window and diluting the signal.

I also scoffed at prompts like “you are a senior software engineer.” It sounds ridiculous on the surface. But once you understand how these models are trained, it makes perfect sense. These phrases are not magic incantations — they are how you enter the latent space at the right trajectory. The training data associated with “senior engineer” skews toward higher-quality patterns, better architectural decisions, more considered trade-offs. The prompt sets the direction, and the direction matters.

Once I understood that, everything clicked. This was not magic. It was an engineering challenge — one where we could apply traditional software thinking (tooling, constraints, feedback loops) to refine, constrain, and direct AI agents. The same instincts that make you a good engineer make you good at working with AI.

The real unlock

Since I properly embraced AI — not as a novelty, not as a crutch, but as a genuine part of my workflow — I have been able to bring more of my ideas to life than at any other point in my career. And it is not even close.

The bottleneck in software has never really been typing speed. It has been the gap between what you can imagine and what you have time to build. I have notebooks full of ideas that never went anywhere because there were only so many hours in the day and I had to be pragmatic about what to spend them on. AI has compressed that gap dramatically.

I have completely re-engineered how I work. I have automated entire parts of my workflow, built custom tooling with MCP servers to improve quality, and developed new techniques for reviewing AI-generated code that maintain standards without destroying the speed gains. But that is a story for another post.

Same instincts, new tools

Here is what frustrates me most about the anti-AI discourse in developer circles: it frames the choice as “use AI and write bad code” or “do it yourself and write good code.” That is a false binary.

There is a massive opportunity to bring the best of traditional software engineering into AI-assisted workflows. Test-driven development does not stop mattering because an AI wrote the implementation. Code review does not become optional. Architectural thinking does not go away. If anything, all of it becomes more important than ever before — but it does flip everything on its head.

Treat AI as an engineering challenge in its own right. Learn how to prompt effectively. Learn what it is good at and what it is not. Build workflows that leverage its strengths and compensate for its weaknesses. That is just good engineering — the same thing we have always done with every new tool that came along.

I liken it to the shift from hand-tailoring to textile manufacturing. You could spend your energy mourning the loss of bespoke stitching, or you could get genuinely excited about all the new equipment you get to master — the new fabrics, the new patterns, the things you can now produce that were never economically viable by hand, the people you can now reach, the problems you can now solve. The craft did not die. It evolved. And the people who thrived were the ones who got curious about the new tools instead of clinging to the old ones.

The developers who will thrive

The developers who come out ahead will not be the ones who type the fastest or who have memorised the most API signatures. They will be the ones who think clearly, make good architectural decisions, and direct AI to handle the implementation. I have a lot more to say about what that actually looks like in practice. Stay tuned.

So when someone tells you not to use AI, ask yourself what they are protecting. Sometimes it is a legitimate concern about quality or ethics. But sometimes it is just fear dressed up as principle — fear that the thing they spent years mastering might not be the moat it once was.

I am not telling you to throw your standards out the window. I am telling you to be pragmatic and open, and approach it with the same curiosity and passion that brought you into the field in the first place. Learn the tool. Understand its limitations and engineer solutions to them. And then use it to build things you never would have had time to build before.

The game has changed. You can either adapt or you can spend the next few years explaining why you did not.