Rok Garbas

Consistency Helps AI More Than It Helps You

I’ve been using AI coding assistants daily for the past year. And I’ve noticed something: the quality of AI help varies wildly depending on the codebase.

Same tools. Same prompts. Completely different results.

The difference? Consistency. The codebases where I get the best AI assistance aren’t necessarily the most sophisticated. They’re the most predictable.

AI Models Thrive on Patterns

Here’s the thing about AI: it’s a pattern-matching machine. When your codebase follows consistent patterns, the AI can recognize them instantly. When every file does things differently, the AI has to figure out each context from scratch.

Think about it from the model’s perspective. It’s trying to predict what code should come next based on what it’s seen. If your codebase has five different ways to handle errors, three different naming conventions, and two competing folder structures—the AI has to spend its context window figuring out which pattern you’re using here.

Consistency isn’t just nice for humans. It’s a force multiplier for AI.

Mono Repos Give AI the Whole Picture

I’ve seen the difference firsthand. In a mono repo, the AI can see your shared utilities, your common patterns, your consistent conventions—all in one place. It understands that handleError in service A works the same as handleError in service B because it can actually see both.

In scattered repos? The AI is flying blind. It can only see what’s in front of it. It doesn’t know about your error handling convention in the other repo. It doesn’t know you already have a utility for that thing it’s about to reinvent.

This isn’t about mono repo vs multi-repo politics. It’s about context. AI assistance improves dramatically when the AI has access to the patterns you’ve already established.

My personal projects live in a single mono repo. Not because I read some blog post about mono repos. Because when I ask Claude to help me with something, it can see how I’ve solved similar problems elsewhere. It learns my conventions from my own code.

Naming Is Documentation

You’ve heard “code is documentation.” With AI, it’s even more true. And naming is the documentation that matters most.

When you name things consistently, you’re giving the AI a map. getUserById, getOrderById, getProductById—the AI sees the pattern. When you ask it to add getInvoiceById, it knows exactly what shape to use.

But when your codebase has getUserById, fetchOrder, retrieveProductData, and get_customer_info? The AI has to guess. Every. Single. Time.

I’m not talking about pedantic style guides. I’m talking about predictability. Whatever conventions you pick, apply them everywhere. The AI will thank you by actually being helpful.

File Structure as Navigation

Same principle applies to file structure. When the AI understands your project layout, it knows where to look and where to put things.

I use a consistent structure across projects in my repo:

project/
├── README.md       # what this project does
├── TODO.md         # what needs doing
├── mod.just        # common commands
├── src/            # source code
├── tests/          # test files
├── docs/           # documentation
└── ...             # project-specific files

When I ask the AI to add a new feature, it doesn’t guess where things go. It knows README explains the project, TODO tracks work, and mod.just has the commands. The patterns are predictable.

This isn’t about finding the “correct” structure. It’s about picking a structure and sticking to it.

Real Examples from My Setup

Let me give you concrete examples from my own workflow.

CLAUDE.md files. Every project in my repo has a CLAUDE.md that explains project-specific context. When I open a project, the AI immediately knows how this particular thing works. Conventions, commands, architecture—all documented in a consistent place.

Just commands. I use just as my command runner everywhere. Every project has just <project> to see available commands. The AI knows this. When it suggests running something, it suggests the right just command. No confusion about whether this project uses make, npm scripts, or bare bash.

Consistent config. YAML files use double quotes for strings. Nix files follow nixfmt-rfc-style. Markdown follows the same conventions. The AI learned these patterns once, and now it applies them everywhere.

The first time I noticed this was when I asked Claude to add a new feature to one project and it automatically matched the exact style of my other projects. Not because I told it to—because it could see the patterns.

Pre-commit Hooks: Give AI a Verification Loop

Here’s something I didn’t expect: AI assistants love having a way to check their work.

I run pre-commit hooks on everything. Formatters, linters, commit message validation—the works. And it turns out this isn’t just good hygiene. It gives the AI a feedback loop.

When Claude writes code for me and I run just pre-commit, one of two things happens:

  1. Everything passes. The AI matched my conventions. We move on.
  2. Something fails. The AI sees the error, understands what went wrong, and fixes it.

That second case is where the magic happens. The AI doesn’t just blindly generate code and hope for the best. It can verify its own work against your actual standards. When the linter complains about formatting, the AI reformats. When the commit message validator rejects “fixed stuff,” the AI writes a proper conventional commit.

My pre-commit setup catches:

  • nixfmt-rfc-style for Nix files
  • prettier for JSON
  • markdownlint for documentation
  • yamllint for YAML configs
  • convco for conventional commit messages

The AI learns from every failure. After a few rounds, it rarely triggers the same hook twice. It’s internalized my project’s rules—not because I explained them, but because the hooks enforced them.

This is the difference between “please follow my conventions” (which the AI might ignore) and “here’s a command that will tell you if you got it wrong” (which the AI can actually use).

Not everything can be linted, of course. Business logic, architecture decisions, whether this abstraction actually makes sense—no hook catches those. But the more guardrails you add, the more the AI can self-correct on the things that can be automated. Every linter you add is one less thing you need to review manually.

Set up pre-commit hooks. Document how to run them. The AI will use them to self-correct—and your codebase stays consistent even when you’re not paying attention.

The Compound Effect

Here’s what surprised me: consistency compounds.

The more consistent your codebase, the better the AI understands it. The better the AI understands it, the more consistent its suggestions become. The more consistent its suggestions, the less cleanup you need.

It’s a virtuous cycle. The investment in consistency pays dividends every single time you ask the AI for help.

And the opposite is also true. Inconsistent codebases stay inconsistent because the AI has no clear pattern to follow. It picks a random approach each time. You either fix it manually or accept the chaos. The codebase drifts further from any consistent pattern.

Start Now

You don’t need to refactor your entire codebase. Start with conventions for new code:

  1. Pick naming conventions and document them. Doesn’t matter what you pick. Matters that you pick something and write it down.

  2. Create a CLAUDE.md (or similar) in each project. Tell the AI how this project works. What commands to run. What patterns to follow.

  3. Use the same structure across projects. README, TODO, commands—put them in the same place every time.

  4. Set up pre-commit hooks. Give the AI a way to verify its work. Formatters, linters, validators—whatever enforces your standards. Document how to run them.

  5. Run formatters automatically. Let tools enforce consistency so you don’t have to remember.

The AI will adapt to whatever patterns you establish. Your job is to establish them clearly—and give it tools to check its own work.

It’s Not About the AI

Here’s the twist: everything I just described is good engineering practice anyway.

Consistent naming? Makes code readable. Predictable structure? Helps new developers navigate. Documented conventions? Saves everyone time.

I’ll admit something: I’ve always gravitated toward codebases with clear conventions. Not because I enjoy enforcing rules—because consistency lets me focus on the actual problem. When I don’t have to figure out “how do we do X here?” from scratch every time, I can spend that mental energy on the thing I’m actually trying to build.

Turns out AI works the same way.

Consistency frees up cognitive load—for humans and for AI. When patterns are predictable, neither of us wastes cycles figuring out the basics. We get straight to the interesting part.

Wait. Am I an AI?

Maybe I’ve just been a pattern-matching machine this whole time, and now I finally have a coworker who gets it.

We’ve known this for decades. The difference now is that consistency has a new beneficiary. Your AI pair programmer rewards good engineering hygiene with dramatically better assistance.

You were supposed to do this stuff anyway. Now you have another reason. And I have receipts.

I’ve been writing code for 20 years and using AI tools daily for the past year. The combination of consistent conventions and AI assistance has changed how I work. Let’s connect if you’re exploring this too.