Coding is getting easier. Software development is getting harder.
There is a version of the current moment that looks like an unambiguous win for software development. Coding assistants write faster than engineers do. They recall syntax, generate boilerplate, suggest tests, and produce a first working version of almost any component in minutes. The cost of writing code is falling rapidly. The standard narrative says this makes software development easier.
That narrative conflates two things that are not the same.
Coding is one slice
Writing code is one activity inside a much longer lifecycle. Before any code is written, there are requirements to understand, tradeoffs to evaluate, and architectural decisions to make that will constrain every subsequent choice for years. After the code is written, there is testing, deployment, incident response, performance tuning, dependency upgrades, and the daily weight of operating something in production. And then, eventually, the hardest part: maintaining, extending, and sometimes understanding software written months or years earlier under different constraints by people who are no longer around.
Estimates vary, but coding commonly accounts for somewhere between 20 and 30 percent of total software development effort over a product’s lifetime. AI has materially reduced the cost of that slice. It has not changed any of the others. The requirements are still hard to get right. The operational surface area is still proportional to complexity. Maintenance costs still accumulate with every abstraction layer added and every feature that doesn’t get removed.
What changes when coding gets cheaper is not that software development gets easier. What changes is the proportion of total effort that coding represents. The expensive parts stay expensive. The cheaper part gets cheaper. The result is a shift in where costs live, and a shift in which costs are visible versus which ones compound quietly in the background.
What agents actually do to a codebase
The interaction model of an AI coding agent is inherently forward-looking. You describe what you want; it builds it; then it asks what comes next.
“Do you want to add error handling for that edge case?” “Should we make this configurable?” “Want me to add a caching layer?” “Should this be an API endpoint so other services can use it?” “Do you want me to containerize this for deployment?”
Each of these prompts is reasonable. Each of the things being proposed has genuine merit in some context. And each one is cheap to say yes to, because the agent will implement it in seconds. The cost that used to enforce discipline, an engineer’s time, is no longer the constraint. The constraint now is judgment about what the system actually needs.
Most people are not good at saying no to reasonable-sounding suggestions. And most agents don’t ask the harder question first: does this need to exist at all?
The one-time analysis that became infrastructure
Consider a concrete example. An analyst needs to understand customer churn trends ahead of a board meeting. They have a spreadsheet export from the CRM and a clear question: what’s driving churn, which segments are affected, how does this quarter compare to last? They ask an agent to help.
In ten minutes, they have a clean analysis: churn rate by segment, month-over-month trends, the top reasons customers cited. The agent did exactly what was asked.
Then it asks what comes next.
Should I save this so you can run the same analysis next quarter? Sure. Want me to make it interactive, so the board could explore the numbers themselves? That could be useful. Should I connect it directly to your database so the data is always current? Even better. Want to add filters for different customer segments? Good idea. Should I add a login so only the right people can see it? Sensible. Should I deploy this somewhere the board can open it before the meeting? Practical.
The board meeting happens. The deck goes fine. The board moves on.
What doesn’t move on: a hosted, authenticated, live-connected dashboard pulling from the production database. It wasn’t discussed as a project. It wasn’t resourced or scoped. It materialized one “yes” at a time over the course of a week. Now it needs to be maintained, secured, and eventually decommissioned, and the analyst who built it has moved on to the next quarter’s analysis.
The original need was: understand the churn data for one meeting.
None of the additions were unreasonable in isolation. All of them were cheap to add. The aggregate result is ongoing infrastructure that will cost more to operate and eventually retire than the original analysis would have cost to redo by hand every quarter for years.
This is not a hypothetical. It is the shape of a pattern that is already common and will become more so.
The cost curve that productivity benchmarks miss
When teams measure the impact of AI coding tools, they typically measure initial development velocity: how long does it take to produce a working first version? That metric is going up, and the improvement is real.
But velocity to first version is not the same as total cost of ownership. A system that takes half the time to build but carries twice the complexity will cost more over its lifetime than the simpler alternative. The costs are just deferred. They appear later, in maintenance cycles, in debugging sessions, in the cognitive overhead required to understand what the system does, and in the difficulty of changing it safely.
Cheap to build is not the same as cheap to own. And free now has a way of becoming very expensive later.
The incentive structure of AI-assisted development optimizes for the metric that is now easy to move. Teams that internalize that optimization without asking harder questions will produce software that is genuinely faster to build and genuinely more expensive to operate and maintain. The costs don’t disappear. They shift.
Keeping things simple just got harder
There is an old principle in software engineering, attributed in various forms to many people, that complexity is the primary cause of system failures, maintenance difficulty, and unpredictable behavior. Simple systems are easier to understand, easier to test, easier to operate, and easier to change. Keeping things simple has always been one of the hardest disciplines in the craft, precisely because there is always a plausible reason to add one more thing.
The economic pressure that used to enforce some of that discipline has weakened. When writing code is expensive, there is a natural brake on scope creep: engineers push back because building more costs more. When writing code is cheap, that brake weakens. The cost signal that used to force hard conversations about what really needs to be built has become quieter.
The discipline now has to be deliberate. It used to be partially economically enforced.
The questions that matter more now
Engineering teams and the product teams they work with need to ask harder questions about necessity, not fewer and not the same number as before, but more. The bar for “this is worth building” needs to rise as the cost of building falls, or the systems being built will systematically expand toward the edge of what’s technically feasible rather than stopping at what’s actually needed.
Some of the questions worth asking more rigorously:
Why does this need to be hosted rather than run locally? Why does this need persistent storage rather than producing output and exiting? Why does this need to be configurable rather than hardcoded for the one case we actually have? Why does this feature need to exist at all, rather than solving the underlying need a different way?
These are not new questions. What is new is that the default answers to all of them are becoming increasingly “because it’s cheap.” That is not a sufficient answer. Cheap to build does not mean cheap to own. The costs of software live where AI tools have not yet reached: in the years of operation after the first commit, in the maintenance cycles, and in the accumulated weight of decisions that seemed reasonable when they were cheap to make.
The promise of AI coding tools is real. So is the trap.