An essay on AI
Vibe Coding and Agentic Engineering Are Not the Same Job
For a year the code came back broken. Then it came back clean. The floor opened for everyone, and a quieter job appeared: keeping the bar while the machine moves fast.
An essay on AI

Vibe Coding and Agentic Engineering Are Not the Same Job

For a year the code came back broken. Then it came back clean. The floor opened for everyone, and a quieter job appeared: keeping the bar while the machine moves fast.

The red gorges of Karijini National Park across the Hamersley Range in the Pilbara of inland Western Australia, painted in bodied oil with deep oxidized-bronze tones.

Something changed in how software gets built. For years you typed the code by hand. Now you describe what you want, and a machine writes it back. The work moved from typing to directing. This is a short field guide to that shift.

Artificial Intelligence (AI) crossed a line where its code stopped needing constant repair. That sounds like pure good news. It is not. The floor dropped open for everyone. The bar that real software has to clear did not move an inch.

Short answer

What is the difference between vibe coding and agentic engineering?

The difference between vibe coding and agentic engineering is the quality bar. Vibe coding lifts the floor so anyone can describe an app and get one. Agentic engineering keeps professional standards while agents move fast. One opens the door. The other guards what ships.

What is the difference between vibe coding and agentic engineering?#

Start with the floor. For most of computing history, building software meant clearing a high bar. You needed years of training to make anything that worked. That bar kept most people out, the way a locked door keeps a house private.

Then the floor rose. Now a parent at the dining table can describe a small tool and watch it appear. A kid can build a game over a weekend. This is vibe coding. You say what you want in plain words, and the work comes back built. The door is open to everyone now.

The change was not gradual. For a year the tools were helpful and wrong by turns, and you read each chunk and repaired the broken parts by hand. Then the repairs dried up. Behind is a strange thing to feel when the screen stops asking you for anything.

Call the second one agentic engineering. Real software still has a bar to clear. It cannot leak private data. It cannot fall over when a thousand people show up. You are still on the hook for what you ship. It is the craft of moving at that new speed while the bar stays exactly where it always was.

So the two are not rivals. One lowered the floor. The other still guards the ceiling. Vibe coding is who can build. Agentic engineering is whether the thing should ship. The floor is open to all of us. The bar belongs to whoever signs for what ships.

Why is AI good at coding but bad at simple questions?#

This is the odd thing. The same model that rebuilds a giant codebase will flub a question a child answers. Try a tiny errand. Should you take the car to the wash at the end of the block, or just walk over. It says walk, since the wash is close by. It forgets the car is the whole reason for the trip.

That is jagged intelligence. The skill is spiky. It is superb at the hard, checkable jobs and clumsy at the plain ones. Like a surgeon who can rebuild a heart valve but cannot find the parking lot, the model holds the genius and the blind spot in one hand.

It helps to picture what the thing is. We did not raise it the way nature raises an animal, shaped over long years by hunger and fear and play. We pulled it out of a sea of text, a kind of ghost assembled from everything people have written down.

So scolding it does nothing. It has no pride to bruise. It is brilliant and hollow in the same breath, which is why it dazzles you on Monday and fails you on Tuesday.

The reason sits in how the model is trained. Labs pour effort into tasks that can be scored, like math and code. Skill climbs steeply there. Anything left off that menu stays clumsy. A lot of the spikiness is simply which subjects a lab decided to teach and which it ignored.

One case makes it plain. Chess jumped sharply from one model to the next. The cause was simple. The reason was dull. A mountain of chess games got fed into its training. The talent appeared only because somebody fed it that pile.

So you cannot read the model by its best day. The brilliant answer and the dumb one come from the same box. Keep your hands on the work and look in the corners. The peak tells you nothing about the valley beside it.

Scorecard of four tasks scored on two columns, can it be checked and how AI does today: checkable tasks like refactoring code read sharp, uncheckable ones like common sense read dull.
Source: Where the answer can be checked, the model is sharp. Where it cannot, the model is dull. Directional, not measured. Source: Hanh Brown.

What does verifiability mean for AI automation?#

Here is the lever under all of it. The word is verifiability. It asks one thing: can you check the answer cheaply and know it is right. That single question decides what gets automated next.

Old computers automate what you can spell out in steps. This generation automates what you can check. Labs train these models by scoring millions of attempts, so the skills that can be graded race ahead. Like a coach who only trains the drills a stopwatch can clock, the labs build muscle where there is a clear win and a clear loss.

That is why math and code move fastest. A right answer there can be marked right. A teacher can grade the page in seconds, or a student can check it against the key. Taste and judgment have no clean score, so they lag.

There is good news buried in this. If your corner of the world can be checked, you are not stuck waiting on the labs. You can gather your own examples, build a scoring test of your own, and train the model against it until it gets sharp on the work you actually do. The lever is real.

And the reach keeps widening. The line between what can be checked and what cannot is not fixed. It moves a little every year, as people find clever ways to score messy work. Think of it as easy versus hard, not yes versus no.

Now the other side. Ask the model to take a working program and make it truly simple, and it digs in its heels. It pads. It copies. It wraps the thing in clever scaffolding nobody asked for. Simple was never on the test it was trained against, so simple is not where it shines.

So the honest read is this. The model can build what you cannot check, and still not know whether what it built is right. That gap is the whole game.

A two-by-two matrix with axes can you check it and do the labs invest: the checkable and funded quadrant automates first, the uncheckable and unfunded quadrant stays human longest.
Source: Two questions, can you check the output and do the labs invest, decide what automates first. Directional, not measured. Source: Hanh Brown.

What skills matter most when AI agents write the code?#

So what stays in human hands? More than the speed suggests. You own the spec, the plan, the taste, and the call on whether the result is sound. The agent colors inside the lines you draw. You decide where the lines go.

There is a clean way to split it. You can hand the machine the doing. You cannot hand it the deciding. It will draft, fetch, and fill the page faster than you ever could, and it will do it without once asking whether the page is worth writing at all. That question is yours. So is the answer.

Here is a bug worth sitting with, because it carries the whole lesson. Picture a little tool where you log in one way and pay a different way. The agent matched your money to your login by comparing the two email addresses.

But folks sign up with one email here and a different one there. There was no stable key underneath. If the two never matched, your payment drifted off and never reached you.

The code ran clean. But the thinking under it was broken. That mistake was upstream of the keyboard, in the spec, and the spec is the human’s job. You name the rule out loud: every record ties to one stable key. The agent will not invent that rule for you.

The little chores you pass along gladly. I no longer keep the exact function names in my head. That kind of recall is what the machine is good at. You still need to grasp what is happening below, so your request points the right way.

This is why the person cannot fade into the background. Direction needs understanding, and the machine carries none of it. It will run hard in whatever direction you point, and just as hard in the wrong one. Point it well and the speed is a gift. Point it blind and the speed is the danger.

So the division is plain. You own the why. The agent owns the how. If the plan was bad, the failure lands on you, since you wrote the spec. That is the trade, and it is a fair one.

How do you hire for agentic engineering?#

Hiring has not caught up. Most of it still runs on the old puzzle. A candidate sits at a desk and solves a clever brain teaser. That told you something once. It tells you little now.

What matters now is fast judgment. Can this person run a crew of agents and hold the bar. The puzzle does not show that. A real project does.

The better test is a real build, in three moves. Hand them something big and real, not a toy. Ask them to make it genuinely secure. Then turn other agents loose to break it, and watch what holds.

Watch how they set the spec. Watch how they steer the tools. Watch how they defend the bar when the room gets loud. That is the worker you want at the next desk.

One more thing separates the strong from the rest. It is not raw talent. It is whether a person bothered to build a real bench around the tools, the way a good worker has always set up a clean shop before the first cut. The mediocre user pokes at the defaults. The strong one wires the whole thing together and never looks back.

And the range is wide. Two people with the same tools now ship work that looks years apart, because one set up the shop and one did not. The tool is the same. The result is not. That spread is new. It is only going to grow.

Folks once bragged about the ten-times engineer who beat a whole team alone. That figure looks tiny today. The strongest do not land at a neat tenfold. From what shows up in the work, the gap runs far wider, because the agents are powerful even when they wander.

How do you make software agent-native?#

Most software is still written for people. The instructions say go to this screen and click the blue button. An agent cannot click a screen the way a person reads a page. So the surface has to change.

Step back and the bigger shift comes into view. Software once meant rules typed out by hand, one line after another. Next came models trained on data, where the rules were learned, not written. Now there is a third way, and it is the one we live in. You write a prompt. The words are the program.

Watch what that does to something as dull as installing a tool. The old way was a brittle script that cracked on every machine it touched. The new way is a block of plain text you hand to your agent, which reads your setup and works around the snags on its own. The instructions stopped being for you. They became something to pass straight to the machine.

