🚀 Vibe Coding — Issue #40
AI Agents Without Chaos: Delegate the Work, Keep the Control
AI Agents • Agentic Coding • Delegation • Guardrails • Code Review • Developer Workflow
Until recently, working with AI as a developer usually looked like this:
You ask a question.
AI answers.
You ask for code.
AI generates it.
You copy, test, modify, and continue.
But AI coding is moving into a very different phase.
Instead of simply suggesting what you should do, AI agents can increasingly perform multi-step work:
Understand the task
↓
Inspect the project
↓
Find relevant files
↓
Create a plan
↓
Modify code
↓
Run tests
↓
Find problems
↓
Make additional changes
↓
Report the resultThat’s enormously powerful.
It’s also where things can go wrong very quickly.
Because there’s a huge difference between:
“Suggest a change.”
and:
“Go make the change.”
Welcome to Vibe Coding — Issue #40, where we’re exploring how to delegate real development work to AI agents without surrendering control of the project.
🤖 What Makes an AI Agent Different?
A traditional AI coding interaction is mostly reactive.
YOU → REQUEST
AI → RESPONSE
YOU → DECIDE WHAT HAPPENS NEXTAn agentic workflow introduces something important:
Autonomy between decisions.
You give the agent an objective.
It may then perform multiple steps toward that objective without asking you what to do after every action.
Think:
GOAL
↓
PLAN
↓
ACT
↓
OBSERVE
↓
ADJUST
↓
ACT AGAIN
↓
VERIFYThat’s where agents become useful.
But it’s also where developers need a new skill:
Delegation.
🎯 Principle #1: Delegate Missions, Not Wishes
This is a weak agent instruction:
Improve this application.What does “improve” mean?
Performance?
Accessibility?
Architecture?
UI?
Security?
Refactoring?
Dependencies?
An autonomous system given a vague objective has an enormous solution space.
Instead, define a bounded mission.
MISSION
Add client-side validation to the registration form.
SUCCESS CRITERIA
- validate email format
- require passwords of at least 8 characters
- display errors using the existing error component
- preserve current server validation
- existing tests must continue passing
BOUNDARIES
- modify only registration-related files
- do not add dependencies
- do not change the API
- do not modify authentication logic
STOP WHEN
The requirements are implemented and tests pass.Now the agent knows what success looks like.
And equally importantly:
It knows where to stop.
🧱 Principle #2: Define the Sandbox
Imagine hiring a contractor to repair one room in your house.
You probably wouldn’t say:
“Here’s the key. Change anything you think needs improving.”
Yet developers sometimes give AI agents effectively that level of freedom.
Instead, establish a sandbox.
Tell the agent:
YOU MAY MODIFY
src/components/RegistrationForm.js
src/validation/register.js
tests/registration.test.js
YOU MAY READ
src/components/
src/validation/
tests/
DO NOT MODIFY
server/
config/
authentication/
package.jsonThis dramatically reduces accidental scope expansion.
Vibe Rule:
Give AI the smallest permissions necessary to complete the mission.
🛑 Principle #3: Create Approval Gates
Not every action should have the same level of autonomy.
Some changes are easy to reverse.
Others can have much larger consequences.
A useful pattern is:
🟢 Green — Agent Can Proceed
Examples:
- inspect files
- search code
- suggest changes
- create local tests
- modify isolated code
- run safe development checks
🟡 Yellow — Review First
Examples:
- add dependencies
- change architecture
- modify shared interfaces
- alter database structures
- change authentication behavior
- make large cross-project refactors
🔴 Red — Explicit Human Approval
Examples:
- production deployment
- destructive data operations
- credential or permission changes
- publishing releases
- irreversible external actions
The more difficult an action is to reverse, the more valuable human approval becomes.
🧠 Principle #4: Ask for the Plan Before the Changes
One of the easiest ways to control agent behavior is to separate:
planning
from
execution.
Try:
Before modifying anything:
1. inspect the relevant files
2. summarize the current implementation
3. identify the files you believe need changes
4. propose your implementation plan
5. identify risks
6. identify assumptions
STOP.
Wait for approval before modifying files.This gives you an opportunity to catch bad reasoning before it becomes bad code.
🔍 Principle #5: Require Evidence
An agent saying:
“Done.”
isn’t enough.
Done according to what?
Ask for evidence.
When finished, report:
FILES CHANGED
List every modified file.
WHY
Explain why each change was necessary.
TESTS
List tests executed and their results.
REQUIREMENTS
Map each requirement to the implementation.
ASSUMPTIONS
List assumptions made.
KNOWN LIMITATIONS
Identify anything still uncertain.
UNRELATED CHANGES
Confirm whether anything outside the requested scope changed.Now the final response becomes something closer to an engineering handoff.
🧪 Principle #6: Let Agents Test Their Own Work—But Don’t Stop There
One of the biggest advantages of agentic coding is the loop:
WRITE
↓
TEST
↓
FAIL
↓
INVESTIGATE
↓
FIX
↓
TEST AGAINThat’s much more useful than simply generating a block of code.
But there’s an important warning.
Passing tests don’t prove the implementation is correct.
The agent may have:
- misunderstood the requirement
- written incomplete tests
- modified a test to match incorrect behavior
- missed an important edge case
So the workflow becomes:
AGENT TESTS
+
HUMAN REVIEW
+
INDEPENDENT VERIFICATION🔄 Principle #7: Keep Changes Small
AI agents make large changes tempting.
You might think:
“If it can modify five files, why not fifty?”
Because reviewability matters.
Compare:
Agent Mission A
Modernize the application.with:
Agent Mission B
Replace duplicated date-formatting logic with the existing formatDate() utility in these four components.
Do not change behavior.Mission B is easier to:
✔ understand
✔ test
✔ review
✔ reverse
✔ trust
Agentic development doesn’t eliminate the value of small changes.
It makes small, well-defined changes even more powerful.
🧩 Principle #8: One Agent, One Responsibility
There’s another temptation.
You have multiple agents available.
Why not let them all loose?
One builds the UI.
One modifies the API.
One refactors.
One writes tests.
One updates documentation.
Now they’re changing overlapping assumptions at the same time.
Chaos.
Instead, think like an engineering manager.
Give each agent a clear responsibility.
AGENT 1
Analyze the existing architecture.
AGENT 2
Implement the approved feature.
AGENT 3
Review the implementation for bugs.
AGENT 4
Review tests and edge cases.Notice something important.
Not every agent needs permission to modify code.
Some agents can be reviewers rather than builders.
👀 The Reviewer Agent Pattern
This is one of my favorite agentic workflows.
Agent A implements the feature.
Agent B receives:
- the requirements
- the implementation
- the changes
- the tests
Then Agent B gets this instruction:
You did not write this implementation.
Review it as a skeptical senior engineer.
Look for:
- requirement mismatches
- unnecessary complexity
- bugs
- security concerns
- missing edge cases
- weak tests
- architectural inconsistencies
Do not rewrite the code.
Return findings ranked:
CRITICAL
HIGH
MEDIUM
LOWNow you’re using AI against AI.
Not because one model is automatically correct.
But because independent review creates another reasoning pass.
⚠️ The Agent Drift Problem
An agent starts with:
“Fix the login button.”
Twenty minutes later it’s:
- restructuring authentication
- renaming utilities
- updating CSS
- changing dependencies
- rewriting tests
How?
Each step seemed reasonable in isolation.
This is agent drift.
The agent gradually expands the interpretation of the mission.
Prevent it with checkpoints.
Every time you believe work outside the original scope is required:
STOP.
Explain:
1. what additional change is needed
2. why it is necessary
3. what files it affects
4. what risk it introduces
Wait for approval.📍 Use Checkpoints, Not Constant Supervision
The answer isn’t necessarily watching every action.
That removes much of the value of autonomy.
Instead, create meaningful checkpoints.
MISSION
↓
PLAN
↓
🛑 APPROVAL
↓
IMPLEMENT
↓
TEST
↓
🛑 REVIEW
↓
REFINE
↓
VERIFY
↓
🛑 FINAL APPROVAL
↓
MERGE / SHIPYou don’t control every keystroke.
You control the decision boundaries.
🧠 The Agent Contract
Here’s a reusable pattern.
MISSION
[Clearly defined objective]
SUCCESS CRITERIA
[What must be true when finished]
AVAILABLE CONTEXT
[Relevant files and project information]
PERMITTED ACTIONS
[What the agent may do]
PROHIBITED ACTIONS
[What requires approval]
SCOPE
[Files/modules that may change]
VERIFICATION
[Tests/checks that must run]
CHECKPOINTS
[When the agent must stop]
FINAL REPORT
- changes made
- tests run
- assumptions
- risks
- unresolved issuesThink of this as an employment contract for your AI agent.
You’re defining:
Responsibility + Authority + Boundaries + Accountability
🔥 Advanced Pattern: Agent → Reviewer → Human
Here’s a powerful workflow:
HUMAN
↓
DEFINE MISSION
↓
BUILDER AGENT
↓
IMPLEMENT
↓
REVIEWER AGENT
↓
CHALLENGE RESULT
↓
BUILDER FIXES
↓
TESTING
↓
HUMAN REVIEWS
↓
SHIP
The developer is no longer manually producing every line.
But the developer still owns:
- the goal
- the constraints
- the architecture
- the acceptance criteria
- the review
- the final decision
That’s not losing control.
That’s higher-level control.
🧪 Issue #40 Challenge: Delegate One Mission
Pick one small task from a project.
Not an entire feature.
Something bounded.
For example:
Add validation to one form.or:
Remove duplicated logic from three functions.or:
Add tests for this utility.Create an Agent Contract.
Then let AI complete the task.
But record every time you needed to intervene.
Was the problem:
- missing context?
- unclear requirements?
- excessive permissions?
- weak acceptance criteria?
- agent drift?
- insufficient testing?
Don’t just evaluate the agent.
Evaluate your delegation.
That’s where the learning happens.
💡 The Developer’s Job Is Moving Up the Stack
Developers once spent much of their time telling computers exactly how to perform operations.
AI increasingly allows us to describe what outcome we want.
That doesn’t eliminate engineering.
It shifts where engineering happens.
From:
WRITE EVERY STEPtoward:
DEFINE
↓
CONSTRAIN
↓
DELEGATE
↓
OBSERVE
↓
VERIFY
↓
DECIDEThe ability to generate code becomes less scarce.
The ability to direct systems intelligently becomes more valuable.
🧠 The Core Lesson of Issue #40
The goal isn’t maximum AI autonomy.
And it isn’t maximum human control.
It’s:
The right autonomy at the right moment.
Give agents enough freedom to be useful.
Give them enough boundaries to remain predictable.
Require enough evidence to verify their work.
And preserve human judgment where consequences matter.
The future of Vibe Coding isn’t:
“AI, build everything.”
It’s:
“Here’s the mission. Here are the boundaries. Show me the plan. Do the work. Prove it works. I’ll make the final call.”
That’s how we move from AI assistance to AI delegation without creating chaos.
Delegate intelligently. Verify relentlessly. Stay in control. 🚀
🔮 Coming in Issue #41
Spec-Driven Vibe Coding: Stop Prompting Features and Start Defining Outcomes
As AI becomes capable of implementing larger pieces of software, the quality of your specification becomes increasingly important.
In Issue #41, we’ll explore:
- turning vague ideas into testable specifications
- defining acceptance criteria before generating code
- separating requirements from implementation
- writing examples that remove ambiguity
- using AI to challenge your specification
- converting specifications into tests
- preventing “technically correct” but wrong implementations
- creating a lightweight spec workflow that doesn’t slow development down
Because when AI can write the implementation quickly, the question becomes: