Most people think the jump from vibe coding to agentic engineering is about writing better prompts.
It isn’t.
I run 100+ AI agents across a Web3 codebase. This is the story of how I learned that prompts control objectives, not boundaries, and that the real engineering isn’t in the agents at all. It’s in everything that runs around them.
The Evolution Nobody Finishes
I went through every stage of this progression, and I stalled at each one longer than I’d like to admit.
- Chatbot. You ask a question. It answers. You copy-paste.
- Autocomplete. Inline completions. Tab, tab, tab.
- Vibe Coding. You hand it a task and let it run. Fix what breaks. Repeat.
- Agentic Engineering. You define constraints, boundaries, and automated checks. Agents run work independently within those guardrails.
Most developers I talk to are somewhere between Autocomplete and Vibe Coding. And Vibe Coding feels like the finish line. You describe what you want, the AI builds it, and you ship. What’s left to improve?
Everything.
Here’s what nobody says out loud: every jump on that chart except the last one is a tool upgrade. You install a better extension. You switch to a better model. You try a different IDE. The jump to Agentic Engineering is not a tool upgrade. It is a behavior change. And that’s why most people stall at Vibe Coding. Tools are easy to adopt. Behaviors are hard to change.
Vibe Coding is hopium. It works until it doesn’t. You have no guardrails, no verification, no way to catch what the AI got wrong until it’s already in production. You’re shipping on vibes and hoping for the best.
The Illusion
Here’s where the hopium becomes dangerous.
Tell an agent “build the signup flow,” and it will build the signup flow. It looks polished. It works in the happy path. And under the hood, it wires the form straight to the database instead of going through the business logic that keeps the app safe. It trusts user input without proper validation. It hardcodes colors and spacing instead of using the design system.
Nothing in the prompt was violated. Everything important was.
That’s the illusion of control. You think you’re controlling the agent because it’s doing what you asked. But all you’re controlling is the objective. Not the boundaries.
So you do what feels logical. You write a better prompt. More detail. More context. More examples. Better phrasing.
If you only improve the prompt, you get higher-quality mistakes.
The output looks more polished. The architecture is still wrong. The validation is still missing. The design system is still ignored. Now, it’s just harder to spot because the surface quality went up.
That’s not control. That’s hope.
Orchestration vs. Harness
This distinction took me months to articulate, but once I saw it, I couldn’t unsee it.
Orchestration tells agents what to do. “You handle the API. You handle the frontend. You handle the tests.” It’s necessary. It is not sufficient.
The harness defines what agents cannot do, what gets caught while they run, and what must pass before their work is accepted. It’s the constraints, detection, and verification that surround the agent, independent of the prompt.
When I stopped thinking about individual agents and started thinking about the system they run inside, everything changed. One ESLint rule replaced dozens of prompt instructions. One pre-commit hook eliminated an entire class of failure that I’d been writing paragraphs of instructions to prevent. I started catching categories of bugs instead of individual instances.
Layer 1: Explicit Prohibitions
The first layer of any harness is telling agents what they absolutely cannot do.
You’ve probably seen or heard of this already. An agent rewrites a failing test so it passes instead of fixing the actual problem. The prompt said, “Make the tests green.” It never said, “don’t modify the tests.” I would never have to say that to a senior developer. They know.
That’s the core tension. These prohibitions are engineering principles you’ve internalized over a career. DRY. Separation of concerns. Never trust user input. The agent hasn’t internalized any of them. It needs every principle stated explicitly, or it will cheerfully violate all of them while producing code that looks professional.
So every project I work on has a prohibitions table. Numbered rules, absolute, no exceptions:
- NEVER push or merge to main.
- NEVER skip verification steps.
- NEVER hardcode colors, fonts, or weights.
- NEVER use
anytype.
Every rule started as a bug. Every bug costs real cleanup time.
Layer 2: Rule Graduation
Here’s the evolution I didn’t expect: the best rules graduate.
They start as prompt-based prohibitions. “Please don’t do X.” They work most of the time. But “most of the time” is not good enough when you’re running 100+ agents, and a 5% failure rate means five violations per batch.
So, the rules graduate to deterministic enforcement. The prompt stays as a defense in depth. The tooling becomes the real enforcement.
“Don’t trust raw input” starts in a markdown file. Then it becomes schema validation and tests. “Don’t commit secrets” starts as an instruction. Then it becomes automated secret scanning in pre-commit hooks. “Don’t change billing logic casually” starts as a warning in the agent’s context. Then it becomes a protected path that requires explicit human approval before any agent can touch it.
Here’s what surprised me about this process. These principles were always worth encoding. I believed in DRY, separation of concerns, and input validation. I preached them in code reviews. But I never insisted on them with tooling. I caught a hardcoded color in review, left a comment, and moved on. The next PR had another hardcoded color. The agents forced the issue because they don’t learn from code review. They don’t remember the comment you left last time. That pressure made me realize I should have been enforcing these principles on myself and every developer all along. The agents didn’t create the need. They exposed it.
If a rule matters enough to write in your instructions, it matters enough to encode in your toolchain. Prompts are suggestions. Enforcement is control.
Layer 3: Deterministic Tooling
This is where I stopped asking and started enforcing.
I built three ESLint plugins because my prompts kept failing on the same issues, no matter how clearly I wrote them. One bans unsafe type casts that bypass validation. One bans putting data-fetching hooks directly in UI components. One bans hardcoded colors, fonts, and weights, forcing agents to use the design system.
You can see the theme one yourself: https://github.com/johnpphd/eslint-plugin-theme-guardrails
Each project picks the plugins it needs. The harness is not monolithic. It’s a composable toolkit.
Prompting tells agents what to do. Linting makes it hard to do anything else.
The Full Pipeline
All three layers compose into a defense-in-depth pipeline:
- Before execution: Pre-run hooks block unauthorized tool use. Agents can’t push to main, can’t skip verification, can’t access tools outside their scope. Deterministic gates, not suggestions.
- During execution: Prohibitions are loaded into every agent’s context. Runtime hooks detect and stop violations as they happen.
- After execution: Full verification pipeline.
yarn typecheck && yarn lint && yarn prettier && yarn build. Custom ESLint plugins catch architectural violations. TypeScript catches type errors. The build catches integration failures.
No single layer is bulletproof. The prompt might fail. The hook might not cover every case. But the linter catches the branded typecast. If that misses, the typecheck catches the downstream error. If that misses, the build fails. Same defense-in-depth principle security engineers have used for decades, applied to agent output instead of network traffic.
The Takeaway
The jump from vibe coding to agentic engineering is not about better prompts. It is about building the system that runs around the agents.
Explicit prohibitions. Rule graduation from instructions to enforcement. Deterministic tooling that catches what prompts miss. A verification pipeline that runs after every output. Each layer compensates for the gaps in the others.
That’s the lesson that took me the longest to internalize. I spent months writing better and better prompts, convinced that the next revision would finally make agents reliable. It didn’t. What made them reliable was accepting that prompts set direction, not boundaries, and building the infrastructure to enforce the boundaries myself. I stopped hoping my agents would follow the rules and started making it hard for them to break them.
The harness constrains the system. But there’s one more constraint that matters even more, and it has nothing to do with tooling. That’s next in the series.
