I asked the VP of Engineering at Augment what "AI-native" actually means
Most companies are adopting AI. Very few are changing how they work.
👋 Hey, it’s Stephane. I help engineers become great engineering managers - whether you want to become one or are already leading a team.
Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.
Where AI Adoption Stalls (sponsored)
Most teams experience the same pattern: developers become more productive, yet organisation-wide delivery barely changes.
The problem isn’t the AI tools - it’s the system around them.
This paper introduces the AI Adoption Ladder, explaining why gains flatten, the nine stages of AI coding adoption, and the bottleneck that prevents teams from reaching the next level. If you’re leading engineering, this framework will help you understand where your organisation is today and what comes next.
Thanks to re:cinq for sponsoring this newsletter!
Every engineering leader seems to be talking about becoming AI native.
The problem is that nobody agrees on what that actually means.
For some companies, it means buying Cursor licenses.
For others, it’s replacing engineers with agents.
For others, it’s simply encouraging people to use ChatGPT more often.
The phrase gets thrown around constantly, but very few people explain what actually changes once a company decides to become “AI native”.
A few weeks ago, Brian Kramer from Augment Code reached out after reading this newsletter. Instead of pitching their product, he suggested I speak with their VP of Engineering, Vinay Perneti, about the journey they’ve been documenting publicly.
That interested me because engineering managers are trying to answer much harder questions:
How do you stop AI-generated code becoming a black box?
What skills actually matter now?
How does hiring change?
What does an engineering organisation look like when agents are involved every day?
So I sent Vinay eight questions.
Here are the answers that stood out.
“AI-native” isn’t a destination
The first thing that surprised me was how Vinay defines AI native.
He doesn’t.
Or rather, he doesn’t think it can be defined as a fixed destination.
Instead, he sees it as an organisation that continually redesigns how work gets done as AI capabilities evolve.
Many companies are treating AI adoption like previous tooling migrations.
“We’ve bought the tool.”
“Everyone has access.”
“Job done.”
That’s not transformation.
That’s procurement.
The interesting organisations aren’t using AI to write code faster.
They’re reassessing their whole SDLC for the modern era.
Writing code is becoming a smaller part of the job
One answer stuck with me more than any other.
Vinay said the hardest part of becoming AI native isn’t the tooling.
It’s accepting that the role of a software engineer is changing.
For years, our identity has been tied to writing code.
Now the highest leverage increasingly comes from:
defining problems
reviewing intent
steering agents
making architectural decisions
deciding what should be built
The implementation itself is becoming easier.
This doesn’t mean engineers disappear.
Ironically, as code becomes cheaper to produce, good engineering judgement becomes more valuable.
Giving everyone an AI coding tool isn’t enough
This was probably my favourite answer.
Vinay said the biggest mistake organisations make is believing the transformation ends once every engineer has an AI coding assistant.
I completely agree.
Software development has never been an individual sport.
Making one engineer twice as fast doesn’t automatically make the organisation twice as productive.
If product decisions still take weeks...
If priorities constantly change...
If pull requests sit around waiting for review...
If nobody understands why decisions were made...
AI simply helps you reach those bottlenecks faster.
Engineering managers should probably spend more time asking:
“What parts of our delivery process no longer make sense and how can we leverage AI in them?”
Shared understanding matters more than ever
84% of engineering leaders worry about losing shared understanding of their codebase as AI generates more code.
That’s a concern many of us have.
We’ve spent years encouraging engineers to read code, understand systems and build context.
If AI writes significantly more of that code, how do you stop knowledge becoming concentrated inside prompts and chat histories?
Vinay’s answer was interesting.
His engineers stay heavily involved in specification reviews before implementation starts.
Then AI helps explain pull requests and the intent behind them during review.
In other words, they don’t just review code.
They review why the code exists.
I suspect we’ll see much more of this over the next couple of years.
Hiring is already changing
I also asked what makes a great engineer today that wasn’t as important two years ago.
The answer wasn’t “prompt engineering”.
It was learning velocity.
The strongest candidates aren’t necessarily the ones who can solve the hardest algorithm question.
They’re the ones who rapidly adapt, experiment and figure out new ways of working.
That aligns with what I’m seeing.
Technical ability still matters.
But curiosity is becoming a competitive advantage.
So... will software engineers still exist?
I had to ask.
Vinay doesn’t believe software engineers disappear.
Neither do I.
But I do think the role becomes much broader.
You’ll still need engineers.
You’ll just expect them to think more about product, architecture, systems, business trade-offs and orchestration than writing every single line themselves.
Software engineering becomes one capability rather than the entire job.
That feels like an important distinction.
Final thoughts
Whether you agree with every prediction or not, one thing feels increasingly obvious.
AI isn’t simply changing how engineers write code.
It’s changing what engineering teams optimise for.
The organisations that benefit most will be the ones willing to rethink how software gets built end to end.
