Vibe coding was meant to let you build without really caring about the code. But what happens to that expression when experienced developers also start using AI agents to produce most of their applications? The difference may no longer be who writes the code, but who stays in control of what gets built.
In the beginning, "vibe coding"
On February 2, 2025, Andrej Karpathy posts a message that gives a name to a new way of building software with AI: vibe coding.
The practice he describes is quite particular.
He asks an AI to produce the code, largely accepts its changes without systematically reading the diffs, tests the result, and feeds errors back to it when they show up.
To the point of, deliberately, no longer really caring about the code itself.
That detail matters.
Vibe coding doesn't simply mean using AI to develop.
In its original sense, it describes a specific way of doing so: favoring the outcome and the iteration loop over a detailed understanding of the code produced.
Karpathy also notes that the approach fits personal, fairly throwaway projects best.
Then the term quickly outgrew its own definition.
Another idea settled around vibe coding:
I have an idea, AI knows how to code, so I can build my application without a developer.
That's probably where the misunderstanding starts.
On one hand, AI genuinely lets someone who doesn't know how to develop produce things that were previously out of reach.
That's a considerable shift.
But on the other hand, developers themselves started folding these same tools into their own work.
And that's not necessarily the same practice.
A developer can ask an AI to produce a huge amount of code while still reasoning about architecture, dependencies, data, security, tests, deployment, or maintainability.
From the outside, the two situations can look identical.
You describe what you want.
The AI writes the code.
The application appears.
That similarity is probably what misled us.
Because the difference is increasingly not about who types the code.
It's about who understands, directs, and takes ownership of what's being built.
"I'll do like you, vibe coding…"
It's actually a recent conversation that brought me back to this question.
While explaining to a friend how I currently work with AI and which tools I use, he replied:
"I'll do like you, vibe coding, using…"
I immediately stopped on those two words: vibe coding.
Not because I find the term offensive, nor because I consider vibe coding an illegitimate practice.
Simply because I didn't really recognize myself in that description.
Yet his remark was perfectly logical.
From the outside, I was describing exactly what people now associate with vibe coding: I state a need, I work with AI agents, they explore the project, produce or modify code, run certain tasks, and help me reach the expected result much faster.
I now produce, this way, an amount of code that would have taken me far longer to write by hand.
So why reject the label?
Because if every intensive use of AI to produce software becomes vibe coding, then a growing share of modern development could soon be labeled that way.
Yet there's a real difference between asking an AI to build something you can't actually evaluate, and delegating part of the construction of a system you continue to design, direct, control, and take ownership of.
In both cases, the AI can write most of the code.
The difference lies elsewhere.
The amount of generated code is no longer the right criterion
You could try to draw a simple line.
On one side, the developer who writes their own code.
On the other, the one who asks an AI to write it.
That line already feels outdated.
An experienced developer can let an agent produce an entire feature, modify several files, write tests, or fix a bug without directly touching every line.
Conversely, someone who doesn't actually master development can get the same apparent result.
In both cases, most of the code will have been generated.
The amount of manually written code no longer really distinguishes the two practices.
The difference lies elsewhere: in the level of mastery retained over what gets produced.
Generating is not deciding
When I hand a task to an agent, I'm not necessarily handing over the decision behind that task.
I can ask it to implement an API without delegating the choice of the overall architecture.
I can ask it to modify an application without letting it freely decide which dependencies to introduce.
I can ask it to solve a problem and then reject its first proposal because it works technically but doesn't fit the project's constraints.
AI can produce the solution without being the one who decides on the solution.
A result can work without being a good solution.
An application can compile while introducing a bad dependency.
A test can pass while checking the wrong thing.
An architecture can be elegant while being disproportionate to the need.
And an answer produced with a lot of confidence by an agent can simply be wrong.
The real criterion: being able to take back control
This is probably where I'd draw the line today.
Not in the number of prompts.
Not in the number of generated lines.
Not even in systematically reading every line produced.
But in a much more demanding question:
Am I still able to understand the important decisions, detect that a direction is wrong, and take back control when necessary?
If the answer is no, I'm also delegating part of my understanding of the system.
If the answer is yes, I'm in a different logic: I delegate execution while retaining mastery of the process.
And that's where the word orchestration starts to make sense to me.
So what am I actually orchestrating?
Talking about orchestration can easily sound abstract.
In my practice, though, it's very concrete.
When I work with an agent, I don't usually start with:
"Build me this feature."
I start by giving it a playing field.
There's an existing project, an architecture, conventions, technical constraints, sometimes an important history, and above all a goal to reach.
Context before the prompt
This is probably one of the biggest changes in how I work.
I think less and less in terms of a "good prompt" and more and more in terms of the context available to the agent.
Does it understand the architecture?
Does it know the conventions in use?
Does it have access to the information it needs?
Does it know what it can change and what it shouldn't touch?
Does it have the tools needed to verify part of its own work?
A highly capable agent with poor context can still produce a very bad solution.
Properly framed and equipped, it can instead take on far more than simple code generation.
It can explore the project, look for an existing implementation, identify the relevant files, propose a strategy, implement it, run the available checks, and fix some of the problems it runs into.
In some cases, my direct intervention during this sequence becomes very light.
My job then is no longer to supervise every single action it takes.
It's to organize the conditions under which I can let it have that autonomy.
Tests, builds, static analysis, functional behavior, Git history, or a CI/CD pipeline become so many checkpoints.
Control simply changes granularity.
I'm no longer trying to verify how each line was produced.
I'm verifying that the resulting system still meets the properties I expect from it.
And when the agent heads in the wrong direction, I take back control: fixing the context, changing the goal, narrowing the scope, questioning the approach, or stepping in directly.
Orchestration, then, isn't watching AIs work in my place.
It's deciding what to delegate, with what context, which tools, what limits, and what control mechanisms.
The agent sees my blind spots too
But this relationship isn't limited to delegating and checking.
This is probably one of the aspects I find most interesting today.
The agent can help me discover what I hadn't seen.
It can flag a constraint I hadn't considered, question an assumption, point out an edge case, or suggest an angle I simply hadn't thought of.
It can see some of my blind spots.
That's particularly useful when the goal itself isn't fully defined yet.
Even when it can't carry the work through end to end right away, the agent can take part in exploring the problem and help surface the gray areas that still need clarifying.
But this relationship runs both ways.
The agent has its own blind spots too.
It can miss implicit business knowledge, give too much weight to something present in its context, overlook an organizational or historical constraint, or propose something coherent in theory but unsuited to the real system.
Sometimes it simply doesn't know it's missing a piece of information.
It sees some of my blind spots, and my experience lets me see some of its.
That's probably a better picture of how I work with AI than the image of a developer simply issuing instructions to a machine.
It's no longer just about delegating then checking.
It's also about confronting two imperfect reasoning capabilities, each with different strengths and weaknesses, to try to reach a better understanding of the problem before even producing its solution.
But is this still development?
I think it is.
As long as we distinguish between developing and writing code.
Developing a solution has never simply meant manually turning a spec into lines of code.
You have to understand a need, translate it into technical concepts, choose an architecture, understand the data, anticipate operational constraints, make trade-offs, test, diagnose, and evolve an existing system without breaking what already works.
Writing code materializes those decisions.
It isn't the sum of those decisions.
We've also been using abstractions for a long time.
A framework saves us from rebuilding standard mechanisms.
An ORM produces queries we don't write directly.
A library wraps code we'll probably never read.
A CI/CD pipeline automates operations we used to do by hand.
AI agents simply push this logic much further.
They're starting to automate not just deterministic technical operations, but part of the intermediate intellectual work itself: analyzing a project, proposing an implementation, writing the corresponding code, producing tests, or tracking down the source of a bug.
The shift is significant.
But it doesn't mean all reasoning disappears.
It moves.
Writing less can demand understanding more
When I carry out a fairly simple task myself, I can move forward gradually and adjust my decisions as I write.
When I want to delegate that same task to an agent, I often need to be much clearer from the start about what I expect.
What's the actual problem?
What's the scope?
Which constraints are non-negotiable?
What can be changed?
What counts as an acceptable result?
And above all: which decisions am I willing to let the agent make?
Delegating effectively therefore relies on a skill that's nothing new in engineering:
knowing how to break down a problem before distributing its execution.
Experience changes its function
My years spent developing, integrating systems, working across different architectures, or operating applications no longer serve only to know how to write a solution.
They also serve to determine whether a proposed solution is reasonable.
To recognize an unnecessarily complex architecture.
To sense when an abstraction shows up too early.
To identify that a problem presented as local actually reveals a deeper structural weakness.
To understand that a solution that's correct in one environment will become problematic in another.
This experience is the reference against which I evaluate what the agent proposes to me.
The developer doesn't disappear behind the agent, then.
Their center of gravity can shift instead: more time spent designing than implementing, more time framing than detailing, more time checking behavior than following every instruction that produced it.
This doesn't mean every developer will become an "orchestrator," nor that knowing how to code will become useless.
That would basically repeat the same misunderstanding that fueled the original vibe coding discourse: confusing the automation of part of the work with the disappearance of the skill needed to master it.
I'd put it this way instead:
orchestration is becoming an additional development skill.
And perhaps an increasingly important one.
As the ability to produce code becomes abundant, value naturally shifts toward the ability to decide which code deserves to be produced, in which system, under which constraints, and with what level of confidence.
So, am I doing vibe coding?
I can now come back to the sentence that triggered this whole reflection:
"I'll do like you, vibe coding, using…"
Looking back, I fully understand why my friend used that expression.
He sees agents producing a large share of my code. Tools capable of exploring a project, proposing solutions, implementing them, and sometimes carrying a task almost all the way to completion.
But no, that's not really what I'd call vibe coding.
Not because I want to draw a line between those who "really" know how to develop and everyone else.
Simply because the term no longer adequately describes what's actually happening.
In its original sense, vibe coding specifically accepts letting go of a detailed understanding of the code produced.
In my practice, I can instead delegate its production massively without wanting to delegate mastery of what I'm building.
I shift my attention toward the problem, the context, the constraints, the structural choices, the checkpoints, and the result.
And this relationship isn't one-way.
The agent produces, explores, questions, and reveals some of my blind spots.
My experience lets me frame its work, challenge its proposals, and identify some of its own.
That's why the term that best fits my current practice is probably orchestration.
Not because I've become a conductor watching machines work in my place.
But because my job increasingly consists of organizing a set of capabilities — human and artificial — to solve a problem and build a solution I remain able to understand and take responsibility for.
The nuance may seem thin when you only look at who writes the code.
For me, it changes almost everything.
Sources
- Andrej Karpathy, February 2, 2025 post introducing the term "vibe coding."
- Andrej Karpathy's later reflections distinguishing vibe coding from professional use of AI coding assistants.