Coding Got Faster. The AI Gain Leaks Out Everywhere Else

A year of conversations with Polish engineering leaders and one case study: where the AI gain gets lost, and how to measure it in three months.

A year ago, Polish IT leaders told us AI would speed up coding and push bottlenecks downstream. This autumn, that is exactly what we hear: code gets written faster, and the gain leaks out in review, testing and task preparation.

The question leaders bring to us has changed too. It is no longer “how do we go faster?” but “where are we losing the AI gain, and how do we measure it?”

To answer it, we combined three sources: our autumn 2025 report, based on a survey of more than 150 IT leaders in Poland, CIONET Poland’s State of AI Adoption 2026 report, and our conversations with engineering leaders in 2026. Then we show what one survey revealed in a 250-engineer organization.

A year ago, leaders predicted exactly this

In October 2025, Polish IT leaders put speed ahead of quality. In the US, the order was reversed. That was the starting point of our report Polish DevEx: data, processes, AI (in Polish).

Speed before quality. 51% of Polish leaders named speed as their biggest delivery challenge; 17% named quality. Among US leaders asked the same questions: 24% and 41%. The report summed it up as “chasing speed, losing quality.”

No time, not no tools. 71% had no time to improve processes; 25% had no data on what to improve. Only 4% named tools as the blocker.

Clarity first. 54% said planning and clarity matter most for engineers’ work. Code quality got 26%, testing and reliability 20%.

Leaders already expected AI to speed up coding and move the bottleneck downstream. A medtech CTO told us a feature that used to take two days now took two hours, but five developers now needed three testers. The report called this “local optimization with AI”: one stage gets faster, and the queue builds up at the next one.

“Now two developers can generate as much technical debt as twenty used to.” — CTO, devtech

A year later, the gain leaks out before and after coding

This autumn, coding is clearly faster. What leaders discuss now is where the gain disappears. The quotes below come from our conversations and are anonymized.

• In one technology organization, lines added keep growing while lines deleted do not: “systems are growing faster.” Its leader “strongly doubts” this turns into real results.

• Review takes a growing share of the work. How big a change is allowed to be has become a dispute between teams.

• Most of the path from idea to production happens before anyone writes code: in business decisions, legal sign-off and clarifying tasks. In one organization, that is about three quarters of time to market.

• Engineers in another organization keep roughly half of their understanding of the code at about three-quarters automation. They call it a fair trade-off and deliberately make agents ask more questions.

• Management expects engineers to run more and more agents in parallel. Some engineers report fatigue and are thinking of leaving; senior leaders do not see it.

“People are turning into people who wait for pull requests, not people who write code. They’re burning out, because they’re checkers, not creators.” — VP Engineering, e-commerce

Everyone measures. Nobody trusts the numbers

That was the main takeaway from CIONET Poland’s TRIBES Day in October. More than half of companies build their own measurement tools and mix data without a consistent method; unsure what to measure, they “measure everything, just in case.” A panel on “apparent efficiency” named the problem: it is getting harder to tell real growth in delivered value from the growing cost of running the ecosystem itself.

Boards expect a return on AI in FTEs and money, “ideally in millions.” What they get: license counts and token usage.

• In a medtech company, the cost of AI coding tools became visible on invoices when billing moved from subscriptions to tokens. Their effect on how software gets built is not visible.

• In an extensive engineering excellence program, AI Adoption is the only pillar without a single metric.

• We often hear, from VPs of engineering and heads alike: “I don’t have actionable data.”

“In the HR engagement survey everyone pats each other on the back and it all looks great. The metrics in the tool look good too. But when someone in the corridor dares to be honest, it’s not rosy at all.” — IT Director, medtech

Leaders recover the gain before the first prompt

The teams that get the most out of AI moved it upstream, into the preparation of work. They spread it through people, not mandates.

• In the best teams of one technology organization, decisions and specifications live in the repository, next to the code. With well-split tasks, implementation takes a few days.

• In e-commerce, an agent keeps asking the product owner questions until a task meets the Definition of Ready. Other agents split epics into tasks.

• Instruction files for agents (such as CLAUDE.md) no longer set teams apart, because most teams have them. Code size and modularity make the difference.

• A team with a champion nearby adopts agentic work in one to two months. Without one, it can take six.

• A centrally rolled-out self-review tool was rejected. A skill built by the engineering community won.

• A VP Engineering in e-commerce set a quarterly goal of “review by the next working day” in a way that let teams own it. They reached it in six weeks.

Polish CIOs: AI won’t fix a broken process

CIONET Poland’s State of AI Adoption 2026 sums up interviews with 13 technology leaders from banking, energy, logistics and e-commerce. Its main conclusion: the Polish market “has moved from fascination to pragmatic verification of AI’s value.”

