Founder's Article · Pragmatic AI Software Engineering

We engineered through a war. Now we engineer past the AI hype.

N-iX founder Andrew Pavliv on the discipline that survives the AI cycle.

Andrew Pavliv, Founder and Chairman of the Supervisory Board, N-iX
Andrew Pavliv
Founder & Chairman of the Supervisory Board, N-iX
Scroll to read
I · The Car Park

Lviv, March 2022.

The chair was a folding one. Plastic seat, metal legs, the kind we stack in the back of meeting rooms. Someone from operations carried it down two flights of concrete stairs into the underground level of an office car park in Lviv, and put it next to a coffee machine that had been carried down the same way. The generator was wheeled in on a hand truck. The satellite dish was tied to the pillar at the entrance ramp using cable ties. The fluorescent strip overhead was on the same circuit as the lift, so when the lift was used the light blinked. During the worst weeks of March 2022, the air-raid siren in Lviv started, on average, every other day. The engineer who sat in that chair did not stop typing when it started.

He was working on a continuous integration pipeline for an enterprise customer in the United States. The customer's product team did not know about the car park. They did not need to know. What they knew was that pull requests were merged on schedule, that the nightly build was green, that the monthly invoice was sent on the date our contract specified. For the entire period of bombardment in our region, the pipeline did not lose a single build.

I want you to keep this picture in your mind. We will return to it.

Andrew Pavliv, N-iX founder, seated in an underground car park in Lviv.
Andrew Pavliv, founder · Lviv, the car park.
For the entire period of bombardment in our region, the pipeline did not lose a single build.
II · The Spending Problem

The spending moved much faster than the engineering.

Three years later, in July 2025, researchers at MIT NANDA published a study about the state of generative artificial intelligence in business. They examined three hundred public deployments of generative AI tools at large corporations. Their finding was that ninety-five percent of these deployments had produced no measurable impact on profit and loss. The previous year, in June 2024, Goldman Sachs published a similar conclusion in their report titled Gen AI: Too Much Spend, Too Little Benefit, that the spending had moved much faster than the engineering.

This is the fact that everyone in the corporate AI conversation is talking around. The chief information officers know it. The boards know it. The vendors know it, but they pretend they do not. Two trillion dollars of enterprise capital has been put into projects whose principal output, until now, has been demonstrations.

A demonstration is not a product. A demonstration is a performance. The lights are correct. The data is selected. The customer in the room is the customer who is going to be impressed. The system has been built to answer exactly the questions the customer will ask, and not one question more. When the demonstration ends, when the customer signs the order, when the system has to be deployed against the actual data of the actual organisation under the actual load of the actual production environment, the system does not work. The vendor offers an extension. The customer accepts. The pilot becomes a project. The project becomes a sunk cost. The sunk cost becomes a slide in the next quarterly board meeting, where it is described using the words "foundational learning".

Ninety-five percent of corporate AI projects produce no measurable impact on profit and loss. This is not a small problem.

95%

of corporate generative-AI deployments produced no measurable P&L impact.

MIT NANDA · JULY 2025 · 300 PUBLIC DEPLOYMENTS STUDIED.

$2T

of enterprise capital deployed, but the principal output, until now, has been demonstrations.

Goldman Sachs · Gen AI: Too Much Spend, Too Little Benefit, June 2024.

1 of 20

AI pilots survive contact with production. The rest become 'foundational learning' slides.

Synthesised from MIT NANDA + Goldman Sachs methodologies.

Our chief technology officer, Valentyn Kropov, says it more directly than I would. "Most of these failures are not failures of AI. They are failures of project selection. Somebody picked the wrong problem. Somebody built a chatbot when the company needed a parser. Somebody bought tokens from OpenAI when the company needed a database." He has been an engineer for twenty-five years, and he has the contempt of a real engineer for work that is impressive in a meeting and useless in a server room.

