Engineering
Writing code stopped being the constraint. What holds a release back now is everything that comes after it: reviewing it, testing it, and knowing it will behave the same way on a shop floor as it did on a laptop.
AI moved the bottleneck from writing to verifying.
Ninety per cent of software teams now use AI daily, and it shows in the output: more pull requests, more tasks closed, more code shipped per engineer. It also shows further down. Median time in pull request review has risen sharply, thirty-one per cent more pull requests now merge with no review at all, and studies put security weaknesses in roughly forty per cent of assistant-generated programs.
So the discipline that pays has changed. It is no longer about producing faster, it is about verifying at the speed things are now produced: tests that are generated and then pruned, review that is a gate rather than a formality, and a delivery chain where a change proves itself instead of being vouched for.
The same rule holds when software leaves the data centre. On a shop floor, on a substation, inside a vehicle, a system that cannot be verified where it runs is a system nobody will trust with anything that matters.
Two families, one discipline
Software engineering and industrial engineering do not follow one another, they meet. Both answer the same question: how do you know this will behave as intended, somewhere you are not watching?
Software
Building, verifying and delivering, at the pace AI now sets
04Software engineering
Bespoke applications designed to be maintained, not only delivered: architecture, quality and the constraints that still hold years later.
See the pageVerifyAI-DLC & augmented testing
The AI-native development cycle and the verification that has to keep up with it: intent written first, tests generated then pruned, review as a gate.
See the pageDeliverAugmented DevOps & SRE
A delivery chain where a change proves itself, and a production you hold rather than watch: pipelines, quality gates, service levels.
See the pageScaleAugmented IT department
An IT department equipped with a GenAI software factory, from enterprise architecture to delivery across many squads.
See the pageIndustrial & OT
Software that runs where the assets are, and answers for itself
03IoT, real time & edge
Data ingested and processed where it is produced: connected assets, event-driven decisions, and compute kept on site for latency, resilience and residency.
See the pageDecideEmbedded AI & industrial GenAI
Low-latency inference next to the assets, and copilots that reach the shop floor safely, with the line between advising and acting written down.
See the pageRepresentDigital twin & BIM
One model of the asset across its life, to simulate and predict before committing anything physical, from construction through to the operations that follow.
See the pageWhat runs, every time
Three example runs, on fictional scopes. They show the shape of what we hand over: a sequence that goes to its end, and what it finds when it gets there.
A feature that proves itself
An assistant writes most of it in an afternoon. What decides whether it ships that week is everything after: the intent written down, the tests that would actually fail, and a review that is a gate rather than a signature.
- Intent written before the code, not after
- Tests that would fail if the code were wrong
- Review as a gate, with a named owner
Finding: the feature passes, and two of the generated tests would have passed on broken code. They are removed. A suite that cannot fail is a suite that reassures without verifying anything, which is worse than no suite at all.
Where software engineering actually stands
of software teams now use AI daily, according to the 2025 DORA report: adoption is settled, and it is no longer what separates teams
more pull requests merging with no review at all, while median time in review rose sharply: the queue moved from writing to verifying
of assistant-generated programs carry a security weakness in published studies, which is why review became the gate rather than the formality
Systems that hold where they run
From a release that took days to a chain that replays itself
−72% time-to-market · 18 squads on one chain
A century-old life insurer whose production releases took several days, mobilised every team, and rested on legacy Jenkins pipelines and proprietary shell scripts accumulated over the years.
A delivery chain rebuilt on Terraform, Ansible, Docker and Kubernetes, with compliance controls wired into the pipeline rather than checked at the end, and eighteen product squads brought onto the same practices.
Real-time video understood at the edge, on 142 cameras
< 200 ms p99 latency · −58% waiting time
Wait times estimated statistically no longer matched the real flows at peak, on a site welcoming fifteen million visitors a year where the video volume rules out sending everything to a central platform.
Computer vision running at the edge, close to the cameras, feeding native mobile applications. Privacy handled at the point of capture, and the decision taken where the data is produced rather than after a round trip.
Software that lives in a maintenance workshop
8 workshops in production · 0 regression
Maintenance workshops running a considerable fleet with legacy tooling: no real-time view, nothing that could be read collectively on a workshop screen, and no quality gate on software changes.
Interactive supervision built from scratch for a 4K workshop display, with test coverage above ninety per cent and a quality gate on every change. Software written for the constraints of the shop floor, not adapted to them afterwards.
Insights & Perspectives
How much faster can AI coding assistants really make software delivery?
A heuristic, a 150-ticket case study and 2025-2026 research: real speed gains sit between 5 and 15%, far below the marketing promises.
From vibe coding to context engineering: 2025 in software development
How 2025 transformed software development, and why MCP, A2A and AI agents put software engineers back at the centre rather than aside.
How to build trust with AI-powered coding assistants
What happens when usage rates become a target, and what a team actually needs before it stops second-guessing everything an assistant proposes.
The other foundations
ExpertiseCloud & platforms
The foundation this software runs on: modernisation, migration, sovereign hosting, reliability and cost under control.
ExpertiseGenAI platforms
The GenAI foundation behind AI-assisted delivery: hybrid LLM gateway, RAG platform, LLMOps and AI FinOps.
Verify at the speed you now produce
A delivery chain where a change proves itself, tests that stay worth running, and software that behaves the same way where you are not watching.
Frequently asked questions
Between five and fifteen per cent on delivery, in the studies that measure end to end rather than counting lines. Individual output rises far more than that, but the gain is absorbed downstream in review, rework and defects that surface later.
Because generation got cheap and verification did not. Median time in pull request review has risen sharply and thirty-one per cent more pull requests merge with no review at all. The queue did not disappear, it moved to where nobody was measuring it.
It can be generated, and then it has to be pruned. A suite that grows with every feature and never loses a test becomes slow, then ignored, then switched off. What matters is not coverage on paper, it is which tests would actually fail if the code were wrong.
Verification does. On a shop floor or a substation, you cannot redeploy in a minute and the link is not always there. The behaviour has to be provable where the software runs, which shapes the architecture rather than being added to it.
A software project with a modelling problem inside it. The model is the easy half. What decides whether it is used is the data feeding it, the pace it refreshes at, and whether an operator can tell when it has drifted from the asset it represents.
Where the boundary between advising and acting is written down, yes. A copilot that surfaces a procedure or reads a maintenance history is useful immediately. Anything that writes to a control system is a different decision, and it is taken separately.
With what is already shipping. We measure the current path from commit to production, find where a change actually waits, and fix that. Starting with tooling before knowing where the queue is buys speed in the one place that was not slow.