Reviewing and Testing Code Written with AI Assistants

An AI coding assistant can help a developer draft an endpoint, suggest tests or work through an unfamiliar library. The resulting code still needs to fit the application around it: its permissions, data model, error handling and operational requirements.

For companies adopting these tools, a useful first step is to review how generated code enters the development process. Who checks it, what context do they have, and which tests need to pass before it is released?

Those questions give engineering leaders a practical way to manage the change while the team learns where the tools are useful.

Keep changes small enough to review

If an assistant helps your team produce more code, check whether review time has grown with it. Larger changes can be difficult to assess carefully, especially when they introduce several behaviours at once.

Encourage developers to split work into changes with a clear purpose. The description should explain what changed, why it is needed and how it was tested. If generated code introduces an unfamiliar pattern or dependency, call that out for the reviewer.

The developer submitting the change should be able to explain how it works, including its failure cases. When that requires further investigation, allow time for it before merging.

Formatting and comments can help a reviewer navigate the code. They provide little evidence on their own that the behaviour is correct. The same review questions should apply regardless of how the code was written.

Make your application's rules explicit

An assistant works with the context it receives. A short request to build an invoice endpoint may omit the rules that determine which invoices a user is allowed to retrieve.

For example, an endpoint might successfully return an invoice by its ID while missing the check that the invoice belongs to the current customer's organisation. A test using an authorised account would pass. A test using an account from a different organisation would reveal the problem.

Document these rules where developers and reviewers can use them. For each sensitive workflow, explain the permitted roles, the data each role can access and any restrictions on changing or exporting it.

Enforce those permissions on the server for every relevant request. Include tests for both allowed and denied actions. OWASP's authorization cheat sheet describes these checks and the importance of granting only the access required.

Use automated checks throughout development

Automated tools can identify known vulnerable dependencies, exposed credentials and some unsafe coding patterns. Infrastructure checks can also flag configuration problems in the files used to provision your services.

Agree which checks run locally, which run in the build process and what should block a release. Assign someone to review findings so that alerts lead to a decision or a fix.

Generated code also deserves a check for new dependencies. Confirm that a suggested package exists, comes from the expected source, has suitable licensing and is appropriate for your project. Developers should understand why it is needed before adding it.

Coverage varies between tools and codebases. Track what each check can assess and where your team still relies on review or testing. That makes it easier to spot gaps when the application changes.

Give human reviewers a clear focus

Reviewers need enough context to judge whether the implementation matches the intended behaviour. A short checklist can help, especially for changes involving sensitive data or privileged actions.

Useful questions include:

• Who can call this function or endpoint, and where is that permission checked?
• Does each query return only the data the current user is entitled to access?
• What happens with missing, malformed or unexpected input?
• Could a response, error message or log entry expose sensitive information?
• Does the change introduce a dependency or external service that needs review?
• Do the tests cover denied actions and failure cases as well as successful use?

AI-assisted review can contribute suggestions, but someone should assess whether those suggestions apply to the product. An additional model review does not remove the need to verify the behaviour.

Test the working application

Code review and automated tests can detect access control problems. Tests against the running application add another view, particularly where several services, permissions or configuration settings interact.

For a product with multiple customer organisations, create test accounts in more than one organisation and with different roles. Check whether each account can access records, downloads, search results and exports it should be restricted from seeing.

Use a suitable test environment and agreed scope. Include regression tests for confirmed findings so future changes can be checked against the same behaviour.

An external assessment can help when you want specialist investigation or an independent view of important workflows. Define the areas you want examined and leave time for the team to address the results.

Agree what developers can share with assistants

Code security is one part of using a coding assistant. Your company also needs to decide which repositories, files and data the tool can access.

Review the specific product's settings and terms for data retention, training use and administrator controls. Give developers clear guidance on handling credentials, customer data and confidential material. Where an assistant can run commands or change files, define its access and review requirements as well.

Keep this guidance practical. A developer should be able to tell which tools are approved, what information they can use with them and where to ask about an unfamiliar case.

Questions for your next engineering review

If you are reviewing how your application handles permissions and customer data, talk to Intrudify about testing those workflows.