Skip to content
The 31 guidesFREN中文
Guides
Part 5 · guide 4 of 5 Level: Intermediate Reading time: 13 min

Review, audit, secure

The agent writes fast, your job becomes checking its work. Best practices for reviewing a diff, auditing quality, and putting security through the wringer, with Claude Code, Codex, OpenCode or any agent.

In this guide
  1. 011. Systematic diff review
  2. 022. The quality audit
  3. 033. The security audit
  4. 04Make it a routine
  5. 05Frequently asked questions
Ulrich Rozier Co-founder of Frandroid, at Humanoid · ulrichrozier.com Author profile, Ulrich Rozier (new tab)
Created Checked

In short

With a code agent, your job becomes checking: review every diff before accepting it, run a regular quality audit and a security audit before each release. Claude Code ships /code-review (alias /review) to hunt bugs in the diff, /simplify for code quality and /security-review for vulnerabilities; Codex has /review in the session and codex review on the command line; with OpenCode, you turn these into reusable commands. Have the code reviewed by a different model from the one that wrote it, and keep a human review on authentication, payments and personal data.

Do this first: Skills: automating your workflows

An agent produces code at a dizzying speed. That’s its strength, and it’s precisely what shifts your role. You’re no longer the one typing every line; you’re the one who checks. And code generated fast, abundantly, and confidently deserves exactly the same care in review as code written by hand. Maybe more, because the agent never doubts itself.

Good news: the agent is also an excellent verification tool. You turn it against its own work. Here are the three passes to make a reflex.

1. Systematic diff review

The golden rule, already met everywhere on this site: you read the diff before accepting it. git diff shows you exactly what changed. You only approve what you understand; for the rest, you ask “why this choice?”

But you can also hand the first pass to a dedicated agent, a reviewer that hunts down what a tired eye lets slip through:

Claude Code ships diff review out of the box. /code-review (or its alias /review) reads the current changes and looks for bugs:

/code-review              # reviews the current diff
/code-review high         # deeper, longer review
/code-review --fix        # then applies the fixes it found

You can also pass it a pull request number or a branch. Or ask for it in plain language: “review the current diff against the base branch, list bugs and regressions by file:line, don’t fix anything without my approval.”

2. The quality audit

Beyond bugs, there’s the health of the code: is it readable, maintainable, tested? Ask for a regular quality audit, the agent is very good at spotting what’s slowly rotting:

  • Duplication and dead code: copy-paste to factor out, functions that no longer serve a purpose.
  • Complexity: sprawling functions, unreadable nesting, anything that would benefit from being broken up.
  • Naming and consistency: misleading names, conventions going in every direction.
  • Test coverage: what isn’t tested and should be.

In Claude Code, /simplify does part of this work out of the box: it reviews the changes for reuse, simplification and efficiency, then applies the fixes. It doesn’t look for bugs; that’s /code-review’s job. Codex and OpenCode have no ready-made quality-audit command: give them the list above as an instruction, for example codex exec "Quality audit of the repo: duplication, dead code, complexity, naming, missing tests. Change nothing." (in non-interactive mode, Codex stays read-only by default), or turn it into a skill.

3. The security audit

This is the pass that gets skipped too often, and the one that hurts most when you neglect it, especially on a machine reachable from the outside. Before putting anything online, explicitly ask for a security review:

0 of 3 steps done Your ticks stay in this browser.

  1. Run a targeted audit

    In Claude Code, /security-review analyzes the changes on your branch against the remote’s default branch (it needs an origin remote) and flags injections, authentication issues and data exposure. On OpenAI’s side, Codex Security runs security scans of the repository (npx @openai/codex-security scan .), but it requires Codex Security access on top of the ChatGPT account. With any agent, the plain-language instruction works too:

    “Do a security review of this code. Look for: injections (SQL, commands), secrets in plain text, vulnerable dependencies, unvalidated inputs, overly broad permissions, and anything exposed without authentication. Rank by severity.”

  2. Check the sensitive spots by hand

    The agent’s audit does the rough work, but cross-check what matters yourself: no secret in the code (see Securing access), user inputs escaped, and nothing publicly exposed that shouldn’t be.

  3. Watch the dependencies

    Half the vulnerabilities come from third-party libraries. Ask the agent to check the versions and flag known vulnerabilities, and keep your dependencies up to date.

Make it a routine

The secret is that these three passes cost you almost nothing if you automate them. Start with the commands that ship with your agent (/code-review, /simplify, /security-review in Claude Code, /review and codex review in Codex). For what they don’t cover, your own criteria, your stack, your recurring traps, write your own skills (an /audit done your way), and make them systematic steps before every deployment.

Frequently asked questions

Can you trust code written by an AI agent without reviewing it?

No. Code generated quickly, in volume and with confidence deserves the same care in review as code written by hand, maybe more, because the agent never doubts itself. Without review, you multiply your output and your bugs at the same speed. Read the diff before accepting it and only approve what you understand; for the rest, ask the agent why it made that choice.

Does an all-green test suite prove the agent's code works?

Not necessarily. An agent can write tests that check nothing real, just to clear the bar. Read a few of them and ask whether they validate the right behaviour or merely exist. A test that can never fail protects you from nothing.

What should a code quality audit look at?

Four kinds of problems: duplication and dead code, complexity (sprawling functions, unreadable nesting), naming and consistency of conventions, and test coverage. An agent is very good at spotting what is slowly rotting. Run this audit regularly, or as soon as a module starts to feel stale.

What should a security review of the code look for?

Injections (SQL, commands), secrets in plain text, vulnerable dependencies, unvalidated input, overly broad permissions and anything exposed without authentication, ranked by severity. The agent's audit does the rough work, but cross-check the essentials yourself: no secrets in the code, user input escaped, nothing publicly exposed that shouldn't be. Since half of all vulnerabilities come from third-party libraries, also keep your dependencies up to date.

Do Codex and OpenCode have a quality audit command like /simplify in Claude Code?

No, neither ships a ready-made one. Give the agent the list of things to check as an instruction (duplication, dead code, complexity, naming, missing tests) and ask it to change nothing, or turn it into a reusable skill. In non-interactive mode, Codex stays read-only by default, which suits an audit well.

Terms in this guide: AgentClaude CodeCodexOpenCode

Spotted a mistake?

A command stopped working, a price changed?

Tools change every month. Tell me what is wrong in this chapter and I will fix it and update its date.

Only the page, your message and the optional contact are kept. Nothing else.

Read next

Maintain and updateSecuring access
Guide 30 of 31 · part 5 no guides read yet Open the list of guides