How to Keep AI-Generated Code Modular

Paul Salmon — Fri, 16 Jan 2026 09:34:50 +0000

Hi, my name is Paul, and I am a senior software engineer exclusively working for start-ups.

I treat programming languages like an all you can eat buffet, and no matter the language, the one thing I value is modularization. For this, our Openai and Claude assistants aren't very helpful. They are trained on a ton of old-school projects where everything's crammed into giant index.js files. Unsupervised vibe coding will often get you +1000 lines of code per file, and a lot of repetition.

Why is it a problem? Well, in start-ups, code is short lived and when vibe coding is used intensively, the AI will always find a way and the burden of refactoring will never be needed. But that is not quite true in reality. Things change quickly, and implementing new components or behavior must be quick and risk free. The AI is very bad at evaluating the impact of one change. If I add a field to this model, what consequences will it have over the whole system? Am I introducing a security risk? Am I breaking something? There come the need for unit tests, of course, but the bigger need, imho, is for modularization. Keep the code isolated, unaware of the exterior, specific to one usage per function, tested and in a single file, that behavior saved me a lot of troubles and a lot of refactoring. While it makes the development a little more verbose, a little more brain teaser, it does make it more robust, and a lot more fun.

And this is what this article is about: how to force your AI tools to generate modular code. For this we need to severely jail the models, prune all liberties and kill every bit of creativity. But I work at Vybe.build, and keeping AI on a short, well-designed leash is kind of our thing.

My Stack

For the sake of this article, I will use a stack I know very well and that I reach for almost every time I build a small SaaS or a "SaaS-replacement" project.

It's not exotic but it is extremely compatible with modular thinking and with AI-assisted development.

I am using:

Next.js with the App Router
TypeScript, everywhere
Vercel for deployment (serverless, zero friction)
Cursor as my AI-powered editor (the same ideas apply to Claude Code, Copilot, etc.)

This stack matters because it forces you to think in terms of boundaries: server vs client, routes vs logic, data vs UI. And boundaries are exactly what AI tends to ignore unless you make them impossible to cross.

You can find a starter project here.

A specific file organization

This is the structure I use:

./
├── app/                    # Next.js App Router pages and routes
├── src/
│   ├── __template__/      # Template used to generate new modules
│   │   ├── api/           # Server-side actions (DB writes, heavy logic, etc.)
│   │   ├── components/    # React components specific to the module
│   │   ├── hooks/         # React hooks
│   │   └── types/         # TypeScript types (shared client/server)
│   ├── auth/              # Authentication module
│   ├── db/                # Database module
│   └── ui/                # Shared UI library
│       ├── components/
│       ├── hooks/
│       └── globals.css
├── prisma/                # Database schema and migrations
└── public/                # Static assets

Each folder under src is a module. A module owns its logic, its hooks, its components, and its types. No reaching into other modules "just this once". If something is shared, it goes into ui or a dedicated shared module.

The template folder is important. It is the blueprint for every new module. When a new feature appears, I don't start by writing code, I start by generating a module from that template. This removes a huge amount of decision-making, both for me and for the AI.

I like the api / components / hooks / types split because it works well with Next.js dual environment. Server code and client code are clearly separated, and the AI has fewer excuses to mix everything together, but ultimately, what your modules are made of is up to you.

NextJS structure

One rule I am very strict about: the app/ directory contains only very specific logic:

Prop injections, server-side data fetching for pages
Access protection, authentication, return value for routes

Next.js has very strong opinions about routing and execution contexts, and that's fine. The app router defines pages and API routes. That's it.

Anything related to business logic, data access, transformations, or even slightly reusable behavior lives in src, inside a module.

Here is an example of a page:

import { getUsers } from '@/src/user/api';
import { User } from '@/src/user/types';

export default async function UserPage() {
  let users: User[] = [];
  let error: string | null = null;

  try {
    users = await getUsers();
  } catch (err) {
    error = err instanceof Error ? err.message : 'An error occurred';
  }

  if (error) {
    return (
      <div>Error: {error}</div>
    );
  }

  return (
    <UserPage users={users} />
  );
}

Fetching data and handling the route-level error belongs to Next.js. Everything else belongs to the user module.

Same idea for API routes:

import { NextResponse } from 'next/server';
import { getUsers } from '@/src/user/api/getUsers';
import { auth } from '@/src/auth';

export const GET = withAuth(async (request: Request) => {
  const session = await auth.api.getSession();
  if (!session) {
    return NextResponse.json(
      { error: "Unauthorized" },
      { status: 401 },
    );
  }

  const users = await getUsers();
  return NextResponse.json(users);
});

Authentication checks and HTTP concerns stay in the route. The actual logic lives in the module.

This separation is boring, repetitive, and extremely effective. It also gives the AI a very clear signal: routes glue things together, modules do the work.

Now with AI

Once this structure is in place, AI becomes both incredibly powerful and incredibly dangerous.

Left alone, it will always try to be helpful in the laziest possible way: it will code everything in the page, and you will end up doing multiple API calls for nothing, rewrite logic everywhere, etc.

The goal is simple: remove choices. If there is only one valid way to do things, the AI will eventually follow it.

Using EJS templates to generate modules

The first step is to make creating a new module trivial and mechanical.

I use a small script (Node + EJS) that generates a module from the template folder. From the outside, it looks like this:

> npm run create-module user

And it generates:

src/user/
├── api/
│   ├── getUser.ts
│   ├── getUsers.ts
│   ├── createUser.ts
│   └── updateUser.ts
├── components/
│   └── UserCard.tsx
├── hooks/
│   ├── useUser.ts
│   └── useUsers.ts
└── types/
    └── User.ts

Nothing magical here. The API files are thin, explicit functions. The hooks are small wrappers, usually around React Query. Components are dumb by default. Types are shared between server and client.

This does two things:

It removes friction for humans.
It gives the AI a very strong prior.
No giant service files.
No "utils.ts" dumping ground.

When I ask the AI to "add a user feature", it doesn't invent a structure. It follows the one that already exists. And if it doesn't, I regenerate or fix the module instead of letting entropy creep in.

Custom ESLint rules as guard rails

Templates handle the happy path. Linters handle the cheating.

A concrete example: API routes.

In Next.js, it is very easy to write this:

export const POST = async (req: Request) => {
  // do stuff
};

But in my apps, every route must go through a wrapper that injects context (session, user, permissions, etc.). Something like:

export const POST = withAuth(async ({ user, req }) => {
  // do stuff
});

So I add a custom ESLint rule that enforces this. If a route exports POST, GET, PUT, whatever, and it is not wrapped correctly, linting fails.

What is interesting is how AI reacts to this.

When the AI generates a route and forgets the wrapper, the linter error shows up immediately. The AI sees the error, understands the pattern, and fixes the code by adding the missing wrapper. You didn't explain security again. You didn't argue. You let the toolchain do the teaching.

This works for many things:

Enforcing file boundaries
Preventing cross-module imports
Forcing naming conventions
Blocking "clever" shortcuts

Clear instructions

This seems obvious but it is good to bring up again. Whether you are using Cursor rules, Claude Code instructions, or a system prompt somewhere else, the idea is the same: write down your constraints early, and evolve them over time.

I don't try to be exhaustive. I start with a short list:

Where code is allowed to live
How modules are structured
What is forbidden (monolithic files, cross-imports, business logic in routes, etc.)

Every time the AI surprises me in a bad way, I don't fix it once. I add a rule.

Here is where I usually put a big instruction block explaining the module structure, the rules around app/, and how to extend existing modules instead of creating new patterns. I won't paste it here, but the exact content matters less than the habit: treat AI instructions like code. Version them. Improve them. Assume they will rot if you don't.

The result

Those tools have been around for a long time, and I mostly ignored them until recently. It’s only now, with AI doing a large part of the typing, that their impact on productivity really clicked for me.

I’m not advocating for modular code, or vibe coding either. You should do whatever works for you. I’m just sharing what I’ve been doing so far, and in my case, it works pretty well.

Hopefully it will give you some ideas.

Thanks for reading!

DEV Community: Paul Salmon