Data and processes come first. According to the report, AI applied to “organizational mess and poor-quality information” only gives you “a faster mess.” Practitioners at TRIBES Day advise against waiting for a big clean-up program: fix data piece by piece, with each rollout.

The return on AI can and should be measured. “The era of investing with eyes closed is over.” Paweł Leżański (CTO of Ringier Axel Springer Polska until June 2026) adds that there are no “AI KPIs,” only organizational ones. Counting lines of code generated by a model, he says, misses the point.

The gain is throughput, not headcount cuts. According to Leżański, teams deliver “a fifth more value within the same budgets.” Daniel Korzeniowski (Żabka Polska) warns that FTE savings don’t always show up in the P&L.

AI projects fail on people. Marcin Mazurek (Bitropy): “Transforming how software teams work will be the most serious challenge for every modern CTO in the coming quarters.” Krzysztof Dąbrowski (COO, mBank): “Let’s delegate routine to machines, but never delegate thinking.”

Case study: what a good AI-assisted SDLC survey shows in three months

We measure two kinds of data: data from systems (repositories, CI/CD, incidents, AI token usage) and survey data from engineers. The easiest place to start is the survey. The first measurement shows where you lose the AI gain and how much is left net; the second, three months later, shows whether the changes won it back.

Here is how it looked in a technology organization we work with, with about 250 engineers. The data is anonymized, and hours are self-reported by engineers.

How much of the gain is left net. Net AI gain is the time AI saves minus the time spent checking and fixing AI code. In this organization, the annualized, self-reported net gain grew from 26,000 hours (about 14 FTEs of capacity) in the first measurement to 39,000 hours (about 22 FTEs of capacity) in the second. Time spent checking and fixing stayed the same, so all of the growth came from more time saved. In the second measurement, checking and fixing still took about half of the time AI saved.

Where the work is stuck. Closed questions show how engineers rate working with AI and which scores moved between measurements.

Where the gain leaks out. 72% of engineers say AI writes most of the code in their merge requests. An open question shows what happens to that code next.

AI code is rarely just wrong. More often it is too big and doesn’t fit the project, so checking it is expensive. We looked at what engineers fix most often in The #1 Reason AI Code Gets Reworked Isn’t the Model. It’s Missing Context. The open answers also show what metrics don’t: verification moves to the end of the work, and AI-driven review can get stuck in fix loops.

“I’d say the same as before. We just produce more code, more often, so we hit bottlenecks more often.” — engineer

“There’s more testing required in the end. Since I don’t write that code myself, I need to double check everything at the end, instead of testing stuff simultaneously while I code.” — engineer

“Asking AI to do the code review often means it keeps finding problems that the AI itself fixed earlier.” — engineer

How to win the gain back. Based on these results, the organization chose five changes that take the AI gain beyond coding:

• smaller changes and self-review before asking for review;

• context and instructions for AI in every repository;

• readiness criteria before a task goes to AI;

• rules enforced automatically in CI, not just in AI instructions;

• one AI policy for the whole organization, with practices grown by champions in teams.

Did the changes work? Repeating the survey after three months, using the same method, helps show whether the net AI gain grows, review gets easier and the blockers lose weight. Changes under about 5 points are within the stated measurement error, so smaller movements should not be treated as clear changes. This organization has already completed two measurements. The next measurement will check whether the five changes improve ease of review and the net gain. The survey results can then be matched with system data, such as review time and change size.

Measure the gain in hours, not tokens

Licenses and tokens tell you what AI costs. They don’t tell you what it gives back, or where the gain leaks out. Net hours do: time saved minus time spent checking and fixing AI code, measured the same way twice.

The simplest place to start is one survey of your engineers. Three months later, a second one shows whether the changes worked. You can see what the results look like in our demo.

AI already creates the gain. The work now is keeping more of it on the way to production.

Sources

• Network Perspective, Polish DevEx: data, processes, AI (in Polish), October 2025: a survey of more than 150 IT leaders in Poland (53% C-level and heads of departments, 40% team leaders, 7% staff engineers and ICs); the same questions were asked to 250 leaders in the US.

• CIONET Poland, State of AI Adoption 2026, September 2026: interviews with 13 technology leaders; registration required; quotes translated from Polish.

• CIONET Poland and Digital Excellence Group, TRIBES Day 2026, Warsaw, 15 October 2026.

• Network Perspective conversations with engineering leaders of large organizations operating in Poland, September–October 2026; quotes anonymized and translated from Polish.

• AI-assisted SDLC survey in a Network Perspective client organization, two measurements with the same method; data anonymized, hours self-reported by engineers, some quotes translated from Polish.