Public Interest Tech Webring - All Posts

Modernizing Government Regulations with AI

2026-03-05T21:30:07+00:00

Somewhere in the tens of millions of words that make up a typical state’s statutory code, there are requirements that no longer make sense.

Provisions that demand wet signatures when digital alternatives exist. Reports that agencies must file but few people read. Approval chains that add weeks to processes without adding any value. Conflicts between statutes passed decades apart. Requirements that may have seemed reasonable in isolation but interact to create bureaucratic obstacles that frustrate both government employees and the people they serve. Everyone agrees that government regulations need to be updated. The challenge is how to do it well at scale.

Manual review is the traditional approach to this problem, and it has obvious limits. Assign a team of policy analysts to read through the state code, title by title, flagging problematic provisions. They’ll find some things. But they’ll also miss things, because human attention flags over millions of words. And the work will take years, by which point new provisions will likely have accumulated.

This is why teams working on regulatory reform are starting to explore how AI tools might help. The appeal of these tools is obvious – AI can process text at a scale humans cannot. Point a model at a state’s entire legal code and ask it to flag provisions that match patterns associated with administrative burden. In theory, you would get comprehensive coverage of state statutes and regulations in a fraction of the time.

But “point AI at the problem” is not a methodology. The teams doing this work seriously are thinking carefully about how to structure the effort so that AI analysis actually produces useful, trustworthy results. Having spent time developing a methodology for a structurally similar problem, I think some important lessons transfer that can be used by teams looking to revise state regulatory rules.

The Parallel With Legacy System Modernization

The challenge of finding burden in regulations has a structural kinship with legacy system modernization that may not be immediately obvious.

Large government agencies run on a collection of systems built decades ago. These systems work, mostly, but they encode business rules that no individual fully understands. The original developers may be retired or gone. Documentation is often incomplete or outdated. The knowledge of what these systems actually do is embedded in the code itself, accumulated across thousands of modifications over decades.

When agencies try to modernize these systems, they face a fundamental problem: you can’t safely replace what you don’t understand. And understanding a codebase of hundreds of thousands or millions of lines exceeds human capacity for comprehensive review.

The parallel to regulatory burden is clear. State legal codes are massive textual corpora that encode requirements accumulated over many decades. The original intent behind provisions may be unclear. The interactions between different provisions are often complex or poorly documented. And the task of understanding what’s actually in this grand body of text exceeds what human reviewers can accomplish through direct reading.

In both cases, AI offers the possibility of analysis at scale. And in both cases, the question is how to structure that analysis so it produces results humans can trust and act on.

SpecOps and System Specifications

I’ve developed a methodology for legacy system modernization called SpecOps. The core tenet of this approach is that AI should produce an intermediate artifact that humans can verify, rather than producing final outputs directly.

In legacy modernization, that intermediate artifact is a specification document: a human-readable description of what the legacy code actually does. AI analyzes the code and generates the specification. Domain and policy experts review the specification and verify whether it accurately captures the system’s behavior. Only after verification does anyone write new code.

This is important because AI can confidently produce outputs that are wrong. It may miss edge cases, misinterpret logic, or generate plausible-looking analysis that doesn’t hold up under scrutiny. If AI outputs flow directly into action without a verification checkpoint, errors can propagate. The specification document creates a place where human judgment can catch what AI might get wrong.

For regulatory reform efforts, the parallel would be structured findings that policy analysts can review. AI would scan legal code and related documents and produce analysis: here are provisions that appear to require reports, here are potential conflicts between statutes, here are requirements that may be duplicative. But the AI doesn’t determine that these provisions are actually burdensome. It surfaces candidates. Humans review the candidates and make determinations.

This framing sets appropriate expectations. AI doesn’t replace the policy judgment required for reform. It makes that judgment possible by surfacing relevant material from a corpus too large for humans to review comprehensively.

Instruction Sets as Portable Knowledge

One of the most useful concepts from SpecOps is the instruction set – the explicit guidance that teaches AI how to analyze a specific type of material (like legacy code) – are shareable.

An instruction set for understanding COBOL code includes patterns for recognizing how COBOL structures logic, common idioms in government COBOL systems, and guidance for extracting business rules from procedural code. The instruction set is what transforms generic AI capability into context-specific analysis.

