Agentic engineering is not vibe coding

The difference is attitude, not tooling. It matters most for designers who now build.

In a year, the way we build software changed. The words we use for it are still catching up.

"Vibe coding" became a loaded term. On one hand, it captures the ease of creation: a loose description turns into working, interactive software with functional and aesthetic parts. On the other hand, it describes the disposable nature of the effort behind a vibe-coded artifact. Prompt, accept, move on, and deal with the mess later, if at all.

That double meaning was there from the start. When Andrej Karpathy coined the term in February 2025, he described accepting every change, not reading the diffs, and letting the code grow beyond his own understanding. He also said it was fine for throwaway weekend projects.

The accidental face of vibe coding

Rick Rubin became the accidental face of that word. Within days of Karpathy's post, an old photo of Rubin, eyes closed, headphones on, became the meme for vibe coding. Instead of brushing it off, he followed his curiosity.

The result was The Way of Code: The Timeless Art of Vibe Coding, an interactive project made with Anthropic and Claude. Rubin adapted Lao Tzu's Tao Te Ching across its 81 chapters. He says he first picked up the text in Stephen Mitchell's translation 40 years ago, and he drew on many translations for the project. Each chapter is paired with an interactive artwork, and readers can ask Claude to reshape that art as they go. A feeling, expressed as a request, becomes a working thing, and the thing changes as you keep asking.

Rubin is openly enthusiastic about vibe coding. Still, I read the project less as a defense of production vibe coding than as a demonstration of what that mode is uniquely good at. It is beautiful and suggestive, and it is deliberately not production software. It shows what happens when you follow a vibe all the way through. It leaves the harder question open: what happens when the artifact has to keep working tomorrow?

A better name for the professional version

"I actually think vibe coding is a slur. … I always tell people I do agentic engineering, and then maybe after 3 a.m. I switch to vibe coding, and then I have regrets on the next day."

— Peter Steinberger, creator of OpenClaw, on the Lex Fridman Podcast #491 (February 2026)

Steinberger had been writing about "agentic engineering" since 2025. In February 2026, Karpathy endorsed it as his favorite name for the professional version of the practice. In this version you orchestrate agents and act as oversight, and "engineering" signals that it takes real expertise. Agents do much of the execution. Humans own the architecture, the review, and the decision about what ships. On Lex Fridman's show a week later, Steinberger gave the distinction its funniest formulation.

I have used a related phrase myself. In my educational materials I called it "agentic prototyping": onboarding designers to build interactive prototypes with AI-assisted tools. I curated best practices, shared reusable workflows, and tried experimental techniques for building experiential, high-fidelity prototypes quickly. That work is where my own version of the distinction started. It was not a new label for the same thing. It was a teaching practice for making prototypes that can be trusted.

A pitfall I see constantly in interaction design: a mobile flow that looks perfect in Figma falls apart on a real phone. Text that seemed fine on a large monitor is too small in the hand. Colors that passed review fail in daylight. Tap targets are too tight for a thumb. The on-screen keyboard covers the button you need, and the flow you mapped out meets an actual person who does something else. None of this is new. What's new is how early you can find it. When a working prototype on a real device takes an afternoon instead of a sprint, these problems surface in the first week, while they're still cheap to fix.

Attitude, not tooling

The difference between agentic engineering and vibe coding is not the model you use. It is the standard of responsibility you bring to its output. A capable agent, directed by someone who knows what the tools can do and has thought the outcome through, can reach a usable, useful artifact and keep improving it. That attitude has four parts:

Be intentional. Know what you are trying to learn, communicate, or decide, and what evidence would change your mind. If you don't know what a good outcome looks like, you won't recognize it when the agent hands it to you.

Be tool-literate. Understand the capabilities and limitations of different tools, and where your judgment has to step in.

Verify, don't just inspect. Decide what evidence you need before you trust the result. It could be tests, measurements, a code review, or watching someone use it. Looking right is not the same as working.

Be systematic, not lucky. Make it repeatable, and improve your workflows. Save what worked, name it, reuse it, and let the next run start from a better place than the last one.

This matters because the evidence on AI-assisted development is still mixed. A 2025 METR study found that experienced open-source developers were slower with AI tools on codebases they knew well, while believing they were faster. Large field experiments at Microsoft, Accenture, and a Fortune 100 company found meaningful gains, especially for less experienced developers. Both can be true. The leverage depends on the task, the person, and the cost of checking the work.

What do you build when you can build anything?

There are many reasons to prototype. One framing that stayed with me comes from designer Zach Johnston's talk "Provocative Prototyping": we prototype to understand, or to be understood. The first mode is learning. The second is about conveying an idea and getting others on board. A good prototype often has to do both, but it helps to know which mode you are in, because they ask for different fidelity, different framing, and invite different kinds of feedback.

With agentic prototyping, the first mode became far more accessible. Techniques that once required deep, hands-on experience suddenly became askable. 3D is a good example. We are seeing a wave of three.js and interactive 3D work from people who never learned modeling, rigging, shaders, or physics in specialized tools. Pieter Levels' browser flight simulator, built with an AI coding tool in early 2025, kicked off a game jam with over a thousand entries within weeks.

You can now vibe code a 3D fishing game in an afternoon. Making it look good, run well, and actually be fun is another matter. For that you have to learn what to ask for: better lighting and shadows, character animation, sound design, and the game design principles that make something engaging and challenging. This is where the agentic loop becomes a learning loop. You ask about what you don't know, research best practices, learn why something works or doesn't, and apply it to what you are building. Building becomes a way of finding out what you think, and a way to push back on your own first idea.

But asking is not the same as judging. The barrier to making the first version has collapsed. The barrier to knowing whether it is good has not.

How the work changes

Design, as I have come to think of it, is decision-making without enough information. If you knew everything, you wouldn't need to design; you'd just build. Nigel Cross described designers as people who tolerate uncertainty, working with incomplete information.

So we need variants, explorations, intuition, and playful processes. We need playgrounds and sandboxes where we can build things and experience how they feel and behave. And now prototyping at near-production fidelity has become cheap enough to do routinely.

That does not mean every prototype should be high fidelity. Polish signals that something is finished, and people give less fundamental feedback on things that look finished. Fidelity is useful only when it helps answer the question you are actually asking. When the question is about the concept, keep it rough. When the question is physical, like scale, touch, contrast, or what happens when the keyboard slides up, only the real device can answer it.

That is why this shift matters. Less time writing every line of code and pushing every pixel; more time on intent, architecture, review, and experimentation. That is not less design or engineering. It is both, at a different level. Making something has become easy; making something you can trust is still the work. The bottleneck moves from typing to deciding, and the prototype becomes the clearest form of the decision itself.

Views are my own and do not represent my employer.