If you're a CEO or CTO with engineers

who learned how to code before AI and

you feel that AI coding should be

transforming your business, but it

isn't, you need to hear this. The tools

aren't the problem. The problem is the

people. Specifically, the engineers who

built their craft before AI was useful.

I run a 20-person dev team at We Use It,

and I've been a fanatic of AI coding

ever since ChatGPT shipped. And I spent

the last 3 years dragging my entire

engineering team towards it. most of

those 3 years, they pushed back.

Hard. They called the code bad. They

mocked everything I built with AI. I've

got the Slack messages to prove it. Then

around 6 months ago, the wall started to

crack. Here's what I tried, what failed,

and what's actually working. Here we go.

Let me take you back to the moment when

I knew everything was going to change.

December 2022. I'm at my laptop trying

to build a dashboard to display phone

system data. Now, here's the thing. I'm

not a developer. I've never been. But

the data that I needed lived inside of

my SQL database in the phone system. And

to get it into our BI dashboards, I had

to write a bunch of my SQL queries,

selects, joins, all that jazz. I'd spent

months grinding through Stack Overflow,

even asking friends who knew my SQL, but

I always ended up hitting this

opened it up and I described the query

that I wanted in plain English. It went

and it wrote the query and and it

worked. Then asked it for a script, it

wrote the script, and it worked, too.

And then within 6 months of playing with

it, I'd built a full app, a prototype of

a full app, that I'd been wanting to

build for years. I was blown away. I

remember thinking, "This is the new way

of writing code. The world is never

going to be the same again. Full stop."

So, in early 2023, I went to my dev team

and I said, "Look, guys, you need to

start using this. This is the future.

This is bigger than auto-complete. Get

on it. And 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. This one was my

favorite. It's been trained on the worst

code on the internet, so all it can ever

produce is bad code. They said it can't

understand what you actually want. Our

app is way too big to fit in the context

window, so it has no idea what it's

doing. Then the security one. It will

suggest packages that are out of date

because of the training cutoff window,

so it will write code with known

vulnerabilities. To be fair, that last

one is is a valid point, and I'll come

back to how we approach this and solve

this later on. I think it's every time I

build something with AI, an internal

tool, a script, anything, the team

picked it apart, saying things like,

"Why is this file so long? Why is it

passing these arguments? This is way

more complicated than it needs to be.

Look how I can simplify this function."

And underneath that, the the the line,

the unspoken word was always the same.

AI coding doesn't work, Axel. Stop

dreaming. Now, here is a key fact. Every

single person on my team

learned to code before AI coding was a

thing. Every single one. They learned

the concepts, then they learned the

syntax, then they practiced by writing

code, refining it over time. That's the

old way of learning to build software.

We don't have anybody on the team who

learned to build software in the AI era,

yet.

When we do, I think that story will look

very different. But hold that thought,

I'll come back to that later. But with

our current team, the resistance came

from every angle. And to be fair, I get

it. If you've spent years building

muscle memory for what good code

actually looks like, and somebody walks

in and says, "Let the machine write it."

You don't hear, "Use this new new tool."

You hear, "Your craft no longer

matters." That's the real reason. It's

not hallucinations, it's identity.

Either way, I kept pushing, and they

kept pushing back Uh for around 3 years.

6 months ago, I started to see a shift.

I noticed it first in the small things.

We needed a marketing automation script.

And one of our guys,

the same guy who'd be mocking my AI

scripts 12 months before, opened up

Claude code, wrote a prompt, and the

script came out of the other side.

Worked first time. He didn't tell me he

used AI to write the script. I had to

ask. And when I did, he said, "Yeah, I

used Claude code." like if it was the

obvious thing to do. 12 months earlier,

this same person was telling me that AI

writes ugly code. Then one of our senior

back-end guys,

the same person who'd been calling AI

coding unreliable for the last 2 years,

started writing spec sheets for every

single new feature he had to build.

Working with our PM on the PRD first,

and then going and writing the technical

specifications all by himself. As if

that's the way you do it now. Why?

Because once you have a good spec, AI

can handle so much more of the

implementation that it could before. We

can move reliably faster. I asked him,

"Why couldn't we have AI write all the

code for We U See?" And he said

something that made me think. He said,

"We U See's been built over the last 4

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 of how

things should be done correctly. Of

course it gets confused." That was

honest of him. And he And he was right.

The problem here wasn't AI. It was that

we'd never written down what good code

should look like. So now, we have.

Here's the reframe that took me 3 years

to see. AI coding doesn't fix bad

