DEV Community: Marlon M

AI Agents Can Ship Code Faster Than You Can Review It. Here's What Stops Them.

Marlon M — Wed, 18 Mar 2026 09:58:13 +0000

Most teams running AI agents have no enforcement at the git layer. Here's what's quietly building in your repo — and the two-line defence that stops it.

An AI agent just wrote and committed 47 files. Did you review all of them?

Probably not.

Nobody does. That's the point — agents move faster than review. And if nothing is enforcing standards at the git layer, bad code reaches the repo at the same speed the agent writes it.

This is the problem quality gates were built for. It used to be a slow, human-speed problem. Now it's urgent.

The Migration That Broke Everything (And What Actually Saved It)

Three years ago I was maintaining a white-label registry platform — a government web app powering multiple clients. We had to migrate from Vue 2 to Vue 3. Vue 3 changed almost everything: the reactivity system, the component model, the entire ecosystem. Some of that pain was inevitable. But the wall we hit in the first hour? That was ours.

The terminal had thousands of errors. Some components were in TypeScript. Some weren't. Some had proper props with default values. Others had been copy-pasted years ago and never revisited. Slot handling had changed between Vue 2 and Vue 3 — a component would render in isolation, pass unit tests, and then silently break in a parent layout. Every broken slot had to be found by hand, by loading the full app, by navigating to the right screen.

The framework changed. But the real damage was the absence of guardrails — no enforced patterns, no consistent structure, nothing that would have caught the drift commit by commit before it compounded into a wall.

That was the human-speed version. Years of unchecked inconsistency, made visible all at once by a forced migration.

Now Imagine an Agent Doing That Every Five Minutes

Now imagine the same thing — but an agent is committing code every five minutes.

No guardrails means the agent generates code in whatever pattern it infers from context. Some files use TypeScript strictly. Others don't. Some follow your component conventions. Others are plausible-looking code that passes a basic check but violates three rules you defined in your style guide six months ago. The agent doesn't know. It wasn't told. And nothing is stopping it.

By the time a human reviews it, the inconsistency is already in the repo. Multiplied across 47 files. And now it's part of your baseline.

This isn't a hypothetical risk — it's already the default of agentic workflows without enforcement. The agent is fast. Capable. And completely indifferent to your project's conventions unless those conventions are defined, fed to the agent, and enforced at the git layer.

Quality gates are that enforcement. When a human pushes, they've at least read the code. When an agent pushes, the gate is the review.

Some teams argue that agents are still "junior devs" and humans are still in control. I think that's already outdated.

Two Lines of Defence

Whether the code comes from a human or an agent, you need the same two layers:

Developer or Agent
        ↓
Line 1: Quality Gates  (pre-push, before code hits the repo)
  → linter (ESLint, ruff, clippy...)
  → formatter (Prettier, black...)
  → type checker (tsc, mypy...)
  → unit tests (jest, pytest, cargo test...)
        ↓
Repository → CI Pipeline
        ↓
Line 2: Integration / UI Tests  (before code hits production)
        ↓
Production

Line 1 is a pre-push git hook that detects your stack automatically and runs all four checks in sequence — linting, formatting, type checking, and unit tests — but only the tools your project actually has installed. If anything fails, the push is blocked:

❌ Quality Gates FAILED — push blocked.

No Husky, no package manager, no Node.js dependency. Works in any git repo regardless of language. One line sets it up for the whole team: git config core.hooksPath .contextkit/hooks. See the full stack support in the docs.

Line 2 catches what line 1 structurally can't — things that only appear at runtime: broken user flows, visual regressions, components that pass unit tests in isolation but fail in a real browser context. Tools like Cypress and Playwright handle this.

The key insight: because unit tests already ran at line 1, your integration suite can focus purely on critical user paths rather than trying to cover everything. An hour-long test suite is expensive. The more you invest in unit coverage at line 1 — fast, cheap, build-time feedback — the leaner and more focused line 2 can be.

Line 1 stops bad code at the gate. Line 2 stops broken behaviour from reaching users.

What You Need Before the Gates Can Work

Most teams already have standards. They're in Confluence, a Notion doc, a wiki somewhere. Someone wrote them. Someone approved them. And then a deadline hit, and the push went out anyway — because nothing mechanically stopped it.

That's the real problem. Not that standards don't exist. It's that documentation you have to remember to follow isn't a guardrail. It's a suggestion. And suggestions don't scale with agents.

What gates actually enforce are standards that live close to the code — version-controlled, readable by your AI tools, and checked on every push:

.contextkit/standards/
├── glossary.md        ← project terminology
├── code-style.md      ← coding conventions
├── testing.md         ← test patterns
├── architecture.md    ← decisions and constraints
└── ai-guidelines.md   ← rules for AI-generated code

This is the loop: standards define what correct looks like. Gates enforce it. Agents read the standards and write to them. Without the standards, the agent guesses. Without the gates, the guesses reach the repo unchecked. And the Confluence doc nobody checked before pushing? It doesn't help either.

