Engineering
How we treat AI-generated code in delivery pipelines
Coding assistants are part of how software is written now. Here is what that changes about review and testing, and what it does not.
Our engineers use AI coding assistants. They are useful for boilerplate, tests, and unfamiliar APIs. They also produce plausible code that is subtly wrong, uses outdated libraries, or introduces licenses and dependencies nobody asked for. Agencies that buy software should know how a vendor handles this.
What does not change
Every line reaches production through the same path: version control, code review by a second engineer, automated tests, security scanning, and an approval. The assistant is a tool the engineer uses; the engineer is responsible for the result.
What we added
Dependency review. Assistants suggest packages freely. Our pipeline flags new dependencies for explicit review and blocks those with unacceptable licenses or known vulnerabilities.
Test independence. When an assistant writes both the code and the tests, the tests tend to confirm the code's assumptions. We require that tests be reviewed separately and that acceptance tests derive from requirements, not from the implementation.
Secrets and data. Assistants must not receive agency data, credentials, or sensitive configuration. Our tooling runs in a mode that does not send code to train external models, and we verify that setting.
Provenance. We note in the pull request when significant portions were assistant-generated, so reviewers look harder.
What agencies should ask
Whether the vendor's engineers use assistants, what data those tools receive, whether the vendor's code review and testing process is independent of the tool, and how dependencies are controlled. A vendor who says "no AI" is either behind or not being straightforward; a vendor who cannot describe controls is the concern.
Bottom line
The productivity is real. So is the need for discipline. Pipelines and review practices that were good before are what make assistants safe to use now.