Professional developers don't vibe with agents — they control them

A couple of years ago, the only job an LLM held in programming was autocomplete: the model suggested a line, finished a function, reminded you of the syntax. By 2025 the focus had moved. Agentic tools arrived that don't advise but act — they read a project, edit files and run the tests.

Told that way it sounds effortless: describe the task in plain language and the code appears. Online the approach has a name — vibe coding: you hand it to the agent and don't read the diff. In professional work the cost of a mistake is higher: quality, security, fit with the architecture and with what the team expects. The authors of Professional Software Developers Don’t Vibe, They Control: AI Agent Use for Coding in 2025 set out to find how experienced developers actually use agents — and why vibing barely survives contact with production.

What the authors set out to find

Agentic coding attracts contradictory claims. Some people announce they will never write code by hand again. Others try it once, hit a bad refactor, and shelve the tool "for later". Meanwhile individual studies have turned up surprising results: experienced developers sometimes finished tasks slower with AI, and autonomous agents in real pipelines carried only a small share of changes through to the end.

So the goal here is not to argue about technology in the abstract but to look at practice: how experienced developers actually fit agents into their work, which tasks they delegate, and where they keep their distance. And above all, what lets them hold on to quality without giving up speed.

The method: closer to real work than a lab test

The study came in two parts.

First, the observation sessions: 13 developers with 3 to 25 years of experience worked on their own real tasks in their usual setup. The researchers watched for 45 minutes with screen and audio recording, then spent another 30 minutes on an interview. The detail that matters: nobody was solving a toy exercise. Participants brought work and personal projects — production code, R&D, side projects.

Second, a qualitative survey of 99 experienced developers, to check whether what showed up in individual sessions matched the wider picture.

That design picks up nuance: not only whether something worked, but how people think, where they stop trusting the agent, what they put in their prompts, how they check the result.

What an agent looks like in professional hands

The paper's central finding reads almost like a slogan: professional developers don't vibe code — they control the agent.

Rather than simply handing the task down, developers:

• plan up front: pin down the requirements, the scope of the change, what counts as done;
• break the work into separate tasks so the agent doesn't lose the thread;
• validate continuously: read the diffs, run the tests, check the logic, hold it against the architecture;
• treat the agent as an accelerator for routine work while keeping the decisions where quality attributes are at stake: reliability, readability, maintainability and security.

The agent is not an autopilot. It's an executor that needs a clear brief and careful acceptance of its work. The higher the stakes — production, critical components — the tighter the control.

Where agents genuinely help

In the participants' experience, agents are strongest on well-specified, straightforward tasks, where it's clear both what has to be done and how to verify it. Adding a small piece of functionality cleanly, making standard edits, generating boilerplate, helping with tests, wiring together the obvious parts.

The risk starts elsewhere:

• complex changes that require a deep grasp of the domain and the project's context;
• architectural decisions, where the trade-offs and long-term consequences matter;
• situations where the agent would need a stable model of the world: the system as a whole, cause and effect, the constraints of the infrastructure and the team.

In those places developers either skip the agent or use it in small doses — as someone to think out loud with, not as the author of the final solution.

Why the mood is positive anyway

What's interesting is that all this caution doesn't come with panic or disappointment. The opposite: most participants see a real gain in productivity, and even enjoy the work more — as long as control stays with the human. Many are confident that their engineering skills and good development practice cover the agent's weak spots, through checking, testing, review, and discipline in how tasks are set and results accepted.

Which leads to a fair demand on the industry: better interfaces for agentic tools, and clear guidance on using them in teams without eroding quality.

What follows from this

The work brings the agentic coding conversation back down to earth. In a professional setting, the agent is a new tool. Experienced developers are willing to delegate execution to a machine; they are not willing to hand over responsibility for architecture and quality.

And the most practical point in the paper is probably this: what decides the outcome is not having the smartest agent, but how well you manage development itself — specifying tasks, bounding the context, checking, testing and accepting changes.