Q: What is the first step in verifying AI-generated code? A: Treat every AI suggestion as a draft and start with a clear spec written in plain language that states inputs, outputs, and error cases. Write unit, property, and negative tests before accepting the model’s code, because that test-first approach is the foundation of how to verify AI-generated code. Q: Which tests should I write to catch edge cases in AI code? A: Write unit tests for expected behavior and include property-based tests for tricky logic like sorting, parsing, or math. Add negative tests for bad inputs, timeouts, and permission errors, and define acceptance tests that mirror real user flows. Q: How can I make AI models use my project context when generating code? A: Provide the model with exact files, schemas, and API shapes or links, and ask it to cite file paths, function names, and line numbers it relied on. Request a short design note explaining what changed and why, prefer diffs over full rewrites to reduce scope, and have it list invariants the code must maintain. Q: What static and automated checks should I run on AI-generated code? A: Run linters, formatters, and type checkers such as mypy, ESLint, or go vet, and add SAST and secret scanners to catch insecure patterns and leaks. Also scan dependencies for CVEs and license issues, use another model for a second opinion, and benchmark hot paths or add basic load tests if performance matters. Q: How should I run AI-generated code safely before deploying it? A: Execute the code in a container or sandbox with least privilege, mock external services, and use ephemeral databases and test fixtures. Do differential testing against a trusted implementation or golden files, fuzz inputs to find crashes and edge behavior, and run chaos tests for timeouts and partial failures. Q: What specific issues hide in “working” AI code that I should check for? A: Watch for security and data-safety traps like missing or misplaced auth checks, insecure defaults, leaked secrets, and lack of input validation that can enable SQLi, XSS, or SSRF. Also check for correctness and reliability problems (happy-path only, tests that mirror the implementation, clock or locale assumptions, and incorrect error propagation) and for performance or platform-fit issues such as N+1 queries, unbounded loops, blocking calls, or microcontroller pin/timing errors. Q: How can teams keep velocity while verifying AI-generated code? A: Keep velocity by writing or refining the spec and tests first, asking AI for small changes or helpers rather than full subsystems, and running linters, type checks, and security scans on save or as pre-commit hooks. Require a short AI rationale in PRs, insist on human review, merge behind feature flags or canaries with alerts, and review post-release metrics to detect regressions early. Q: When should I reject AI-generated code instead of accepting it? A: Reject the output if you cannot explain the change simply to a teammate, if it expands scope beyond the spec or touches auth/crypto without expert review, or if it adds a new dependency without a clear need or security review. Also reject code that passes unit tests but fails property or fuzz checks, or whose documentation and comments do not match actual behavior.