This is exactly what I didn't have three years ago. The standards existed — loosely, informally, in people's heads and in docs nobody opened under pressure. If code-style.md had been enforced from day one, the inconsistency we found during the migration would have been caught year by year, push by push, instead of all at once.

I ended up building ContextKit to handle this — standards folder, git hooks, and bridge files for whatever AI tools your team uses. One install.

TL;DR

With agents writing code at scale, quality gates are no longer optional — they're the only automated review that scales with them. Letting agents push without enforced gates is the fastest way to degrade a codebase.

Line 1 — Quality Gates (pre-push)
Runs linter, formatter, type checker, and unit tests before code hits the repo.

Line 2 — Integration / UI Tests (CI)
Catches broken flows, runtime regressions, visual bugs before code hits production.

Strong unit coverage at line 1 reduces the cost and surface area of line 2.

The real question isn't whether you trust your agent. It's whether your repo does.

I'm curious how teams are actually handling this right now:

Are you letting agents commit directly to your repo?
Or is every change still gated by human review?
If you have gates — what are you actually enforcing?

I have a strong opinion — but I'm genuinely curious what teams are doing right now.

npm i -g @nolrm/contextkit && cd your-project && ck install

Written by Marlon Maniti. I build tools for AI-native development workflows. Follow for more on context engineering, squad pipelines, and shipping with AI at speed.

How I Get Claude to Think Like 5 Specialists (And Never Lose Context)

Marlon M — Wed, 04 Mar 2026 23:22:33 +0000

Start alone. Scale to a team. The context never dies.

You open a new session. You tell the AI to be your product manager. Then your architect. Then your developer, tester, and reviewer, all in the same conversation, all at once. And it tries. It really does. But it's juggling five jobs with no structure, and something always slips. An edge case the PO should have caught. A test that never got written. A review that missed the obvious thing.

This isn't an AI problem. It's a structure problem.

The Fix: Five Roles, Not Five People

contextkit is built around a simple idea: the best way to build something is to think about it in distinct roles, in sequence, with each role fully informed by the one before it.

Its Squad workflow gives you five specialized commands, each representing a role:

/squad: Product Owner
/squad-architect: Architect
/squad-dev: Developer
/squad-test: Tester
/squad-review: Reviewer

You don't need five people. One person can run all five. The discipline of switching roles is what forces you to catch things you'd miss if you just dove straight into code.

And everything flows through a single shared file: .contextkit/squad/handoff.md.

How It Works: One File Carries Everything

When you run /squad "add a user authentication flow", contextkit creates the handoff file and the Product Owner role writes into it: the user story, acceptance criteria, edge cases, and what's explicitly out of scope. That's the spec. It stays in the file forever.

Then /squad-architect reads that spec and writes its own section: the technical approach, which files to change, the trade-offs, the steps in order.

Then /squad-dev reads the architect's plan and implements. Every decision made along the way gets documented in the handoff.

Then /squad-test reads the acceptance criteria and the implementation. Writes and runs tests against both.

Then /squad-review reads everything and gives a PASS or NEEDS-WORK verdict with specific notes.

No role starts cold. No context is lost. Each role inherits everything the previous one knew.

Why This Makes You Better Solo

When you wear all five hats in a single AI session, you tend to skip the uncomfortable parts. The architect in you gets impatient and jumps to code. The developer in you doesn't want to write tests. The reviewer in you is too close to the work to see the gaps.

Squad forces you to slow down at each stage, think from one perspective at a time, and document what you found before moving on. The result is work that's more complete, more reasoned, and easier to revisit.

The handoff file becomes your own second brain for the task. When you come back tomorrow, or next week, you don't re-read the codebase. You open the file and know exactly where things stand.

Use the Right Model for Each Role

Not every role needs the same horsepower. A reviewer reading a complex spec might warrant your most capable model. A developer grinding through implementation steps can run on something faster and cheaper.

Squad's config.md lets you configure this:

# .contextkit/squad/config.md
checkpoint: po
model_routing: true

With model_routing: true, /squad-auto automatically routes Dev and Test phases to Claude Haiku, saving roughly 35% on tokens, while keeping Architect and Review on your primary model. You get the right intelligence at each step without overpaying for it.

And When You Want to Bring Someone Else In

Here's where it gets powerful beyond solo work.

Because the handoff file is plain markdown, it's completely portable. Any developer, any AI tool, any teammate can open it and contribute to the next role.

You could run the PO spec yourself in Claude Code, then send the file to a senior engineer who does the architecture in Cursor. A junior dev picks up the implementation. QA runs the tests. Anyone does the review.

No re-prompting. No "let me explain the project." No "what did we decide about the database?" It's all in the file. It was always in the file.

The same structure that makes you better as a solo developer becomes the coordination layer for your entire team, with zero extra setup.

Run It Your Way

Run /squad "add user authentication" and then /squad-auto. The pipeline writes the spec, designs the architecture, implements the code, runs tests, and delivers a verdict. Hands-free.

/squad "add user authentication"   # PO writes the spec
/squad-auto                        # Architect → Dev → Test → Review, hands-free