These instruction sets turn out to be highly portable. An instruction set for comprehending COBOL eligibility calculations works whether you’re modernizing a benefits system in California or a tax system in New York. The COBOL is similar enough, and the patterns of government system design are common enough, that the instruction set transfers and is useful in multiple contexts.

The same principle also applies to regulatory analysis. An instruction set for identifying reporting requirements in statutory language should work across states. One for spotting conflicts between statutes and implementing regulations could be refined through use in one jurisdiction and then shared with others. The patterns of legal drafting are similar enough that instruction sets should transfer.

This creates an opportunity for cumulative improvement. A first-generation instruction set for identifying burden sources will likely have some gaps. Those gaps become visible when policy analysts review the output and note what was missed or mischaracterized. The instruction set can then be iteratively improved, and subsequent analysis will be more accurate. Each jurisdiction that uses and refines these instruction sets can make them more valuable for the next jurisdiction that uses them.

If tools are built around explicit, shareable instruction sets rather than opaque proprietary products, the knowledge of how to find regulatory burden becomes a public good that accumulates over time.

Simple Tooling Is All You Need

One implication worth emphasizing: the tooling required for this work is not exotic.

The minimum viable toolchain for SpecOps is a Git repository, an AI coding agent, basic instruction sets, a markdown or text editor, and a pull request workflow for reviews. No specialized or expensive platform is required.

The regulatory analysis equivalent would be very similar: a frontier AI model with sufficient context window, instruction sets tuned for identifying burden patterns in legal text, a repository for managing those instruction sets and storing outputs, and a review workflow that routes findings to policy analysts for verification.

The value is in the methodology and the shareable instruction sets, not in proprietary tooling. This is important for sustainability and for cross-jurisdiction sharing. States can adopt and adapt the approach using tools they very likely already have access to.

The Future of Regulatory Reform

Teams are actively exploring how AI can accelerate the identification of administrative burden in government regulations. The opportunity is real: AI can help humans see what’s in these massive textual corpora at a scale that manual review alone simply cannot achieve.

But the goal isn’t AI-generated reform recommendations. The goal is comprehensible representations that allow humans to exercise judgment effectively. AI can surface candidate options for change. Humans haver to verify these findings and make decisions about what to actually change.

The SpecOps methodology was developed for legacy system modernization, but the core principles applies to regulatory reform as well: before you can safely change complex accumulated logic, you need to understand what’s actually there.

2026-02-22 Update

2026-02-23T00:00:00+00:00

Work Stuff

Its been a while.

I left the IRS voluntarily last year during what was unarguably a shit time for federal employees. I might write about my federal experience at some point, but theres not much to say that hasnt already been said ^{[footnote 1]}.

Either way, Im back at the Suffolk LIT Lab, at my same old role, which coincidentally opened back up right before I decided to leave the IRS last year (and definitely played a part in that decision). Working on a lot of the same work there, which is better recorded at its blog.

Its fine.

Personal

Doing

I dropped Spotify, and after a brief stint with Tidal, am just self-hosting Jellyfin as a Music streaming service, which is great. It just runs on my desktop, and I download whatever albums Im listening to at the moment to FinAmp on my phone. It just works. Its gotten me listening to my older music library at lot more.

Upgraded to PopOS! 24.04 recently. Its fine, but the desktop environment, Cosmic, kinda sucks. Its really buggy, and just doesnt work like it should. Switched to Gnome, and its fine.

Ive become a bit of a home improvement DIY-er, painting my living room and working on making wall-to-wall shelves above the TV. Still in progress, maybe Ill post pics when Im done with that.

Listening To

A ton of great stuff since I last updated. Some favs:

Fat Dog is my favorite new band, followed closely by Touchdown Jesus.
As is tradition, listened to a lot of Bad Bunny before and after his Superbowl performance.
Graham Kartna has been around a while, but I only recently listened to his full length albums, For Your Safety and the Safety of Others, and its incredibly catchy and surprisingly good song writing and lyricism.
Im about 7 years late, but Persona 5 has the best game soundtrack of all time. Been listening a lot to the Silksong Soundtrack recently too.

	Song	Artist
	BAILE INoLVIDABLE	Bad Bunny
	Lace	Christopher Larkin
	I Love My Wife	Touchdown Jesus
	King of the Slugs	Fat Dog
	Folds Like Origami	Kainalu

