I am leading an R&D team of around 300 engineers in Nokia's Packet Core portfolio. Telco Core software is an unforgiving place to run experiments: long-lived C and C++ codebases, 3GPP conformance, carrier-grade SLAs, and customers who notice network issues within minutes. It is exactly the kind of environment where "just add AI" goes wrong quietly and expensively. What follows is what I have learned, moving an experienced organization to an AI-native way of working — the parts that were harder than expected, and the parts that mattered more than the tooling.
Resistance is a signal, not an obstacle
The engineers who push back hardest are usually the ones who have watched tooling waves arrive and recede, and who carry the most domain scar tissue. Treating them as laggards to be managed is both insulting and strategically wrong — they are the people whose judgment you most need pointed at AI output.
Two things have mattered. The first is narrative sequencing: if AI arrives framed as the reason for reorganization, you have just told people the tool is there to replace them, and no enablement budget undoes that. Lead with the outcomes — quality and speed — and introduce AI as the enabler, not the cause.
The second is proof over mandate. Let a skeptic pick their own painful task — the legacy module nobody wants to touch, the test suite two years on the backlog — and ask them to measure before and after honestly, including the failures. Nothing converts like a two-day job finishing before lunch.
What I do not accept is quiet opt-out. Enthusiasm is optional; participation is not. Someone who has tried it properly and can say where it fails is exercising engineering judgment; someone who has not tried it and has opinions anyway is not.
"The instinct to route around skeptical senior engineers is one of the most common — and costly — mistakes we see in AI transformation efforts. This is a rare, candid account of doing the opposite."
Quality is where most AI programs quietly fail
AI changes the throughput of one step in the chain, not the chain. Code gets written two or three times faster, while review, integration and system verification run at last year's speed — gated by human attention and test execution time, not typing speed. So, the queue in front of review grows.
What happens next is a human problem, not a tooling one. A reviewer facing a 900-line change they did not write, with four more behind it, does not review line by line — they skim for shape. And AI-generated code has excellent shape: correct naming, consistent style, plausible error handling, comments matching our conventions. It looks like our code, which is what makes it dangerous. The defects that survive are semantic, not syntactic — a misread 3GPP procedure, a state transition right in the common path and wrong on re-establishment. They escape because review has degraded into pattern-matching, and they surface in a live network months later.
The response has to be structural. Asking people to review more carefully fails, because the incentive is throughput.
We use AI to write unit and functional test cases, and it is very good at it — coverage on branches nobody would have bothered with, error paths written the same day as the code. But one failure mode is easy to miss: when the same model writes the implementation and the tests from the same misreading of a specification, the tests may not catch the defect — they ratify it — a green pipeline proving the code does what the code does. The discipline that prevents it is easy to state and hard to enforce: tests must be derived from the specification, not from the implementation. Feed the test-generation context the 3GPP clause and the interface contract, not the diff.
That is precisely why we keep system test separate: an independent layer with its own ownership and derivation, validating observable network behavior against requirements rather than against our own code. Keeping AI out of system test is not conservatism; it protects the one measurement that is not correlated with everything upstream of it.
"Code review was built to catch typos and logic errors — not sophisticated mimicry. This section is the clearest explanation we have published of why AI-generated code is dangerous precisely because it looks correct."
The same tool amplifies different things
Something I observed first hand over the last year. For a strong engineer, AI is a power tool: they know what correct looks like in this domain, so they reject bad output in seconds and keep the 80% that saves them a day. A junior cannot reliably distinguish plausible from correct, and AI produces plausible with total confidence. The risk is not obviously bad code — it is code that passes review because it looks like ours.
There is a second-order cost too. Debugging skill is built by being stuck, and AI is extremely good at removing the experience of being stuck. So, juniors need stricter guardrails: smaller blast radius, mandatory senior review, and a rule that they can explain every line they submit and why the alternative was rejected. Otherwise, you build engineers who can ship and cannot debug — which, in a product running in live networks at three in the morning, is not a skills gap — it is an operational risk.
"This is the piece’s sharpest insight: AI does not level the playing field between junior and senior engineers. Left undesigned, it widens the gap."
New roles — which you will not be able to design up front
I should be honest about how these emerged. We did not draw an AI-native org chart at the start and staff it; nobody knows what such an organization looks like structurally. We started integrating AI, hit friction repeatedly, and noticed in about four months that certain work had no owner — the same problem kept recurring because it belonged to everyone and therefore to nobody. So, my advice is not "create these roles" but: watch for the pattern. Solving the same organizational problem is an unstaffed role announcing itself.
The AI enablement lead, embedded per area rather than central. Central enablement — training, shared guidance, a community of practice did not yield results. What mattered was not "how to prompt" but "how to get useful output from a twenty-year-old signaling module with undocumented invariants": domain-specific, perishable, and credible only from someone who works in that code.
The context owner. The same tooling produced dramatically different quality across teams, and the variable was documentation, not engineering skill. Current architecture notes and accurate interface specifications gave good output; drifted documentation gave confident nonsense, because the model filled the gaps. Documentation used to be a hygiene issue you could defer indefinitely; it is now an input to the production system, and stale specs are a direct defect source.
None of the above were in the transformation plan. All three are now load-bearing.
Metrics — measure the engine, but judge by the outcome
Our first measurement was wrong in the most seductive way: the numbers were excellent. Licenses deployed, prompts per developer, percentage of code AI-assisted — all climbing, all easy to collect, all reporting beautifully upward. It took a couple of months to admit we could not point to one thing that had gotten better for a customer. Those are activity metrics: they tell you people are using the tool, which you can see by walking around, and they are trivially gamed the moment they become a target. What replaced them works on two levels, and both are necessary.
System metrics tell you whether the machine actually changed: cycle time from commit to release candidate, complexity-normalized defect density, escaped field defects, review rework rate, and the split between new capability and maintenance. Watch the review queue — it is your earliest indicator, showing the imbalance between generation and verification weeks before it becomes a defect. These are the numbers you steer by week by week.
Outcome metrics tell you whether any of it mattered: content delivered per release train against what we committed to, schedule predictability, defects reaching customers, time to resolve customer-reported issues, and capacity moved from maintenance onto new capability. This layer answers the only question the business is actually asking.
You need both because they can diverge, and the divergence is the finding. Early on our commit-to-candidate time improved noticeably while release content did not move at all — we had not created capacity, we had relocated the bottleneck downstream. That is not a disappointing result; it is a precise diagnosis of where to look next, and either layer alone would have missed it.
One honest caveat: you will not get clean attribution. Three release trains a year, shifting scope, organizational change in parallel — no controlled experiment exists here, and a precise AI-attributable percentage is a number reverse-engineered to please someone. Set your baseline before you start, accept directional evidence, and be straightforward about the uncertainty. Overclaiming early is how these programs lose credibility with exactly the engineers you need on board.
If AI is working, both layers move — the system first, the outcomes a release or two later. If only the adoption numbers move, you have bought tooling, not transformation.
"Most AI transformation reporting stops at adoption metrics because they are easy to produce and always trend upward. This is one of the few accounts we have seen that insists on the harder, more honest number instead."
Closing
None of this is a rollout. Moving an established team to an AI-native way of working is a journey measured in release cycles, not quarters, and it has to be planned and instrumented as you go — because you will be wrong about several things, and you want to find that out from your own data rather than from a customer. It does not succeed without the buy-in of your experienced engineers and managers; they know what correct looks like, and any approach that routes around them produces speed you cannot trust. And it needs an open mind in both directions — real curiosity about what this technology can do, and equal honesty about what it cannot yet do safely in a system carrying live traffic. The organizations that get the most out of AI will not be the ones that adopted it fastest, but the ones that stayed clear-eyed about where to put it and where to keep it out.