Sun, Jul 12, 2026NY 8:00 PM EDTLA 5:00 PM PDTLON 1:00 AM GMT+1PAR 2:00 AM GMT+2DXB 4:00 AM GMT+4SIN 8:00 AM GMT+8TOK 9:00 AM GMT+9SYD 10:00 AM GMT+10UTC 12:00 AM UTCPayment alerts updated guide pathsScam watch official links firstConsumer alertsSupport-scam watchMoney help deskHow-to guides
Strangely Useful

Payment problems, online safety, browser privacy, AI tools, and everyday tech choices.

Browse the site
Topic hubsFake support guideWrong Cash App paymentLatest storiesTopicsPayment helpSearch
All sections
Internet & CultureTech & AISecurity & TrustPractical TechnologyMoney & PaymentsBrowser & PrivacyAI ToolsSoftware & ServicesInternet Culture & Everyday WorkflowsHidden HistoryUseful ThingsEntertainmentQuizzesAboutHow we workHow guides are madeFollow by RSS
AI Tools - list

Treat AI-Written Code Like a Pull Request From a Stranger

Generated code can contain insecure defaults and invented packages. Review the diff before running it.

By Strangely Useful EditorsReviewed by the Strangely Useful AI Tools deskPublished July 12, 2026Updated July 13, 20262 sources2 min read
Quick answer

Check dependencies, permissions, secrets, network access, and tests before running AI-written code on your machine or production system.

AI-generated code passes through review checkpoints.
Generated code enters the normal review pipeline. Illustration by Strangely Useful.
In this story7 sectionsDefine intentCheck dangerous edgesVerify dependenciesRun it in a contained environmentTrace data through the changeKeep attribution and licensing visibleReview configuration alongside source

Never run or merge AI-generated code until a person reviews the exact diff, dependencies and commands. A plausible code block does not carry accountability.

Define intent

Write what the change should do and must not touch. Review small diffs; sprawling refactors can hide unrelated deletions.

Check dangerous edges

  • Authentication and authorization.
  • Input validation and injection.
  • Secrets and environment files.
  • Shell commands and network calls.
  • New packages and install scripts.
  • Logs that may expose data.

Verify dependencies

Confirm every package exists in the official registry and is the intended project. Models can invent believable names. Inspect lockfile changes before installing.

Test failure paths

Add tests for malformed input, missing permissions, timeouts and repeats. Run static analysis and the existing suite. A generated test repeating the implementation is not independent evidence.

Keep the branch protections used for any unfamiliar contributor. Speed matters only while the review surface remains understandable.

Run it in a contained environment

Use a disposable branch, test account, container or sandbox with no production secrets. Deny outbound network access unless the test requires it. A review can miss a command hidden in a build hook, so containment complements—not replaces—reading the code.

Trace data through the change

Identify every input, transformation, storage location and output. Check authorization at the server boundary rather than trusting a generated user interface. Confirm logs do not capture passwords, tokens or full uploaded documents.

Challenge the happy path

Try an empty value, oversized input, wrong account, expired token, duplicate request and interrupted network call. Check that retries do not create duplicate charges or records. Security failures often live where the sample prompt did not ask the model to look.

Keep attribution and licensing visible

Do not accept the model's assurance that code is original or license-safe. Review suspiciously distinctive blocks, package licenses and repository policy. Record AI assistance if the project's contribution rules require it.

Review configuration alongside source

Generated infrastructure files can expose a service publicly, weaken security headers or grant a wildcard permission even when the application code looks harmless. Include manifests, workflow files, database migrations and deployment settings in the diff. Run a dry deployment and inspect the planned resources before applying changes to a live account.

Have a second reviewer inspect high-impact changes without first reading the model's explanation. Independent review can catch assumptions that the generated summary made sound settled, especially around permissions, destructive migrations and fallback behavior.

Require a clean review before merge.

Sources used2 sources checked for this guide
  1. OWASP Top 10 for LLM ApplicationsOWASPreference - Retrieved Jul 12, 2026

    Used forOWASP identifies insecure output, supply-chain and excessive-agency risks.

  2. Secure by DesignCISAreference - Retrieved Jul 12, 2026

    Used forCISA promotes secure defaults.

Guide feedback

Was this guide useful?

No personal details are collected here. Use corrections for factual issues.