How Many Developers Do You Really Have? The Hidden Economics of AI Coding Agents

If you have ten developers and each of them uses AI agents every day, it's no longer obvious whether you still have a ten-person engineering team in any meaningful sense. What you may actually have is ten developers plus an invisible layer of virtual capacity that is constantly influencing how work is produced, reviewed, and delivered, but isn't properly measured.

This problem is quickly becoming more important as AI coding assistants and agents progressively move from experiments into daily software delivery. Developers now use them not only for isolated tasks, but across the entire lifecycle of work: generating code, writing tests, refactoring modules, explaining legacy systems, drafting pull requests, debugging issues, producing documentation, and automating repetitive implementation work.

On the surface, this still looks like a straightforward productivity story. A tool helps developers move faster, the team writes more code, tickets progress more quickly, and repetitive work becomes easier to offload. The subscription cost also looks small compared with the cost of engineering time, which reinforces the intuition that this is a simple efficiency gain. But that framing misses a lot of what is actually changing.

AI coding tools are more than just software subscriptions. Once they become part of day-to-day delivery, they effectively become part of the team's capacity model, and that means they need to be evaluated differently from standard tooling spend. The real, complex question is whether AI-assisted development improves the economics of delivery once you account for cost, quality, review burden, rework, maintainability, and risk.

And to be clear, I don't mean to raise panic or be completely contrarian. In some setups, the answer to that question is clearly positive. AI can reduce repetitive work, accelerate onboarding, help with tests, speed up exploration, and give developers more leverage over routine implementation tasks. In those environments, it behaves like a genuine force multiplier and improves throughput in a measurable way.

In many other setups, the picture is much less clear. AI tools can increase the amount of code produced without improving delivery outcomes. They can shift bottlenecks from implementation to review, generate technically correct but inefficient or misaligned solutions, and introduce subtle architectural or maintenance issues. They can also distort incentives when organisations start measuring AI usage instead of measuring actual delivery performance.

The key distinction is whether the team understands what AI changes in the delivery system, and uses it in a way that supports value creation, not just elaborate, but ultimately meaningless KPIs.

AI coding tools are not just subscriptions. They are capacity bets.

Many organisations still treat AI coding tools primarily as a procurement decision. The discussion often revolves around how many seats are needed, which tool to choose, what the per-developer monthly cost is, and whether the organisation is paying for a single assistant, multiple IDE integrations, premium model access, or usage-based API consumption.

These are all valid operational questions, but the picture they paint is incomplete. A coding agent is not comparable to a design tool or a password manager, because it does not just support work; it actively produces work that enters the engineering pipeline. That output still needs to be reviewed, tested, integrated, secured, deployed, and maintained, which means it directly influences architecture, quality, velocity, and long-term technical debt.

This is why the buying decision is also a capacity decision. When a team adopts AI coding tools, it is implicitly betting that the additional output generated by AI will be more valuable than the combined cost of the tools, the usage, and the downstream effort required to validate and maintain what is produced.

Sometimes that bet clearly pays off. AI can be highly effective at generating boilerplate, drafting unit tests, explaining unfamiliar code, writing simple transformations, producing documentation, or helping developers explore unfamiliar APIs. In those cases, it reduces friction and allows engineers to focus on higher-value decisions.

However, the value is not guaranteed. If AI increases output in areas that are already constrained by review capacity, testing discipline, architectural decision-making, or product uncertainty, then it may not increase delivery at all. Instead, it may simply increase work-in-progress and shift complexity elsewhere in the system. In some cases, teams even end up using AI to add more capacity to parts of the workflow that are not the actual bottlenecks, while the real constraints in review, system design, or product clarity remain unchanged.

For that reason, while evaluating AI-assisted development, you have to go beyond just the tooling cost, and recognise it as an intervention in the entire delivery system.

The visible cost is not the real cost

The visible cost of AI tools is relatively easy to track. Organisations can see subscription fees, seat licenses, model usage, API calls, premium tiers, agent runs, and vendor invoices. Finance teams can aggregate these numbers, procurement can compare plans, and engineering leaders can calculate rough per-user costs.

But the real cost structure is significantly broader than what appears on invoices. AI usage introduces costs that are often distributed across the organisation and therefore harder to attribute directly. These include time spent prompting and re-prompting, reviewing AI-generated code, debugging plausible but incorrect implementations, rewriting generated output, managing larger pull requests, dealing with duplicated tooling across teams, maintaining code that is not fully understood, and addressing security or performance issues that only surface later in the lifecycle.

Even considering those issues, AI tools are still often worth using. The point is that the subscription cost is only one component of the total system cost. In some setups, tools introduced to improve productivity and reduce labour cost can become surprisingly expensive once usage patterns, premium models, orchestration layers, supervision effort, and rework are included.

Under a poorly designed setup, the expected efficiency gains can disappear once the full system cost is taken into account. In such cases, the organisation is not just buying tooling, it's also implicitly buying a new layer of work required to supervise and stabilise the output of that tooling. That supervisory effort is often underestimated.