engineering practices. It exposes them.

And then it forces you to fix them

properly. We've now built a

comprehensive coding standards document.

We're refactoring all our back-end

services into a mono repo, so that

everything lives in one place. Code,

docs, so that any developer or any AI

can navigate it. We've also improved our

security stack. We're using Docker

hardened images to reduce the attack

surface. We're using contact 7 MCP

inside Claude code so that it can use

the latest packages available beyond the

training cutoff date of the model. We've

got a keto running for about a month now

that's scanning all our repositories,

our containers, and deployments and

notifying us of vulnerabilities. But

none of this is really about AI. It's

about us as a an organization wanting to

write good code. Bad packages get

shipped by humans, too. Insecure code

gets written by humans, too. The

question for us isn't isn't is AI safe?

The question is are we set up to produce

good code regardless of who or what

wrote it. We started treating AI like

another developer on the team and I

think that's the right approach. So, why

has my team finally come round?

Honestly, I think three things at once.

One, I've been harping the same drum for

like 3 years. They're tired of hearing

it from me. Two, Claude code got

dramatically better over the last 12

months. And three, the developers that

my team follows online started talking

about the tools seriously. Not as

evangelists, as skeptics. Take the prime

engine, for example, a developer

YouTuber who my team follows. He's

cautious about AI coding, but cautious

is different to 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 the hype. They got

permission from the skeptics. Sometimes

you don't win the argument, you just

outlast it and you let other people make

it for you.

But the process of trying to convert my

own team has made me think about

something much bigger. I think there's a

fork in the road in software development

right now. Two generations of software

developer. One being shaped before AI

existed and one being shaped now. The

gap between them is going to define the

next decade. On one side, you got

developers who learned how to code

before AI existed. That's my team, and

probably yours. They learned the syntax.

They learned languages by typing them

out character by character. Their craft

was in their fingers. I call them hand

coder software engineers, or hand coders

for short. On the other side, there

software developers that are learning

how to build software now with AI in the

editor from day one. They're not

learning like the hand coders did. I

call these AI native software engineers.

They won't sit there memorizing

JavaScript or Rust or Python syntax,

because they don't need to. The AI

handles that. What they'll learn is the

concepts, the architecture, computer

science principles, how memory gets

allocated, how a system scales. It's

going to be way more about architecture

than it is about syntax. It's not about

writing code anymore. It's about

structure, building, orchestration. AI

native software engineers become

managers of agents. They define the

system. They write the spec. Then they

set a fleet of agents loose, and they

review what comes back, and they test

it. And the important thing here is that

they're responsible for the code that

their agents produces.

But they don't write code by hand. They

don't need to. I think I'm an early

version of this. Yes, I hired developers

before AI, but I never learned how to

code. I learned to build software with

AI from the start. I architect the

system. I write the spec, and then I

pass it to Claude Code to build it. Then

I test the output. That's how I built

the scheduler. It started off as an

internal tool, and now it's a fully

working app, used in production by real

users, not a demo. And I didn't write a

single line of it by hand. I built it

the way I think an AI native software

engineer is going to be building

everything.

If you're hiring a junior dev in say 2

years time, or even less time than that,

the people applying for those jobs are

going to look very different from the

hand coders that 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. That isn't a

hypothesis, it's already happening. I

think a lot of people disagree with me

on this, but I'm 100% convinced this

happening. The question worth sitting

with isn't can an AI native software

engineer really exist? It's what does an

a 10X AI native software engineer

actually look like? The old 10X coder

ships software faster than anybody else.

What about the 10X AI native software

engineer? The one who doesn't write the

code, but orchestrates, manages,

reviews, and refines. What level of

output can that person actually achieve?

I don't know for sure, but I'm starting

to think they're already out there.

Maybe they'll be more of them than the

traditional 10X coders. Maybe every

company will have one.

If you're a CEO or CTO trying to push AI

coding into a team of hand coders, keep

pushing. Be patient, but pick AI native

software engineers when you hire. Most

of the rest will come around when the

evidence is loud enough. Probably faster

if it's coming from somebody 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.

Mind it. If this is useful, hit

subscribe. I'm documenting the entire

journey of building We Use AI, launching

it as a SaaS, the story as it happens.

Join my newsletter at axelmollest.com

for a more detailed version of what I

share here straight in your inbox. Next

video is why building software is the

easy part. The hard part is

distribution. A year ago, they called it

bad code. Today, they're using it daily

in production. The argument resolves

itself if you outlast it. See you in the

next one.