noah jobse

Alberta open-sourced its AI factory. Read the Velocity Papers.

#ai-agents #spec-driven-development #govtech #alberta #security

Every so often a large organization does something ambitious with AI and then tells you, in real detail, exactly how. Usually it is a lab or a hyperscaler. This time it was my provincial government.

The Government of Alberta just published The Velocity White Papers: 21 open-source technical papers on how the Ministry of Technology and Innovation used AI agents, built mostly on Claude, to review and start rebuilding a code estate of roughly 1,280 applications and 3,400 repositories across 27 ministries. The headline number is the one everyone quotes: about 466 million lines of code assessed in 20 hours by around 50 agents. Doing that by hand was estimated at 130 years and close to two billion dollars.

I went in expecting a press release with a case-study wrapper. What I found was closer to an engineering handbook, with the actual repos linked, the harness open-sourced, and the tradeoffs written down honestly. I build multi-tenant SaaS on Vue and Postgres for a living, and their reference application template is Vue 3, Node, and Postgres, so I could read a lot of this like my own codebase. That does not happen often with government documentation.

I want to walk through the four parts that stuck with me.

Pronghorn, and the case against building first

The paper I liked most is the one on Pronghorn, the first stage of their three-stage "AI factory" (the other two are Nexus for orchestration and Velocity for measuring delivery). Pronghorn is named after the antelope: second-fastest land animal in the world, fastest in North America, native to Alberta, built for endurance and a wide field of view. It is a good name, and a very Alberta one.

What Pronghorn actually does is force the boring, essential work that agentic coding tempts you to skip. You start a project with a bit of metadata and a choice of model, then work in a chat that renders prototypes inline. You feed it an artifact space of slide decks, PDFs, Word docs, and web pages so the agent has real context. From that, it builds a proper requirements hierarchy: epics, then features, then user stories, then acceptance criteria. Only then does anyone build.

The part I found genuinely clever is the shared architecture canvas, built on React Flow, where you drag and drop the pieces of an application and let agents read the canvas and draw on it alongside you. Their reasoning is that a canvas is a compact, precise specification, a hierarchy of nodes and labelled edges, where the verbose output of a language model is not. It is another mechanism for keeping an interface from being vibe-coded into existence.

If you have read anything I have written about where research should live, at spec time or build time, you can see why this landed. The papers put it plainly: the temptation in agentic development is to start building immediately, because it is satisfying and fast, and it is also how you end up with an architecture badly misaligned with the stack you have to live in. That is the whole game.

The harness

Underneath the factory is a concept they call the harness, and they open-sourced it as a repo called COMMON-HARNESS. The premise is that off-the-shelf coding tools produce apps that lack the controls a public service needs, and that agents are unreliable witnesses of their own work. So instead of trusting the model to behave, you constrain it with files that define your expectations.

If you use Claude Code this will look familiar. The entry point is a CLAUDE.md file the agent reads at the start of every session, with skills living in a .claude/skills folder. Each skill is a small playbook for one kind of task: how to structure requirements, how to write a migration, how to run a security audit, how to review prose. I keep CLAUDE.md files in my own repos, so seeing a government ship an enterprise-grade, audited version of the same idea was oddly affirming. They run long-horizon work like planning, architecture, and threat modelling on Opus, which can carry a whole delivery cycle.

Paired with the harness is an anti-drift system, and this is the paper I would hand to anyone who has watched an AI quietly break a codebase. Their framing: AI-generated code is usually 98 to 100 percent functionally correct, in that it compiles and runs, but its practices let drift grow invisibly. You rename a component in one place and something unrelated breaks. The docs stop matching the interface. A database field stops showing up where it should.

Their answer is a set of small watchers that bolt onto the builder agent rather than overloading it, each named for what it does: a Chain Walker that follows a change outward along its dependency chain, a heatmap that shows which files are churning, small automatic tests, an end-of-step checklist, an index card per file, and a shared dashboard that grids every feature against every link. The insight I keep thinking about is architectural: do not pile drift, security, testing, docs, and style onto one agent until its instructions balloon and stop helping. Add a watcher, not another paragraph. Some watchers even run on a cheaper model, saving the strong one for the hard calls.

Red, Blue, Green, and Yellow

Their quality-assurance layer is four review agents, each nicknamed for a colour, and it is the most quietly reassuring part of the whole collection.

Green checks code quality and hygiene. Yellow checks the written copy for AI tells. Red probes a running application the way a threat actor would. Blue is the defender: it runs last, reads everything the others found, maps the application, classifies how sensitive each part is, writes a threat model, and walks every requirement in the OWASP ASVS Level 2 standard. Every app starts from a secure template with about 95 major controls built in, and the agents verify that template and a great deal more. Green, Yellow, and Red's reconnaissance are deterministic Node and Python scripts that need no model to run, which is a smart way to keep the mechanical checks cheap and repeatable and reserve judgment for where it is actually needed.

I have to call out the Yellow agent specifically. It flags the tells that undermine public trust in government writing, and the very first one on the list is the em dash, followed by stock clichés and the overused "it is not A, it is B" construction. For those of us who already refuse to use em dashes, having a provincial cyber team encode that into an automated reviewer is deeply validating. Standards, at last.

The stack

The infrastructure paper is the one I would have written first, and it is refreshingly unromantic about vendor loyalty. Alberta runs a hybrid environment across Google, Azure, and AWS, plus smaller platforms, plus three legacy data centres, plus their own GPUs running open-source models on-premises. They note that the model lead changes every couple of months, so they stay deliberately provider-agnostic.

The piece that ties it together is a gateway they call Bifrost, which abstracts the provider so a workload can move between clouds, or from cloud to their own compute, as prices and needs change. It also enforces per-workload budgets so token spend does not run away, and runs personal-information detection on the way through. Data is classified as unclassified or Protected A, B, or C, and residency is controlled in Canada through their agreements and platform guardrails.

What earns my trust is that they do not oversell. They state that no model today fully resists prompt injection, that the best resist hijacking only 95 to 98 percent of the time, and that a skill file is still software that can carry a poisoned instruction and therefore needs auditing before use. That is the correct posture, and it is the kind of caution I wish more teams shipping agentic features would adopt.

Why this is worth your afternoon

There is a lot more in the 21 papers: a training academy that has reached more than 15,000 people, an argument that org hierarchy is a lossy compression algorithm, a game engine for measuring delivery when an agent is a full member of the team, and a case study where an application quoted at 1.9 million dollars and five months shipped for about 108 thousand dollars in four days.

But you do not have to care about government to get value here. If you are building anything real with AI agents, the Velocity Papers are a working, in-production account of how to do it with the controls left in. That it came from Alberta, and that they gave it away for free, is the part I am proud of.

Start here: thevelocitywhitepapers.com. The Pronghorn, harness, and Red/Blue/Green/Yellow papers are where I would begin.