If AI Can Write the Code, Where Do Software Developers Create Value?

I started writing code in 2009. Over the years, I've spent entire days solving problems, reading documentation, trying different approaches, and debugging until I finally understood what went wrong. Some systems took months to build and years to mature.

Now, with AI coding agents, I can describe a requirement and get hundreds of lines of code back in minutes. Work that once took several days can sometimes reach a working first version in an afternoon. AI can also read a codebase, write tests, explain errors, and propose changes across multiple files.

This has changed what it feels like to be a software developer. Skills that once took years to develop can now be applied with considerable assistance from AI. I suspect this is part of why some developers feel unsettled. When a large part of your professional work can suddenly be done much faster, where does that leave your value?

I want to approach this question from the economics of the software industry, using a familiar concept from business strategy: the value chain.

One thing worth remembering is that even before AI, writing code was only one stage of building and selling software. We spend years getting better at that stage, so it's understandable that we sometimes see the entire product through the work we do ourselves.

Imagine you're building inventory and sales management software for small retailers.

Before writing anything, you need to understand the problems these businesses face. Maybe they manage inventory in spreadsheets, struggle to track which products are still in stock, or have trouble reconciling orders across multiple sales channels.

You study how they operate, identify which problems matter most, decide what the software needs to do, and design a solution. Only then do you start coding.

And when the code is written, there is still plenty of work left.

The software needs testing, deployment, maintenance, and data protection. You need to find customers, help them get started, handle support requests, and improve the product based on how people actually use it.

If you can't find customers, the product might never generate revenue. If users can't figure out how it works, even a feature-rich application can be abandoned. If the system constantly breaks, customers may leave despite the quality of its original implementation.

Coding is an important link in a much longer chain.

Figure 1. The software value chain, from market research and design through development, distribution, operations, and customer retention. Coding is highlighted to show where it fits in the overall process.

In Michael Porter's Value Chain framework, a business is understood through a set of connected activities, from creating a product and getting it to customers to providing service afterward. Competitive advantage comes from how a company organizes these activities, manages costs, and creates value that customers are willing to pay for.

Applied to software, this helps separate three concepts that are often confused.

Use value is the practical benefit the software provides. Good inventory management software might reduce losses, save employees time, and help a retailer make better purchasing decisions.

Economic value created concerns the benefits a solution produces relative to the resources required to deliver it. A piece of software might generate benefits far greater than its development cost.

Value captured by the business is the portion of those benefits the company can turn into revenue and profit, accounting for costs, competition, and market conditions.

These concepts are closely related, but they aren't interchangeable.

An engineer might build an extremely sophisticated system that demonstrates exceptional technical skill. Yet if it doesn't solve an important problem or reach the right customers, the economic return may be small.

Meanwhile, a simple application with only a handful of features can become a successful business if it solves the right problem, is easy to use, and has an effective way to reach customers.

There are certainly products where deep technical capability is the main source of differentiation. Databases, infrastructure systems, security software, and applications with demanding reliability requirements are obvious examples.

There is no universal formula for calculating what percentage of a software product's value comes from coding.

What matters is recognizing that technical difficulty and the ability to capture economic value are separate things to evaluate.

The software industry has many business models. I'll focus on three familiar ones: software outsourcing, software products, and Software as a Service (SaaS).

All three require software development capabilities. But their revenue models, cost structures, and profit drivers differ considerably.

Figure 2. The value chains of software outsourcing, software products, and SaaS. Different activities matter more for creating and capturing value in each model.

In outsourcing, the customer usually already has a business need or a project they want delivered. A software company provides the people, expertise, and processes required to build the solution under a contract.

Suppose a company takes on an $80,000 project to build an internal management system over six months.

It needs to plan staffing, engineering costs, project management, testing, support, and potential risks.

Coding may account for most of the direct engineering hours. But the company's profit also depends on winning the contract, negotiating a reasonable price, estimating the work accurately, controlling scope, allocating people effectively, and maintaining quality.

A company can have excellent developers and still lose money if it consistently underestimates projects, fails to control changing requirements, or spends too much time fixing defects.

In this model, programming expertise is an important production resource. The ability to organize that resource and deliver contracts effectively determines how much revenue the company can turn into profit.

In the software product model, a company researches, builds, owns, and commercializes its own software.

Consider a company developing accounting software for small businesses. It needs to understand customer needs, build the right features, choose a pricing model, distribute the software, and provide support.

Once the product is ready, the company can sell the same software to many customers without rebuilding it from scratch for every buyer.

This is one of the important economic advantages of software products.

The initial development cost may be high, but the cost of delivering another copy is often relatively low compared with physical goods. Operating, supporting, updating, and distributing the software still costs money, of course.

Here, intellectual property ownership, product-market fit, brand, and distribution become especially important.

You might own the source code for an excellent application, but that doesn't guarantee people will buy it. Customers still need to discover the product, trust it, and have a reason to choose it over available alternatives.

SaaS shares many characteristics with the software product model, but its business depends more heavily on delivering an ongoing service, usually through subscriptions.

Imagine a task management SaaS priced at $8 per month.

With 1,000 paying customers, that produces $8,000 in monthly recurring revenue before adjustments.

But maintaining that revenue requires reliable infrastructure, customer support, ongoing product improvements, and enough value to convince users to keep paying.

If customers use the product for a month and then leave, the company may struggle even with a healthy number of new signups.

If customers stay for years, the initial acquisition cost can be spread across a longer relationship, potentially improving the economics of the business.

This is why SaaS companies pay close attention to metrics such as Customer Acquisition Cost (CAC), churn rate, Customer Lifetime Value (LTV), gross margin, and Net Revenue Retention (NRR).

For SaaS, shipping the first working version is only the beginning of a much longer business process.

Looking across all three models, coding capabilities are used in different ways. Yet revenue and profit depend on the entire chain of activities.

That distinction matters when we consider how AI affects different software businesses.

Another useful model for understanding the value chain is the Smile Curve, which illustrates how value added may be distributed across different activities in an industry.

In its typical form, activities near the beginning of the chain, such as research, design, and technology ownership, can generate substantial value. Activities near the end, including branding, distribution, and customer service, can also be valuable. Meanwhile, standardized production activities in the middle may face stronger price competition.

I wanted to see what this perspective might suggest about software before and after AI.

Figure 3. A conceptual model of how differentiation and value capture may shift across the software value chain. The curves represent a strategic hypothesis, not measured empirical data.

Before AI, turning requirements into working software generally required substantial specialized labor.

A company building a product needed to hire or contract developers who could write code, design systems, test functionality, and deploy applications.

Programming skills had a degree of scarcity, which gave people with those skills a meaningful advantage.

Someone who understands a product and knows how to work effectively with AI can build prototypes faster. Developers can use coding agents to generate initial implementations, add tests, refactor code, and understand unfamiliar codebases.

Repetitive technical work that can be clearly specified is becoming easier to automate. In many situations, the cost of producing a unit of software output may fall.

From an economic perspective, when a capability becomes easier to obtain, competitive advantages based mainly on its scarcity may weaken.

This is especially visible in common features such as CRUD interfaces, basic dashboards, landing pages, admin forms, and relatively standard integrations.

If many competitors can build similar features at a lower cost, customers gain more choices. It becomes harder for a business to justify high prices simply because implementation takes a lot of engineering time.

However, we should distinguish the value of coding activity from competitive advantage based on coding.

AI may increase the total amount of software being produced. Ideas that were previously too expensive to pursue may become viable. Demand for reliable, secure, maintainable software doesn't automatically disappear.

What faces greater pressure is the ability to charge a premium solely for programming tasks that tools and competitors can increasingly perform.

Competitive advantage may therefore shift toward other capabilities.

At the beginning of the chain, these include understanding an industry, identifying the right problems, designing solutions, and making appropriate architectural decisions.

At the other end, they include data, ecosystems, distribution channels, customer relationships, and the ability to deliver business outcomes that users actually care about.

AI also increases the need for verification. When code can be generated faster, companies need effective ways to ensure that systems behave correctly, remain secure, and can be maintained over time.

I think this is a reasonable way to understand the possible shift in value, although the shape of the curve will vary considerably across different types of software.

If AI can generate code in seconds, does that mean software development tasks get completed proportionally faster?

Research suggests the answer depends heavily on the task, the developer's experience, the tools involved, and the working environment.

That is a significant result, but it was measured on a particular task in an experimental setting.

McKinsey also published research in 2023 showing that generative AI could substantially reduce the time required for certain development activities, including code generation, documentation, and refactoring. The improvements varied according to task complexity and developer experience.

Then, in July 2025, METR published a controlled experiment involving 16 experienced developers working on 246 tasks in open-source projects they already knew well.

The result was surprising: under the conditions of that experiment, developers allowed to use AI took approximately 19% longer to complete their tasks.

Interestingly, those developers still felt that AI had made them faster.

In February 2026, METR published a follow-up. The researchers observed signs that newer tools were improving productivity, but limitations involving participant selection and measurement prevented them from making a reliable estimate of the speedup.

I don't think these findings contradict the experience of watching AI produce code incredibly quickly.

They remind us that generating code is only one part of completing a software development task.

A developer still needs to understand the existing system, evaluate the impact of a change, verify the logic, handle errors, integrate the implementation, and make sure it can be deployed safely.

Google's 2025 DORA report, drawing on a survey of nearly 5,000 technology professionals and qualitative research, makes an important observation: AI tends to amplify an organization's existing capabilities.

Teams with strong engineering practices, platforms, and processes are generally better positioned to make effective use of AI.

In an analysis published in March 2026, DORA also highlighted how time saved during code creation can shift into reviewing, evaluating, and verifying the result.

A change generated quickly but difficult to review, poorly tested, or likely to break production may not improve the efficiency of the development process as a whole.

This is why I think we should measure the time from identifying a need to delivering a stable, valuable solution, rather than measuring code generation speed alone.

Figure 4. AI may reduce code generation time, but overall productivity also depends on verification, integration, deployment, and operations.

Becoming proficient in software engineering takes years of work.

From learning your first programming language to understanding data structures, frameworks, databases, and eventually designing complete systems, the process requires continuous practice and accumulated experience.

When someone spends most of their working life solving coding problems, it's natural for programming to become central to their professional identity.

Every difficult bug fixed, every complex query optimized, and every major system delivered reinforces that sense of competence.

But along the way, I think it's easy to confuse three things.

A difficult algorithm may require considerable expertise to implement. But if it solves a minor problem that few people care about, the economic value created may be limited.

Meanwhile, something as simple as automated payment reminders could save a business significant manual work and improve its ability to collect outstanding payments.

Technical difficulty and business benefit are sometimes connected, but they aren't always proportional.

A feature might have taken us three days to build in the past.

If AI helps us build the same feature in three hours at the same level of quality, the customer may still receive essentially the same benefit.

The amount of labor has decreased while the practical value remains.

This is one of the ways technology creates productivity gains.

What changes is the production cost and the way businesses can price the work.

In a model that sells engineering hours, this creates direct pressure. In a model that sells products, lower development costs may allow a business to test more ideas or improve margins, depending on competition.

This is something people with engineering backgrounds, myself included, need to keep reminding ourselves.

We often feel a product is nearly finished when its main features are working reliably.

But from a business perspective, it may still be at a very early stage.

Does anyone actually need it? How are they solving the problem now? Are they willing to pay? How will we reach them? Is the product good enough for them to keep using it?

Writing more code usually won't answer those questions.

AI makes the differences between these three ideas more visible.

As the time and effort required for many programming tasks decrease, we have another reason to reconsider how our work contributes to value across the whole system.

Figure 5. A conceptual comparison of how competitive advantage may shift across three software business models. These curves are analytical hypotheses and cannot be used to infer each activity's share of profit.

For software outsourcing, AI may allow the same team to complete more work.

But if both the provider and the customer continue to price everything strictly by labor hours, greater productivity can create pricing challenges.

Outsourcing companies need to consider how to turn productivity improvements into profit, higher-value services, or outcome-based contracts when results can be measured appropriately.

For software products, lower initial development costs make it easier for more people to enter the market.

This creates opportunities for small teams and independent developers, but also increases the number of competing products.

When common features can be replicated quickly, owning a particular feature may offer less protection against competition.

Understanding the market, building a brand, owning intellectual property, and reaching customers become increasingly important.

For SaaS, AI can help companies build and improve products faster, including features that would previously have been too expensive to implement.

But the business still needs to retain customers, maintain service quality, and operate with a sustainable cost structure.

Costs related to AI models, inference, infrastructure, and agent operations may also change SaaS economics.

I think AI increases both the opportunities and the competitive pressure across all three models.

The ability to develop software faster doesn't guarantee that a company will make more money.

The outcome depends on whether the company can turn that productivity into customer value and competitive advantage.

I don't think every developer needs to become a founder, product manager, or business specialist.

We still need engineers with deep technical expertise, particularly for complex systems with demanding reliability requirements.

But I do think we should broaden our understanding of the work happening before and after the part we're responsible for.

When you receive a development request, spend time understanding what users actually need.

Suppose a customer asks for an order tracking dashboard.

Before choosing a charting library, ask what decisions they need to make using that dashboard.

Perhaps their real problem is identifying delayed deliveries.

In that case, a timely alert system might be more useful than a complex dashboard.

Understanding the underlying problem helps us avoid building things nobody really needs.

AI can generate code, but someone still needs to take responsibility for how the components of a system work together.

It's worth developing a solid understanding of data modeling, transactions, concurrency, authorization, security, integrations, scalability, and operations.

For example, AI can generate an API that receives orders from an ecommerce platform relatively quickly.

But what should happen if the same order is submitted twice?

What if payment succeeds but the inventory update fails?

What if a request is retried after a timeout?

These are problems involving data integrity and system design.

Being able to handle them correctly creates substantial value when software is used in real operations.

I believe learning to work with AI coding agents should now be part of a developer's professional development.

Beyond knowing how to assign tasks to AI, we need to provide useful context, define acceptance criteria, design tests, review changes, and evaluate results.

One practical habit is to write down the conditions for successful completion before asking AI to implement anything.

For example, when building a payment feature, the acceptance criteria might include:

AI can then help write the implementation and tests, but the results still need to be verified against those conditions.

This shifts our attention from the amount of code produced to whether the system behaves correctly.

If you work at a software company, try to understand what happens to the product after deployment.

How do customers discover it? Why do they choose it? How much does it cost to serve one customer? Where do users tend to give up? What problems generate support requests?

If you work on SaaS, learn about CAC, churn, retention, and LTV.

If you work in outsourcing, understand how projects are estimated, priced, and managed for profitability.

You don't need to own these responsibilities yourself.

But understanding them can help you make engineering decisions that better support the business.

A developer might complete 20 tickets in a sprint.

That's useful information for tracking work, but it doesn't tell us what those changes accomplished.

We can start connecting engineering work to more concrete results: reducing order processing time, decreasing defects, improving workflow completion rates, lowering operating costs, or improving system response times.

Of course, not every engineering task can be tied directly to revenue.

Reliability, security, maintainability, and developer experience are important outcomes too.

The goal is to understand how our work contributes to the results the product is supposed to achieve.

Figure 6. Five directions for developers to grow beyond coding execution: problem understanding, system architecture, AI engineering, product thinking, and outcome measurement.

I think it does, and I expect it will continue to matter for a long time.

But the way we apply that skill may change considerably.

Experienced developers have an advantage when working with AI because they understand systems, can evaluate proposed solutions, and can recognize mistakes that less experienced people might miss.

At the same time, AI gives people with domain expertise new opportunities to participate in software development.

Someone who understands accounting, education, business operations, or marketing may now be able to build prototypes, test ideas, and contribute more directly to developing software.

As more people gain the ability to build, those of us with technical backgrounds need to think carefully about what makes our expertise distinctive.

For some, that may mean deep specialization in distributed systems, security, data, or performance optimization.

For others, it may mean combining engineering with industry knowledge, product design, or the ability to lead complex projects.

There isn't one path that works for everyone.

Turning an idea into something that actually works has always been satisfying. AI makes that process even more interesting because I can experiment with things I previously didn't have enough time to build.

But the more I work with AI, the more attention I find myself paying to what should be built, why it needs to exist, what constraints must be respected, and how we can tell whether a solution is actually good.

Writing code faster doesn't answer those questions for us.

Looking at the entire value chain, I think AI presents a meaningful opportunity for developers.

We may be able to spend less time on certain implementation tasks and more time understanding problems, designing systems, verifying quality, and delivering results.

Customers ultimately pay for the problems software solves and the value it delivers. The number of lines we write is rarely what matters to them.

Coding remains one of the capabilities that helps create that value.

As AI changes how coding gets done, this seems like a good time to reconsider where our own work fits within the software value chain.

The following sources informed the theoretical framework and helped me examine the evidence on AI's impact. The value curves in this article are my own conceptual illustrations, not empirical measurements from these studies.