Want to step through manually or run batch tasks across multiple features? The docs cover it.

When Something Doesn't Add Up

Real work isn't linear. Any role can raise a question for an upstream role. The pipeline pauses, you answer it, you re-run the command to continue. Nothing gets silently skipped. Every question and answer lives in the handoff file. The trace is complete.

The Real Shift

Most developers using AI work in isolated sessions: private, fragile, starting from scratch every time.

Squad makes your context durable and portable. It lives in a file that survives session resets, tool switches, and handoffs between people. Start alone, scale to a team. The file travels with the work.

One developer can think like five specialists. Five developers can work like one team.

That's the shift.

Get Started in 60 Seconds

1. Install the CLI

npm i -g @nolrm/contextkit

2. Set up your project

cd your-project
contextkit install

This creates a .contextkit/ folder with skeleton standards files. After setup, run /analyze in your AI tool: it scans your codebase and fills those files with your project's actual conventions: naming patterns, architecture decisions, tech stack specifics. From that point on, every AI session starts with full project context already loaded.

3. Start your first Squad task

/squad "your task here"

The handoff file is created. The PO spec is written. You're off.

npm: npmjs.com/package/@nolrm/contextkit
GitHub: github.com/nolrm/contextkit
Docs: contextkit-docs.vercel.app/docs/squad

Written by Marlon Maniti

I got tired of re-explaining my codebase to AI tools every session. contextkit is what I built to fix that. If you're using AI to ship software, this is for you.

Follow me for more on AI-native dev workflows. If this saved you from one lost-context session, hit the clap button.

⚡ Stop Explaining Your Project to AI - Let It Learn with Vibe Kit

Marlon M — Tue, 28 Oct 2025 02:36:19 +0000

You know that feeling when your AI assistant writes decent code… but completely ignores your style, naming, and structure? You spend five minutes explaining your setup before you even get a usable response. Yeah, that’s not productive.

So I built Vibe Kit, a CLI that helps your AI tools vibe with your codebase. No more essay-length prompts. Just smarter AI that already understands your project.

👉 Full docs and setup guide: vibe-kit-docs.vercel.app
📦 npm → @nolrm/vibe-kit

🧩 The Problem

AI tools like Cursor, Copilot, Claude, or Gemini are incredible at writing syntax. But they don’t know your architecture, naming patterns, or test style They hallucinate stuff. They mix tabs with spaces. They think your “checkout flow” is a PayPal button.

You end up rewriting half the code they generate. And that kills the flow.

💡 The Fix: Context Engineering

Instead of explaining your conventions every time you chat with an AI, teach it once, through structured markdown context. That’s what Vibe Kit does.

It sets up a .vibe-kit/ folder in your repo filled with markdown files that describe your project standards, architecture, and patterns. Every AI tool you use can read those files directly.

Each file becomes part of your project’s knowledge base. The next time your AI assistant runs, it already knows how your code should look and behave.

⏱️ Less Explaining, More Building

One of the biggest time-sinks in AI-assisted coding is repeating context.

Before you get the perfect output, you end up typing paragraphs like:

“We use strict TypeScript, React functional components, Jest for testing, and our checkout flow lives in /src/features/payments…”

With Vibe Kit, that context already lives in .vibe-kit/ markdown files.

The AI reads them automatically. So now, your prompts can be short and human:

“Add checkout flow for customer”
Boom. It already knows your stack, coding standards, and testing approach.

Less talking. More shipping.

🧠 Why It Matters

We’re moving past “prompt engineering.” The real unlock is context engineering. It’s not about crafting perfect prompts , it’s about giving your AI the right information before you even start typing. With .vibe-kit/, your team defines one shared source of truth:

Glossary → Project terms & language
Code Style → Patterns, naming, formatting
Testing → Rules for consistency
Architecture → Key design decisions
AI Guidelines → Dos and don’ts for your AI tools

Once defined, it’s reusable across projects, teams, and tools.

🤝 Works With All The Cool Tools

Cursor, VS Code (Copilot Chat), Codex CLI, Claude CLI, Aider, Continue.dev, Gemini CLI , Vibe Kit plays nicely with all of them.

Each integration adds its own setup without overwriting anything.

Every developer keeps their preferred AI, but shares the same project context.

💬 Why Developers Love It

🧠 Smarter AI — Generates code that fits your stack
🌍 Cross-platform — Works everywhere
⚡ Zero config — Auto-detects tools and package managers
🛡️ Safe install — Always keeps backups
🤝 Team-friendly — One context shared across all AI tools

🌐 Links

📦 npm → @nolrm/vibe-kit

💻 GitHub → github.com/nolrm/vibe-kit

📚 Docs → vibe-kit-docs.vercel.app

✍️ Made by a Dev, for Devs

Hey, I’m Marlon Maniti . I built Vibe Kit because I got tired of explaining my codebase to AI tools over and over.

Now, I just give them context once and they remember.

If you use AI to build, you’ll vibe with this.

⭐ Star it, share feedback, or open an issue, let’s make AI coding actually collaborative.