By Archie Marincowitz
New Business Development, DVT

There is a conversation happening in the boardrooms of South Africa's mining houses, chemical companies, and manufacturers right now. It usually starts with a frustrated CIO or COO pointing at a list: the mobile application for field maintenance crews that has been in development for eighteen months. The plant operations dashboard that went live missing half its integrations. The AI-powered scheduling tool that is still a pilot, twelve months after the pilot was supposed to end. The digital platform that works in the demo environment and nowhere else.

The frustration is not irrational. These organisations have invested in technology. They have bought the licences, approved the projects, hired the vendors. What they have not done, and this is the part that rarely gets said plainly, is rethink the way the development team works. Until that changes, the delivery problems will persist regardless of what technology gets procured next.

This is not a technology problem. It is a delivery model problem. And in 2026, there is a direct answer to it.

The Real Cost of How Software Gets Built Today

Industrial organisations in mining, manufacturing, and chemicals share a common software delivery pattern. A business need emerges: digitising a safety checklist process, building a predictive-maintenance dashboard, integrating OT sensor data with an ERP system. A project is scoped. A development team is assembled, usually through staff augmentation or a time-and-materials arrangement with a vendor. Developers pick up tickets. Code gets written.

Several months later, a few things have typically happened. Documentation is sparse or nonexistent, because writing documentation was never a sprint deliverable. Testing was manual and happened at the end of each sprint, which means defects compounded. When a developer left the team, and developers always leave, the knowledge they held walked out with them. The next team member inherited a codebase without a map. Delivery momentum collapsed.

For organisations operating at the complexity of a deep-level mine, a continuous chemical process, or a high-volume automotive plant, this pattern is not merely inconvenient. It is expensive in ways that are hard to attribute precisely but impossible to ignore: delayed capability, rework budgets that surface as project overruns, and technology investments that never reach their intended business value because the software supposed to unlock them never quite worked.

The knowledge lives in the developers' heads. When they leave, it leaves with them. This is the most common and least acknowledged reason why industrial digital projects fail to deliver.

What Has Changed

The shift that has happened in software engineering over the past eighteen months is not about AI writing better code, though it does. It is about a fundamentally different starting point for how software gets built.

The old model starts with a developer picking up a ticket and writing code. The new model starts with a specification, a precise and structured description of what needs to be built, why, and how it should behave, generated and validated with AI before a single line of code is written.

The difference between these two models is not marginal. In a traditional development team, velocity degrades as a codebase grows more complex. Context is held in people's heads, and as team composition changes, that context erodes. In a spec-driven team, the specification library grows with the system. Every feature leaves behind a versioned record of what was built, why it was built that way, and what the acceptance criteria looked like. A new team member, from DVT, from the client organisation, or from a future partner, can onboard against the specification library rather than against the codebase alone. Velocity does not degrade. Over time, it improves.

Quality follows the same logic. In the old model, testing is a phase that happens after development, manually, at the end of a sprint. In a spec-driven model, tests are generated directly from the acceptance criteria in the specification and run automatically in the CI/CD pipeline. If the code drifts from the specification, the build fails. Quality is structural, not inspected in after the fact.

What a DVT AI Build Team Looks Like in Practice

DVT's AI Build Team model is built on this foundation. It is not a rebranded staff augmentation offering. It is a compact, cross-functional delivery unit, typically a backend engineer, frontend engineer, QA engineer, feature analyst who drives the specification process, and an engineering oversight layer that governs how AI is used, where every role operates within an AI-first software development lifecycle.

Take a mining company building a condition-monitoring platform that integrates vibration data from underground equipment into a maintenance workflow. The feature analyst works with the client's operational team to produce a requirements definition precise enough for AI to act on reliably.

System design is proposed by AI, reviewed and approved by a tech lead before implementation begins. Engineers work with AI-assisted code generation tooling suited to the client's cloud and security environment. Tests are generated from the acceptance criteria and enforced automatically by the pipeline. When the engagement ends or the team changes, the knowledge library remains: a complete, versioned record of every decision the team made.

