By the ProofCohort team. Questions or corrections? Contact our team.Published
What should you check before deploying AI-generated code?
Review the behavior you will own: permissions, data handling, failure paths, and the evidence that the change works. Passing a build only shows that the application compiled. It does not establish that one user cannot edit another user's record. GitHub's September 2026 discussion of AI-assisted development emphasizes review and technical judgment. This checklist applies that principle to a small project API, with checks you can demonstrate in a pull request.
Start with the request and its side effects
Suppose an assistant adds a feature that lets a learner submit a project URL for review. Before reading the diff, write the expected behavior: an authenticated learner can submit to their own active enrollment; the request validates the URL; retries do not create duplicate submissions; a failed save does not display success. List the route, database records, background work, and user-visible states affected. This gives your review a concrete contract instead of a vague search for code that looks wrong.
Test authorization at the operation itself
OWASP recommends checking permissions on every request and denying access unless permitted. Authentication establishes identity; authorization decides what that identity may do. In Next.js, a page-level check does not protect a Server Action by itself. Recheck identity and access inside the operation, using trusted server-side information. Apply the same principle to an API endpoint in another framework. A disabled button, hidden menu, or client-supplied role is not an access decision.
Use a concrete review matrix
Run these checks in your own local or staging project with synthetic accounts. For every denied request, inspect persisted state as well as the response. An error message is misleading if the write already happened.
| Check | Exercise | Expected result |
|---|---|---|
| Signed-out access | Send the submit request without a valid session. | Reject it; create no submission. |
| Record ownership | Use test user A with test user B's enrollment ID. | Reject it; reveal no private enrollment details. |
| Input handling | Send a missing URL, an oversized value, and an invalid scheme. | Return a useful validation error; do not save invalid data. |
| Retry behavior | Repeat the same logical submission after a simulated lost response. | Follow the documented retry policy without creating unintended duplicates. |
| Dependency failure | Make the save operation fail in the test environment. | Show a recoverable error and preserve the user's draft. |
Follow untrusted data beyond the first validator
Trace each accepted value to where it is used. A valid-looking URL may still be unsafe for a server to fetch; storing a user link and fetching it are different features. In this example, keep automatic URL fetching outside scope until its network boundaries are designed. Use parameterized database operations, return only the fields the UI needs, and keep privileged credentials out of browser code and logs. Review new dependencies against their actual documentation and purpose. A generated import is not evidence that a package exists, is needed, or is correctly configured.
Make tests independent of the generated implementation
Write the expected outcome from the requirement, then inspect whether the test would catch the actual bug. For the ownership case, create two test users and two enrollments, attempt the cross-user submission, and confirm the second enrollment is unchanged. A mock that always returns the current user's enrollment cannot exercise that mistake. Prefer a small integration check at the boundary where identity, permission, and persistence meet. Keep a separate happy-path test so a change that rejects every request cannot look successful.
Review the browser states and release evidence
Open the form on a narrow screen and with a keyboard. Check the field label, validation message, pending state, failure recovery, and final confirmation. Test a slow response instead of relying only on a fast local connection. Before publishing, save the build and test commands, the behavior checked, and any remaining limitation. If a change includes a migration, understand its effect on existing rows and how recovery would work before applying it. Rollback is a plan to verify, not a synonym for redeploying the previous UI.
How should you describe AI assistance in a portfolio?
Explain which work the tool assisted with and which decisions, reviews, and checks you performed. Keep an example of a defect you identified and the evidence that the fix addressed it. Do not publish private prompts, account data, or secrets to prove tool use. Follow your program's disclosure requirements and link a repository or demo that a reviewer can inspect. A short, accurate explanation of your contribution is more useful than claiming every line was handwritten or accepting generated behavior you cannot explain.
Explore related programs
Read each program's prerequisites, duration and weekly syllabus before applying. Enrolled learners follow their assigned tasks; independent practice alone does not earn a certificate.