This review is a sponsored partnership with KRONE consulting.
MAIN Next: AI-Driven Software Delivery and Human-Centric Innovation is a 298-page methodology book by Peter Svoboda, Jan Krupička, Petr Neugebauer and Viktor Michač, four practitioners with long QA careers behind them in Czechia and Slovakia. It does not ask you to throw out Scrum, Kanban or SAFe. It sits on top of whatever you already run, adding roles, metrics and governance for the situation most of us are now in, where a machine produces a large share of the work and a person is still accountable for what gets released into production.
I read a lot of writing about AI and software delivery, and most of it has the same defect. It counts what the AI produced and stops counting there. This book does not do that, and that is the reason it is worth your time.
It measures the part that usually goes unmentioned
The idea running through the whole book is that AI assistance has two sides and that teams only ever measure one of them. Chapter 3 introduces what the authors call the Efficiency Multiplier, and then immediately qualifies it:
“A feature delivered with heavy AI assistance might appear to have fewer direct human hours, but if the overhead for setup or oversight is high, then real productivity gains may be less than they seem on the surface.”
From there the book builds out a set of measures I have not seen assembled before. There is an Overhead Coefficient that captures the time spent reviewing outputs, tuning prompts and re-running jobs. There is a split of every backlog item into three categories: fully AI-driven, AI-assisted with human refinement, and human-led. There is a Prompt Success Rate, the proportion of generations accepted with only trivial edits, which the authors suggest tracking separately by functional area, by task type and by individual, because a power user and a novice on the same team will produce very different numbers. And there is an Error Density measure for defects attributable to generated code per unit of that code.
None of these are difficult to start collecting. What they do is make the correction loop visible in the same place as the productivity claim, so the two can be compared rather than one standing in for the other.
Google’s DORA team arrived at a similar conclusion from an entirely different direction. In The ROI of AI-assisted Software Development, published in early 2026, they modelled the effects of AI adoption across 10 outcomes. The largest effect was on individual effectiveness, which is the finding everyone quotes. The second largest was on software delivery instability, which is the finding almost nobody quotes, and DORA describe the mechanism:
“AI-assisted coding can increase the volume and velocity of code generation, overwhelming existing deployment pipelines and manual review gates.”
They call it the instability tax. The MAIN Next authors reach the same conclusion as the DORA team: measure the gain and the cost separately, or the gain will be overstated.
Reviewing generated code takes more seniority than writing it
Buried in chapter 7, in a paragraph about mandatory human review of generated components, is this:
“This might imply higher requirements for expert skills of the reviewing personnel and on a long scale, would lead to a shift from need of IT routine work personnel to highly qualified staff.”
That is a large claim in a small sentence. Reading generated code thoroughly is harder than writing the equivalent code yourself, because you have to reconstruct intent you never formed, in work that is fluent enough to look finished. So the volume of work requiring senior judgement goes up at the same moment as the volume of routine work that used to produce senior people goes down. The book states the shift and moves on to the next bullet, and I would have liked to read more on it.
It matters because the measurement problem the authors identify in estimation shows up again in review, and there it is already distorting numbers teams look at every week. I have been applying the book’s split to review data across a set of open source repositories, counting the reviews a machine performed separately from the ones a person submitted, and found the two counts are a long way apart.
The book’s tendency is spot on: separate the AI-assisted work from the human work before you report either. Most teams already have dashboards mixing the two, reporting a number that improves while the thing it is supposed to represent gets worse.
Chapters 7, 9 and 10 are where the authors’ careers show
MAIN Next is strongest wherever the authors are drawing on their own experience, and they have spent their careers in QA. Chapter 7, on quality and security, is the best chapter in the book. It works through data poisoning, adversarial inputs, model inference and reverse engineering, and social engineering at scale, which is a standard enough list. Then it adds a category most security writing on AI leaves out entirely: humans as a vulnerability surface in their own right, covering data leakage through prompts, incorrect use of approved tools, and insider threat against training and evaluation data. That section alone is well worth getting and reading the book!
Chapter 9 on metrics and chapter 10 on estimation are the practical core, and chapter 10 states that estimation in this environment is unstable and explains why: model versions change, data quality shifts, and per-person variance in prompting skill is large enough to swamp a team average.
The case study on railway signalling under SIL1 to SIL4 and the move to ETCS is the one I would show to a delivery manager first. It is specific about which activities went to a model, where AI-generated code was acceptable for lower safety integrity levels, and where sign-off stayed strictly human for SIL4 route logic. That is a real answer to the question of how far you let this go, from a domain where getting it wrong can not be fixed with a rollback.
If I wanted more of anything, it would be evidence of that quality throughout. Most of the six case studies are anonymised as Company A through Company F with round outcome figures and no note on sample, window or how the number was derived. I would trade several of them for one where the organisation is named and the working is shown. The book is also a little longer than its argument requires, because every chapter summarises itself and then previews the next one.
Four measures to take into your next retrospective
If you are a test manager, QA lead or delivery manager, particularly in finance, healthcare, automotive or rail, this is a useful book and chapters 7, 9 and 10 will pay for it on their own. If you are an executive looking for a business case, the opening chapters stay general, so read them alongside the DORA report.
The most useful thing to do with it is to ask what your team’s actual numbers are: how much of last sprint was AI-assisted, what the overhead on that work was, what proportion of generations were usable first time, and how many of your reviews were performed by a person. Most teams cannot answer any of those, and the book is at its best where it makes that obvious.
MAIN Next: AI-Driven Software Delivery and Human-Centric Innovation, Peter Svoboda, Jan Krupička, Petr Neugebauer and Viktor Michač, 2025.
#ad #SoftwareTesting #QualityEngineering #AIinTesting #SoftwareDelivery #TestManagement #MAINNext