AI-Native Engineering Leadership: What Actually Changed

Augment Code asked 217 engineering leaders what "AI native" means. Gregor Ojstersek gives a definition you can operate on, then argues the more uncomfortable thing: the goal of engineering leadership never changed, only the shape of the day did.

---

Ask 217 engineering leaders what "AI native" means and you get answers running from just a buzzword, a marketing term for selling stuff, to the greatest thing since sliced bread. That gap is not philosophy. It is a buying problem.

Gregor Ojstersek opens this talk by refusing to let that stand. Twenty-plus years from engineer to CTO, now a fractional CTO, he has spent that time listening to engineers and managers through the Engineering Leadership newsletter.

A definition you can actually operate

His definition, written with Tibo Sotio, head of Codex at OpenAI, is a process description rather than a product category: continuously identifying and eliminating bottlenecks across the entire software engineering life cycle.

Notice what it does not say. It does not mention a vendor. It does not mention model choice. It says that you question the way you plan, the way you do strategy, the way you prioritise features, the way you resolve bugs, the way you generate code, and the way you review code.

Two of those are already shifting in front of us. AI code reviews are more and more common, and human code reviews are becoming more and more of a bottleneck. That is the single most useful sentence in the talk.

The answer nobody expected

Then he asks the question the whole room expects to be a keynote about disruption. What has actually changed in engineering leadership from one to two years ago?

His answer: there hasn't actually been a lot of changes.

The goal of engineering leaders has always been to do what is best for the team, their people, the organization, and the overall business. That has not moved. What moved is everything around it. The tools are totally different. The processes are different. The way people build stuff is different.

Eight hours in the zone

What used to make an engineer great was the ability to get in the zone and write code for eight hours straight. That day is not coming back. The day now is navigating AI and AI tools to do what needs doing, and the skills that make someone good at that are recognisably the skills of a great tech lead or a great manager.

He lists them without ceremony. Delegating. Dissecting bigger projects into smaller pieces. Giving feedback. Patience and perseverance.

Every engineer is becoming basically a tech lead. In startups and mid-size companies especially, engineers are owning solutions end to end. The leadership behaviour is not a new responsibility bolted onto the job. It is what the job already was, now applied to a different kind of teammate.

Managers, demoted to individual contributors

A lot of engineering managers are being sought after to become individual contributors again. Amazon was the first starter of this trend, and Meta and a lot of other companies started to do similarly.

His argument for why this is not bad news: the skills you learn as an engineering manager are the same skills you need to do AI-assisted engineering well.

When a company decides to raise the IC-to-manager ratio, his instruction is simple. Do not look at it as a demotion. As an IC you have more power, more responsibility and more ownership. You just do not have human reports directly.

Three roles, one job

Right now he sees a lot more tech leads and staff engineers, and the three roles in the middle are getting closer and closer together. Managers are taking more of the staff engineer's responsibilities. Engineers are asked to take end-to-end ownership from start to finish of a feature.

His read: fewer engineering managers, fewer pure architect roles, and a merge towards the software engineer being expected to have the skills and knowledge of a great tech lead.

Being good at many things is not a nice to have anymore, it is a must-have.

Generalists, and the specialists who set the standard

Two hiring profiles are emerging. Companies look for great generalists who can take end-to-end ownership across the full software development life cycle. They also look for someone really good at a specific rare technology.

The rare specialist keeps an automatic advantage: people want things to be performant, and they want to set good templates so every other engineer, and also AI, can replicate the great practices and patterns.

Two skills, not twenty

Asked what to focus on to become a great AI native engineering leader, he names two areas and admits AI tools are not one of them.

Human-related skills: leadership, teamwork, good communication, empathy and emotional intelligence.

Problem solving in general: being pragmatic and resourceful, knowing how to utilise different tools, having good business understanding, and having a deep understanding of a relevant topic.

His equation: good human skills plus good problem solving means you can learn everything you need to solve a certain problem and provide an impact. That is the whole toolkit.

Titles will change over the years and you cannot control them. But you can focus on making sure that you provide an impact. The goal of engineering leaders has always been to do what is best for the team. Everything around that got rebuilt. The goal did not move.

---

Source: Gregor Ojstersek, "AI-Native Engineering Leadership: How the Role Is Changing in 2026," Engineering Leadership LIVE by Augment Code, published 12 June 2026. Every figure and quotation checked against the full video transcript. Published by Su Qin, CMO of DXP.