AI-native engineering leadership means leading teams where AI performs more of the execution, so judgment becomes the scarce resource rather than throughput. The shift is from managing how much gets built to managing which problems are worth solving, what context the model lacks, and who remains accountable when output is plausible but wrong.
The bicycle for the mind became a jetpack, and most organizations are still using it to fly in circles.
For thirty years the binding constraint on software teams was execution capacity. Everything we built as managers — estimation, sprint planning, velocity, headcount planning — exists to allocate a scarce supply of implementation. When implementation stops being scarce, every one of those tools is measuring the wrong thing.
The failure mode is not that AI writes bad code. It is that it writes plausible code very quickly, and an organization optimised for throughput has no mechanism for noticing that it is now producing confident answers to questions nobody checked were the right questions.
The framework I use splits the problem into three, because the answer is different at each level.
Product layer. When building is cheap, the cost of building the wrong thing goes up, not down. The scarce skill is deciding what deserves to exist. Discovery and problem selection become more valuable than delivery speed, which is the reverse of the last decade's instinct.
Team layer. Juniors can now produce senior-looking output, which breaks how we assess and grow people. If you evaluate on artefacts, you will promote people who cannot yet reason about what they shipped. Evaluation has to move toward the quality of the decision and the ability to explain the trade-off.
Leadership layer. Accountability cannot be delegated to a model. Someone has to own the outcome when the output was plausible and wrong, and that person needs enough context to have known better. This is the layer most organizations have not touched at all.
Intelligence is the capacity to find an answer. Wisdom is knowing which answer is worth having, and what it costs to be wrong. We have just made the first one abundant and the second one no easier.
Practically, this means the leader's job shifts from removing obstacles to execution toward supplying the context a model cannot have: what the customer actually meant, what broke last time, which constraint is real and which is habit, and who is going to live with the consequence.
Three changes are worth more than any tooling decision:
This is the substance of Smart but Not Wise, delivered as a keynote at ELC Prague and as the closing keynote at AWS Community Day Romania. The day job behind it: leading Stripe's Bucharest engineering site and the platform 8,500 operators worldwide use to run risk, compliance and financial crime operations.
Yes, and the distinction is the whole point. Adopting tools changes how fast a team executes. Being AI-native changes what you manage: you stop optimising throughput and start optimising judgment, problem selection and accountability. Most organizations have done the first and not the second.
It means the shape changes more than the size. Demand for implementation capacity falls; demand for people who can decide what to build, supply missing context and own outcomes rises. Teams that only measured output will conclude they need fewer people and be surprised by what breaks.
By moving assessment from artefacts to reasoning. Ask what was decided against and why, which parts they are unsure about, and what they would check first if it broke at 3am. Output has stopped being a reliable signal of understanding.
Treating AI adoption as a productivity programme with a tooling budget and a rollout plan. That framing generates more output and no more judgment, which is the opposite of what has become scarce.
It is the title of the keynote. Intelligence — finding an answer — is now abundant. Wisdom — knowing which answer is worth having and what it costs to be wrong — is not, and no model supplies it for you.