Gaming

I happened to break my leg after getting hit by a car on my bike last year, so I had a lot of time to play games and got through a good chunk of my backlog.

Balatro: fun game, but didnt keep me sucked in for more than a few days.
Outer Wilds: amazing game. Go in blind.
Persona 5: As mentioned above, incredible soundtrack. The gameplay I enjoyed less though, and it got extremely repetitive / grindy in the endgame.
Read Dead Redemption 2: Similar complaints to Persona 5; the gameplay is fine, but gets so grindy by the end. But despite that, it tells a great story, and cant really be separated from all of that grind.
Silksong: Good game, but idk, it crosses the line into not fun because of the boss difficulty. Set it down multiple times for like a month at a time when I got stuck on bosses, and just gave up at the Act 3 final boss.

Reading

Read embarissingly little this last year.

I did get through the entirety of Berserk, through the last Miura chapters. Its good, gorgeous, and has somehow affected even more of the media I consume that I thought it had.
Getting through House of Leaves now, I like it, and enjoy the complexity, but storywise, Im halfway through and feel like Ive got it, I dont know what else they could do.

For clarity, Fuck Trump, Fuck ICE, and Fuck Musk. [go back to reference]

From Sharing Code to Sharing Knowledge

2026-02-18T16:25:10+00:00

How AI Tools are Changing Government Technology Collaboration Forever

The world of software development is changing rapidly, and the implications for how governments share technology are only beginning to come into focus.

For two decades, the vision for reducing waste in government technology has been straightforward: build once, share widely. Fifty states all need unemployment insurance systems. They all need licensing systems, benefits administration, tax processing. Why should each one spend the effort to build essentially the same thing? The legacy contractors who currently dominate this space have built their moats around proprietary code and switching costs, charging full price to build similar systems in state after state. The logic of sharing drove open source policies like the Federal Source Code Policy and the SHARE IT Act, which require agencies to make custom code available for reuse.

A recent piece in the Law and Political Economy Project blog, “The Means-Testing Industrial Complex”, offers a thoughtful examination of this dysfunction. The author – Luke Farrell, a veteran federal technology leader – shines a bright light on the waste of the current contractor-dominated model and the extraction enabled by private equity consolidation. Luke’s piece is an important read. But it also suggests, almost in passing, an idea that deserves more scrutiny – that CMS could build an open source version of Medicaid eligibility software for states to use and build on, following the model of IRS Direct File.

This idea encapsulates some assumptions that deserve closer examination, assumptions that may no longer hold as AI-assisted development tools mature.

The Friction Points of Code Sharing

There is room for debate about the success of government open source code initiatives, at least as far as driving reuse of code in one agency or government that is built by another. There are some clear examples of how open source software and code sharing have worked really well. Shared platforms like cloud.gov and Login.gov, and shared standards like the U.S. Web Design System are some notable examples. But leaving aside questions about the efficacy of this approach, the traditional model of sharing code between agencies and between governments faces inherent friction.

Different jurisdictions have genuinely different requirements. A licensing system for professional engineers encodes specific requirements about education, examination, and experience that can vary (sometimes widely) by state. A benefits eligibility system implements rules that reflect each jurisdiction’s specific policy decisions. Adopting another jurisdiction’s code means either accepting their policy choices or doing significant adaptation work.

A reasonable counterargument is that well-designed software can separate jurisdiction-specific policy logic from common infrastructure through modular architecture and configuration. In theory, you could build a licensing system where the core workflows are shared while the specific requirements for each profession in each state are configuration parameters. But building software this way is harder and more expensive than building for a single use case. It requires anticipating variation, designing clean abstractions, and maintaining flexibility that may never be used. Government contracts typically reward delivering specific functionality on time and within budget, not elegant architecture or modularity that hypothetical future adopters might appreciate. The agency paying for the system bears the cost of building for reuse while the benefits accrue to other agencies that may or may not ever adopt it. The existing incentive structure works against modularity even when everyone agrees it would be valuable in the abstract.

