Accelerating software delivery without compromising accreditation
AI assisted development produces measurable reductions in the time required to write, test, and document software. Federal teams adopting these tools report genuine gains.
On federal programs, those reductions frequently do not produce earlier delivery to users. Code written more rapidly still requires review, testing, security scanning, documentation, assessment, and authorization. Where the accreditation path is measured in months, increased development velocity changes the size of the queue rather than the delivery date.
This is not an argument against adoption. It is an argument that adoption without a corresponding change to the accreditation path produces a faster team and an unchanged schedule.
Applications with the highest federal value
The applications producing the greatest value in this environment are not those most frequently demonstrated.
Legacy comprehension. Many federal systems are decades old, implemented in languages with a contracting practitioner base, and inadequately documented. Artificial intelligence performs well at explaining unfamiliar code, tracing logic paths, and generating documentation for systems whose original authors are unavailable. On modernization programs, comprehension of the existing system is frequently the longest scheduled activity.
Test coverage on inherited code. Legacy systems frequently carry limited automated test coverage, which is the condition making modernization risky. Generating characterization tests that capture current behavior establishes the verification basis required before refactoring.
Compliance documentation. Control documentation, system security plan narratives, and configuration evidence consume substantial engineering capacity. Generating them from actual system configuration, subject to human review before submission, is well suited work.
Infrastructure as code. Generation and review of infrastructure code, particularly for hardened baselines and control implementation.
Greenfield feature velocity, the application most frequently demonstrated, is rarely the binding constraint on federal programs.
Required controls
Prohibition on controlled unclassified information, credentials, and sensitive configuration in prompts to external services. This requires technical controls and explicit guidance, as the failure mode is inadvertent rather than deliberate.
Provenance and licensing review. Generated code requires the same license examination as any dependency, and software bill of materials discipline is more consequential where generation is rapid.
Human review. Generated code that no engineer fully understands constitutes a maintenance liability and an accreditation risk. Review standards should be at least as rigorous as those applied to manually written code, as generated code is frequently plausible in appearance and incorrect in detail.
Continued security scanning. Artificial intelligence changes the method of code production rather than the verification requirement.
Advancing the accreditation path
Compliance as code. Express control implementations as testable, versioned configuration rather than as prose. Evidence generated continuously from operating systems is stronger than evidence assembled periodically for assessment.
Control inheritance. Development on an authorized platform with a documented control baseline inherits a substantial proportion of the required work. Establishing precisely what is inherited and what must be implemented is among the highest value architecture decisions available on a federal program.
Continuous monitoring. Ongoing authorization replaces periodic reauthorization with continuous evidence. Where an agency supports this model, delivery economics change substantially.
Early assessor engagement. Findings identified late are expensive to remediate. Involving the assessing organization during design, rather than at system completion, consistently reduces the authorization timeline.
Position
Federal teams should adopt AI assisted development. The binding constraint on most federal programs is not development velocity. It is the interval between completed code and operational capability in the hands of users.
On modernization programs, schedule risk has consistently originated outside the development activity. It has been attributable to assessment scheduling, control narratives requiring revision following architecture changes, and dependencies on platform authorizations delivered later than planned. Teams optimize the activities within their control, which is a reasonable response and rarely where the schedule is determined. The higher value allocation is early effort directed at the activities outside their control, specifically engaging the assessing organization during design rather than at completion.
Programs delivering effectively are advancing development velocity and accreditation capacity concurrently.