AI Strategy27 August 20267 min read

Shipping AI into the Public Sector — Part 2 of 9

Spec-driven development with an AI coding agent

We built the real thing with an AI coding agent. What made it work was not the code generation — it was making the specification the source of truth, and writing the guardrails down where the agent could not quietly drift past them.

#AI Strategy#AI Agents#Solution Architecture#Delivery

The build for this public-sector service was done with an AI coding agent, and it went well. But the interesting part is not that an agent wrote the code. That is unremarkable now. The interesting part is what had to be true around it for the output to be worth having.

The short version: the specification became the artefact, and the code became a derivative of it. Once that inversion held, the agent was genuinely fast. Before it held, the agent was fast at producing things nobody could review.

Constitution, specification, plan, tasks, implementationNON-NEGOTIABLESConstitutionWHAT AND WHYSpecificationHOWTechnical planIN WHAT ORDERTasksGENERATEDImplementationwhen code and spec disagree, the spec winsHumans keep the gates: access, security, testing, acceptance
Each stage is a reviewable artefact, not a conversation. Code is regenerated from the spec, which is why the loop points backwards: when the two disagree, the spec is what gets corrected first.

The chain, and why each link is separate

Five artefacts, each reviewable on its own, each feeding the next.

The constitution holds the non-negotiables. Not preferences — the things that must be true of anything produced, no matter what else changes. For this delivery that meant data residency, least-privilege, privacy by design, and evidence-first. It is short. It changes almost never. Every later artefact is checked against it.

The specification says what the thing does and why, in language a domain person can argue with. This is where the actual thinking lives and it is the artefact worth protecting.

The technical plan says how — the architecture, the services, the data shapes, the trade-offs that were considered and rejected. Keeping "how" separate from "what" matters more than it sounds, because it lets you change the implementation without relitigating the requirement.

The tasks put the plan in an order that a machine can execute and a human can track.

The implementation is generated. It is the output, not the asset.

The rule that makes it work

When the code and the spec disagree, the spec wins.

This sounds like a truism and is in practice a hard discipline, because the code is right there and correcting the spec feels like paperwork. But the moment you allow the code to be the source of truth, you have lost the property that made the whole approach worth adopting: that a human can review the thinking rather than the output. Review the thinking and you catch a wrong decision. Review forty files of generated code and you catch typos.

Concretely, when something was wrong, we fixed the spec and regenerated rather than patching the code in place. It felt slower perhaps twice. It was faster every other time, because the correction stayed corrected instead of being reintroduced by the next generation pass.

Guardrails have to be artefacts, not intentions

This is the part of the approach I would most defend, and it maps directly onto something Eugene Perumal of Valutivity argued in ITWeb this month (Deploying AI agents safely): that governance has to be treated as a design input, not an afterthought.

An agent will not violate a rule you have written down and put in front of it. It will absolutely drift past a rule that exists only in a delivery lead's head, because it has no way of knowing it exists. So the guardrails go in the constitution as first-class, versioned text:

  • Personal data does not leave the country.
  • The deployment identity is scoped to the resource group.
  • No secrets in source, ever; federated identity only.
  • Every milestone has a named evidence artefact.

Written like that, they survive a context window, a new session, a different model, and a handover to a person who was not in the original conversation. That last one is the real test. Intentions do not survive handover. Artefacts do.

Perumal's framing is that ungoverned agentic AI "does not move faster. It moves confidently toward value-destroying events." The word doing the work is confidently. An agent without written guardrails is not tentative about crossing a line it cannot see.

Build a walking skeleton before you build features

The single highest-leverage sequencing decision we made was to build one thin slice through the entire stack before building anything wide.

A walking skeleton before the featuresWALKING SKELETON — ONE SLICE, ALL THE WAY DOWNPipelineInfrastructureAppDataTelemetryONLY THEN, FAN OUTFeature 1Feature 2Feature 3Feature 4Feature 5A feature that is finished but undeployed proves less than a skeleton that is live
One thin slice that touches every layer, deployed for real. It proves access, infrastructure, pipeline and evidence capture in a single pass — which is why it is worth more than three finished features sitting on a laptop.

Not a feature. A slice: pipeline, infrastructure, application, data, telemetry — the smallest thing that touches all of them and is genuinely deployed into the real tenant. It does almost nothing useful. That is the point.

What it proves is everything the access chain is about to throw at you, while there is still time to react. It proves the deployment identity works. It proves the pipeline can reach the tenant. It proves the resource providers are registered. It produces the first real evidence artefact for the proof pack. And it does all of that in week one rather than week six.

The counterfactual is the pattern everyone has lived through: three polished features, none deployed, and an access problem discovered late enough that it eats the buffer. A feature that is finished but undeployed proves considerably less than a skeleton that is live.

Where the humans stay

Agents accelerate the production of artefacts. They do not absorb accountability, and the gates are where that distinction gets enforced. On this delivery humans owned four:

Access. No agent requests permissions. A person asks a named administrator, because the request needs judgement about what is reasonable to ask for.

Security. Least-privilege decisions are reviewed by a person against the constitution, every time. More on that here.

Testing. An agent writing both the implementation and the tests that bless it is not a control. Someone independent decides what "working" means.

Acceptance. A person signs that the built thing matches the specified thing.

None of this slows an agent down in any way that matters. What it does is keep the acceleration pointed somewhere.

The uncomfortable part

Spec-driven development rewards teams who were already disciplined and punishes teams who were not. If your requirements were vague before an agent arrived, the agent will now produce a large volume of code that confidently implements the vagueness. Nothing about the tooling fixes that; it just increases the throughput of the underlying problem.

Which is the honest summary: AI agents do not remove the need for discipline. They raise the return on it sharply, and they raise the cost of not having it by about the same amount.

How CloudNala can help

We use this workflow on client deliveries, and the part we are most often useful for is the front of it rather than the code generation — getting the constitution written so it is specific enough to constrain anything, getting the specification into language the client's domain people will genuinely argue with, and sequencing a walking skeleton that clears the access and residency questions while there is still room in the plan. Teams rarely need help making an agent produce code. They need the artefacts that make the code reviewable.


Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Book an AI Readiness Workshop or write to us at consult@cloudnala.co.za