Technology stack fragmentation also creates barriers to traditional software sharing. One state may use Ruby on Rails, another may use Python and Django, a third favors Java or the .NET Framework. Even functionally similar systems can become difficult to share when the adopting jurisdiction lacks expertise in the originating jurisdiction’s technology choices.

Adoption requires capacity the adopter simply may not have. Understanding someone else’s codebase, evaluating whether it fits your needs, identifying what must change, making those changes without breaking things, and maintaining the modified version over time all demand technical expertise. For agencies that struggle to maintain their existing systems, taking on a complex external codebase may not reduce their burden at all.

Maintenance obligations can persist after adoption. Once an agency has adopted open source code, someone has to keep it running, patch security vulnerabilities, update dependencies, and adapt to changing requirements. The original developers may have moved on; the adopting jurisdiction now owns this burden now.

How AI Changes the Equation

AI-assisted coding tools are shifting the economics of software development in ways that change what’s worth sharing.

The cost of writing code is dropping. Tasks that once required days of developer time can now be accomplished in hours with AI assistance. Generating a working implementation from a clear description of requirements is becoming routine. Code is becoming way less expensive to produce.

The cost of understanding existing code is also dropping. Large language models excel at code comprehension. They can explain what unfamiliar code does, trace through logic, identify where specific functionality lives, and answer questions that would previously have required access to the original developers.

But while the economics of what we can learn from legacy code has changed, we still need humans to specify what the code should do. An AI assistant can be used to build a benefits eligibility system, but only if someone (a human) provides clear requirements about eligibility rules, edge cases, integration points, and workflow logic. The knowledge of how government programs actually work remains essential.

This changes what is scarce and what is valuable – and ultimately, what governments should focus on sharing and reusing. If code is cheap to generate and adapt, but domain knowledge remains hard-won, then the knowledge becomes the asset worth sharing rather than the code itself.

What Knowledge Sharing Looks Like

Consider what an AI coding assistant needs if it will be used to successfully build a government software system. It needs to understand the domain: what the system does, what workflows it supports, what edge cases exist. It needs to understand the regulatory context: accessibility requirements, security standards, compliance obligations. It needs to understand integration patterns: how this system connects to others, what data flows where, what APIs exist.

This knowledge can be captured and shared in ways that sidestep the friction points of traditional code sharing. The key is recognizing that some layers of knowledge are more portable than others.

The things that vary by jurisdiction: specific eligibility thresholds, fee structures, examination requirements, documentation rules, reciprocity agreements. These reflect policy choices that differ from state to state. The things that don’t vary much: the general workflow of receiving an application, verifying credentials, checking against requirements, issuing or denying a license, handling renewals, managing complaints. The structural patterns of how licensing systems work are common even when the specific parameters differ from jurisdiction to jurisdiction.

Shareable software specifications can describe these common workflow patterns while leaving room for jurisdiction-specific policy parameters. The specification captures the general shape of the system, the decisions that need to be made at each step, the data that needs to be captured, the integrations that need to exist. Each jurisdiction supplies their own rules to fill in the blanks. This is similar to how OpenFisca, the open source rules-as-code engine, operates: the engine and the structure for expressing rules are shared across countries, while each country models its own tax and benefit policies using the common framework.

Instruction sets can inform AI assistants about government domains, legacy platforms, and common patterns. An instruction set for understanding COBOL has value whether you’re modernizing benefits systems in California or tax systems in New York. An instruction set describing the common patterns in professional licensing workflows can help an AI assistant generate better code regardless of which state’s specific requirements it’s implementing. The knowledge is portable even when the policy details are not.

Reference architectures can describe how systems should connect, what security boundaries matter, what integration patterns work. This structural knowledge helps any implementation fit into the broader ecosystem. In this model, jurisdictions build their own systems, generating much of the code with AI assistance.

But they build from shared specifications of common patterns, informed by shared domain knowledge, validated against shared structural tests. The knowledge of how these systems generally work transfers even when the specific policy logic doesn’t.

The Maintenance Advantage

Knowledge sharing also addresses the maintenance burden differently than traditional code sharing.

When you adopt someone else’s code, you own the obligation to maintain it. When you generate code from shared specifications using AI tools, you can regenerate or modify it as needs change. The specification remains the source of truth; the code becomes more disposable.

