Vibe Coding vs Prompt-Driven: One Year Later, the Debate Is Already Outdated

A little over a year later, I still think this distinction was relevant. But it no longer suffices to describe what is happening. The debate is no longer just about whether to "vibe" or write better prompts. In the meantime, development agents have profoundly changed the way we work. The real issue is now much broader: it's no longer just about how to talk to an AI, but about the environment in which we make it work.

My 2025 Article Wasn’t Wrong, It Just Belonged to Another Era

When I reread what I wrote at the time, I see above all how quickly our way of using AI has evolved. In 2025, much of AI-assisted development still relied on a conversational logic. You asked for a feature, the AI proposed code, you copied it into the project, encountered an error, and then returned to the conversation to ask for a correction.

In this context, the quality of the request was extremely important. The more context you provided, the more you detailed the constraints and precisely described what you expected, the more you increased the chances of getting a usable response. This is what led me to contrast Vibe Coding with a more structured approach.

Today, this representation already seems almost limited to me. When I work with a development agent, I no longer simply ask it to produce code. I give it access to a project, its files, its conventions, its tests, its tools, and sometimes other agents. I give it an environment in which it can explore, modify, verify, and start over.

The difference may seem slight in formulation, but it profoundly changes the nature of the work.

Vibe Coding Remains Extremely Effective

It’s important to start by recognizing something: Vibe Coding works very well in many cases. For prototyping an idea, experimenting quickly, building a personal tool, or testing a technology, it’s hard to be faster. You describe what you want to achieve, the AI produces something, you check if it meets the need, and adjust progressively.

In this context, immediately seeking a perfect architecture or complete test coverage can even be counterproductive. It all depends on what you’re building and, above all, the expected lifespan of the project.

The problem arises when this exploration logic becomes the main development method for software intended to last several years. A program can work perfectly today while being fragile, difficult to maintain, or incomprehensible a few months later. A feature can produce the right result while introducing a poor abstraction or a security flaw. An agent can also complete a task by modifying far more than was actually necessary.

This is where the observation from my first article remains valid: getting something that works is not the same as building something you understand and can maintain.

The Prompt Has Lost Much of Its Central Status

For a long time, many discussions around generative AI in development revolved around prompt engineering. We explained that you had to learn how to talk to models, structure requests, define roles, provide examples, and detail each step.

These best practices haven’t disappeared, but in my way of working today, the prompt is far from being the most important part of the system. I can send a fairly simple instruction like "fix this bug and add the necessary tests" and trigger a much more complex sequence of work behind it.

The agent will explore the repository, identify the relevant files, search for how a similar feature is implemented elsewhere, modify several files, run commands, execute tests, analyze their results, and then correct its own work. At this stage, the quality of the result no longer depends solely on the sentence I wrote at the start.

It depends mainly on what the agent finds around it.

If it correctly understands the architecture, knows the project’s conventions, has relevant tests, and can use the right tools, a relatively short instruction may suffice. Conversely, the best prompt in the world will never fully compensate for a poorly documented project, without tests, and filled with implicit rules that only the team knows.

This is why the debate about prompts seems much less interesting to me today than the one about context and the work environment.

The Repository Also Becomes a Tool for the AI

This is probably one of the most important changes of the past year. When I build a project heavily assisted by agents today, I no longer think only about what human developers need to understand. I also think about what agents need to understand without having to reinvent everything for each task.

This changes how we document a project. Conventions, architectural decisions, useful commands, security rules, or business behaviors are no longer just documentation for a developer joining the team in six months. They become directly usable by the agents working daily on the code.

Files like AGENTS.md, well-maintained internal documentation, implementation examples, automated tests, or validation scripts thus take on new value. They still serve humans, but they also become part of the AI’s operational context.

We are thus gradually starting to design the repository as an environment capable of explaining itself how it should be modified.

And in my opinion, this is much more interesting than seeking the perfect prompt.

More and More, I Talk About Development Harnesses

I increasingly use the word "harness" to describe this environment. The image seems quite accurate to me: a model can be extremely powerful, but this power must be channeled if you want to use it on a real project.

An agent can propose an excellent solution. It can also invent an API, take a wrong business assumption for a truth, or consider a task complete simply because its code compiles. Its main problem isn’t necessarily a lack of capability. It’s often a lack of constraints and feedback.

The harness serves precisely to reduce this uncertainty space.

Git lets you see what has actually changed. Tests provide objective feedback on certain behaviors. Linting prevents certain stylistic or structural drifts. Documentation provides the necessary context. Tools allow searching for real information rather than letting the model guess. Rules define what is allowed, what is forbidden, and what requires human validation.

Taken separately, none of these elements are new. Git, tests, and documentation obviously existed long before LLMs. What changes is that they are now becoming direct components of the agents’ work system.

In 2025, I thought a lot about the quality of the instruction given to the AI. In 2026, I think much more about the quality of the system surrounding it.

A Poor Environment Pushes the AI to Invent

Let’s take a simple example. You ask an agent to modify a relatively complex business feature. You can spend a lot of time writing a detailed request, but if the project contains no business documentation, few tests, and many implicit conventions, the agent will have to fill in the gaps.

And this is precisely what models know how to do.

The problem is that in software development, completing what seems probable isn’t always what we want. We don’t just want a plausible answer. We want an answer compatible with the reality of the product, its history, and its constraints.

Conversely, when a project contains clear documentation, coherent tests, and explicit rules, the agent can work with much simpler instructions. It has enough elements to verify its hypotheses instead of having to invent them.

This is an important evolution in my own way of working: when the AI makes a mistake, my first reaction is no longer systematically to rewrite the prompt. I first ask what was missing in the environment for it to make that bad decision.

