Before you ship AI-generated code

HUB LLC · 12 September 2026 · Commerce

Software generated with AI can look complete long before it is ready for customers. The useful question is whether the system behaves correctly, protects its data and can be operated by the people responsible for it.

This checklist is a starting point for reviewing a web application or internal business tool. It is not a security certification or an exhaustive audit. Apply it to the risks of the actual system, with deeper specialist review where needed.

1. Define the behavior you are accepting

Write down the important user journeys before inspecting implementation details. For each journey, specify the initial state, the action and the expected result. Include failures and repeated requests, not just the happy path.

For an order integration, “the order appears in the warehouse system” is incomplete. What happens if the network times out after the receiving system has already created the order? A retry should not silently create a duplicate. The business rule and its test must account for that case.

2. Inspect the boundaries

Identify what each user role can read and change. Test these permissions at the server or API boundary, not only through hidden buttons in the interface. Check that one account cannot fetch another account’s records by changing an identifier.

Separate configuration from secrets. Inspect the repository and deployment configuration for credentials. Rotate any exposed credential through the relevant provider, and investigate where it may have been used. Deleting a line from the latest version does not remove it from history.

3. Review the dependencies and architecture

List the libraries, external services and runtime versions the application depends on. Check that each dependency is real, appropriate and maintained for the intended use. Confirm that the lockfile and deployed environment agree.

Follow one important piece of data through the application. Where is it validated? Where can it change? Who owns the authoritative copy? Repeated validation or duplicated business logic across several generated files often creates inconsistent behavior.

4. Ask tests to challenge the implementation

A generated test can repeat the same wrong assumption as generated code. Begin with the behavior you specified, then make sure the checks would fail for a plausible defect.

• Exercise empty, malformed and unexpectedly large input.
• Test authentication, authorization and expired sessions.
• Simulate unavailable dependencies and partial failures.
• Verify duplicate requests and concurrent updates where relevant.
• Keep regression checks for every repaired business-critical defect.

Passing tests are evidence about the cases they cover. They do not establish that untested behavior is correct.

5. Rehearse the release and recovery

Build and run the application in an environment that represents the intended deployment. Confirm configuration, scheduled tasks, migration order and external integrations. Record what is expected to change and how you will know the release has succeeded.

A code rollback may not reverse a database migration. Plan recovery for both application and data, and rehearse restoration of the backups you intend to rely on. Identify who makes the rollback decision and what information they need.

6. Leave an operating trail

Make failures visible through useful logs and alerts. Avoid logging secrets or unnecessary personal data. Give the next engineer instructions to deploy, diagnose and recover the system without relying on the conversation that originally generated it.

The review should end with a decision: ready for the agreed use, ready after specific repairs, or blocked by unresolved risks. Record those risks with their impact, evidence and owner. “AI wrote it” explains the origin of the code; it does not replace an engineering assessment.

Tool documentation

For the current capabilities of individual tools, consult their official documentation: OpenAI Codex, Claude Code, GitHub Copilot cloud agent and Cursor Agent. Tool behavior and available controls evolve; this checklist describes engineering responsibilities rather than a tool ranking.