Maintaining specifications and instruction sets still requires effort. Rules change, edge cases get discovered, better patterns emerge. But the burden differs from maintaining a running codebase. And updates to shared knowledge resources benefit everyone building from them, without requiring coordinated deployments or version management across independent instances.

Looking Ahead

The case for traditional government code sharing rests on the assumption that code is expensive to write and therefore should be reused. AI-assisted software development is eroding that assumption. Code is becoming cheaper to produce. The scarce resource is no longer working code, but the knowledge required to specify what code should do.

This suggests the future of government technology collaboration may look less like code sharing and more like a system for sharing open source software specifications Specifications, test suites, domain models, instruction sets that encode understanding of how government actually works. It can all be shared, and it is increasingly becoming more valuable than code itself.

I explore this shift in detail in The SpecOps Methodology, which describes an approach to legacy system modernization built around capturing and sharing institutional knowledge. In a world where AI tools can generate implementations from specifications, the specifications themselves become the durable, shareable asset.

The people who have spent years advocating for government technology sharing aren’t wrong that collaboration should reduce waste and improve outcomes. But the question of what governments share, and what they reuse is changing. As the economics of software development shift, the answer may be shifting too.

Failing to run a server on 3 different phones

2026-02-13T01:00:00+00:00

Ive had this article on how to turn an old phone into a web server bookmarked for months, and finally got around to actually trying it. I, for some strange reason, have a series of old phones in my closet. You can sometimes trade in old phones for a credit when getting a new phone, but I end up keeping my phones long enough that the credit is $0, lol. This is the exact sort of thing Ive been waiting to use my old phones for.

While the post itself is simple, trying to actually do any of this is kinda ridiculous, mostly due to battery and unlocking issues. I couldnt even get past the first section of that post. All of my attempts failed, so Ill recap in order of simplest failure, to most complex.

The Moto X

My Moto X, already a budget phone when I got it in late 2013, is now 13 years old! Unfortunately, that means its completely borked. I plug it in to charge, the change screen comes up with 0%, it charges for about a minute, shows the Moto boot screen, vibrates, then dies. I assume that it cant even hold enough voltage to turn on. So thats a no go unfortunately. I could try to replace the battery, but that has gone poorly for me in the past (see the next section).

The Pixel 3: At least the phone turns on

The next phone is the most recent one; a Pixel 3. I originally replaced this one after attempting a battery swap and not being able to turn the phone on after. Im not sure how, but after leaving it plugged in for ~30 minutes, it charges! It inconsistently turns on, but at least it does! A miracle that will quickly be stymied.

Following our article, we first go to the Postmarket OS wiki page for the phone. The first step to make any progress is to unlock the bootloader of the phone. It differs from each Android version, but in most of them you find the build number for the phone in the settings (under settings, System info or About this phone), and tap the build number a bunch of times. Eventually (after like 7 or 8 taps), youll get a prompt to keep tapping to become a developer. This unlocks some more options in your settings, meant for app developers working on the hardware, but IMO are always useful to enable. On that page, there should be an option labeled OEM unlocking, and one labeled USB Debugging. You have switch both on to be able to put Postmarket OS on your phone.

I immediately hit a wall, because the OEM unlocking option is grayed out with the message connect to the internet or cantact your carrier. Hm. Its already connected to the internet. After various searching, I try:

Updating to the latest OS. Doesnt work.
Forcing a check in by going to the phone and dialing *#*#CHECKIN#*#*. No change.
Factory reset. Still nothing.

I see a bunch of people saying that Verizon carrier phones cant be unlocked, but I remember specifically getting this phone from the Google store directly, unlocked, for this reason. I eventually find this gravestone of a post: if a phone has an encrypted bootloader, it cant be unlocked. It is what it is, and theres no point in attempting to pursue the matter further. Everything sucks and the appeal of Android is a lie.

The Nexus 6P: The furthest along, the most frustrating

My Nexus 6P was in the best condition of all of these so far, and it still turns on okay. The Postmarket OS wiki page for the Nexus 6P is sparser than the Pixel one, but we know about the secret unlocking step ^{[footnote 1]}. Luckily, this phone doesnt have an ecrypted or carried locked bootloader, so the setting can be easily turned on.