Sometimes, a rule needs to be added. Sometimes, a test needs to be written. Sometimes, an architectural decision needs to be documented. Sometimes, the agent simply needs to be prevented from accessing certain actions.

In all cases, we improve the system rather than the conversation.

Code Has Become Abundant, Not Good Software

There’s also an economic transformation behind all this. For a long time, writing code represented a significant part of development costs. Producing an implementation required time, sometimes a lot of time, and the ability to quickly produce correct code obviously had great value.

With agents, the cost of this production collapses.

Generating several variants of an implementation is no longer really a problem. Rewriting part of a component, creating tests, or producing a migration can now take a few minutes where it previously represented a much larger amount of work.

But this doesn’t mean that producing good software has become easy.

Software isn’t just code. It’s made up of history, business decisions, dependencies, security constraints, performance, users, and sometimes compromises that seem strange if you don’t know their origin.

This is where the difference between producing code and building software becomes even more visible.

Code has gradually become abundant. Technical judgment, however, remains rare.

The Developer’s Job Isn’t Disappearing, Its Center of Gravity Is Shifting

The question "Will AI replace developers?" seems less and less interesting to me. It assumes that the profession is a homogeneous activity that could be automated in one go.

The reality is much more gradual.

Some tasks are already largely absorbed by agents. Creating a CRUD, adding a simple endpoint, writing a migration, generating basic tests, refactoring repetitive code, or exploring an unknown repository have become much faster.

This doesn’t mean the developer no longer has a role. It mainly means that their value is shifting toward parts that the agent handles less well: understanding the real problem, correctly breaking down the work, choosing an architecture, identifying invisible constraints, recognizing an unnecessary abstraction, or deciding that a technically correct solution is bad for the product.

It’s also necessary to decide what you want to automate and, sometimes more importantly, what you don’t want to automate.

The more capable agents become, the more valuable this decision-making ability becomes.

Knowing How to Code Remains Essential

There’s an interesting paradox, though. The more easily agents produce code, the more some consider it unnecessary to understand that code.

I think exactly the opposite.

When I work with several agents, I can generate many more changes in a day than before. But this also means I have to evaluate many more technical decisions. The speed of production increases, so the validation capacity must increase with it.

The bottleneck is no longer necessarily writing.

It’s gradually becoming understanding.

An agent can generate several hundred lines of code very quickly. This doesn’t mean they should exist. It can propose a coherent architecture that isn’t adapted to the product. It can also write perfectly green tests that don’t actually verify the important behavior.

And above all, it can explain with great assurance why all this is correct.

This explanation is still not proof.

Git, Diffs, and Tests Become Even More Important

This is perhaps one of the most interesting paradoxes of agentic development: the more modern the tools become, the more certain development fundamentals become important.

Git is more useful than ever. Diffs are more useful than ever. Tests are more useful than ever.

When an agent tells me a feature is complete, it’s not really that statement that interests me. I want to know which files have changed, which dependencies have been added, which commands have been executed, and which behaviors have actually been verified.

I also want to be able to understand what happened several weeks later if something breaks.

In a world where generating code costs less and less, traceability becomes paradoxically more valuable.

The developer must be able to reconstruct the technical reasoning behind the modifications, even if much of the production has been automated.

The Next Challenge Will Be Agent Supervision

We’re still at the beginning of this transformation. Today, many developers mainly use one agent in a terminal. But we’re already seeing environments where several agents work simultaneously on different parts of a project.

One agent can handle the frontend while another works on the API. A third can analyze tests, a fourth verify changes, and another search for documentation or analyze a problem reported in production.

At this stage, the problem becomes very different from Vibe Coding.

You need to know which agent did what, understand why a decision was made, prevent multiple agents from modifying the same files simultaneously, and ensure that context circulates correctly between them. You also need to be able to detect when an agent is looping, when a sub-agent wasn’t actually launched, or when a step supposed to be automated ultimately wasn’t.

We’re thus starting to touch on issues close to orchestration, observability, and supervision.

And here again, the prompt is no longer the main subject.

We’re Moving from "Coding with AI" to "Architecting the AI’s Work"

If I had to summarize this evolution in one sentence, it would probably be this: in 2025, I was mainly learning to code with AI; in 2026, I’m mainly trying to architect how it works.

In the first model, the AI is essentially a tool that the developer queries. In the second, it becomes an actor in the development system. It has context, tools, responsibilities, constraints, and sometimes the ability to delegate part of its work.

The developer’s role is then gradually approaching that of an architect or orchestrator. It’s no longer just about producing each line of code yourself, but about building an environment in which agents can produce, verify, and correct their work while remaining under control.

This requires a different skill.

Not necessarily less technical.

Probably even the opposite.

So, Vibe Coding or Prompt-Driven?

A year later, I would therefore answer the question that was at the heart of my first article differently.

Vibe Coding remains an excellent exploration method. A structured approach is still preferable when you want more control, security, and maintainability.

But I no longer think this opposition correctly describes the future of AI-assisted development.

We’re entering a third phase, where the quality of the result depends less and less on an isolated prompt and more and more on the entire system around the model. Context, tools, tests, rules, memory, observability, and validation mechanisms become essential elements of the process.

The developer must therefore no longer just learn how to ask something correctly of an AI.

They must learn to build the conditions in which this AI can work correctly.

And this is probably where the real breakthrough lies today.

In Vibe Coding, you trust the result because it seems to work.

In a mature agentic approach, you try to build a system capable of giving you good reasons to trust it.

---

This article follows up on my analysis published in June 2025: Vibe Coding vs Prompt-Driven: Two Approaches to Generative AI for Development. A little over a year later, it mainly constitutes an interesting snapshot of how quickly our way of developing is changing.