This recommendation may be more contested than the others, so we will state it as a testable prediction rather than an argument: within a short number of years, a small team, and eventually a single experienced practitioner, using AI-assisted development will be able to build a working system covering the core capabilities of a Medicaid Enterprise System in a timeframe and at a cost that today’s market would consider impossible. The ability to deliver software is improving at an exponential pace, and nothing about Medicaid’s functional requirements exempts them from that curve. The prediction is testable through exactly the demonstration mechanisms recommended elsewhere in this response, and CMS should want it tested: if it is wrong, the cost of testing was small; if it is right, every current assumption about vendors, products, and procurement changes.
The implication is that the ecosystem should prepare for a future that does not depend on commercial software products at all, where the vendor market shifts from selling products to providing expert services: domain knowledge, delivery capability, and accountability for outcomes, applied to software that is built rather than bought. This seismic shift will benefit the government organizations that are ready to pivot and strand the ones whose standards, funding rules, and certification pathways assume current COTS models are permanent.
Preparing costs almost nothing and forecloses nothing. It means writing standards about data, interfaces, security properties, and outcomes rather than about products and modules, so that an AI-built component qualifies on the same evidence a COTS module does. It means certification and authority-to-operate pathways that judge working software on demonstrated properties rather than vendor pedigree. And it means resisting the temptation to enshrine today’s product landscape into the standards program’s definitions, because a standards program that hard-codes the present will be the single largest obstacle to adopting what comes next.