Oh, but that just gives you the ability to unlock the phone. Unmentioned anywhere on the Postmarket wiki (that I could find) is that you need to also install adb and fastboot to actually unlock the phone. These can be installed on Ubuntu with sudo apt install adb fastboot. Keeping the phone on, plug it in to your computer and accept the prompt asking if it should allow USB debugging. Confirm that your computer can see the phone by running adb devices. Then, turn the phone off, and hold the power and volume down buttons until a weird little screen with the android being dissected comes up.

Just look at him. Somebody help the lil guy.

fastboot devices should show the phone now (adb devices wont). From there, you run fastboot flashing unlock to actually unlock it.

Next step is to install pmbootstrap on my computer, straight forward enough thanks to uv^{[footnote 2]}. pmbootstrap init and pmbootstrap install run fine, and I mostly follow the defaults at each prompt.

After that, you can run pmbootstrap flasher flash_rootfs (and also pmbootstarp flasher flash_kernel?). At this point, its supposedly done, and you can ssh in to the device when its plugged into your computer, but I cannot get this part to work. It doesnt show up when I see what IP addresses Im connected to with ip a, and it just shows the Google logo the whole time. Idk why, I just seem to be at an impasse. I initially tried using the console UI for Postmarket, and thought that maybe a different UI would show more information, so I tried again with the buffyboard UI instead. No luck. Discovered on a different page of the Postmarket OS wiki that I should be running pmbootstrap chroot fastboot reboot after installing to make sure everything wrote correctly, but no change, still a mystery Google screen.

Conclusion?

Idk. Ill probably recycle the Moto X and trade in the Pixel 3 (where it will probably also be recycled). I probably should with the Nexus too, but idk. Theres a reason I never got into hardware; its inscrutible and you hit hard walls that I just dont seem to with software. Bummer of an ending.

Note: the order of this article is not the order in which I tried these phones. I spend a very confused 30 minutes trying to figure out why it wasnt working on the Nexus before realizing I had to unlock the bootloader first. [go back to reference]
Outside the scope of this article, but uv is the closest to just working that Ive ever seen the Python ecosystem get. Fairly refreshing, and makes me sad every time I have to interact with pip. [go back to reference]

Government Software at the Crossroads

2026-02-11T14:58:09+00:00

The software industry is undergoing its most significant transformation since the rise of cloud computing. Last week, $285 billion in market cap evaporated from software stocks in a single day a selloff traders are referring to as the “SaaSpocalypse.” Investors seem to have reached the conclusion that AI agents are going to reshape how organizations buy and use software. I don’t think they are wrong.

Private sector companies are scrambling to adapt. But there’s another sector that may be even more exposed to this shift, and far less prepared for it: government.

Really Bad Timing

Many government technology leaders are being asked to make major procurement decisions during a period of unprecedented instability in the software industry. The assumptions that have traditionally guided smart technology investments for the past decade buy commercial off-the-shelf software, pay per seat, move to the cloud may no longer hold.

The problem is that the government procurement cycle is slow by design. Decisions being made today will bind agencies to contracts lasting as long as five to seven years. An enterprise agreement signed this in Q1 could lock an agency into paying for software seats that AI tools have made redundant by year three with no easy off ramp.

The traditional mismatch between government procurement cycles and the pace of change in the technology industry is becoming even more acute in the AI era. This problem is only going to get worse.

Still Fighting the Last War

Most government technology leaders are still operating from a playbook written in the 2010s. The common strategy is to modernize legacy systems by migrating to commercial SaaS products. This may have been the right move ten years ago. Cloud-based software offered better security, lower maintenance burden, and faster feature updates than aging on-premise systems.

But the landscape has shifted significantly, particularly in the last 12 months. The value of software is migrating from user interfaces to APIs, from per-seat licenses to outcomes, from products to orchestration layers. AI agents don’t need polished dashboards they need access to data and the ability to execute tasks. A procurement strategy optimized for buying seats for commercial interfaces may be optimizing for exactly the wrong thing.

The mental model of “replace the old thing with the new commercial thing” simply doesn’t account for a world where AI agents can wrap existing systems, orchestrate actions across them, and generate deliverables without requiring wholesale replacement of underlying infrastructure.

A Matter of Trust

Another concern for government organizations is that the organizations best positioned to advise them on these shifts – existing legacy vendors – are often not incentivized to do so.

