AI-Native View as Markdown

Nest conventions make agent-written code reviewable

The framework's opinionated structure turns out to be exactly what makes generated back-end code fast to review. Here is how to lean on it.

Frameworks that impose structure were unfashionable for a decade. They are worth another look now, for a reason that did not exist then: when a machine writes the code, the value of everything having an obvious place goes up sharply.

A generated Express application can put a database query anywhere. A generated Nest application puts it in a service, injected into a controller, registered in a module — because that is the only shape the framework accepts. So reviewing it is a matter of checking a small number of known locations rather than reading everything.

What the structure buys you#

The CLI generates the skeleton. nest g resource orders produces module, controller, service, DTOs and a spec file, wired together. Ask an agent to use it rather than to write the files freehand, and every feature in your codebase looks the same.

Dependency injection makes tests trivial to write. Which means an agent can actually produce useful tests, which means the loop closes.

Decorators put the contract next to the code. @Roles(Role.Admin), @IsEmail(), @HttpCode(201) are all greppable, and their absence is greppable too. That is a reviewable property.

Global pipes, guards and filters are declared in one place. Security posture lives in main.ts and app.module.ts rather than being distributed across every route.

The AGENTS.md that goes with it#

The instructions file is where you turn those properties into rules the agent follows every session — commands, the structure contract, and above all the security configuration Nest will happily let you get wrong.

That file has a page of its own, with the full template: Writing an AGENTS.md for NestJS.

The two lines in it that matter most, if you read nothing else:

- JwtAuthGuard is global via APP_GUARD. Opt out with @Public(), never opt in.
- ValidationPipe: { whitelist: true, forbidNonWhitelisted: true, transform: true }.

The first fails closed; the per-route alternative fails open. The second is what stands between you and mass assignment.

The review checks worth automating#

# a controller that talks to the database directly
grep -rn "PrismaService\|Repository<" src --include="*.controller.ts"

# ValidationPipe without whitelist
grep -rn "new ValidationPipe" src | grep -v whitelist

# routes with no auth decorator in a module that should have them
grep -rn "@Public()" src

# spreading a DTO straight into an update — mass assignment
grep -rn "data: { \.\.\." src

# entities with a secret field and no @Exclude
grep -rln "passwordHash\|refreshToken" src | xargs grep -L "@Exclude"

Five greps, and they cover the failure modes that actually cause incidents in Nest codebases. Put them in a pnpm check:security script and run it in CI.

Where generated Nest goes wrong#

• Logic creeping into controllers. The most common structural drift. Catch it with the grep above and with a line in review.
• @UseGuards() per route instead of a global guard. Fails open.
• ValidationPipe with no options. Mass assignment.
• Request-scoped providers used casually, which quietly makes the whole injection chain request-scoped.
• Missing @Type() on nested DTOs, so nested validation silently does nothing.
• forwardRef sprinkled around instead of extracting the shared concept.

Common questions#

Is Nest overkill for a small API?#

For something with three endpoints, yes — Fastify or Hono will be simpler and faster to start. Nest earns its structure at the point where several people (or several agent sessions) are changing the same codebase and consistency starts to matter more than brevity.

Does the CLI matter that much?#

More than it used to. nest g resource produces a consistent skeleton every time, which means every feature is shaped identically, which means your review is pattern-matching rather than reading. Ask the agent to use it.

Do decorators confuse language models?#

Not noticeably — there is a lot of Nest and Angular in the training data and the patterns are highly regular. The regularity is the point: generated Nest tends to look like existing Nest, which is exactly the property you want.