AI tools and agents are no longer something developers are just experimenting with. Tools like Codex, Claude, Cursor, and GitHub Copilot are already used to generate code, explain unfamiliar files, suggest refactors, write tests, and automate repetitive implementation work.
Everywhere you look, someone is talking about how much more they can do with AI. Productivity is up tenfold. Work that used to take months can now be done in a week. At least, that is the story we keep hearing.
And the productivity boost is real. You can see it yourself with one of the many freely available AI chatbots. Ask it to write a function that solves a moderately complex problem in your language of choice, and more often than not it will produce usable code in a few minutes. Without AI, that same task might have taken a couple of hours, or half a day on a slow day.
But this is where the discussion often goes wrong. People see code being produced faster and treat that as productivity. More agents, more code, more output, more productivity.
The problem is that this is a very narrow way to think about productivity.
Software productivity is about the whole development process
Software development is not a factory line where productivity can be measured by how many units come out at the end of the day. In a factory, the units are standardized. One unit is comparable to the next.
In software development, each task is different. A small code change may require days of investigation, while a large change may be straightforward. One design decision may reduce future complexity, while another may create years of maintenance cost.
So output alone is a poor measure. We are not counting identical units. We are comparing work that differs in complexity, risk, value, uncertainty, and long-term impact.
A better way to think about software productivity is process efficiency. Not producing more code in less time, but improving how quickly and safely a team can understand the problem, make good decisions, implement a solution, verify that it works, ship it, and maintain it afterward.
If implementation becomes faster but review, testing, debugging, or maintenance becomes slower, the team has not necessarily become more productive.
Software development productivity should not be measured by how many features are shipped, how much code is produced, or how much AI is used. It should be measured by whether the team can deliver valuable, reliable, maintainable software with less waste, less rework, less confusion, and less unnecessary risk across the whole process.
This is why team productivity is most meaningful when measured against the same team’s past performance. Comparing different teams is much harder, because the work, context, codebase, constraints, and risks are rarely the same. A perfectly fair comparison would require giving two teams the same work under the same conditions, but that would be a waste of time for the organization.
AI does not change who owns the code
AI agents can reduce the cost of implementation, but they do not remove the overall cost of software development. Engineers still have to understand the requirements, make design decisions, review the changes, verify the behavior, and deploy safely.
If an engineer accepts AI-generated code, they are also accepting responsibility for it.
Before AI agents, code ownership was usually easier to trace. Developers were responsible for the code they wrote, reviewed, and integrated into the system. When a change caused a problem, the basic questions were familiar: who wrote it, who reviewed it, and who approved it?
AI agents do not make those questions disappear.
What has changed is the distance between the developer and the change. The developer is no longer always building it line by line. Sometimes the implementation arrives as a finished diff from an agent that inspected the codebase, made decisions, and modified several files.
The developer may not have written every line, but they still have to understand the change well enough to approve it. That means AI-generated code often requires more care, not less. Developers need to review it, test it, and verify its assumptions. They cannot rely on the fact that the code looks right or that the AI produced it confidently.
This is where pressure creates a dangerous incentive. When teams are pushed to use AI tools heavily, developers may be tempted to treat AI-generated code as someone else’s responsibility. It can start to feel like something the organization wanted, the manager encouraged, or the process demanded.
But organizational pressure does not make ownership disappear. A manager may have encouraged the use of AI, and the process may have rewarded faster output, but the engineer still accepted the change. The team still merged it. The organization still shipped it.
AI can generate code, but it cannot own code. And I do not expect the companies building AI tools to take on that responsibility either. They may provide the model, the editor, or the agent, but they will not own the production consequences of the code their tools generate.
Different ways developers delegate to AI
Developers are not all delegating the same amount of work to AI. Some use it like a smarter search engine. Some use it as autocomplete. Some use it as a coding assistant inside the IDE. Others are already orchestrating agents across larger parts of the development workflow.
These are not just different tools. They are different levels of delegation.
The first pattern is the developer who mainly works with a chatbot, whether that is ChatGPT, Gemini, Claude, or something similar. The developer asks questions, pastes code, copies useful parts of the answer, and applies the result manually.
This works surprisingly well for many tasks. The chatbot has limited context, but for isolated questions, small changes, explanations, examples, and debugging hints, that is often enough. The developer still controls the process. They decide what context to provide, which answers to trust, and what code to copy into the project.
The second pattern is the developer who uses AI mostly as autocomplete. Instead of having a conversation with the tool, they stay in the editor and move faster. If the AI can complete a line, a block, a test, or a small implementation detail before they finish typing it, great.
This workflow has less friction because the developer does not have to leave the editor. The AI is close to the code, but the developer is still leading. The tool accelerates implementation, but it usually does not decide the direction of the change.
The third pattern is the developer who uses an AI agent inside the terminal or IDE. At this level, tools like Claude Code, Codex, Gemini CLI, Cursor, and similar products can inspect files, propose changes, run commands, generate tests, and modify the codebase directly.
This is where the relationship changes. The AI is no longer only answering questions or completing code. It is acting on the codebase. It has more context, more autonomy, and can produce changes the developer did not write line by line.
The fourth pattern is the developer who orchestrates agent work. Instead of asking one tool to complete one task, they coordinate multiple agents or multiple runs of the same agent. One run may investigate the codebase, another may implement the change, another may write tests, and another may review the result.
This can be powerful, but it also increases the distance between the developer and the change. The more work is delegated, the more important it becomes to ask whether the developer still understands the result well enough to review it, approve it, and own it.
That is why the question is not only which AI tool a developer uses. The more important question is how much work they delegate, how much control they give up, and how much understanding they keep.
So who is actually more productive?
The easy answer is to point to the developer who orchestrates agents. They delegate more work, produce more output, and spend less time writing code by hand. From the outside, that looks like the highest level of productivity.
But that answer is too simple.
Each workflow creates efficiency in one part of the process and cost in another. The chatbot user may move slower, but they stay close to the code. The autocomplete user gains speed without leaving the implementation flow. The agent user can move much faster, but they also have to review larger changes and verify the tool’s assumptions. The agent orchestrator may get the biggest implementation boost, but they also create the biggest ownership challenge.
A workflow that produces code quickly but increases review time, debugging time, integration risk, or maintenance cost may not be more productive at all. It may simply be moving the work from writing code to understanding code. And understanding requirements and code is not trivial.
There is another cost that is easy to ignore: giving the AI enough direction.
If you want an AI agent to produce a safe, useful, and maintainable change, you often need to describe the task clearly. You may need to explain the expected behavior, list edge cases, define what should not change, describe the existing architecture, and sometimes write the unit tests first. That work is not free.
In that workflow, the cost moves into requirements definition. The developer spends less time writing the implementation, but more time defining what the implementation should do. This can be a good trade-off. In fact, it is often the right trade-off. Clear requirements and good tests are valuable even without AI.
The other option is to give the AI agent a broader goal and let it decide more of the path by itself. The prompt is shorter, the agent does more, and the developer does less upfront work. That can feel productive at first, but the cost usually moves into quality assurance.
Now the developer has to check whether the AI understood the problem correctly, whether it made reasonable assumptions, whether the tests actually test the right behavior, and whether the implementation matches the real requirement rather than the agent’s interpretation of it.
This is why AI productivity is not only about how quickly the first version appears. A fast implementation is not useful if the team later spends the saved time discovering misunderstood requirements, weak tests, hidden regressions, or code that works only for the happy path.
There is no magic workflow where the cost disappears. You can pay the cost upfront by writing clearer instructions and tests, or you can pay it later through careful review and quality assurance. The productive workflow is the one where the cost is placed where it is easiest to control.
There is also a human problem we do not talk about enough: watching an AI agent work is boring.
At first, it feels impressive. The agent reads files, runs commands, edits code, writes tests, and explains what it is doing. But after a while, the developer is just sitting there, waiting. The work is happening, but the developer is not fully working either.
A developer watching an agent is not in the same mental state as a developer writing code. They are not fully engaged in implementation, but they also cannot completely disengage, because they still need to monitor the result. It is a strange middle state: too passive to be satisfying, but too responsible to ignore.
That can become demotivating. Software development is not only about output. It is also about attention, flow, curiosity, and momentum. When the developer spends too much time waiting for agents, reviewing large diffs, and trying to reconstruct why a change was made, the work can start to feel less like engineering and more like supervising a slow and unreliable intern.
This also belongs in the productivity calculation. If AI saves implementation time but makes the developer more bored, distracted, detached, or mentally tired, then the workflow may not be as efficient as it looks. A process that produces more code but reduces the developer’s ability to stay engaged and make good decisions has a real cost.
That is one reason why running multiple prompts can feel attractive. While one agent is working, the developer can start another task. But this only helps up to a point. After that, the developer is not avoiding boredom. They are creating context switching.
The productive use of AI agents has to consider the human operating the system. If the workflow turns the developer into someone who waits, watches, and cleans up after agents all day, then something is wrong. The best AI workflow should make the developer feel more effective, not more detached from the work.
Conclusion
The productive way to use AI agents is not to maximize automation. It is to reduce waste while keeping ownership clear. And it is not necessarily to run only one prompt at a time. Parallelism can be useful.
But there is a limit.
The developer must still be able to understand, review, and own the result of each task. If running multiple prompts means losing track of what each agent is doing, why it is doing it, or what assumptions it made, then the workflow has stopped being productive. It has become unmanaged delegation.
For me, the best workflow is usually to use tools like Codex, Claude Code, Cursor, or Gemini CLI with access to the source code, but limit the number of prompts to what I can manage. I am the orchestrator, and I guide and review everything the AI generates.
Access to the source code matters. It reduces the knowledge cost of using the tool. The developer does not have to paste files manually, explain every dependency, or reconstruct the project context in a chat window. The agent can inspect the code, search for related files, understand existing patterns, and propose changes based on the actual system.
The important thing is not the number of prompts. The important thing is whether the developer can still keep the line of reasoning in their head.
AI agents create waiting time. While the agent is churning, the developer has to decide what to do with that time. They can start another task, review previous output, write tests, check documentation, or move to another project. But every new task adds cognitive load.
There is a point where parallel AI work stops being efficient and starts becoming context switching. Past that point, the developer is not multiplying productivity. They are multiplying loose ends.
So the practical rule is simple: run multiple AI tasks only up to the point where you can still review them properly and own the results.