For a chemicals company managing a complex process-control system with a patchwork of legacy integrations, the same model applies. The feature analyst's first task is often to reverse-engineer documentation from an existing codebase, to build the map that should have existed from the beginning, before any modernisation work starts. For organisations where institutional knowledge of a critical system exists only in the heads of two or three engineers who have been there for decades, that map is the single most valuable thing a delivery team can produce before touching the code.

For a manufacturer building an AI-assisted production scheduling tool, the AI Build Team model addresses the problem that kills most of these projects before they reach production: the specification is never precise enough for the development team to build the right thing, so the tool gets built to the wrong requirement, gets reworked, loses momentum, and ends up as another pilot on the list. Starting from a validated specification changes that dynamic entirely.

A feature that previously took two weeks was delivered in a couple of days. That is not a marketing claim. It is the internal AWS benchmark that drove the development of Kiro IDE.

The Partnership Case for African Industrial Organisations

Building this capability entirely in-house is a five-year project for most organisations, and the talent market makes it harder, not easier. Senior engineers who are genuinely proficient in AI-first delivery methodology, context engineering, and agentic development tooling are scarce. The organisations competing for them include global tech companies offering remote work at dollar-denominated salaries. A mining company or chemicals group trying to build this team from scratch is not competing on favourable terms.

The model that works, and that is working right now in South African enterprise technology, is a build-operate-transfer approach with a local partner who already has the methodology, the tooling proficiency, and the engineering depth. The client gets production-grade AI-driven delivery from the first sprint. The specification library and the capability compound over time. The partner accelerates the journey rather than replacing the destination.

For South African and broader African industrial organisations, two dimensions of partner selection deserve explicit attention. The first is genuine local delivery capacity. Understanding the operating environment, load-shedding contingencies in infrastructure design, POPIA implications in data handling, B-BBEE considerations in team composition and procurement, is not incidental. It is the difference between a partner who can actually execute in this context and one who presents credibly in a pitch and then struggles with the reality.

The second is the distinction between AI Build Teams and what is often sold as AI-enhanced delivery. An AI Build Team means every role operates within the AI-first lifecycle from day one. Not just the developers. Not just occasionally. Not only when it is convenient. The feature analyst drives specifications with AI. The QA engineer generates tests from acceptance criteria. Engineering oversight validates that AI-generated output meets enterprise standards, because AI-generated code has a measurable vulnerability rate, and catching those vulnerabilities at the specification level is not optional in regulated industrial environments.

DVT has been building custom software for enterprise clients for over 25 years. The AI Build Team model is not a pivot. It is a structural evolution of a delivery methodology that has always prioritised engineering discipline and knowledge retention. The difference now is that AI compresses delivery timelines radically, and Spec-Driven Development ensures that compression does not come at the cost of quality or institutional knowledge.

The Question Worth Asking

The right question for an industrial CIO or CTO right now is not which AI tool to buy next. It is a more uncomfortable one: how much of the software delivery budget allocated in the past three years has produced systems that are well-documented, maintainable, and genuinely understood by the people responsible for them?

For most organisations in mining, manufacturing, and chemicals, the honest answer reveals a significant gap between investment and outcome. Pilots that never reached production. Platforms that are technically live but operationally brittle. Knowledge that exists only in the heads of a handful of people who may or may not still be with the organisation next year.

The AI Build Team model addresses the root cause of that gap, not by adding more developers or buying more tools, but by changing how software gets built at a fundamental level. Specifications before code. Tests generated from requirements. Documentation produced continuously as a byproduct of delivery, not as an afterthought at the close of a project. Knowledge that lives in the system, not in individuals.

For organisations whose operational technology depends on software that works, where a broken integration between a condition-monitoring system and a maintenance workflow is not an IT problem but a safety risk, where a scheduling tool that does not reflect current plant state is not a convenience issue but a production loss, that shift in delivery model is not a nice-to-have. It is a business imperative.

DVT is having this conversation with industrial organisations across South Africa and the broader continent. If you want to understand what an AI Build Team engagement looks like for your specific environment and delivery challenges, we would welcome the discussion.

To learn more about DVT’s AI Build Teams, visit https://www.dvtsoftware.com/services/artificial-intelligence/ai-build-teams.