Артыкул апублікаваны на англійскай мове.
Seven Open-Source Tools to Audit AI-Generated Code Before Production
Seven GitHub projects, from mutation testing to load tests, that check test quality, leaked secrets, dependencies, accessibility and speed of AI-built apps.
Your coding assistant reports that the work is finished, the tests are green and the app is running in the preview. It feels like the end of the job. It usually isn't.
A green test run only proves that the tests passed. Whether those tests would fail on a broken implementation is a separate question. So are a few others: did a credential slip into a commit, are the packages you pulled in free of known holes, and what happens when fifty people open the app at once? An assistant rarely volunteers answers to these.
Seven open-source tools cover those gaps, each looking at a different angle: test strength, leaked secrets, vulnerable dependencies, code patterns, dead code, accessibility and load. Several target JavaScript and TypeScript, so they fit AI-built web apps especially well. Run them before anything reaches production.
StrykerJS: do your tests actually bite?
StrykerJS is a mutation testing framework for JavaScript and TypeScript. It makes small deliberate changes to your source, such as flipping a comparison or deleting a statement, and reruns the suite each time. If every test still passes after the change, that test suite has a blind spot. Coverage percentages can't show this, because a line can be executed without ever being checked.
For a small project, you can try it straight away:
pnpm add --save-dev @stryker-mutator/core
# Only for small projects:
npx stryker run
With no config, it falls back to sensible defaults. It runs npm test as the test command and looks for code to mutate under lib and src.
Gitleaks: catch secrets early
Gitleaks scans files and Git history for credentials like API keys and tokens. You can run it by hand or wire it into an automated pipeline, which stops a leaked key before it spreads across clones and forks. Generated code is a common source of this problem, since a model happily pastes a placeholder key that turns out to be a real one.
To fetch and compile it:
git clone https://github.com/gitleaks/gitleaks.git
cd gitleaks
make build
OSV-Scanner: know what you depend on
OSV-Scanner compares the packages in your lockfiles with the OSV vulnerability database. It reports which of your exact versions have published advisories, giving you a concrete picture of the risk that dependencies bring in. Assistants often add libraries without a second thought, so this check pays for itself quickly.
You can build it with Go:
go install github.com/google/osv-scanner/v2/cmd/osv-scanner@latest
Semgrep: static analysis with rules
Semgrep is a fast open-source static analyzer. It matches patterns in code to find bugs, flag insecure constructs and enforce your team's conventions. It understands more than thirty languages and runs in an editor, as a pre-commit hook or inside a CI/CD job.
Installation goes through pip:
python3 -m pip install semgrep
Knip: delete what nobody uses
Knip finds files, dependencies and exports in JavaScript and TypeScript projects that nothing references. Generated code piles up leftovers quickly: abandoned helpers, packages added then never imported. Cleaning them out shrinks the maintenance burden and makes the repository easier to read as it grows.
axe-core: accessibility checks
axe-core is an accessibility testing engine for web pages and other HTML-based interfaces. It's quick and lightweight, and it plugs into whatever test setup you already have, so accessibility assertions can sit alongside ordinary functional ones. Assistants tend to produce markup that looks right but lacks labels, roles and contrast, and this is how you notice.
k6: how does it behave under load?
k6 is a load testing tool. You describe scenarios in code, measure response times and error rates, and set thresholds that fail a run automatically when performance slips. A small example:
import http from "k6/http";
import { check, sleep } from "k6";
// Test configuration
export const options = {
thresholds: {
// Assert that 99% of requests finish within 3000ms.
http_req_duration: ["p(99) < 3000"],
},
// Ramp the number of virtual users up and down
stages: [
{ duration: "30s", target: 15 },
{ duration: "1m", target: 15 },
{ duration: "20s", target: 0 },
],
};
// Simulated user behavior
export default function () {
let res = http.get("https://quickpizza.grafana.com");
// Validate response status
check(res, { "status was 200": (r) => r.status == 200 });
sleep(1);
}
The script simulates ten virtual users for thirty seconds, each pausing a second between requests. Its thresholds demand that the 95th percentile of response time stay under 500 ms and that fewer than 1% of requests fail.
Save the file as test.js, install k6, and start it with k6 run test.js.
Putting it together
None of these tools proves your app is correct, and none is meant to. Together they cover the questions a passing demo skips. Start with Gitleaks and OSV-Scanner, which take minutes and catch the costliest mistakes. Then add Stryker and Semgrep to check the code itself, Knip to prune it, axe-core for accessibility and k6 for traffic. If a different open-source tool belongs in your own checklist, add it. The goal is the same each time: trust the result only after something has tried to break it.