What he is describing is an industry-wide failure to distinguish between two kinds of work. There is the work that survives a slide deck. And there is the work that survives a Tuesday morning at 9:13 in the morning, when a customer in Stuttgart has clicked the wrong button, and the system has to recover correctly, or the company receives a phone call from an angry chief operating officer. The first kind of work is the kind most enterprise AI has been until now. The second kind is the kind that pays.

In our industry there is a phrase, "demoware is debt". I think this is the right phrase for the present moment. The bills come the moment the demonstration ends.

Most of these failures are not failures of AI. They are failures of project selection. Somebody picked the wrong problem. Somebody built a chatbot when the company needed a parser.

Valentyn Kropov · CTO, N-iX
III · What it looks like when it works

An antenna.
De-icing fluid.
A pattern nobody had seen.

There is an aviation company in the United States called Gogo. They provide the broadband internet on commercial flights. The maintenance industry has a name for the pattern that was eating their antennas. It is called no-fault-found.

The thing on the underside of the aircraft that pulls signal from the satellite is an antenna, and antennas on commercial aircraft have a specific maintenance pattern called no-fault-found. The airline pulls the antenna because the system reports a fault. The maintenance team examines the antenna. The maintenance team finds nothing wrong with it. The antenna is reinstalled on the aircraft. Everyone is unhappy. The airline has paid for the maintenance window. Gogo has paid the airline for the downtime under their service contract. The antenna fails again three weeks later, in the same way, for the same reason that nobody has yet identified.

Gogo had been living with this for several years. The no-fault-found rate was a line on their operating losses that everyone had stopped looking at because nobody could see what to do about it.

We took this project. We started where every credible AI engagement should start: by assessing whether their data was ready to be acted on by a model in the first place. Our team migrated their on-premise data infrastructure to a cloud architecture, built a unified data platform aggregating more than twenty source streams from the antennas, the maintenance records, and the flight telemetry, and trained predictive models on the combined picture. The models began to anticipate antenna failures with better than ninety percent accuracy, twenty to thirty days in advance. The pattern is the same one our chief technology officer, Valentyn Kropov, has written about in the context of AI site reliability engineering: most production failures take longer to diagnose than to fix, and the value of an AI-driven system sits in the minutes between detection and resolution. The no-fault-found rate dropped by seventy-five percent.

But the seventy-five percent number is not the real story. The real story is what the models found.

The antennas were failing after the application of de-icing fluid at certain northern airports during certain months of the year. The chemical was reaching the antenna housing and working through the seal in a slow chemistry that had not appeared in any laboratory test, because no laboratory had thought to run that specific test. Once the pattern became visible in the data, Gogo's engineers added a protective layer to the antenna housing. The failure mode stopped. The savings went directly to operating profit.

This is what an AI project looks like when it actually works. The model produced a finding. The finding was specific. The finding could be acted on. The action was physical. The physical action ended a problem that had been costing real money for many years. There is no demonstration here. It is only an aircraft antenna, a piece of de-icing fluid chemistry, and a software pipeline that joined them together long enough for a human engineer to see the connection. The data engineering and the AI engineering were the same team, working from the same backlog, against the same audit trail. Most of the failures we see in our industry come from the gap between those two functions. We do not run that gap.

01

Start where it matters

Assess whether the data is ready to be acted on by a model. Migrate on-premise to cloud. Build a unified data platform aggregating 20+ source streams.

02

Train on the combined picture

Predictive models anticipate antenna failures with >90% accuracy, 20-30 days in advance.

75% drop in no-fault-found
03

Find the cause nobody looked for

De-icing fluid at certain northern airports, in certain months, was reaching the antenna housing and working through the seal in a slow chemistry no laboratory had tested.

04

Savings to operating profit

Gogo's engineers added a protective layer. The failure mode stopped. The model produced a finding. The finding could be acted on. The action was physical.

IV · The Bank Work

A European bank. Two million customers. 260 branches.

