Building an AI delivery capability inside an enterprise software business

The situation

Syntegra builds and supports Predictiv, an enterprise resource planning (ERP) platform used by distribution, manufacturing and retail businesses in Southern Africa. The estate is large and old in places: a vendored open-source ERP core, more than a hundred of Syntegra’s own modules, point-of-sale and mobile applications, and customer instances that each drift in their own way.

By early 2026, AI coding agents could write a great deal of that code. The question was whether an organisation of Syntegra’s size could let them do so without losing control of what reached customers.

Why it mattered

Speed was not the constraint. The constraints were the ones every established software business recognises: requirements that were never written down precisely, knowledge held by a few people, generated metadata edited by hand until it no longer matched its source, and releases whose testing could not be reconstructed afterwards. An agent working faster inside those conditions produces the same failures faster. DORA’s 2025 research on AI-assisted development makes a similar point at industry scale: AI amplifies the strengths and weaknesses an organisation already has.

What was built

The platform report describes an AI Operating Model realised through a harness around Claude Code, Anthropic’s coding agent. The distinction between what was supplied and what was built matters for any credit or comparison, so it is drawn here first.

Supplied by vendors

• Claude Code agent runtime, hooks, skills and subagents
• Anthropic and OpenAI models
• GitLab, Taiga, cloud machines, Astro, PostgreSQL

Custom harness

• Principles enforced as hooks and gates
• Generators, contracts and a standards ledger
• Phased delivery with evidence rules
• Fleet tooling, knowledge catalogues, model registry

Human contribution

• Direction and priorities
• Reserved decisions: commitments, risk, destructive changes
• Review, rulings and approval to publish or release

Product estate

• The ERP and its modules
• Point of sale and mobile applications
• Customer instances, reached only through governed paths

The custom part is the harness. Its main elements:

• Principles as enforced rules. “Tooling first”, “language by runtime”, “diagnose before retry” and “no autonomous deletion” are each backed by a runtime hook or a commit gate, not left to the prompt.
• Generators and contracts. Application metadata is produced from specifications by generators and never edited by hand. Each artefact type declares the checks it must pass.
• A phased lifecycle with evidence rules. Work moves through DEFINE, GENERATE, VERIFY and DEPLOY. At each exit, requirements must be matched by code, then tests, then documentation, and a claim of “complete” with no passing test behind it blocks the exit.
• A disposable fleet. One workstream runs on one cloud machine. Machines are created and destroyed by tool, and every machine pulls the framework from version control every half hour.
• Governed knowledge and models. Catalogues of the data model and business rules, a shared memory of rulings and lessons, and a model registry that chooses models by purpose and records the cost of every call.

How it is used

A person sets direction and makes the decisions reserved to people: funding a piece of work, accepting a risk above appetite, signing an external commitment, approving anything destructive. The agent does the defined work in between, inside the controls. When a control refuses an action, the refusal names the sanctioned route, and the agent takes it.

What the records show

The records are internal and self-reported. They show the system in use and its controls acting; they do not show a productivity gain, because none has been measured.

• Volume of governed work. 135 bounded pieces of work tracked through the phased lifecycle between February and September 2026. Of these, 22 pieces of work passed the final deployment gate.
• Controls that act. The records hold more than 18,000 recorded gate runs, and more recorded phase-exit attempts fail than pass. Separately, runtime hooks logged more than 30,000 refused agent actions, recorded on a single workstation: attempts to write straight to the database or hand-edit generated files, each redirected to the proper tool.
• Improvement from use. Friction found in any session becomes a queued item. So far there are more than 960 improvement items closed as fixed.
• Quality of an AI surface. For the product’s own chat assistant, answer correctness on an internal question set rose from 37% to 76% with no change of model, by correcting its tools, scope and prompts.

One change, end to end

A user reported, with a screenshot, that fuel-meter readings in a customer’s fleet module were carrying the wrong opening value. The agent traced the fault to one calculation, fixed it, and verified the fix against live data before committing. It then declined to run a proposed bulk correction of historical records, because the evidence contradicted its own model of the fault. A person made the decisions and merged the change. Regression tests were added, the fix passed every later verification run, and a release note described it. Four days separated the report from the release note.

Two gaps remain in that record: the request never became a ticket, and no customer acceptance was captured. Both are recorded, not hidden.

What did not work

• The improvement queue grows faster than it drains. More than half of the items closed so far expired rather than being fixed, and the backlog rose through September 2026.
• Some gates are slow. The full self-test gate can hold a commit for many minutes, and it is the most frequent cause of a refused commit.
• Authorship is ambiguous. Most commits carry the operator’s name whether the agent or the person wrote them, so personal and agent contributions cannot be separated from version control alone.
• Unattended work can stop silently. A nightly fix session once ran broken for twelve days before anyone noticed.

Boundaries

Not measured: productivity against a human team, lead time from request to production, production change-failure rate, or cost per change. The evidence covers one organisation’s software delivery and support. It has not been reviewed by an independent party, and none of it should be read as certification.

What transfers

An organisation does not need this toolset to apply the method. It needs four decisions: which decisions stay human; which rules are enforced where the agent acts rather than written in a prompt; what counts as evidence that a requirement is met; and where knowledge lives so every session starts informed. The tooling follows from those.