Your AI agent made 30 decisions today. You reviewed 3 of them.
One of those silent decisions added a framework library to fix a single line bug. Another built an entire job queue when you asked for an export button. A third tried to hand-roll authentication after failing to fix a login loop, which would have shipped undetected if nobody caught it.
This is what agentic delivery actually looks like. And most teams aren’t equipped for it.
The gap that’s opening up
The shift from “AI assists developers” to “developers steer AI agents” sounds like a small distinction. It’s not. It rewires everything downstream.
When developers stop writing code and start writing prompts, the entire SDLC changes. The coding stage gets faster, but it creates bottlenecks everywhere else. Verification becomes the new bottleneck, because there’s exponentially more code to review and the decisions inside it aren’t always obvious.
Research shows teams spend roughly a quarter of their time checking and fixing AI output. The job got harder, not easier.
And the real problem isn’t the obvious failures, the Claude that deletes a production database gets caught. It’s the silent ones. The scope creep. The overengineering. The frameworks shipped to solve single-line bugs. The features nobody asked for that made it to production because they “just work.”
This gap has a name: vibe code drift. It’s the widening distance between what you asked the agent to do and what actually got built. The developer gets farther from the code. The mental model erodes. The decisions become invisible.
What your job actually became

In the old model, developers wrote code. In the agentic model, developers decide and verify.
Your job is no longer to write. It’s to set clear intent, guide the agent toward it, and verify it delivered what you asked for, not what it thought you wanted.
Intent isn’t just specs. It’s architecture, ADRs, constraints, deferred work, tradeoffs, the reasoning behind decisions. It’s everything that makes the code defensible later.
The harness around the agent matters as much as the model itself. The harness is context discipline, prompt design, how you structure work, the skills you build. A research paper showed GPT-4 performed dramatically better at coding benchmarks just by adding a better harness, not by using a different model.
Yet most teams obsess over which model to use and barely invest in the harness.
One phrase changes everything
Here’s a concrete example from working with Claude: ask it to “pull a URL parameter and add it to HTML, keeping the code as short and lightweight as possible.”
You get a one-liner. It works. It also ships with an XSS vulnerability. The agent focused on the instruction about being short and ignored security.
Remove that one phrase about being short and ask again. Claude immediately catches the XSS vulnerability and writes secure code.
One instruction determined what the agent prioritized. One phrase was the difference between a security hole and secure code.
This is why wording matters. This is why instruction files matter. And this is why you can’t just dump context into prompts and hope for the best.
The discipline behind staying in control
Context is finite.
Keep it under 100,000 tokens. If you go above 50% of your model’s context window, performance degrades noticeably. Every token costs money, adds latency, and competes for the model’s attention. Curate ruthlessly.
Your CLAUDE.md file might be hurting you.
esearch found that agent instruction files make AI perform worse and increase token usage by 20%. The reason: teams add everything they can think of, bloating context with instructions the agent could infer from the code itself. Better approach: shorter files, living close to where the agent needs them, reviewed regularly.
Separate what machines can check from what humans must judge.
Linting, tests, security scanning, license checks—automate these. XSS vulnerabilities, architectural decisions, scope creep, silent assumptions—humans need to verify these. Teams spend a quarter of their time on verification because the volume is enormous. Protect human attention by automating what you can.
Get the plan before the code.
Ask your agent to tell you what it understood before it writes a single line. This is before any code exists. It’s cheap to fix direction wrong at the planning stage. It’s expensive to fix it in production.
Persist the decisions.
Store your specs, AI plans, the micro-decisions from conversations, agent task logs. Why? So anyone on the team—including future agents—can ask “why was this decision made?” and get a real answer. So decisions become auditable, traceable, defensible.
The silent failures that ship
Carpath identifies four failure modes that keep recurring:
Silent assumptions. The agent makes a choice and doesn’t tell you.
Overengineering. A small bug gets fixed with an entire framework library. It works. You don’t notice unless you look.
Stray edits. The agent changes things you didn’t ask it to change. A migration gets rewritten manually instead of using your migration framework because the agent couldn’t infer that migrations should use commands, not hand-edits.
Weak success criteria. You ask for “clean up the reporting module” and get a full job queue built because you didn’t specify what “clean up” means. The agent filled the gap.
The common thread: AI will fill gaps unless you’re explicit about intent and you verify constantly.
When everyone works in silos
Decisions used to happen in groups. Someone spotted an issue, the team discussed it, shared understanding emerged.
Now, decisions happen in chat between a developer and their agent. The conversation disappears. The code ships. Nobody knows what was actually decided.
This breaks collaboration. It loses context. It means the next person to touch that code has no idea why a framework was added or what constraints drove the decision.
The solution isn’t to ban agents. It’s to persist what matters: specs, plans, the reasoning behind decisions. Store them where the team can find them. Structure them so agents can reference them later.
When a human reviewer opens a PR, they should be able to ask an agent “why does this code exist? What was the constraint?” and get an answer. Not because the AI can read minds, but because the developer captured the decision when it was made.
Introducing Nissy: Closing the drift loop

Vibe code drift is the symptom. Nissy is the tool built to address it.
It’s a local-first assistant that runs alongside Claude Code, Cursor, and Copilot. It hooks into two moments: before you send a prompt to your agent, and after the agent delivers code.
Pre-check: catches if you’re about to send sensitive data (IP addresses, API keys, PII). Warns if your prompt is setting the agent up for failure. Flags if you’re missing verification criteria. All done locally, nothing leaves your machine.
Post-check: measures the delta between what you asked and what you got. Flags scope creep (“you asked for a button, you got a job queue”). Detects overengineering. Surfaces decisions the agent made silently.
Long-term view: generates reports on your prompting patterns, where you’re strong, where you’re weak, best practices you’re skipping, repetitive mistakes.
In the live demo, it caught a developer about to send a client IP address embedded in an error log to Claude. Blocked it before it left the machine. Caught an XSS vulnerability in a prompt before the agent even saw it. Flagged that an agent shipped a full HTML page when asked for a snippet. Flagged that an agent built a job queue when asked for an export button.
It’s not trying to replace judgment. It’s trying to give you back ownership of the code, not just visibility into it.
The professional standard
There’s a hard limit to how much you should be automating: the point where you can no longer take accountability for what ships.
If you can’t explain why a decision was made, if you don’t have evidence it was reviewed, if you can’t trace it back to intent, you’ve crossed the line. That’s where regulation comes in. That’s where you lose your insurance. That’s where you lose client trust.
Agentic delivery isn’t about going faster. It’s about building software you can defend.
That means clear intent. Disciplined context. Early verification. Persistent decisions. Team alignment. And tools that help you stay in control when the code is being written by something you can’t read the mind of.
What’s Next
Watch the full webinar to see the live demo, walk through concrete patterns, and see how this plays out across the entire SDLC – from requirements through design, through code, through reviews, through team collaboration.
Try Nissy early access to see what catching vibe code drift in real time feels like.
The future of software isn’t about who writes the code. It’s about who owns the decisions.