A European bank with two million customers and 260 branches has been working with our team since February 2023 on what looks, from outside, like a less interesting project. It is the work of moving the bank's backup and disaster recovery infrastructure off on-premise data centres and onto a secure AWS landing zone, with disaster recovery plans that satisfy the European Central Bank's auditors. It is the work of running a comprehensive Well-Architected Review across the bank's critical workloads, including identity management, transaction processing, and customer data before a single workload is migrated. It is the work that no demonstration can do.

The bank does not lose data, and it does not fail an audit. It also does not have to explain why a system run by a US-headquartered cloud provider has been required, under the US CLOUD Act of 2018, to surrender customer records without warning. We were one of a small group of partners selected for the AWS European Sovereign Cloud at its launch in January 2026. The credential matters because the regulatory perimeter in Europe like DORA, NIS2, the EU Data Act, the proposed Cloud and AI Development Act, has moved very fast in the last eighteen months, and most of our customers in regulated industries have not yet adjusted their cloud architecture to keep pace.

The discipline that prevents these regulatory non-events from becoming events is the same discipline that makes the Gogo project succeed. It is engineering. There is no magic. This is what we call Pragmatic AI Software Engineering: the practice of earning the right to scale on production systems through evidence, rather than demonstrations.

AWS European Sovereign Cloud
Launch partner · January 2026
Regulatory perimeter
DORA · NIS2 · EU Data Act · Cloud & AI Act
Customer estate
2M customers, 260 branches
Engagement start
February 2023, and ongoing
Pragmatic AI Software Engineering: earning the right to scale on production systems through evidence rather than demonstrations.
V · Return to the car park

The plans were not improvised. They were rehearsed.

Now I want you to think again about the car park.

The reason the pipeline did not lose a build during the bombardment is that the business continuity plans had been written eight years before the bombardment began, after the annexation of Crimea in 2014, and revised through the autumn of 2021. The plans named which engineers would relocate to which cities. The plans named which contracts our company carried with backup power providers in Western Ukraine. The plans named the satellite dish vendor and the lead time for equipment delivery. When the invasion began, six hundred of our engineers relocated within the opening days. Three independent power stations supplied our new offices in Kyiv. Service delivery to our customers ran above ninety-five percent through the worst quarters. Sixteen new enterprise customers signed contracts with our firm in March 2022, the month when the world expected Ukrainian companies to collapse. Our revenue grew thirty-five percent in the twelve months that followed.

These plans were not improvised. They were rehearsed. The architectural patterns underneath them are drawn from the Carnegie Mellon Software Engineering Institute, adapted by a Ukrainian software architect who is now serving as a colonel in our military intelligence. By the time that chair was actually carried down the stairs, every engineer in our company had read the plan and trained against it.

This is the discipline that makes the Gogo project possible. It is the same discipline. Pragmatic AI Software Engineering is what we call this discipline when it meets the AI cycle. Every engagement we begin starts with a written hypothesis about which line of the customer's profit and loss will move. Every engagement carries a kill criterion that the customer agrees to in writing, before the first sprint. Projects that miss the criterion are killed, and not extended. Most firms in our industry that quietly extend their failed pilots because nobody on the vendor side wants to send the cancellation invoice. We send the cancellation invoice.

A firm that has practised an eight-year continuity plan against war is not going to take a customer's two-hundred-thousand-dollar monthly cloud bill and watch it grow because nobody asked the question whether the model was the right tool. (One US-based software company we work with had been spending approximately that amount, every month, to use a frontier model for tasks that could be handled by a Python parser at one hundredth of the cost. We rebuilt the pipeline. The bill dropped by an order of magnitude. The accuracy went up.) A firm that has shipped software through bombardment is not going to ship a chatbot when the customer needs a parser.

2014

Continuity plans first written, after the annexation of Crimea.

Autumn 2021

Plans revised with named engineers, named cities, named vendors.

Feb 2022

600 engineers relocated within the opening days of invasion.

March 2022

16 new enterprise customers signed in the month the world expected collapse.

95%+
Service delivery through the worst quarters
600
Engineers relocated in the opening days
+35%
Revenue growth in the 12 months that followed
VI · The four-tier AI engineering ladder

Not ad-hoc AI training labelled as transformation.