Making software agent-native means treating the agent as the reader. Give it the exact text or command to run, not a tour of the menus. Publish your data in a form the model can parse. The honest test is simple. Could a single prompt build the thing and put it online untouched.

Here the new tools do not change the oldest rule. Like a farmer with a new tractor who still has to choose which field to plow, you get speed, not direction. The machine turns the soil. You decide what to grow and why.

That is where this lands at home. A parent can let a child hand a school report to a machine and watch a clean answer appear. The parent still has to ask the child what the report was about. The answer you cannot check is the answer you do not really have. The floor opened for all of us. The judgment stayed.

Source: Andrej Karpathy, in a fireside talk titled “From Vibe Coding to Agentic Engineering” with host Stephanie Zhan, at Sequoia Capital’s AI Ascent 2026: https://www.youtube.com/watch?v=96jN2OCOfLs

Questions readers ask

Six questions on this essay.

01 Is vibe coding safe for real, production software?

Vibe coding is safe for low-stakes things you control: a personal tool, a weekend prototype, a script that touches no one else. It gets risky the moment other people, their money, or their private data are involved. The reason is not the speed. It is that a rising floor does not raise the bar. Production software still has to resist attacks, survive load, and protect data, and none of that comes free with a good prompt. The safe move is to treat vibe coding as a first draft and agentic engineering as the finish: keep the fast build, then apply real review, real testing, and someone who owns the result. Speed is fine. Skipping the bar is not.

02 How can I tell if AI will be strong at my specific problem?

Ask one question first: can the right answer be checked cheaply. If your problem looks like math, code, or anything with a clear pass or fail, you are likely on trained ground and the model will fly. If success is a matter of taste, nuance, or long context that no one scored during training, expect rough output. A fast way to probe it is to run a few real cases by hand and compare. Where it is strong, it stays strong. Where it guesses, it guesses with confidence and gets it wrong. Map your own terrain before you bet a project on it, because the model carries no manual of where it is strong and where it is blind.

03 Can non-code work like writing be automated the same way?

To a degree, yes, and the path is the same one: make the work checkable. Writing has no single right answer, so it resists the clean scoring that drove code and math forward. But you can get partway there by having a panel of models judge a draft against clear standards, which turns a fuzzy task into a rough score. The more honestly you can define good, the more of the work you can hand off. The catch is that the judges inherit the same blind spots, so a person still owns the final read. The principle holds across fields: the easier it is to check the output, the faster that output can be automated, whatever the work is.

04 What is the fastest way to get better at directing AI agents?

Invest in your own setup. The widest gap right now is not talent, it is whether a person has built a real workflow around the tools or is still poking at them by hand. The strongest users treat their environment like a workshop: the right tools wired together, defaults tuned, the friction sanded down. Then they practice the actual skill, which is writing a clear, detailed spec and reviewing what comes back with a sharp eye. Start by picking one real project and running it end to end with agents, not a toy. You learn the spiky edges by hitting them. The speed comes from reps and a good bench, the same way it always did for any craft.

05 Do I still need the fundamentals if the agent remembers the details?

Yes, and the reason is subtle. You can safely hand off recall: the exact names, the small arguments, the boilerplate you used to keep in your head. The agent is excellent at that, and forgetting it costs you little. What you cannot hand off is understanding of how the thing works underneath, because that is what lets you ask for the right thing and catch a wrong answer. Without the fundamentals, you cannot tell a clever result from a broken one that merely looks clean. The trade is a good one: drop the trivia, keep the working model of how the system behaves. The details live in the machine now. The judgment still lives in you.

06 Why does code from an agent often come out bloated?

Because clean, simple work was never really what the training rewarded. The model learned to produce code that passes checks, not code that a careful person would call elegant. So you often get a result that runs but is padded, repetitive, and propped up by fragile shortcuts. Ask it to make something genuinely simple and it tends to resist, because simplicity was outside the scored tasks that shaped it. None of this is permanent. There is nothing stopping the tools from learning taste; the work just has not been done yet. Until then, the aesthetic call stays a human job. Read the output the way an editor reads a first draft, and tighten what the machine left loose.

About the author
Hanh D. Brown, writer.

Hanh D. Brown writes on AI, aging, and the decisions in between. Twenty years building systems for life-stage choices, now writing the publication with time to ask why.

Read more

Subscribe: a new essay when it's finished, never before. Join readers thinking about AI, aging, and the decisions in between.

Subscribe From the work See the work