Vibe coding raised the floor. Agentic engineering raises the bar. Taste runs the gate

In early 2025, Andrej Karpathy coined "vibe coding" and a generation of builders stopped reading the diffs their models produced. It worked, until the prototype had to become a product. I have written before about that exact stretch, the distance between a vibe-coded demo and something users can trust, in The vibe-code gap is real. A year later, the same man named the disciplined sequel: agentic engineering, from his Sequoia Ascent 2026 talk.

Karpathy framed the split in two lines. Vibe coding raises the floor — anyone can now build anything. Agentic engineering is about raising the ceiling. And on the ceiling, the only thing that has not been automated away is taste. The discipline, as he frames it, is coordinating fallible agents while preserving correctness, security, taste, and maintainability. The first two have automated checks today. Taste does not. That is the sentence most people skim past.

On this page

• What is agentic engineering and how is it different from vibe coding?
• Why does the review gate become the bottleneck for solo founders?
• Where does taste actually decide what ships?
• How do you actually run the taste gate solo?

What is agentic engineering and how is it different from vibe coding?

Agentic engineering is vibe coding with an exit door. Vibe coding said: give in, forget the code, iterate until it runs. Agentic engineering says the unit of work is no longer the whole app and the outcome is no longer the demo. Simon Willison drew the cleanest line: if you reviewed what the model wrote, tested it, and could explain it, that is software development with an AI assistant rather than vibe coding. That review step is the gate that separates play from engineering.

The practical shift is the macro action. Karpathy's framing moves from prompting for an app to issuing commands like "implement this feature, refactor this subsystem, make this failing suite pass." The agent plans, writes, and verifies. The human keeps a spec, reads the changes, and runs a gate the machine cannot fake. The model shoulders the writing. A person still decides what the writing means for the product.

Why does the review gate become the bottleneck for solo founders?

Because you are the only reviewer you have. A team can spread the gate across architecture, QA, and design. A founder is the whole path between the model's output and a shipped product, and every diff review is a decision about hierarchy, edge cases, consistency, and where the product ends. Nobody steps in when you are tired.

Vibe coding made the demo cheap. Agentic engineering makes the review expensive. Most solo builders react by skipping the gate when the pressure hits, and that is exactly when the model's taste defaults take over. The agent quietly reproduces the average of everything it has seen. Someone still has to say what this product is, and that someone is you.

Where does taste actually decide what ships?

In the review gate. An agent's own tests validate correctness, style, and sometimes security, and those pass once the eval set is up. Taste is everything those tests do not cover. The empty state. The error state. Focus management. The spacing used on every screen. Whether a pattern is a leftover from the model average or a deliberate product choice. Each of those is a judgment call a human makes while reading a diff.

This is the part of the automation that agentic engineering formalized. The model proposes, a stack of checks validates, and a person still chooses what good means. Most founders build the checks and skip the reading, then blame the model when the product feels generic. The problem was never the model. It was the gate nobody ran. The agentic workflow just moved all the taste into the one step that still requires a person.

How do you actually run the taste gate solo?

Start earlier than the diff. Write a short spec before the agent runs — the change, the constraint, the quality bar. I read it back whenever a diff surprises me. Then review like a skeptic, not a bystander. Open the diff and check the three decisions that shape the product, not the ones the agent flagged as safe. Click the flows it did not write. Test the empty and error states by hand.

Then build an eval set: a file of real cases where you know what good looks like, and run it on every change, not just the memorable ones. That file is taste made measurable, and it is the part of the workflow that protects more than the code. The gate you keep is your version of the discipline. Keep it honest, keep it personal, and the agents stay below you. The ceiling that hides in Karpathy's talk is not the model. It is a person reading a diff and deciding good. That is your job. Nobody has automated it yet.