Vibe coding: why senior developers should lead this revolution, not fight it

Artificial intelligence is changing the way we build software.

And, as with almost every major shift in the tech industry, it is also meeting resistance.

One of the most debated ideas right now is vibe coding: using AI models to generate a significant share of the code from instructions, context and iterations in natural language.

For some developers, especially those with many years of experience, this approach can look dangerous.

And, to some extent, they are right.

But that is not the whole story.

The real problem isn't vibe coding

There is a huge difference between someone with no technical background asking:

“Build an invoicing system.”

and an architect or senior developer explaining:

“I need this service under this architecture, using these patterns, following these authentication policies, with unit tests, exception handling, observability and these security criteria.”

Both people are using artificial intelligence.

But they are not doing the same thing.

Technical knowledge is still essential, because AI can produce code that is syntactically correct and still a bad decision from an architecture, security or maintainability standpoint.

Developers themselves recognize it.

The 2025 Stack Overflow survey, with more than 49,000 participants, showed that 84% use or plan to use AI tools in their development process. Among professional developers, about 51% were already using them daily.

Trust, however, is not growing at the same pace. 46% said they don't trust the accuracy of these tools' answers, and 45% named as a frustration that debugging AI-generated code can be time-consuming.

To me, that data doesn't show that AI has failed.

It shows exactly the opposite: we need human expertise on top of AI.

Does AI really make development faster?

The responsible answer is: it depends.

That matters, because exaggerated claims are everywhere.

A controlled experiment published by Microsoft Research studied developers who had to implement an HTTP server in JavaScript. Participants with access to GitHub Copilot finished the task 55.8% faster than the group without the assistant.

It is an impressive result.

But there is evidence pointing the other way.

METR ran an experiment with 16 experienced developers working on 246 real tasks in mature repositories they had known for years.

The result was surprising: with the AI tools available in early 2025, they took 19% longer.

METR itself now warns that the study is a snapshot of early 2025 and that it no longer considers it necessarily representative of what today's tools can do.

So: does AI make a developer 55% faster or 19% slower?

Both can be true.

Because software development is not a uniform activity.

Writing boilerplate, tests, a simple API, documentation or certain repetitive components is not the same problem as changing a million-line platform with ten years of architectural decisions behind it.

That is exactly one of the big mistakes in the vibe coding debate.

Not all vibe coding is the same

Consider two scenarios.

Scenario 1

Someone describes an application superficially. The AI generates hundreds or thousands of lines of code. It works. It ships.

Nobody really reviews:

• architecture,
• security,
• dependencies,
• patterns,
• scalability,
• observability,
• quality,
• tests,
• technical debt.

This kind of vibe coding can indeed be dangerous.

Scenario 2

A senior developer or architect designs the solution first.

They define the architecture, technologies, standards, constraints, security criteria and integration approach.

Then they use AI to speed up the implementation.

And finally they put the code through tests and additional reviews.

That is vibe coding too. But it is a completely different discipline.

In this scenario, AI writes more of the code, but the human keeps the engineering responsibility.

From prompts to Skills, and from Skills to agents

This, to me, is the really interesting change.

The future of AI-assisted development probably won't be only about writing better prompts.

It will be about building systems of context, Skills and specialized agents.

A Skill can teach the AI environment how we want a given activity done:

• how we structure a project,
• which patterns we allow,
• how we build an API,
• which standards we follow,
• how we document,
• how we test,
• which checks must run before code is accepted.

And around those instructions we can add specialized agents. For example:

• Architecture agent: checks whether the implementation respects the project's architectural decisions.
• Security agent: looks for issues with authentication, authorization, secrets handling, input validation and common vulnerabilities.
• Quality agent: evaluates complexity, duplication, maintainability and consistency.
• Testing agent: generates and runs unit tests, integration tests and edge cases.
• Documentation agent: keeps the README, technical docs, APIs and key decisions in sync with the code.

So the workflow changes.

Before: design → code → test → document → review.

Now we can move toward: design → delegate → generate → test automatically → review with agents → validate as a human → deploy.

AI stops being just a code generator. It becomes an execution layer inside the engineering process.

Seniority doesn't lose importance: it changes where it adds value

For years we associated part of seniority with the ability to write code quickly.

But writing code was never a senior developer's real differentiator.

Their value lies in knowing what to build, how to build it, what not to build and what consequences each decision will have.

A senior developer understands why a given architecture may cause problems three years from now. They know where to introduce abstractions and where to avoid them. They recognize security risks. They understand performance. They can assess technical debt. They can anticipate operational problems.

And they have something particularly hard to give an AI model: context.

That's why I think it is a mistake for some experienced professionals to see AI only as a threat.

They are precisely the ones with an extraordinary advantage in using it.

The new senior developer can become an orchestrator

Anthropic analyzed 500,000 coding-related interactions and found that, in Claude Code, 79% of conversations were classified as automation, versus 21% as collaboration or augmentation.

That points to an interesting shift. More and more tasks will be fully delegable to agents.

But automating a task is not the same as automating responsibility for a system.

Someone has to set the limits. Someone has to review. Someone has to decide whether an implementation makes sense.

That is where I believe the senior developer's job will evolve. From “I write every line of the system” to “I design how the system should work, set the rules, delegate parts of the implementation and verify the results”.

That doesn't reduce their importance. It increases it.

We shouldn't only measure how much code AI generates

There is another risk.

We can generate ten times more code without being ten times more productive. We could even end up less productive if we increase bugs, rework, vulnerabilities, technical debt, complexity and maintenance costs.

That's why organizations should measure engineering outcomes, not just lines generated. Some far more useful metrics:

• Lead time: how long it takes from a need to production.
• Cycle time: how long the team actually takes to implement a change.
• Deployment frequency: how often we can deploy safely.
• Change failure rate: how many changes cause incidents or rollbacks.
• Code review time: how much human effort the generated code still needs.
• Post-deployment defects: whether we are building faster but also introducing more errors.

This is probably where we will find the real ROI of AI-assisted development.

So, vibe coding: yes or no?

My answer is: yes, but professionalized.

I don't believe in replacing engineering with prompts. I believe in applying engineering to prompts, context, Skills and agents.

I don't think it's a good idea to accept any code because “the AI wrote it”. I think human review will matter even more as we generate code faster.

And I don't think senior developers should fight this transformation either. I think they should lead it.

Because someone who understands architecture, security, cloud, DevOps, patterns, APIs and operations has enormous capacity when they can also delegate part of the mechanical work to AI agents.

The equation then stops being AI vs. developer and becomes:

Experience + AI + Skills + Agents + Automation + Human review.

AI doesn't necessarily eliminate the developer. It amplifies the good developer.

We will probably see teams able to deliver in weeks projects that used to take months. That doesn't mean dropping quality controls to ship sooner. It means using AI to cut the time spent on mechanical tasks and putting more human capacity into the decisions that really matter: architecture, security, user experience, operations, innovation and business.

Code was always a means to build those solutions. It was never the goal.

So instead of asking whether vibe coding will replace developers, maybe we should ask a different question:

How productive can a great developer become once they learn to work really well with artificial intelligence?

I think we are only beginning to find out.

References

• Microsoft Research: The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. A controlled experiment that observed a 55.8% time improvement on a specific task.
• METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. Found a 19% increase in time in its experimental setting; METR has since published newer results from early 2026.
• Stack Overflow 2025 Developer Survey: AI. More than 49,000 responses with data on AI adoption, trust and agents.
• Anthropic Economic Index: AI's Impact on Software Development. An analysis of 500,000 development-related interactions.