The central mistake is treating productivity gains in software delivery as a signal to shrink staff rather than to expand the portfolio of valuable work. When each hour of developer time produces more output, the economic value of that hour rises, so the question becomes how to redeploy the newly freed capacity. In many organizations, IT demand already exceeds supply, with useful projects, maintenance, and risk reduction deferred simply because teams are full. That makes headcount cuts a poor default response.
The mechanism is straightforward: automation-assisted IDEs, agentic code generation, higher-level specification tools, and broader contributor access reduce the cost of producing and operating software. That lower cost improves the return on projects already sitting in the pipeline and can push marginal backlog items above the organizationโs implicit ROI threshold. It also makes new experiments, internal productivity tools, and technical-debt reduction more attractive. Practitioners should read this as a capacity problem, not merely a tooling upgrade, because the business benefit depends on what the team does next.
The limits are real. If a company truly has enough delivery capacity, cuts may still be defensible, but that is presented as unusual. Layoffs can also damage balanced teams, weaken agility, and make future hiring harder when urgent needs arise. More important, the source argues that complex, enterprise-grade systems still require technologists to ensure security, resilience, observability, and maintainability. The practical conclusion is not promotional enthusiasm but disciplined reinvestment: use the productivity dividend to clear backlog, reduce risk, and widen future options.
AI-driven changes in software development are increasing the velocity of software development teams. Organizational leaders under pressure to reduce costs may quickly move to take advantage of these productivity improvements by reducing developer headcount. But there is another possibility: Use the increased capacity to accomplish more technology goals. Let me explain the strong business case for doing so.
AI brings changes that increase the value of each hour of developer timeโthe very definition of productivity. Most obviously, AI-assisted integrated development environments (IDEs) can automate routine development work, inserting code and identifying potential issues as the developer is typing. They also make information easily available to the developer that would have required research before.
There are many other ways AI increases productivity when you consider the entire software delivery process. AI agents can generate test cases, refactor code, and manage dependencies. Agentic code can be more powerful than traditional code because it uses ML models as primitivesโa single call to an LLM can exercise a chain of thought to control the agentโs flow and to reason about solutions. The LLM can also use external tools to accomplish parts of the solution. As a result, the developerโs code is compact; it delegates much of the hard stuff to the LLM.
Code can also be written at a higher level of abstraction with tools such as
Kiro, which translates between high-level specifications and code. Developers can work more efficiently, and product managers and IT architects can participate in the code development process, taking some of the burden from software developers. And tools like
Amazon Quick Suite broaden the potential base of contributors further, allowing data analysts and even end-user employees to participate in creating agents.
1
All these factors contribute to productivity gains. But how should the company use this productivity increase to generate business value? How should that increase be converted into profits?
The productivity increase means that each software developer, or each hour of developer time, is more highly leveragedโit is worth more to the company. Virtually every business I have worked with maintains a list of valuable IT projects but has chosen to limit its capacity so IT can only do a subset of them. Choosing this subset is often referred to as โprioritizing,โ though it is really about making go/no-go decisions among many appealing projects. IT may be triaging thousands of small tasks that linger in their ticketing and bug tracking systems. Tasks often sit in this limbo for years until the firm realizes thereโs no chance theyโll ever get to them and finally deletes them. Innovative ideas float around the organization, never even getting to the proposal stage because everyone knows IT capacity is limited. And many important pieces of IT work donโt even make it onto those listsโmodernizations, reductions in technical debt, investments in agility, and risk management investments in general. These make up the organizationโs IT backlog.
If the companyโs IT intake and governance process is working well, these backlog tasks are projected to have a sound ROIโbut the IT department is busy with tasks that have an even higher expected ROI. The company implicitly sets an ROI threshold for projects it plans to do. In my experience, governance is rarely this smooth, but weโll consider the theoretical case.
The crucial thing to note is that the AI-driven productivity increases
change the ROI calculation for everything in the backlog: The productivity gain means that each task costs less, so its ROI increases. The new ROI might even exceed the previous threshold. Projects in the pipeline that can take advantage of AI have an even higher expected return. And AI will lead to innovative new ideas with yet a higher ROI than those in the backlog.
This suggests that at least some of the productivity gain should be used to increase ITโs delivery capacity. You might even say that reducing headcountโheadcount that has become even more valuable to the companyโdestroys business value. Counterintuitive as it might be, hiring more developers could make sense, since each incremental developer contributes more to the companyโs bottom line.
Reducing headcount makes the most sense if the company has exactly the IT capacity it needs. That is unlikely. More often companies have line of business leaders who are frustrated because IT doesnโt have time for their important projects, and an IT team frustrated by constantly saying no to initiatives that clearly have value. And that value increases as development productivity increases.
Companies that need to find savings should not panic: Many of those projects languishing in the backlog are intended to reduce costs elsewhere in the organization. The cost savings will still come, just in a different budget category. Also, many of the newly possible AI initiatives that developers can spend time on will enhance employee productivity across the entire company. Using software productivity increases to develop, deploy, and operate these tools will deliver benefits that are multiplied across the company.
Many executives I talk to want to increase innovation in their organizations. They can use the increased IT capacity to maintain a portfolio of innovative experiments and proofs of concept. The ability to try new ideas quickly and with low risk is an important driver of innovation.
Most companies also carry a lot of IT-related risk: outdated systems, security vulnerabilities, and applications without adequate disaster recovery (DR) capabilities. The company carries technical debt that slows it down and reduces its agility; increasing agility raises the value of future IT projects and effectively buys call options on future opportunities. Because addressing these problems doesnโt have a business sponsor or an obvious ROI, they are often neglected. Again, newfound IT capacity can be used here to create a more future-ready organization.
Gains from increasing IT capacity may be easier to realize than the gains from laying off developers. Development teams need to maintain a balance between skill sets; layoffs can upset that balance. Teams that have gelled are powerful; laying off some of their members can reduce productivity. And laying off teams reduces agilityโif a sudden, critical need arises, hiring new developers is inefficient.
The key point is that AI still requires technologists, who will create some of the more complex agents and make all the companyโs AI agents enterprise-grade, with the appropriate resilience and security. But with AI-driven productivity improvements, each dollar spent on those technologists brings a higher return to the business than before. Spending marginal dollars on IT, rather than reducing IT spend, is the route to higher business value.
Thatโs assuming that the organization doesnโt already have enough IT capacity. Does yours?
โMark
- I say โparticipate inโ on the assumption that for a scalable, enterprise-ready agent, technologists need to be involved to ensure security, resilience, observability, and maintainability. They also need to fit the agent into overall enterprise architecture frameworks and decisions.
https://aws.amazon.com/blogs/enterprise-strategy/ai-increased-productivity-consider-hiring-more-developers/
Related