The fundamental problem with government software has never just been that it is badly built. It is that conventional software assumes a level of standardisation in users, processes, data, and institutions that government rarely possesses.
Generative AI changes both sides of that equation: it can make software dramatically easier to produce, but that also means software itself becomes less scarce and less defensible.
Why government software is so often terrible
Enterprise software starts with the premise that there is a stable, codifiable process. The conventional logic flows in a single direction:
process → requirements → software → users follow software
Government frequently works in reverse. A property-tax workflow in one Urban Local Body (ULB) isn't quite the same as in the neighbouring district. Field officers develop workarounds. Paper forms change. State rules diverge. Data fields arrive half-filled. Hindi, Punjabi, and English get mixed together in single text inputs. The workflow described in an RFP is almost never the workflow actually followed at the civic counter.
Procurement compounds this structural mismatch. A department is required to specify exactly what it wants before anyone has interacted with a prototype. The specification becomes a tender; the vendor optimises against the tender. Acceptance criteria focus on whether specified features exist in the repo rather than whether a citizen or clerk can successfully use them.
The result is software that is technically compliant and experientially absurd.
Once deployed, changing anything requires a formal change request, vendor negotiations, budget approvals, and another multi-month development cycle.
The software gradually becomes a fossilised representation of what somebody believed the department did three years ago.
Consumer software evolved rapidly because platforms observe millions of live interactions and change an interface overnight. Government software, by contrast, treats the user interface as a frozen legal contract.
GenAI attacks that rigidity
The most consequential impact of AI in government is not placing a chatbot on top of a portal. It is that the distance between specification and working software is collapsing.
The software development lifecycle shifts toward an iterative loop:
intent → specification → generated application → test → deployment → observation → revised specification
A department head can describe an operational rule in plain language:
An engineer should see all unresolved road complaints in her ward, inspect the associated photographs, assign the complaint to a contractor, and escalate anything unresolved after 72 hours.
That description can increasingly be converted into schemas, user interfaces, database permissions, API endpoints, automated test suites, and escalation workflows with substantially less bespoke engineering.
Variation suddenly becomes cheap. Instead of forcing Punjab, Karnataka, and Madhya Pradesh into an identical, brittle application, a central team can maintain a common underlying specification while generating controlled local variations.
The standardised object no longer needs to be the user interface. It can be the specification, data model, permission matrix, API boundary, audit log requirement, and deployment architecture.
The commoditisation paradox
The same technology democratising software creation destroys traditional barriers to entry for vendors. Five years ago, producing a credible Public Grievance Redressal (PGR) system required a substantial engineering organization, months of scaffolding, and dedicated interface designers.
Now, a small team using Claude Code, Codex, and standard cloud infrastructure can assemble an impressive-looking grievance dashboard in days.
Suddenly, fifty companies can demonstrate essentially the same product:
- AI-powered grievance redressal
- AI-powered property intelligence
- AI-powered command-and-control
- AI-powered water management
- AI-powered municipal dashboards
This creates a sharp operational paradox:
GenAI makes government software easier to build at the exact moment it makes choosing government software harder.
The bottleneck shifts. It was once “Can somebody build this system?” It becomes “Which implementation can actually be trusted to work under administrative stress?”
Value shifts from software to systems
If applications become cheap to generate, the valuable layer moves downward and outward:
messy reality → data → ontology → specification → application → workflow → institutional adoption
The generated application becomes the least defensible node in that chain.
Imagine twenty vendors generating a slick road-maintenance dashboard. Very few can reliably answer the load-bearing questions sitting beneath the interface:
- What exactly constitutes a road segment in municipal records?
- Which agency owns this specific right-of-way?
- How are road IDs reconciled between legacy GIS layers and department MIS?
- Is this reported pothole genuinely new, or a duplicate entry from another channel?
- Which engineer has legal jurisdiction over this repair?
- What evidence constitutes formal contractual closure?
- What happens when the field engineer disagrees with the model's classification?
- How does this entry trigger contractor billing and audit trails?
- Can the same system deploy in another city whose underlying data looks completely different?
These are not primary coding problems. They are systems-design, ontology, and institutional-knowledge problems.
This points toward spec-to-prod government infrastructure. Instead of tendering for a static PGR application, government bodies can define what a compliant PGR system is. The underlying infrastructure generates and configures the implementation, executes continuous tests against the specification, deploys into the secure public cloud, and audits compliance in real time.
In this model, LLMs and code-generation engines are not competitors to the platform. They are interchangeable compilation engines underneath it.
When anyone can build the application, competitive advantage belongs to those who own the understanding of government itself—its semantics, exceptions, edge cases, and decision structures—rather than the source code.
As explored in India’s AI Problem Is a Data Problem, AI lowers the cost of turning an understood problem into software, but does not automatically lower the cost of understanding noisy ground reality. In Indian civic tech, that institutional data layer is the real moat.