The hidden cost is supervision

AI generates output that must be evaluated, validated, corrected, or rejected before it can safely become part of a production system. This introduces a supervision cost that is structurally different from traditional development work.

In human teams, supervision already exists as part of the engineering process. Junior developers require review, mid-level developers require feedback, and senior developers still require alignment with architecture, product requirements, security expectations, and team standards. However, AI-generated code changes the nature of that supervision rather than removing it.

A key difference is that traditional team setups were implicitly optimised for a world where code creation itself was the primary constraint. Writing code required time, context switching, and cognitive effort, which naturally limited throughput. In that environment, review was important, but it rarely became the dominant bottleneck because the flow of incoming changes was naturally paced by the cost of producing them.

AI changes this balance. When code can be generated almost effortlessly, the constraint shifts away from implementation and toward validation. Many organisations were not structurally designed for this shift. Their processes, team topologies, and expectations around review bandwidth were built for a slower input rate of changes, not for a system where large volumes of code can be produced in minutes.

A junior developer's mistake is often relatively easy to detect. The code may not compile, the implementation may be incomplete, tests may fail, or the misunderstanding may be obvious enough to surface quickly in review. These issues are typically visible and localised.

AI-generated code can fail in a more expensive and less obvious way. It may compile, pass basic checks, and appear correct at first glance, while still being inefficient, overly complex, insecure, difficult to extend, inconsistent with the architecture, or subtly incorrect in domain-specific edge cases. These types of issues are harder to detect and often require senior-level attention to evaluate properly.

This is one of the reasons why "AI writes code faster" does not automatically translate into "the team ships faster." If AI increases the volume of code faster than the team increases its ability to validate that code, the bottleneck simply moves. Implementation becomes faster, but review, debugging, integration, and maintenance become heavier. The productivity gain may still exist, but it is no longer free.

AI can increase velocity or just increase output

A common mistake in AI-assisted development is confusing output with throughput. Output refers to how much code is written, how many files change, how many pull requests are opened, or how many tasks appear to progress. Throughput, however, refers to how much valuable work actually reaches users with acceptable quality, risk, and maintainability.

AI is extremely effective at increasing output. It can help developers generate more code, create more test cases, draft documentation, explore alternative solutions, and move faster through familiar implementation patterns. In well-structured environments, this can also translate into higher throughput.

However, the relationship between output and throughput is not linear. More code can mean more value, but it can also mean more review burden, more defects, more rework, more architectural drift, and a larger surface area that must be maintained over time.

Teams with strong engineering practices are more likely to benefit from AI because they already have the mechanisms required to absorb increased output: automated testing, disciplined code review, clear architecture ownership, CI/CD pipelines, observability, security checks, and a well-defined notion of done. In such environments, AI acts as an accelerator more than a destabiliser.

Teams without those foundations may experience the opposite effect. AI can increase the speed of implementation faster than the system can safely integrate changes, which means it does not solve delivery problems but instead accelerates existing bottlenecks.

This is why organisations need an effective way of identifying whether AI tools actually help them deliver better software faster, with less waste and acceptable risk. And this can be surprisingly challenging.

Is your AI developer worth 1 FTE, 0.3 FTE, or negative capacity?

Many discussions about AI coding tools implicitly treat them as additional developer capacity, which can be a useful abstraction as long as it's taken seriously. If an AI agent is treated as a "virtual developer," then it should be evaluated using the same kinds of questions applied to human capacity.

What work is it good at, what work should it avoid, how much supervision does it require, what quality does it produce, how much rework does it generate, and does it improve delivery or merely increase activity? Does it help senior engineers, junior engineers, or both? Does it reduce bottlenecks or simply move them elsewhere in the system?

Under this framing, an AI agent might be worth close to a FTE in a narrow, well-defined workflow. It might be worth significantly less in broader contexts, or it might even create negative capacity if it generates low-quality output that increases senior review and cleanup burden.

A useful mental model is that AI-assisted capacity equals useful delivery gain minus supervision cost, rework cost, quality risk, and tool or model cost. This is not a precise formula, but a way of making the system-level trade-offs visible.

If AI saves five hours of implementation but creates six hours of review and debugging, the net capacity is negative. If it reduces boilerplate and produces code that fits existing patterns, the gain may be real. If it improves test coverage and catches defects earlier, the value may exceed just the time saved. If it accelerates junior developers but increases senior review load, the effect may be mixed. If it produces code that works today but becomes expensive to maintain later, the cost may be deferred rather than avoided.

The point is not to assume AI is either good or bad by default, but to measure its full impact on the system.

Bad AI productivity metrics create bad developer behaviour

As organisations invest in AI tools, they often want evidence of adoption. This is understandable, since leadership teams naturally want to know whether the tools they are paying for are actually being used. However, this is also where measurement can easily go wrong.

If the KPI becomes AI usage, people will optimise for AI usage rather than for better software delivery. This is where unintended behaviours start to emerge across teams.