The company is called N-iX. We were founded in Lviv in 2002, with engineers whose backgrounds were in Linux and Novell systems. A heritage that predates most of the categories the industry now uses to sell itself. Today our firm runs engineering operations across nine countries: Ukraine, the United Kingdom, the United States, Poland, India, and four others, with headquarters in Malta. In 2015 we co-founded the Lviv IT Cluster, the regional industry consortium modelled in spirit on the cooperative dynamics that produced Silicon Valley and Boston's Route 128. The Cluster is now home to approximately two hundred software firms. We are one of them. Most of those two hundred firms compete with us for engineers in the same university towns, and for customers in the same European and American markets.

I mention this because the differentiation question is not abstract for our company. We do not pretend the Lviv market is empty. We compete on two specific things. We run smaller sales margins than most of the regional comparison set, which lets us pay our engineers more and retain them longer. And we have invested in turning conventional software engineers into AI-augmented engineers under a defined competency framework, rather than running ad hoc AI training sessions and labelling the result a transformation.

We are committing in public to that framework. We have built a four-tier AI engineering ladder, calibrated to published research from Microsoft, GitHub, Anthropic, and Stack Overflow, not to vendor benchmarks. Level 1 is the engineer who uses AI coding tools fluently and knows where the tools fail. Level 2 is the engineer who designs the context that the AI model receives, rather than only accepting what the model produces. Level 3 is the engineer who designs the workflow itself, including which models are used for which tasks and where human review is required. Level 4 is the engineer who governs the AI estate at the organisational scale, who maintains the AI bill of materials, and who answers the auditor's questions when the auditor arrives.

L1 · AI-ASSISTED ENGINEER

Uses AI tools daily for scoped tasks. Reviews every output. Knows when not to trust the model.

Target: 100% of engineers by Q2 2026
VII · Public 2026 commitments

We have 2,400 engineers. Small enough to be checkable.

By the end of the second quarter of 2026, every engineer in our company will be qualified at minimum Level 1. By the end of 2026, sixty percent of our engineering organisation will be qualified at Level 2, and fifteen percent will be qualified at Level 3. Our first quarterly report against these numbers will publish in June 2026. We are not setting a public 2026 target for Level 4, because Level 4 is a governance role, and the right number for it depends on customer demand for that level of assurance, which we are still measuring.

Larger offshore consultancies reported that they have trained hundreds of thousand their engineers on generative AI. These are real efforts and the absolute numbers are larger than ours. They are also impossible for any customer to verify at the scale of the claim. We have two thousand four hundred engineers. The number is small enough to be checkable. As Valentyn puts it: the question is not how many engineers a firm has trained, but which ones can ship.

By Q2 2026 / End of 2026
Level 1: AI-assisted engineers (by Q2 2026) 100%
Level 2: AI-augmented engineers (by end of 2026) 60%
Level 3: AI workflow architects (by end of 2026) 15%

The question is not how many engineers a firm has trained. The question is which ones can ship.

Valentyn Kropov · CTO, N-iX

I want to say one final thing about the car park, and then I will finish.

Sometime in late 2022, after the immediate crisis had passed, a colleague from operations took the chair out of the car park and carried it back upstairs. I do not know what happened to it after this. But by that point, our company had a different chair. We had built the version of the chair that does not need to be carried anywhere, because the discipline of continuity had been rehearsed into our business so thoroughly that the next car park already has its own chair, and its own coffee machine, and its own high-speed Starlink internet access satellite dish, and its own engineer who knows the protocol.

This is what we are selling now. Not the car park, which was a moment in our history. We are selling the version of the chair that is already in the place where it needs to be when the next thing happens, whatever the next thing turns out to be. In the present cycle, the next thing is artificial intelligence. The cycle that comes after this one will be something else. Most of what is being marketed today as AI capability will not survive contact with a real production system, in the same way that most of what was marketed as digital transformation a decade ago did not survive contact with a real customer.

The work that survives
is the work that was engineered for survival.

We learned this in a car park.