My 6-steps Verification Workflow for AI Coding Agents

---

The Problem Everyone Ignores

Here's what nobody tells you about AI-native development: The real bottleneck isn't writing code—it's verifying that the code doesn't break everything else.

Sure, everyone runs unit tests. That's the baseline. But after months of watching AI agents work at MadKudu, I realized there's a whole verification workflow that most people completely miss. And the cost of missing it? Technical debt that accumulates faster than your AI can ship features.

The thing is, AI agents are incredibly good at fixing issues when they have the right context in the moment. But ask them to clean up dozens or hundreds of files after the fact? That's when things fall apart.

My PNPM Check Script: The 6-Step Verification Workflow

Let me walk you through the exact workflow I use after every single AI coding session. It's baked into a script I call pnpm check, and it's saved me countless hours of debugging.

Step 1: Format Everything

First up: automatic code formatting with Prettier.

Why? Because your AI agent doesn't inherently know your style guide. It might write code that works but looks like it came from five different developers who've never met.

Running Prettier ensures everything is uniform. Consistent formatting means:

• Cleaner diffs in code reviews
• Easier pattern recognition for AI in future sessions
• One less thing to argue about in PRs

Simple command:

prettier --write .

Done. Moving on.

Step 2: Lint With Auto-Fix

This is where things get interesting. I don't just run ESLint—I run it with the --fix flag:

eslint . --fix

This single flag saves me an absurd amount of tokens and iterations.

Here's why: ESLint can automatically fix tons of issues—missing semicolons, incorrect import order, spacing problems, etc. Why waste AI cycles (and your money) having the agent fix things that can be fixed automatically?

After auto-fix runs, only the real errors remain—the ones that actually require thinking to solve.

Pro Tip: Never Let Agents Disable Linting Rules

I've learned this the hard way. Put this in your coding guidelines and treat it as gospel:

NEVER disable ESLint rules to make the error go away.

