Agentic Engineering vs Vibe Coding
The mindset that separates people who ship from people who get stuck — and why staying in charge is the whole game
Two people, same tools, opposite results
Give two people the exact same AI and the exact same task. One ships a working feature in an afternoon. The other is "two weeks from launching" — and is still two weeks from launching six months later. The difference is almost never the tool. It's who is doing the thinking.
Vibe coding = you offshore the thinking to the AI and hope. Agentic engineering = you do the thinking, and the AI does the typing. Same models. Completely different outcomes.
This is not anti-AI. The engineer this module is based on has AI write 95% of his code. The point is the other 5% — the judgment, the plan, the "no, do it this way" — is where all the value lives.
The mental model that makes it click
The model does not think. It does not "understand." It converts your words to tokens and predicts the next one. That's it. Powerful, but not a mind. So the right way to hold it:
It has read everything and forgotten nothing — but it doesn't know which of the things it knows applies to your situation. That's your job. You point; it runs. You decide; it executes.
A useful warning sign: the model is agreeable. Ask it "are there problems with this code?" and it will happily invent ten, whether or not any exist. It will tell you your plan is brilliant. It has no idea. When you are in the driver's seat making the call, that agreeableness is harmless. When you hand it the wheel, it will drive you confidently off a cliff.
Model vs harness — know the difference
Two words you'll hear constantly. They are not the same thing, and people who confuse them stay stuck.
model → the engine (Opus, GPT, etc.)
harness → everything wrapped around it
# tools, system prompt,
# file access, the loopThe model alone can't do anything — it only predicts text. It can't read a file or run a command.
The harness gives it hands: the ability to read files, search, run commands, and loop until done.
Same model, different harness = a totally different experience. This is why people's results with the same AI vary so wildly.
At Ormus, the harness is Claude Code — and our skills are the tools we hand the model.
A year ago the advice was "stuff the model with everything" — dump the whole codebase in as context. The advice today is the opposite. Modern models read your code and infer the stack themselves. Don't over-explain. Only tell it the things it can't know: the vision, how the project is used, the one weird bit of structure.
Context engineering — the make-or-break skill
Every model has a finite context window. The single biggest lever you have is keeping it clean. The more you bloat it, the dumber the agent gets. Stay in the sweet spot.
A small task fits in a clean context window. A huge task forces the model to dump everything in, and it starts to fumble. Big ask → split it.
The plan is how you hold the agent accountable. Have it draft the plan, then say: "this is too big — break it into the smallest reviewable chunks."
Code is the best source of truth — better than any docs. When you need the agent to use a library correctly, point it at that library's actual source, not a hand-written description of it.
When a thread gets bloated (~70%+ full), don't fight it. Start a new session with a tight prompt. A fresh context beats a tired one.
The loop: define the end-state, let it run
Here's the part that feels like magic. You don't tell the agent how — you tell it when it's done, and you give it a way to check. Then it loops on its own until the goal is met.
"Make it work" is a weak goal — the agent can't tell when it's done, so it spins or stops too early. "This test passes" / "the review comes back clean" / "the app deploys" are verifiable goals. Nail the finish line and the agent figures out the path. Skip it, and you get a dumb loop that runs forever — the thing people fear when they've never actually used one.
Left alone, an agent rewrites code that already exists instead of reusing it — nine times out of ten. That's how a codebase rots into something even the agent can't debug. After each feature, run a clean-up pass: "where is this logic duplicated? consolidate it." Clean structure is easier for the next agent session to pick up. The old engineering disciplines — clean structure, real tests, good docs — turn out to be exactly what agents need.
Mindset check
Three situations. No memorization — just apply the mindset.
You need a feature added. You have ten minutes before a call.
What's the agentic-engineering move?
You propose an approach. The agent replies: "Great idea — that's definitely the right call."
How much should that reassure you?
The agent drafts a plan to rebuild a whole module in one giant pass. It looks thorough.
What do you say back?
Everything you just learned isn't only for engineers. The biggest, most immediate wins are in ordinary knowledge work — contracts, accounting, reports. Next module shows you where the real leverage is, even if you never write a line of code.