I've Been Writing Code for 20 Years. Here's Why I Finally Stopped Fighting AI — and What I Learned

When ChatGPT launched, my first instinct was scepticism. After two decades of professional software development — Java, Python, microservices on AWS, production systems supporting real businesses — I’d developed strong instincts through hard experience. Three-am incidents. Failed architectures. Hard-won judgement about what makes software good. The idea that a chatbot was going to transform my field felt like hyperbole, and I chose to largely ignore it for a while.

The turning point

The shift didn’t come from conference talks or social media posts about productivity gains. It came from necessity.

I was building a content SaaS platform — content generation pipelines, voice analysis, AWS infrastructure, full-stack features — and the scope had grown faster than the time available to build it. A colleague suggested trying AI for the routine scaffolding work: boilerplate code, configuration files, unit test stubs. The things that take mechanical effort before you can do the interesting work.

I tried it, reluctantly. The results were more useful than I expected. The output wasn’t production-ready — it never is — but it gave me something to work with, refine, and iterate from. The time saved on the boring parts made a real difference.

Understanding what AI actually is

The mental model that clarified everything: AI is a very fast, very well-read junior developer who has read every Stack Overflow thread ever written and has zero ego about being wrong.

Like a junior developer, it will confidently propose incorrect suggestions, miss domain-specific nuances, and occasionally produce code that looks right but isn’t. But just as you wouldn’t refuse to work with a junior developer because they sometimes get things wrong, you shouldn’t dismiss AI output because it requires review. You review it, you critique it, you improve it. That’s the job.

The critical insight is this: the years of experience I’d been worried would be made redundant are actually what make AI useful. Understanding why generated code might be subtly wrong. Knowing what correct architecture looks like for this specific system. Recognising when a suggestion is plausible but dangerous. That judgement doesn’t disappear — it becomes the filter through which AI output has to pass.

What I’ve learned in practice

A few things have become clear from regular use.

AI genuinely accelerates the work that requires minimal cognitive effort: boilerplate, documentation, test scaffolding, translating patterns between languages. The speed gains here are real.

AI is counterproductive when the underlying problem isn’t well-defined. If you have a fuzzy domain model or an unclear requirement, AI will produce confident-sounding output that reflects the fuzziness back at you. The discipline of thinking clearly before prompting doesn’t change — it just shows up faster when you don’t.

The engineers who struggle most with AI tools tend to be those uncomfortable with ambiguity, not those with weak technical skills. Working effectively with AI requires a different kind of judgement than writing code from scratch, and that’s a growth opportunity regardless of how you feel about the tools.

What this means if you’re still on the sidelines

If you’re a sceptical engineer who hasn’t seriously engaged with AI tools yet, your hesitation is reasonable. Your experience is genuinely valuable. But staying entirely on the sidelines has consequences — not because AI will replace you, but because engineers who direct these tools effectively are getting faster, and that gap compounds over time.

Starting is simpler than you think. Find one tedious part of your current work and try it there. Evaluate the output critically — which you’re already equipped to do.

The fear is understandable. The indefinite hesitation isn’t.

Written by an engineer who spent too long on the shore.