Large systems integrators and consultancies that guide government technology strategy make their money from complexity and labor hours. A message of “you may need fewer tools, less customization, and smaller teams orchestrated by AI” does not align with their business model. So government leaders may not hear that message they need to hear until the shift is already obvious and the contracts are already signed.

Even absent malice, the fact that these changes are misaligned with existing legacy vendors business models means that simply won’t be incentivized to provide the information government leaders need to hear, when they need it.

The Build-vs-Buy Calculus Is Changing Fast

There’s another assumption baked into traditional government technology strategy that deserves a reexamination – the economics of building software.

For a long time, this logic was straightforward. Custom software development was expensive, slow, and risky. Projects routinely ran over budget and past deadlines. Maintaining bespoke systems required specialized staff that agencies struggled to hire and retain. Commercial off-the-shelf products offered a potential way out vendors amortize development costs across many customers, governments benefit from continuous improvement and transfer the maintenance burden to external organizations built better for it.

This logic has driven the preference for COTS and SaaS procurement. Why build it when you can buy it?

But the economics of software development have shifted dramatically in the past eight months. AI coding assistants have moved from novelty to core infrastructure. Recent analysis suggests that a meaningful percentage of code commits on major platforms are now authored by AI not assisted by AI, but generated by it. The changes we are seeing are not trivial. Entire codebases are being refactored by AI agents working in parallel. This will change the math on custom development. The cost of building software tailored to an agency’s specific needs rather than adapting workflows to fit a vendor’s product is dropping rapidly.

None of this means commercial software will go away overnight. But it does mean the factors that made COTS and SaaS the default safe choice are eroding. The question “should we buy or build?” deserves renewed analysis based on current economics, not assumptions inherited from an era when custom development was synonymous with cost overruns and contractor dependency.

A Different Kind of Risk

The traditional risk calculus in government technology focuses on project failure the big modernization effort that goes over budget, misses deadlines, or fails to deliver promised functionality. These are real risks, and they’ve shaped a culture of caution around major technology investments in government.

But there’s a different kind of risk emerging: the risk of committing to a technology strategy that becomes obsolete mid-execution. The risk isn’t that the project fails it’s that it succeeds at the wrong thing. An agency could execute flawlessly on a cloud migration strategy and still end up paying for years of software licenses that deliver diminishing value as AI reshapes workflows around them.

This is new territory. The frameworks government uses to evaluate technology risk weren’t designed for a world where the underlying economics of software could shift dramatically within a single contract period.

What Would A Safe Approach Look Like?

Given all this uncertainty, what would a prudent approach to government software strategy look like in early 2026? I think it looks something like this:

Shorter commitments where possible. The long-term enterprise agreement that locked in favorable pricing made sense in a stable environment. In a period of rapid change, flexibility may be worth more than discounted pricing. Agencies should scrutinize contract terms that limit their ability to adapt quickly.

Invest in understanding before deciding. Before committing to a modernization path, invest in truly understanding existing systems not just their code, but the institutional knowledge and business logic they embody. That understanding has value regardless of whether you eventually replace, wrap, or extend those systems. Methodologies like SpecOps that focus on generating verified specifications of legacy system behavior offer a way to preserve optionality while the landscape clarifies.

Watch the API layer, not the interface. When evaluating software, pay attention to how well it exposes functionality via APIs, not just how polished its user interface is. The interface matters less in a world where AI agents are increasingly the “users” of enterprise software.

Cultivate independent perspective. Seek out advisors whose business model doesn’t depend on selling implementation services, and who have expertise in using AI to develop solution. The analysis that matters most right now is the analysis that might recommend doing less, not more.

The Time Is Now

Government technology decisions have always involved balancing risk against opportunity. What’s different now is the speed of change in the underlying assumptions.

The organizations that navigate this transition the best will be those that recognize the moment for what it is: not a time to double down on the strategies of the past decade, but a time to preserve optionality, invest in understanding, and resist the pressure to lock in long-term commitments based on a model of software value that may already be shifting beneath our feet.

The window to make these adjustments is right now before the next round of multi-year contracts for COTS or SaaS software are signed, and before government agencies find themselves paying for a model of software that the rest of the world has moved on from.