Vibe coding, explained.

"Vibe coding" started as a half-joking tweet from Andrej Karpathy in early 2025: "I just talk to the computer and accept whatever it does." A year later, the term has stuck — partly because it names something real, partly because the discourse around it has become its own subgenre. This is the honest version.

What it actually is

Vibe coding is the workflow where you stop typing code and start describing intent. The agent reads, writes, runs commands, and you steer with feedback. You're still in the loop — accepting or rejecting diffs, redirecting when things go sideways — but you're operating at a higher level of abstraction than "characters in a file."

At its best, it feels like pair-programming with a tireless junior who has read your whole codebase. At its worst, it produces fluent code that compiles, runs, passes a test, and is subtly wrong in a way you'll only notice in production.

Why senior engineers are wary

The objection isn't snobbery — it's a well-founded fear that the failure modes of agentic code are uncorrelated with the failure modes humans are trained to catch. A reviewer skimming a 200-line agent-written diff is reading for human mistakes (missing edge cases, off-by-ones, bad naming) and may not notice the load-bearing things an agent gets wrong (silently invented APIs, plausible-but-fake error handling, the wrong library version).

The senior-engineer take, in our experience, is: vibe code the easy 80%, but read the diff like you wrote it. The agent is a productivity multiplier, not a responsibility transfer.

The parts that are here to stay

• Per-hunk diffs. The "show me what you're about to change, let me accept hunks individually" pattern is now table stakes. It's the single highest-leverage UX in the category.
• Approval gates. The agent proposes; you approve. Reads run automatically, writes wait. This is the only safe way to give an agent shell access.
• Project memory. A small file the agent reads first (AZMX.md, CLAUDE.md, AGENTS.md) that captures "things that would surprise a newcomer." Without it, agents make the same mistake every session.
• Sub-agents. A delegate agent for narrow tasks (run the tests, search the docs) keeps the main agent's context clean.

The parts that are noise

• Fully autonomous agents. They demo well. In production codebases with real constraints, they wander. The economics are also brutal — autonomy burns a lot of tokens.
• "AI does the whole PR." Sometimes, for small surface area. Often, not. The win is per-step assistance, not end-to-end delegation.
• Voice-only coding. A cool demo. Not yet a workflow.

How to vibe code without getting burned

• Use an agent with approval gates. Any agent that defaults to "yes" on destructive verbs is wrong.
• Use per-hunk diffs. Accept the changes you'd write yourself. Reject the ones that look weird, even if you can't immediately say why.
• Write a project memory file. The agent will reread it at the start of every session. Five minutes here saves five hours of repeated mistakes.
• Keep your hands on the terminal. The agent should be in the same window — not in a side panel you have to alt-tab to. The friction of switching windows is the friction of paying attention.

Where this is going

By the end of 2026, the conversation will have moved on from "vibe coding" to "how do we ship coding agents that don't lie." That's the right question. The tools that win the next round will be the ones that show their work — show every command before they run it, every write before it lands, every external call before it leaves the machine. That's the bet AZMX AI is making.

See AZMX AI's approval gates in action · The complete guide to agent security