Why? Because lazy agents (and let's be honest, lazy developers) will take the easiest route. Instead of fixing the actual problem, they'll slap an // eslint-disable-next-line comment on it and move on.

Don't let them. Force the fix.

Step 3: Type Check Everything

Next up: compile the code with TypeScript.

tsc --noEmit

At this stage, I know:

• Tests are passing
• Code is formatted correctly
• No linting errors remain
• Everything compiles without type errors

This is critical. Type errors are like small cracks in a foundation—ignore them now, and they'll become structural problems later.

Remember what I said in my AI-native principles article? Typing is non-negotiable. This step is where that principle pays dividends. The more precise the error messages, the faster your AI can fix issues.

Just last week, this workflow caught 23 type errors in a single session where our agent was refactoring our authentication flow. Every single one would have been a runtime bug in production. Instead, they were fixed in minutes while the context was fresh.

Step 4: Run Your Tests

Obviously, run your test suite:

pnpm test

But here's the key: this happens AFTER formatting, linting, and type checking.

Why? Because if your code doesn't even compile, why waste time running tests? Fix the foundational issues first, then verify behavior.

Plus, if you've followed my advice about high test coverage (another principle from the AI-native playbook), your tests will catch the subtle bugs that type checking misses.

Step 5: Check for Outdated Dependencies

Here's the step most people forget: scan for outdated dependencies.

pnpm outdated

This one's sneaky. Your AI agent just shipped a beautiful feature, everything works perfectly... but you're running on packages that are three major versions behind.

Why does this matter in an AI-native workflow?

Because outdated dependencies are technical debt with an expiration date. The longer you wait, the harder the upgrade becomes. And when you finally have to upgrade (security vulnerability, anyone?), you're looking at a massive refactoring session where your AI agent has to wade through breaking changes across dozens of files.

Catching outdated dependencies early means smaller, manageable updates instead of catastrophic migrations.

I've seen teams ignore this until they're stuck on a Node version that's out of support, or a framework version that no longer gets security patches. Then what should've been a 30-minute update becomes a week-long nightmare.

The beauty of checking this regularly? You can update dependencies incrementally, one or two at a time, while your AI agent still has context about the current codebase structure. Much better than batching 47 dependency updates and praying nothing breaks.

Step 6: The 400-Line File Limit

Okay, here's the bonus step that almost nobody does, but it completely transformed how our AI agents work:

I wrote a tiny script that scans my entire codebase and flags any file over 400 lines.

In my setup:

• Warning at 400 lines
• Error at 500 lines

Why This Matters More Than You Think

Big files are the enemy of AI-native development. I learned this when our agent kept making the same mistakes in a 800-line component file. It would fix one part and break another because it couldn't hold the entire file context effectively.

Here's why file size matters so much:

1. Bigger files = bigger context windows = slower model responses = higher costs
2. Large files make code editing harder = more mistakes = more iterations
3. Bloated files mean poor separation of concerns = AI gets confused about what goes where
4. Semantic search performs worse = AI can't find the right context as easily

By enforcing this limit, I force the agent (and myself) to:

• Break code into smaller, well-organized modules
• Create proper component hierarchies
• Maintain clean separation of concerns
• Keep the codebase navigable

And yes, I know what you're thinking: "But I already told the AI to keep files small in my rules!"

Suggestions don't work. Enforcement does.

When the build breaks because a file is too long, the agent has to fix it. It's not optional. It's not a "nice to have." It's a hard requirement.

The Script

Here's a simple version of what this looks like:

// check-file-sizes.js
const fs = require('fs');
const path = require('path');
const glob = require('glob');

const WARNING_THRESHOLD = 400;
const ERROR_THRESHOLD = 500;

function checkFileSize(filePath) {
  const content = fs.readFileSync(filePath, 'utf-8');
  const lines = content.split('\n').length;
  
  if (lines > ERROR_THRESHOLD) {
    console.error(`❌ ERROR: ${filePath} has ${lines} lines (max: ${ERROR_THRESHOLD})`);
    return 'error';
  } else if (lines > WARNING_THRESHOLD) {
    console.warn(`⚠️  WARNING: ${filePath} has ${lines} lines (recommended max: ${WARNING_THRESHOLD})`);
    return 'warning';
  }
  
  return 'ok';
}

// Scan your source files
const files = glob.sync('src/**/*.{ts,tsx,js,jsx}');
let hasErrors = false;

files.forEach(file => {
  const result = checkFileSize(file);
  if (result === 'error') hasErrors = true;
});

if (hasErrors) {
  process.exit(1);
}

Add this to your pnpm check script, and watch your codebase stay lean and maintainable.

Why This Workflow is Non-Negotiable

Remember: AI agents are brilliant at fixing problems in the moment, but terrible at cleaning up messes after the fact.

If you let issues accumulate—formatting inconsistencies, linting errors, type issues, bloated files—you'll hit a point where even the best AI can't untangle the mess. You'll spend more time fighting your codebase than building features.

But when you run this verification workflow after every coding session, you catch problems immediately, while the context is fresh and the fixes are straightforward.

When You Might Skip Steps (But Probably Shouldn't)

Look, I get it. Sometimes you're in a rush. An emergency hotfix, a quick prototype, a proof-of-concept that'll never see production. In these rare cases, you might be tempted to skip the full workflow.

Here's my take: Skip at your own risk.

Even for "throwaway" code, I've seen too many prototypes become production systems. That quick hack becomes the foundation everyone builds on. And if you skipped the verification workflow, you've just baked technical debt into your foundation.

The only time I truly skip steps is for isolated experiments in a separate branch that I know will be deleted. Everything else gets the full treatment.

The Bottom Line

In AI-native development, verification isn't a nice-to-have—it's the foundation that lets you move fast without breaking things.

Without this workflow, you're trading short-term speed for long-term chaos. Your agent ships features fast, but each one leaves behind a trail of issues that compound over time.

With it? You get sustained velocity. You ship features confidently, knowing that the fundamentals are solid, and you're not creating tomorrow's problems today.

Here's my challenge: Implement this 6-step verification workflow in your next AI coding session. I guarantee you'll catch issues you didn't even know were there.

And if you think 400 lines is too strict? Try it for a week. I dare you. You might find that smaller files make everything—AI performance, code reviews, debugging—dramatically easier.

The future of development isn't just about letting AI write code. It's about building systems that keep that code clean, maintainable, and scalable.

Disclaimer: The views and opinions expressed in this article are my own and do not necessarily reflect the official policy or position of my employer. Any content provided is not intended to malign any organization, company, or individual.