Part 1: Why Agentic Engineering Isn’t Vibe Coding
A friend recently posted about AI skills using The Matrix analogy: Trinity doesn’t learn to fly a helicopter — Tank uploads a precise, verified program directly into her mind. She steps into the cockpit and flies.
That analogy is perfect. But it exposes a fundamental misunderstanding about how these systems actually get built.
Trinity doesn’t vibe her way into flying. Tank uploads a precise, verified program.
That’s the difference between vibe coding and what Addy Osmani calls Agentic Engineering. “Vibe coding” has poisoned the well — it suggests you can prompt your way to production software. You can’t.
I have 70+ agents in my web3 development workflow. They’re not prompt dumps. They’re structured: clear responsibilities, explicit knowledge files, defined handoff points between agents. Building them took the same architectural thinking that’s always separated working systems from chaos.
The old principles translate directly:
- DRY → DRYP (Don’t Repeat Your Prompt)
- Separation of concerns → Agent boundaries
- Interface design → Handoff contracts
- Documentation → Precompiled context
Building good skills is architecture work. The Trinity scene works because someone engineered that pilot program. Tank didn’t vibe code it.
The Problem That Started Everything
The biggest thing I learned building AI coding workflows: more context is not better.
I work in web3. I have ABIs that are thousands of lines. A Ponder database schema that would eat half the context window if I fed it in raw. My first instinct was to give the AI everything and let it figure out what matters.
That doesn’t work.
The AI gets lost. Important instructions get ignored. It latches onto random details. Results get worse as context gets bigger. There’s a term for this: context rot. As the context window fills up, earlier instructions get “crowded out” and the model starts ignoring them.
So I built a skills-specialist agent.
Its only job is precompiling context for other agents. It reads my raw ABIs, schemas, and docs, then generates slim reference files tailored to specific tasks. It builds skills.
When I need UI work done, I don’t hand my ui-designer the entire codebase. The skills-specialist has already built a component reference with just the props and patterns that agent needs. When I need contract integration, the web3-implementer gets only the relevant functions and events. The raw ABI stays on disk.
Agents building context for agents.
The Memory Hierarchy Mental Model
The mental model that made everything click: treat context like RAM, not a junk drawer.
| Layer | What It Holds |
|—-|—-|
| Disk | Full codebase, raw ABIs, complete schemas |
| RAM | Precompiled skills — task-specific reference files |
| Registers | The current prompt and immediate context |
You don’t load everything into memory. You load what you need for the current task.
My skills-specialist is the compiler that transforms disk into RAM. Without it, I’m back to stuffing context and hoping for the best.
What a Precompiled Skill Looks Like
Here’s the pattern my skills-specialist generates:
# MorphoVault Reference
> Use when implementing vault deposit/withdraw flows.
## Terminology
- **shares**: Vault shares representing proportional ownership
- **assets**: The underlying token being deposited
## Key Functions
### deposit(uint256 assets, address receiver) → uint256 shares
Deposits assets and mints shares to receiver.
See: protocols/morpho/abis/MetaMorpho.json
### withdraw(uint256 assets, address receiver, address owner) → uint256 shares
Burns shares and sends assets to receiver.
See: protocols/morpho/abis/MetaMorpho.json
## Events
### Deposit(address indexed sender, uint256 assets, uint256 shares)
### Withdraw(address indexed sender, uint256 assets, uint256 shares)
## Related Hooks
- useVaultDeposit: src/hooks/blockchain/useVaultDeposit.ts
- useVaultBalance: src/hooks/ponder/useVaultBalance.ts
Short. Scannable. Pointers to source files. Domain terms defined. Clear sections.
The raw Morpho ABI is 2,000+ lines. This reference is 30 lines and contains everything an agent needs to implement a deposit flow.
The Craft Behind the Curtain
Skills don’t build themselves. My skills-creator is itself a skill — one I built through iteration, testing, and architectural thinking.
Every skill in my system has:
- Clear responsibilities — What does this agent own?
- Explicit knowledge files — What precompiled context does it need?
- Defined handoff points — When does it call other agents?
- Verification criteria — How do we know it’s done?
That’s not vibing. That’s engineering.
The distribution insight is right — skills compress the distance between user and value. But someone still has to build them well. That’s the craft.
Coming Up in Part 2
Next, I’ll cover the organizational breakthrough that made 70+ agents manageable: the distinction between skills (personas you converse with) and agents (workers you dispatch).
Turns out only ~10 needed to be conversational. The rest just needed to be discoverable.
This is Part 1 of “Lessons from Building a 100+ Agent Swarm in Web3.” Follow for Part 2 on agent organization, or connect if you’re building similar systems.
