What 3 Years of Pushing AI Coding Did to My Dev Team

If you're a CEO or CTO with engineers who learned to code before AI, and you can feel that AI coding should be transforming your business but it isn't, this is for you.

The tools aren't the problem. The problem is the people. Specifically, the engineers who built their craft before AI was useful. The ones your business actually runs on.

I've been a fanatic of AI coding since the month ChatGPT shipped. For most of the three years since, my dev team at We UC pushed back. Hard. They called the code bad. They mocked everything I built with AI. I've still got the Slack messages.

Then six months ago, the wall started to crack.

The December 2022 MySQL Moment

Let me take you back to the moment I knew everything was about to change.

December 2022. I'm at my laptop trying to build a dashboard to display phone system data. I'm not a developer. Never have been. But the data lived inside a MySQL database, and to get it into our BI dashboard I had to write a fair amount of SQL. Selects, joins, all of that.

I'd spent months grinding through Stack Overflow. Asked friends who knew MySQL. Always hit a wall.

Then ChatGPT came out. I described the query I wanted in plain English. It wrote the query. It worked. First try. Then I asked it for a script. The script worked too.

Within six months, I'd built a working prototype of a full app I'd been wanting for years. I sat there, blown away. And I remember thinking, this is the new way of writing code. The world is never going to be the same again.

So in early 2023, I went to my dev team and said, you need to start using this. This is the future. Get on it.

Three Years of No

Every single one of them pushed back.

The objections came in waves. You can't trust it. It hallucinates. It writes ugly code. It writes bad code, because it's been trained on the worst code on the internet. It can't fit our app in its context window. It will suggest packages that are out of date because of the training cutoff window, so it will write code with known vulnerabilities.

Every time I built something with AI, an internal tool, a script, anything, the team picked it apart. "Why is this file so long? Why did it pass these arguments? This is way more complicated than it needs to be. Look how I can simplify this function."

That last line, I heard a hundred times. "Look how I can simplify this function."

And underneath it, the unspoken word was always the same. AI coding doesn't work, Axel. Stop dreaming.

It took me two years to realise the resistance wasn't really about the code. It was about identity.

If you've spent years building muscle memory for what good code looks like, and someone walks in saying "let the machine write it," you don't hear "use a new tool." You hear "your craft no longer matters." That's the real reason. Not hallucinations. Identity.

I kept pushing. They kept pushing back. For three years.

The First Crack

Six months ago, things started to shift. I noticed it first in the small things.

We needed a marketing automation script. One of our mid-level developers, the same person who'd been mocking my AI scripts twelve months earlier, opened Claude Code, wrote a thorough prompt, and the script came out clean. Worked first try. He didn't tell me he'd used AI. I had to ask.

Around the same time, one of our senior backend developers, the one who'd called AI coding unreliable for the previous two years, started insisting on detailed technical specs for every new feature. Working with our PM on the PRD first, then writing the spec sheet himself. As if that's just how you do it now.

Why? Because once we have a good spec, AI can handle far more of the implementation than before. We move reliably faster.

I asked him why we couldn't just let AI write all of We UC. And he said something that stuck with me.

"We UC has been built over four years by different people, without a clearly defined coding standard from day one. So whenever AI looks at our code, it sees five different opinions about the right way to do things. Of course it gets confused."

That was honest. And he was right.

AI Coding Exposes, It Doesn't Fix

Here's the reframe that took me three years to see. AI coding doesn't fix bad engineering practices. It exposes them. And then it forces you to fix them properly.

The problem wasn't AI. We had never written down what good code should look like inside our company. So now we have. We're building a comprehensive coding standards document. We're refactoring our backend services into a monorepo so everything lives in one place: code, docs, tests. Where any developer, or any AI, can navigate it.

We had also been under-documenting our architecture decisions for years. The why behind choices, not just the what. So when we feed our codebase into AI now, we have something to feed in beyond the raw code. Without documented decisions, the AI was filling in the gaps with its own guesses. That's where the problems were starting.

We've improved our security stack too. Docker hardened images for the attack surface. Context7 MCP inside Claude Code so the AI uses the latest version of every package, not whatever was current at its training cutoff. Aikido running for the last month, scanning containers and deployments for vulnerabilities.

But none of this is really about AI. It's about wanting to write good code as an organisation. Bad packages get shipped by humans too. Insecure code gets written by humans too. The question isn't "is AI safe?" The question is, are we set up to produce good code, regardless of who or what wrote it?

We've started treating AI like another developer on the team. I think that's the right approach.

Permission from Skeptics

Why did my team finally come round? Honestly, three things hit at once.

I'd been hammering the same drum for three years. They were tired of hearing it from me.

Claude Code itself got dramatically better. The models stepped up significantly over the last twelve months.

And the third one, which surprised me. The developers my team follows online started talking about the tools seriously. Not as evangelists. As skeptics. ThePrimeagen, the YouTuber my team trusts most, is still cautious about AI coding. But cautious is different from dismissive. When the practitioners my team respects moved from "this is hype" to "this is a real tool with real trade-offs," that gave my team permission to do the same.

They didn't get converted by hype. They got permission from skeptics.

Sometimes you don't win the argument. You outlast it. And you let other people make it for you.

Two Generations of Developer

The process of converting my team has made me think about something much bigger.

There's a fork in the road in software development right now. Two generations of developer. One shaped before AI existed. One being shaped now. The gap between them is going to define the next decade.

On one side: developers who learned to code before AI was useful. That's my team and probably yours. They learned the syntax. They learned languages by typing them out, character by character. Their craft is in their fingers.

I call them hand coder software engineers. Or hand coders, for short.

On the other side: developers learning to build software now, with AI in the editor from day one. They won't memorise JavaScript or Python or Rust syntax, because they don't need to. AI handles that. What they will learn is the concepts. The architecture. Computer science principles. How memory gets allocated. How a system scales.

I call them AI native software engineers. They become managers of agents. They define the system, write the spec, set a fleet of agents loose, review the output. They're responsible for what the agents produce. But they don't write the code by hand. They don't need to.

I think I'm an early version of how this works. I never learned to code in the syntax sense. I learned to build software with AI from the start. I architect the system, write the spec, pass it to Claude Code, then test the output.

That's how I built The Scheduler. It started as an internal tool at one of my other companies. Now it's a fully working product, in production, used by real customers. Not a demo. I didn't write a single line by hand. I built it the way I think an AI native software engineer is going to be building everything.

I've done it twice. Before The Scheduler I built a search tool that pulled customer data from across our CRM, our phone system, and several internal servers. Two days. Working app. I'm not a developer.

If you're hiring a junior developer in two years time, the people applying for those jobs are going to look very different from the hand coders you've hired before. We're going to be hiring AI native software engineers. People who don't need to know how to write code in the syntax sense, but who absolutely know how to build software. Real software. Production grade.

What This Means If You're Hiring

If you're a CEO or CTO trying to push AI coding into a team of hand coders, keep pushing. Be patient. Pick AI native engineers when you hire.

Most of the rest will come around when the evidence is loud enough. Probably faster if it's coming from someone other than you.

And if you're where I was a year ago, don't be discouraged. Their mindset will change. Their work will change. Mine did.

A year ago they called it bad code. Today they're using it daily, in production. The argument resolves itself. If you outlast it.

Watch the video: