How AI Is Changing the Cost of Building and Running Software

AI-assisted development is changing the way software is built, making certain parts of the process faster and more manageable. Developers can use AI tools to generate code, create initial test cases, explore different approaches, and work through early versions of an application. These tools can certainly save time, but they do not take away the complexity of software development. Code still needs to be reviewed, tested, refined, and made reliable enough for real-world use. Much of the work still depends on a developer's experience, judgement, and understanding of the problem.

For businesses planning a new application, these improvements naturally raise an important question: if AI helps developers work more efficiently, will software development also become cheaper? Could a smaller team now handle projects that once required more people?

The answer is not quite that simple. Faster development does not necessarily translate into lower overall project costs. There are other expenses to consider, along with the time needed for planning, testing, maintenance, and ongoing improvements. The impact on developer demand and employment is equally difficult to predict.

A useful way to understand this is to look at something businesses have been using for decades: project management software. These tools have made planning, tracking, and coordinating work considerably easier. Yet the need for project managers has not disappeared.

AI-assisted development may follow a similar pattern. Greater productivity can change how work gets done, but it does not automatically reduce the amount of work businesses need. The number of projects companies want to undertake, the cost of running and maintaining software, and the way development teams organise themselves all play a part.

1. What Exactly Can AI Make More Productive in Software Development?

AI is not limited to writing code. Its usefulness can extend across much of the software development lifecycle, although the gains vary considerably depending on the task.

Consider a few common activities.

• Coding: Developers can use AI to generate functions, suggest implementations, explain unfamiliar code, and create repetitive sections of an application.

• Testing and debugging: AI can suggest test cases, help identify likely causes of errors, and assist with interpreting logs. The output still needs to be checked against actual system behaviour.

• Requirements gathering: AI can help organise stakeholder discussions, identify missing information, and turn rough notes into clearer requirements.

• BRD writing: A business requirements document (BRD) can be drafted from meeting notes, business objectives, and process descriptions, giving the team a starting point for review.

• Technical specifications and documentation: AI can help document APIs, explain system components, and prepare technical specifications that developers can refine.

These are useful improvements. However, there is a difference between producing an initial draft quickly and completing the work correctly.

A requirements document may read well but overlook an important business rule. Generated code may pass a simple test but fail under unusual conditions. Documentation may describe how a system should work rather than how it actually works.

The time saved on generation can therefore be partly offset by review, correction, testing, and integration.

What does a productivity improvement of 20% actually mean?

Suppose a development task normally takes 100 working hours. For illustration, assume AI makes the developer 20% more productive, meaning the same amount of work can be completed at 1.2 times the previous rate.

The calculation is:

1001.2=83.3hours

The task now takes approximately 83.3 hours, saving 16.7 hours.

The distinction matters. A 20% increase in productivity does not mean a 20% reduction in the time needed to finish a task.

Also, the 20% figure here is an illustrative assumption, not an industry average.

Research findings vary by setting. GitHub's controlled Copilot experiment found that participants completed a specific coding task 55% faster with the tool. A 2025 enterprise-based randomized trial involving 96 Google software engineers estimated a 21% reduction in time spent on a complex task, while noting a wide confidence interval. In contrast, a 2025 METR study found that experienced developers working on familiar, mature open-source projects took 19% longer with the AI tools tested in that experiment. These results measure different tasks, tools, and working conditions, so they should not be treated as competing estimates of one universal productivity gain. (GitHub research; Google study; METR study).

The practical lesson is straightforward: AI can improve productivity, sometimes substantially. The size of the gain depends on what is being built, who is building it, and how much checking the output requires.

2. Writing Code Is Only Part of the Cost of Software

When a business receives a software development estimate, it is tempting to think mainly about the developers and the number of hours they will spend coding. In reality, a project involves a much wider set of responsibilities.

Someone needs to understand the business problem. Someone has to decide which features matter, manage expectations, resolve disagreements, coordinate delivery, test the product, and make sure the finished system works for its intended users.

Depending on the project, the people involved may include:

• Business stakeholders and executives, who define the problem, approve budgets, and make decisions about priorities.

• Product owners and business analysts, who translate business needs into requirements and decide what the product should do.

• Project managers and engineering managers, who coordinate delivery, resources, risks, and teams.

• IT directors and technical leads, who oversee technical direction, architecture, security, and integration decisions.

• Developers and QA engineers, who build the application and check whether it works as expected.

• Salespeople and account managers, who find customers, manage relationships, prepare proposals, and support ongoing business.

Not every project needs a dedicated person for every role. A small internal application might be handled by two developers and a business owner. A large enterprise system may require several teams, multiple levels of management, and extensive stakeholder coordination.

The point is that coding is one part of a much larger activity.

Why the cost of people matters

The cost of these roles also varies. A senior US-based salesperson's total compensation can sometimes exceed the combined cost of several offshore developers. Senior managers, specialised consultants, and experienced technical leads can also represent a significant share of the budget.

That does not mean these roles are unnecessary. A salesperson who brings in a major client or a technical lead who prevents a costly architectural mistake may contribute far more value than their cost suggests.

It simply means that reducing coding hours does not reduce every other expense at the same rate.

A hypothetical project budget

Consider a software project with the following illustrative budget.

In this example, AI reduces development hours by 16.7%, while the other costs remain unchanged. The overall project cost falls by approximately 9.3%, not 16.7%.

These figures are hypothetical, not an industry benchmark. Actual savings depend on how the team uses AI and whether the other activities also become more efficient.

There is another distinction worth making here. Sales salaries, advertising, lead generation, office expenses, and general administration may be company-wide costs rather than direct expenses assigned to a single project. They still influence what a software company charges, but they should not automatically be counted as project delivery costs.

For a buyer, the useful question is not simply, "How many coding hours can AI eliminate?" It is, "Which parts of this particular project will become cheaper, and by how much?"

That brings us to a more interesting question: if better tools reduce the effort required to do a job, why should we assume that fewer people will be needed to do it?

3. Better Tools Don't Necessarily Mean Fewer Jobs

A common assumption goes something like this: if technology makes each worker more productive, businesses will need fewer workers. Sometimes that happens. But it is not the only possible outcome.

A useful historical comparison comes from project management.

For decades, software such as Microsoft Project, Jira, and Trello has made it easier to organise tasks, track progress, manage deadlines, share updates, and coordinate teams. Work that once required a great deal of manual reporting can now be handled through shared boards, automated notifications, and dashboards.

These tools have made project management more efficient in many settings. Yet project management employment in the United States has not simply declined as these tools have become commonplace.

The figures published by the US Bureau of Labor Statistics offer an interesting illustration.

Sources: BLS May 2021 occupational estimates, BLS May 2023 occupational estimates, and BLS Occupational Outlook Handbook.

There is an important qualification here. These figures cover project management specialists across industries, not just IT project managers. The historical estimates and forward-looking projections also come from different statistical programmes and methodologies. They should not be treated as a perfectly comparable annual series or proof that project management software caused employment to grow.

Still, the broader question is worth exploring. Why might employment continue to grow in an occupation whose work has been supported by increasingly capable tools?

The productivity effect versus the demand effect

There are two economic forces to consider.

The productivity effect: If a project manager can coordinate more projects using better software, a company may need fewer project managers to handle the same workload.

The demand effect: If coordinating projects becomes easier or cheaper, businesses may choose to undertake more projects. New opportunities that previously seemed too expensive or difficult to manage may become worthwhile.

These forces can operate at the same time. The first reduces the amount of labor needed for each unit of work. The second increases the total amount of work being undertaken.

Which one dominates depends on the circumstances.

A simple example

Imagine a business initially has 100 projects and each project manager can handle five projects at a time. It needs 20 project managers.

Now suppose better tools make each project manager 2.5 times as productive. Each person can handle 12.5 projects, so the original 100 projects require only eight project managers.

That is the productivity effect.

But imagine the business opportunity expands and the number of projects grows fivefold, from 100 to 500. At 12.5 projects per manager, the business now needs 40 project managers.

Despite a substantial productivity improvement, employment has doubled from 20 to 40.

The example is hypothetical, of course. Real projects differ in size and complexity, and project managers cannot always be allocated in neat fractions. But the underlying arithmetic demonstrates something important: greater productivity per worker does not tell us how many workers an economy or industry will ultimately employ.

What research says about collaborative work management tools

A 2026 study published in Management Science, titled Collaborative Work Management Technologies and Managerial Intensity in U.S. Corporations, provides a useful counterpoint to the employment figures.

The researchers examined 3,017 US public firms over the period from 2010 to 2019, using a dataset combining more than 26 million job listings and over 20 million social profiles. They found that adopting collaborative work management technologies was followed by a 3.2% reduction in managerial intensity. In other words, managers made up a smaller share of the workforce at adopting firms. The study also found increases in job-posting signals associated with decentralized working. (Read the study.)

This finding matters because it shows that technology can change organizational structure. Companies adopting these tools did, on average, become less management-intensive by the measure studied.

But it does not contradict the wider employment figures. The study examined a different population, a different outcome, and a specific group of firms. Managerial intensity is not the same as the total number of project management specialists employed across the US economy.

Both things can be true: some organizations can need fewer managers relative to their workforce, while the overall economy continues to create demand for project-related work.

And this is precisely why the comparison is useful. Better tools can reduce the labor required for existing work without determining the total volume of work that businesses will choose to undertake.

What this means for AI-assisted software development

Now consider software development.

If AI reduces the time needed to build an application, some businesses may complete their existing projects with fewer developer hours. They might reduce budgets, shorten delivery schedules, or reassign developers to other work.

However, lower development costs could also make software projects viable for businesses that previously could not justify the expense.

A small company might commission an internal reporting tool instead of managing everything in spreadsheets. A retailer might automate a process that was previously handled manually. An established business might build several smaller applications rather than prioritizing just one large project.

In each case, the cost of developing software has fallen, but the number of projects being undertaken could rise.

That does not guarantee more developer jobs. Demand might grow slowly, companies might choose to automate rather than hire, or productivity gains might outpace the increase in new work. Some roles may shrink or change, and certain types of development work may become less valuable.

The point is that productivity alone cannot settle the question.

The future impact of AI depends on how much software businesses want, how affordable it becomes, and how organizations choose to use the time and money they save. Predicting employment from coding speed alone leaves out the very forces that determine how markets respond.

4. The Difference Between Building Software and Running It

Getting an application to work for the first time is one thing. Keeping it useful, secure, and reliable for the next five years is another.

AI can make the first stage considerably faster. A founder can describe an idea, generate an interface, connect a database, and produce a prototype without investing months in development. This is one reason vibe coding has attracted attention: people can experiment with software ideas before committing to a substantial budget.

But a working prototype is not necessarily a production-ready application.

A system that looks fine during a demonstration may struggle when hundreds of users access it simultaneously. It may have weak access controls, incomplete error handling, unreliable integrations, or a database structure that becomes difficult to maintain as the business grows.

These problems are not inevitable consequences of AI-generated code. Experienced developers can use AI to produce sound software, too. The risk comes from treating generated output as finished work without the necessary engineering and verification.

Where the long-term costs appear

Once software goes live, businesses still need to account for:

• Maintenance and enhancements: Fixing defects, updating dependencies, and adapting the application as business requirements change.

• Infrastructure: Paying for hosting, cloud resources, storage, monitoring, and other services needed to keep the application running.

• Security: Managing access, addressing vulnerabilities, protecting data, and responding to new threats.

• Integrations: Maintaining connections with payment gateways, CRM systems, accounting software, and other business applications.

• Technical debt: Revisiting shortcuts and design decisions that make future changes slower, riskier, or more expensive.

A cheap initial build can therefore become an expensive long-term commitment if it creates problems that must be corrected later.

The reverse is also true. AI-assisted development can reduce lifetime costs when it helps teams write better tests, document systems, identify defects early, and maintain existing applications more efficiently.

For buyers, the sensible approach is to assess the total cost of ownership rather than the initial development quote alone. A slightly more expensive application that is easier to maintain may be the cheaper option over its useful life.

5. More Competition Doesn't Automatically Mean Better Software

AI is also changing who can offer software development services.

Freelancers can produce prototypes more quickly. Small agencies can take on work that previously required larger teams. Businesses with limited technical resources can experiment with building their own tools.

That wider access is valuable. Customers have more options, and some projects that were once financially unrealistic are now within reach.

However, more providers do not automatically make it easier to find the right one.

Think of it like a freeway

Imagine a freeway with very little traffic. A skilled driver can travel efficiently, choose a lane, and reach the destination without much difficulty.

Now imagine the same freeway filled with thousands of cars. Even excellent drivers get stuck. They may know exactly what they are doing, but there is only so much road available.

The problem is no longer driving ability. It is congestion.

Something similar can happen in the software market. If the number of providers grows much faster than customer demand, even capable businesses can struggle to get noticed.

Customers cannot thoroughly assess hundreds of developers or agencies before making a decision. They often narrow their options through:

• Search visibility and online presence.

• Referrals and previous customer experiences.

• Pricing, proposals, and delivery timelines.

• Portfolio examples and case studies.

• The clarity of initial conversations and first impressions.

These signals can be useful, but they do not always reveal the quality of the underlying engineering.

A polished portfolio does not guarantee secure code. A low quote does not necessarily mean poor work, just as a high quote does not guarantee excellent results. And a provider who communicates confidently may not be the one best equipped to maintain a complicated application over several years.

For customers, this creates a practical challenge: separating genuine capability from the ability to market that capability.

AI can widen access to software development, but it cannot remove the need to evaluate architecture, testing practices, security, documentation, and long-term support. In a crowded market, those checks may become more important, not less.

Conclusion: Productivity Is Only One Part of the Equation

AI is changing the economics of software development, but the consequences are not as simple as faster coding leading to proportionally lower costs and fewer jobs.

The project management comparison illustrates why. Tools can make individual workers more productive, reduce managerial intensity within some organizations, and still coexist with growing demand for project-related work across the wider economy. These observations do not prove what AI will do to software employment, but they show why productivity alone is an incomplete guide.

For businesses, the same principle applies to software investments. Lower development costs may make more projects possible, while maintenance, infrastructure, security, and competition continue to shape the final outcome.

The better question is not simply how quickly AI can build an application. It is whether that application solves the right problem, works reliably, remains maintainable, and delivers value over time.

Business decision-makers should evaluate software investments on total cost, reliability, maintainability, and long-term business value—not just development speed or the initial price.