How Exactly Professional Software Developers Use AI Coding Agents

As AI agentic coding tools have improved, more and more professional developers are reporting that they feel happier when agents (Cursor, Claude Code, etc.) complete their tasks successfully and save them time. When the AI-generated solutions are correct and usable, developers enjoy working with agents more than without. Many say that agents have made coding fun again, because they can finally resume work they previously lacked the energy or time to do, and they are experiencing less stress. Software developers and data analysts with over a decade of experience are increasingly saying they will never go back to coding by hand, because "that ship has sailed".  Some developers even claim their productivity has increased ten-fold. But how exactly do professional software developers use and control AI agents? This question was the focus of research presented in the paper "Professional Software Developers Don't Vibe, They Control: AI Agent Use for Coding".

They Control Architectural Decisions and Code Changes

All professional developers working with AI agents keep control of the process - period. Nobody just lets the agent run wild.

That said, the tasks they give agents vary widely: building new features (which requires planning design and architecture) versus fixing bugs (where the design already exists - you just find what broke and patch it).

How developers work with agents when building a new feature

Most figure out the design plan themselves first, then hand that plan off to the agent. This is especially true when:

• You're working for a client with specific requirements
• The project has proprietary info you can't fully share with the agent
• It's just faster to do it yourself than explain everything and then fix what the agent screws up

Some developers take a different approach. They ask the agent to draft a plan first, then revise it themselves. This makes sense when you're not super familiar with the domain you're working in and want the agent's ideas as a jumping-off point.

When developers aren't familiar with the domain, they may ask the agent to sketch out a plan for building the feature. Then they vet it using their general engineering know-how.

What are they checking for? The plan needs to break down the coding work into small, sequential steps. So they can test integration after each step to make sure the new code plays nice with the existing codebase, and, if something breaks, they know exactly where to look.

Professional developers read AI code carefully, even when the amount of code is large.

They also watch what else the agent tries to do. For example, they may reject unnecessary dependencies the agent wants to install.

And if something breaks, many developers debug and dig through the code manually to figure it out themselves instead of asking the agent to fix it. Sometimes it's faster than re-explaining the issue to the agent.

By the way, if a developer reviews the code and makes changes, they need to tell the agent what they changed so it doesn't lose context. Otherwise the agent won't account for those changes down the line.

Some developers, by the way, use the agent not for writing code, but only for explaining unfamiliar architecture in existing applications and for creating diagrams to visualize the structure. This means that if a developer is handed an application for updates that was previously developed by other engineers and needs to quickly get up to speed on how it is built, this is an optimal use case.

They use Effective Prompting Strategies to Control Coding Agents

The more detail you put into a prompt, the more control you keep and the less cleanup you need later.

Professional developers always keep the prompt focused on one thing: a small, specific modification. 

They use prompts with maximum information, including file, function, and variable names, as well as full texts of error messages. 

When they modify existing code, they constantly try to remove ambiguity. 

For example, they may mention what data types they expect to see, what specific libraries they want to use, what domain objects they expect to alter (app-specific entities). They also describe what the UI should do when someone takes an action, such as clicking the Submit button. 

Their prompts clearly state what the LLM should look at through file references, what they want the agent to do, and how the output should look. They can toss in screenshots or code examples to show what they want. 

After mentioning all these details in the prompt, they may ask the agent to "do just step 1 now from TASKS.md" at the end. That stops the agent from racing ahead. 

Modern LLM models behind coding agents can switch to extended thinking mode. However, developers may still additionally ask for step-by-step thinking in their prompts to make the agent reason out loud, rather than work in fast mode. This lets engineers control the reasoning process. They can see the agent’s thought process before any code gets written.

Coding agents work well with knowledge bases, both internal and external, that are accessible through MCP servers. For example, Context7 MCP Server pulls up to date, version specific documentation about the libraries you use and code examples straight from the source and places them directly into your prompt, so you do not have to search for and copy-paste docs yourself.

Professional developers don't limit themselves to just the coding agent. They open, for example, ChatGPT separately first to brainstorm, get explanations, and refine their prompt. Only after that do they go to the coding agent and drop in the polished prompt.

Professional developers use a coding agent configuration file to avoid repeating the same instructions in every coding session, and for new projects. This file contains rules the agent must consistently follow. 

These aren't rules you write once and forget - the file needs to be updated periodically. 

Most often this custom settings file is refined to remove ambiguous interpretations for the agent and correct the agent's behavior based on past mistakes caused by its default system prompt. 

It may include:

•  Project requirements (for example, "always use TypeScript", "use only this library and don't use that one") 
• Coding rules ("always write clear variable names", "always add comments", "make code readable", "write tests for every function")

Is there one ready-made prompt that professional developers can share with each other or with non-professional coders so they can use it? No, because prompting is an individual thing. 

What matters is understanding the prompting strategy, not copying someone's prompts. 

Through self-teaching, trial and error, and feedback, each developer individually breathes life into this prompting strategy with specific content adapted to their own needs. 

Those who experiment with agents more often and more consistently see higher effectiveness in their AI-assisted coding work. They become more productive than those who don't actively work with coding agents, even though they are becoming the new normal.

One question remains:

• should you work in one long chat, continuing the same conversation (since that's supposed to make it easier for the agent to hold context with all the details), 
• or open new windows for each task? 

Long chats make it convenient to work interactively, but tasks may drag on longer since the agent has more load to handle. Plus it gets more expensive - every request processes the entire long context, burning through API tokens faster. 

With new windows, the problem is you lose the conversation history for the task. 

How to deal with this in each specific case - each engineer decides individually.