Developers may begin to optimise for the number of prompts, tokens, AI-generated lines of code, accepted suggestions, or agent runs. Teams may feel pressure to use AI even when it does not improve outcomes. Workflows may become AI-heavy because they are visible, not because they are effective. In some cases, expensive models may be used for trivial tasks simply because usage is being tracked rather than cost-effectiveness.

In extreme cases, this leads to tokenmaxxing, where the goal becomes maximising visible AI activity because it is interpreted as progress. This is fundamentally a misaligned fitness function, because it rewards activity rather than outcomes.

AI adoption never was the goal. It was just a means to reach better delivery. Usage metrics can still be useful as a supporting signal, especially during early rollout phases, but they can't be confused with performance indicators.

A developer who uses AI heavily is not automatically more productive. A developer who uses AI selectively, avoids unnecessary output, and ships high-quality changes faster may be creating significantly more value. The same applies at team level, where high AI usage can either indicate improved flow or increased review burden, depending on what is actually happening in the system.

What engineering teams should actually measure

If AI tools are becoming part of engineering capacity, they should be evaluated using delivery metrics rather than procurement or usage metrics alone. The exact set of metrics will vary depending on context, but the goal is to capture system-level behaviour rather than isolated activity.

Useful signals may include lead time for changes, cycle time, review time, pull request size, rework rate, defect rate, escaped defects, deployment frequency, time spent debugging, onboarding time, senior review load, cost per meaningful delivery outcome, and the percentage of AI-generated code that is substantially rewritten during review.

Unfortunately, no single metric is sufficient on its own. Lead time may improve while defect rates worsen. Review time may increase because more issues are being caught earlier, which may actually be a positive signal. Pull request volume may increase without corresponding value delivery. Developer satisfaction may improve even if costs rise.

I'm not trying to convince you to spend a bunch of time and resources building a perfect measurement system. All I'm trying to say is this: avoid making decisions based on incomplete signals such as invoices, intuition, or raw usage data.

A practical approach is to ask a small set of questions at the end of each sprint: where did AI actually help us move faster, where did it create additional cleanup work, which tasks were good candidates for AI assistance, which tasks should remain human-led, did review burden increase or decrease, and are we shipping better software or simply producing more code.

This set of questions is more valuable than complex dashboards that are difficult to interpret or trust, or focus on wrong metrics in the first place.

AI FinOps is becoming part of engineering leadership

Cost management of AI solutions increasingly becomes part of engineering leadership rather than being purely a finance concern. And the answer shouldn't be optimising for the cheapest possible model or restricting access to tools.

Instead, the goal is to understand the relationship between cost, quality, speed, and risk across different types of work. Some tasks may justify premium models, while others are perfectly suited to cheaper alternatives. Some workflows may benefit from agentic systems, while others are better handled with lightweight assistance or no AI at all.

Without explicit guidance, teams tend to discover these boundaries through trial, error, and increasingly expensive invoices. A more mature approach asks when premium models are appropriate, when cheaper models are sufficient, which tasks are safe for automation, which outputs require senior review, where AI actually reduces cycle time, and where it simply increases output without improving outcomes.

This is the emerging discipline of AI FinOps for engineering teams. It's about aligning cost awareness with delivery performance. Making the AI expenses effective in a way that's truly meaningful for the business.

The most mature organisations will not only track how much they spend on AI tools, but also understand what kind of engineering capacity they are effectively buying, where it creates value, where it introduces hidden work, and how to improve the cost-to-value relationship over time.

The role of engineering leadership changes

AI-assisted development changes the role of engineering leadership in subtle but important ways. The question becomes how AI should be integrated into the delivery system in a way that preserves quality and improves outcomes.

Engineering leaders need to define where AI is encouraged, where it is optional, where it requires review, and where it should be avoided or constrained. They also need to help teams distinguish between good delegation and abdication of responsibility.

Good delegation means using AI for tasks where the problem is well-defined, the risk is manageable, the output can be validated, and the human developer remains accountable for the result. Abdication, on the other hand, means accepting generated output without fully understanding whether it fits the system or meets the required standards.

This distinction becomes more important as tools become more capable. AI can accelerate development, but it does not remove engineering responsibility. Someone still needs to own architecture, evaluate trade-offs, understand domain constraints, protect quality, and decide whether a solution is actually good enough to ship. As the tools improve, the importance of human judgement increases, not decreases.

Closing thought

One way or another developers in your teams are already using AI. The important question is whether your organisation is prepared for that. Does it understand what AI changes in the software delivery system and whether it is adapting its measurement, incentives, and processes accordingly.

If AI agents add useful capacity, that capacity should be measured. If they introduce hidden work, that work should be made visible. If they increase cost, that cost should be connected to outcomes. If they distort incentives, the metrics should be adjusted. And if they generate more code, the organisation must ensure it can still review, integrate, and maintain that code effectively.

AI coding tools can be extremely valuable, but they are not magic capacity and they are not just another subscription. Once they become part of everyday engineering work, they become part of the delivery system itself, and anything that becomes part of that system needs to be measured, managed, and continuously improved.