There is a point at which software stops being something an organization builds and starts becoming something it has inherited. Governments know this problem particularly well.
A large software estate is a little like an old city. Nobody designed the whole thing at once. One generation builds something useful, the next builds around it, and eventually you have new infrastructure running through decisions made by people who left decades ago.
In software, those layers are applications, business rules, infrastructure, vendor dependencies, programming languages and documentation of varying archaeological value. Nobody wakes up one morning and decides to create an enormous, complicated technology estate. It accumulates because the organization keeps existing.
Eventually, though, you have to deal with what you inherited.
And AI has changed the stakes. For years, technical debt was largely a problem of human capacity. How many developers could you put against an aging estate? How quickly could they understand unfamiliar systems? How much could you modernize before the next part became obsolete?
AI changes that calculation in two directions. It gives organizations new tools for understanding and working on software at a scale that was previously constrained by human attention. It also gives anyone trying to attack that software more powerful tools for doing the same thing. The models keep getting better, and so do the capabilities available to anyone who wants to find vulnerabilities, analyze systems or exploit weaknesses.
That makes forty years of accumulated code more than an expensive maintenance problem. Increasingly, it is a liability that organizations need to understand before somebody else does.
That is the problem the Government of Alberta set out to tackle, and the Velocity White Papers are essentially a record of what happened when it did. Across 22 papers, Alberta documents its approach to using agentic AI to understand, secure and modernize a software estate built up over decades. The papers cover everything from the architecture and tooling behind the work to the experiments, methodologies and technical practices developed along the way, and the associated code and resources are openly available.
The Government of Alberta reported that a team using roughly 50 AI agents assessed 466 million lines of government code in about 20 hours, looking for security vulnerabilities, infrastructure weaknesses and gaps in documentation.
Twenty hours is the kind of number that attracts attention, but the number is not really why we find Alberta’s work interesting. What matters is that somebody went first.
There is a curious problem with AI right now: everyone is experimenting, and almost nobody knows quite how much of what they are seeing is signal and how much is smoke. The technology has enormous potential but figuring out how to use it well is itself a process of discovery.
The first organization to work through that process has to make all the mistakes. It has to figure out what works, what does not, what infrastructure is missing, what people need to learn, where the risks are and which seemingly clever idea turns out to be considerably less clever in practice. Once that work has been done, however, someone else can start further up the hill.
That is what makes Alberta’s Velocity White Papers worth paying attention to.
Rather than keeping those lessons inside the organization, Alberta has documented them as a body of reusable practices, tools and guidance. The papers describe how people learn to work with AI agents, how agents receive organizational context, how their work is constrained and observed, how software is assessed, and how those practices can be applied across a large technical estate. Alberta has also made the papers and associated tools openly available so that other governments and organizations can use and build on the work.
It is a remarkably useful thing to do at a moment when so many organizations are trying to work out what AI actually means for them.
Organizations are good at having initiatives. They are not nearly as good at turning those initiatives into shared knowledge. One team discovers something, one person becomes the internal expert, a presentation gets made, and six months later another team begins the same experiment with a slightly different set of assumptions. It is a rather inefficient way to learn.
Writing the work down changes the economics of learning. The next team can start with the accumulated knowledge rather than the original question. They can argue with the method, improve it, adapt it or decide that something does not apply to them. What they do not have to do is rediscover every lesson themselves.
Git Insights is a good example. The public dataset maps 4,041 application records to 2,182 business capabilities across 40 domains, creating a view of what government software does, what technology it uses, where risk exists and where modernization effort might be directed.
It is difficult to imagine a more useful starting point for an organization with 466 million lines of code to contend with. Before you transform something, you generally need to understand what you have. That sounds almost insultingly obvious. In a large organization, it rarely is.
There is a reason we still look at the Babylonian astronomical diaries. Centuries later, those Akkadian clay tablets remain useful because the Babylonians left behind more than mere observations; they left behind empirical data that allowed later generations to build on what they had observed. Knowledge becomes considerably more valuable when the next person can see where you started.
The Velocity White Papers give other organizations something similar: a place to start.
And there is another lesson buried in Alberta’s work. The infrastructure required to make AI useful turns out to look remarkably familiar.
Good documentation. Clear standards. Better testing infrastructure. Automation. Deployment practices. Knowledge of how systems and databases actually work. These have always been the things that make software organizations run well, although they have rarely been the most glamorous items on anyone’s technology roadmap. They improved continuity, reduced friction and made life easier for the person who inherited your code six months later.
AI makes that groundwork considerably more consequential.
An AI agent can move quickly through a codebase, but speed is not much use if the codebase contains patterns that should not be repeated, the testing infrastructure is weak or nobody has clearly articulated how the system is supposed to work. The agent needs to know what “right” looks like. The better the environment around the agent, the more useful the agent becomes.
Alberta’s work suggests that this preparation can have a very tangible payoff. The province reports savings of roughly $5 million a week from its AI-enabled modernization work, while also beginning to get ahead of technical debt rather than continually falling behind it.
That is where the Velocity White Papers become more interesting than a collection of successful AI experiments. Alberta has not simply found some useful applications for a new technology; it has documented the work of figuring out how an organization can actually use it, including the less glamorous preparation that makes the technology effective in the first place. At Guidanti, we start with an assessment for the same reason: before recommending where AI might help, we need to understand the systems, processes and needs already in place.
And perhaps that is one of the more useful ways to think about AI adoption right now. The organizations that benefit most may not be the ones running the largest number of experiments or producing the most impressive demonstrations. They may be the ones that learn how to turn an experiment into institutional knowledge, and institutional knowledge into the way the organization works.