13 September 2026
For most of software history, writing code was expensive enough to act as its own constraint. A new feature needed engineering time. An internal tool competed with customer-facing work for the same developers. A new integration might sit in the backlog for months because nobody could justify pulling people away from more important projects. Companies complained about development capacity constantly, but that scarcity had an unintended benefit: it forced at least some consideration of whether additional software was worth creating.
AI coding tools are removing that constraint remarkably quickly.
A developer who once spent most of a day implementing a predictable feature can now produce the first version in an hour. Tests, migrations, API clients, documentation and repetitive application logic can be generated almost immediately. Coding agents can inspect repositories, make changes across multiple files, run tests and iterate on failures with progressively less supervision. Small teams can now produce an amount of software that would have required significantly more engineering capacity only a few years ago.
This is usually described as a productivity breakthrough.
It is.
But it also creates a problem the industry has spent considerably less time discussing.
Companies are becoming capable of creating code faster than they are becoming capable of owning it.
That distinction matters because writing code is only the beginning of its cost. Once code reaches production, somebody becomes responsible for everything it does next. It needs to remain compatible with changing infrastructure. Dependencies need updates. Security vulnerabilities need patches. Business rules evolve. APIs change. Data models migrate. Customers discover edge cases nobody anticipated during implementation. New developers need to understand why the system behaves the way it does, while existing developers need enough confidence to modify one part without damaging another.
None of those responsibilities become free because the original implementation was generated in twenty minutes.
In fact, cheaper generation can make the problem larger. When the marginal cost of adding another feature approaches zero, the natural resistance to adding software begins to disappear. Instead of asking whether a new workflow deserves permanent implementation, teams can simply build it. Instead of consolidating two similar capabilities, creating a third becomes easier. Instead of understanding why an existing service is difficult to change, an AI agent can sometimes build around it faster than a team could fix the underlying architecture.
Every individual decision looks productive.
The codebase grows.
The number of things the organization is responsible for grows with it.
And eventually the company discovers that development throughput and engineering capacity were never the same thing.
Code Is Not Output. It Is Inventory.
Software teams have traditionally used language that makes code sound like a productive asset. We talk about shipping more, increasing velocity, delivering features and expanding functionality. Those measures made some sense when implementation itself was expensive. Producing more useful software with the same engineering team often indicated that something had genuinely improved.
AI complicates that relationship because output can now increase dramatically without an equivalent increase in business value.
Suppose two teams are solving the same operational problem. One team understands the underlying process, removes an unnecessary workflow and makes a relatively small change to an existing system. Another team uses AI to rapidly create a new service, several endpoints, an administrative interface and an integration to connect everything back to the original platform. The second team may produce considerably more code and may even appear more productive according to conventional engineering metrics.
It has also created considerably more software that somebody needs to own.
Every service has a lifecycle. Every endpoint creates an interface that may eventually need compatibility. Every database table introduces assumptions about data. Every dependency creates another relationship with software the organization does not control. Every background job needs failure behaviour. Every permission needs to remain correct as roles change. Even well-written code adds something to the organization’s future maintenance surface.
That makes code surprisingly similar to inventory.
Creating inventory is not automatically valuable. It becomes valuable when the business needs it, can use it and can afford to carry it. Excess inventory ties up capital, requires storage and eventually becomes obsolete. Excess code behaves differently financially, but the underlying principle is remarkably similar. It occupies engineering attention, increases the number of things that can fail and makes future change more difficult simply because there is more system to understand.
The difference is that software inventory is unusually easy to hide.
A warehouse containing twice as much physical stock is visible. A codebase containing twice as many abstractions, dependencies and execution paths can continue looking perfectly healthy for years. Cloud infrastructure keeps running. Features continue shipping. Customers may notice nothing. The cost appears gradually through slower debugging, longer onboarding, more fragile releases, increasing security work and a growing reluctance to change parts of the system nobody fully understands.
By the time the organization recognizes the problem, removing code can be considerably harder than adding it was.
This is why AI should change the way engineering leaders think about productivity. If code generation becomes abundant, the amount of code produced becomes a progressively worse measure of engineering performance. The scarce capability moves elsewhere: understanding what deserves to exist, designing the smallest coherent solution and resisting functionality whose long-term ownership cost exceeds its business value.
We made a related argument in The Hidden Cost of Vibe Coding: Cheap to Build, Expensive to Own. The first version of AI-generated software can be genuinely inexpensive. The mistake is extrapolating those economics across the lifetime of the system. Code that costs almost nothing to generate can still create years of maintenance obligations.
AI makes the factory faster.
It does not make the warehouse infinite.
Technical Debt Can Now Accumulate Faster Than Engineering Judgment
Technical debt has never required bad developers. Much of it comes from perfectly rational decisions made under pressure. A team accepts a shortcut because a customer needs something this week. An integration is implemented quickly because the external system will supposedly be replaced next year. Two similar workflows remain separate because consolidating them would delay an important release. Individually, these compromises are often sensible. Problems emerge when temporary decisions become permanent and the organization keeps building on top of them.
AI changes this equation because it increases the number of implementation decisions a team can make in the same period.
Imagine an engineering organization where five developers previously completed twenty meaningful changes during a month. Architecture reviews, code reviews and informal conversations evolved around roughly that volume of work. Senior engineers had enough exposure to understand what was entering the system and could intervene when several apparently unrelated changes began pulling the architecture in conflicting directions.
Now give the same team capable coding agents.
The developers may be able to explore more approaches, implement changes faster and automate substantial portions of testing and documentation. The team might comfortably produce twice or three times the previous change volume without adding another engineer.
What did not necessarily double or triple is the amount of architectural judgement available.
The senior engineer still has the same number of hours in the week. Security specialists still have the same attention. Product leaders still need to determine whether the additional features are actually necessary. Domain experts still need to verify that generated implementations reflect the business correctly. Review capacity does not automatically scale because generation capacity did.
This creates a new form of engineering bottleneck.
Code generation can scale faster than engineering judgement.
The danger is not that every AI-generated change contains a serious mistake. Most may be perfectly reasonable. The problem is statistical and organizational. If a team makes substantially more changes, it creates substantially more opportunities for small inconsistencies to enter the system. One feature introduces a slightly different authorization pattern. Another duplicates business logic because the agent did not discover the existing implementation. A third adds a dependency because it was the fastest way to satisfy the immediate requirement. A fourth creates another abstraction around an architectural problem that should probably have been removed instead.
Nothing breaks.
That is precisely why the debt survives.
Six months later, the organization has a larger system containing more locally sensible decisions that nobody consciously designed as a whole. AI did not create the architectural problem. It increased the speed at which ordinary engineering decisions accumulated.
We have discussed this broader dynamic in How Much Technical Debt Is Too Much? A Startup Founder’s Guide and How Enterprise Software Becomes Unmaintainable. Technical debt becomes dangerous when the organization loses the ability to distinguish intentional compromises from accidental complexity. AI raises the stakes because teams can now add complexity faster than traditional review structures were designed to absorb.
The solution is not to slow AI down until development feels like it did before.
It is to become considerably more deliberate about what deserves to enter the codebase in the first place.
The Most Expensive Code May Be the Code Nobody Needed to Write
If AI makes code generation abundant, one of the most valuable engineering skills becomes surprisingly old-fashioned: deciding not to build something.
This sounds almost contradictory to the current direction of software development. Coding agents are improving rapidly, implementation cycles are shrinking and ideas that once required weeks of engineering can now be tested in days or hours. When the cost of trying something falls this dramatically, experimentation should increase. Teams should prototype more. Developers should explore alternatives that previously would have been too expensive to investigate. Businesses should absolutely take advantage of the fact that software has become easier to create.
The problem is what happens after the experiment succeeds just enough to survive.
Software organizations have always been better at adding than removing. A new feature usually has an obvious stakeholder, a business case and somebody asking when it will be ready. Removing an existing feature is different. Someone may still use it. Another workflow may depend on it. Historical data may assume it exists. Nobody wants to be responsible for discovering the obscure customer who relied on behaviour that was never properly documented. As a result, functionality tends to accumulate even when its original purpose has largely disappeared.
AI can accelerate that accumulation because the threshold for saying yes becomes much lower.
A request that previously would have triggered a discussion about whether an existing workflow could be adapted may now be easier to solve by generating another one. A team that once would have consolidated two similar services might allow both to remain because maintaining them appears cheap when AI can help with future changes. An internal tool that would never have justified a development budget can now be created in an afternoon, which is useful until dozens of such tools begin depending on production data, authentication systems and APIs that somebody needs to keep stable.
This is not a hypothetical argument against experimentation. The ability to build disposable software cheaply is one of AI’s most valuable contributions to engineering. The important word is disposable. If an experiment proves that the idea is weak, the code should be allowed to disappear with it. If a prototype proves that the idea is valuable, the team should decide consciously whether the implementation itself deserves to become permanent. Those are two separate decisions, and AI makes it easier than ever to confuse them.
The distinction becomes particularly important in enterprise environments because software rarely remains isolated. A small application begins importing customer data. Another team asks for access. An API is added. Someone creates a scheduled process around its output. Reporting starts depending on its database. Within a year, a tool that cost almost nothing to create has become part of the organization’s operating model. Removing it now requires coordination across several teams, even though nobody ever made a deliberate decision that the software should become long-term infrastructure.
This is where Most Companies Don’t Need More Software. They Need Fewer Systems becomes relevant to AI-assisted development. The same fragmentation that companies created by purchasing too many specialized applications can now happen internally through code generation. Instead of subscribing to another SaaS product for every problem, organizations can generate another application, service or workflow for almost no initial cost. The technology changes, but the architectural outcome can be remarkably similar: more places where logic lives, more systems exchanging information and more uncertainty about which one actually owns a business capability.
A mature AI-enabled engineering organization should therefore become more aggressive about reuse, consolidation and deletion precisely because generation has become cheap. Before creating another service, ask whether the capability belongs inside an existing one. Before generating another internal tool, understand whether the workflow itself should exist. Before adding another abstraction around an awkward part of the system, consider whether removing the underlying complexity would be cheaper over the next five years.
This is not less productive engineering.
It may become the highest form of engineering productivity in an environment where anyone can generate more code.
AI Makes It Easier to Build Around Problems That Should Have Been Removed
There is another reason rapidly increasing development capacity can make software more expensive over time. AI is exceptionally useful when navigating complexity. Coding agents can search large repositories, trace dependencies, explain unfamiliar code and generate changes across parts of a system that would take a developer considerable time to understand manually. For organizations maintaining legacy platforms, this can be enormously valuable. Work that once felt prohibitively difficult can become practical again.
But there is a subtle downside to making complexity easier to navigate.
Sometimes complexity should not be navigated. It should be removed.
Consider a business process that has accumulated years of exceptions. The software reflects each one faithfully: special customer rules, historical pricing behaviour, different approval paths, duplicate data models and integrations built around systems that were supposed to be retired years ago. A traditional development team encountering this environment would quickly feel the cost. Every change would require investigation, meetings and careful testing. Eventually, the pain itself might create enough pressure for the organization to simplify the underlying process or modernize the architecture.
An AI coding agent changes the immediate experience. It can inspect the relevant areas, identify where another exception belongs and implement it much faster. The organization gets the requested feature without confronting the larger structural problem.
That feels like progress.
Sometimes it is merely postponement.
The danger is that AI becomes a highly effective mechanism for extending software that should have been simplified. Instead of paying down complexity, teams become better at operating inside it. Instead of consolidating duplicated business logic, they use AI to find every copy whenever a change is required. Instead of replacing an obsolete integration, an agent generates another compatibility layer around it. Instead of questioning why five workflows exist for essentially the same process, the organization becomes capable of maintaining all five more efficiently.
The short-term economics can look excellent because every individual change costs less than it did before.
The long-term architecture can still become worse.
This matters because complexity has a compounding cost. Every workaround creates another condition future changes must respect. Every compatibility layer becomes another dependency. Every duplicated rule increases the probability that one implementation eventually diverges from another. AI may reduce the effort required to understand these relationships, but it does not remove the relationships themselves.
Eventually, the organization is using increasingly sophisticated intelligence simply to understand complexity it continuously chose not to eliminate.
There is an uncomfortable analogy here with infrastructure. If transportation becomes cheaper, a company can afford to operate warehouses in inefficient locations for longer. That does not make the network efficient. It merely reduces the immediate penalty for poor design. AI can have a similar effect on software architecture. It lowers the cost of moving through a complicated codebase, which can reduce the urgency to make the codebase less complicated.
This is why modernization decisions should not be evaluated solely by comparing today’s implementation effort. Why Legacy Software Modernization Projects Fail is relevant here because legacy complexity is rarely only a technical problem. Old systems often encode organizational decisions, historical workflows and business rules that nobody has reconsidered for years. Giving an AI agent better tools to modify those systems can create significant value, but it should not become an excuse to preserve every assumption the legacy platform contains.
The best use of AI may sometimes be helping engineers understand an old system well enough to delete half of it.
That outcome will never produce the most impressive code-generation metric.
It may produce the best software.
More Code Also Means More Surface Area to Secure
The maintenance problem becomes even more important when security enters the equation because software does not need to contain obviously poor code to increase risk. Every additional capability changes the surface the organization needs to protect. A new endpoint introduces another access path. A new integration requires credentials and permissions. A new dependency creates another external component whose vulnerabilities and updates may eventually matter. A new administrative workflow creates another place where authorization must remain correct. A new background process may access information users should never see directly.
Even if every individual implementation is reasonably good, the security model becomes responsible for more things.
This distinction matters because discussions about AI-generated security often focus too narrowly on whether models write vulnerable code. That is an important question, but it is not the only one. Imagine that AI-generated code becomes statistically as secure as human-written code under equivalent review. If the same organization now produces three times as much software, it may still have significantly more security surface to understand, test and monitor.
Security teams do not receive unlimited attention simply because development throughput increases.
The same bottleneck appears again.
Engineering can generate another service quickly. Security still needs to understand what information it handles, who can access it, how authentication works, which dependencies it introduces and what happens if the service is compromised. Developers can generate another integration in an afternoon. Someone still needs to decide whether the credentials have excessive permissions, how secrets are rotated and what data the third party is allowed to receive. An AI agent can create a new administrative feature almost immediately. Authorization still needs to remain correct across every path capable of reaching the same underlying data.
The problem becomes especially serious when generated software spreads outside conventional engineering teams. One of the promises of AI development is that people with less technical experience can create useful applications themselves. For low-risk internal experimentation, that can be enormously valuable. But the moment those applications begin connecting to customer records, production databases, payment information or company-wide authentication, they become part of the organization’s security architecture whether anyone intended them to or not.
The application may have cost $50 in tokens.
Its access to production data does not become $50 worth of risk.
This is why the argument in The Hidden Cost of Vibe Coding: Cheap to Build, Expensive to Own extends beyond maintainability. Cheap implementation changes how much software organizations are willing to create, and volume itself becomes a security consideration. The safest code is not automatically the code with the most sophisticated security controls. Sometimes it is the code that never needed to exist.
As AI increases development capacity, security-conscious organizations will need stronger boundaries around what can reach production, which systems can access sensitive data and where generated applications are allowed to integrate. The objective should not be to prevent experimentation. It should be to ensure that experimentation does not quietly become infrastructure without anyone accepting responsibility for what that transition means.
AI makes software easier to create.
It does not make additional attack surface free.
The Best AI Engineering Teams May Be the Ones That Delete the Most Code
If code generation continues becoming cheaper, engineering organizations will eventually need to reconsider what productivity actually means. For decades, output has been relatively easy to observe. Teams shipped features, completed tickets, closed pull requests and expanded products. None of those measures were perfect, but they existed in an environment where producing software required substantial human effort. When implementation capacity was scarce, increasing useful output often represented a meaningful improvement.
That assumption becomes less reliable when an AI coding agent can generate a substantial implementation before a developer has finished their first coffee. A team can produce more pull requests, more tests, more services and more functionality without necessarily solving more valuable business problems. In that environment, celebrating output alone begins to resemble judging a factory by how much material it consumes rather than by what customers are willing to pay for what comes out the other side.
The better engineering organizations will probably respond by becoming more selective, not less ambitious. They will still use AI aggressively because refusing cheaper and faster implementation would make little sense. But they will place more value on reducing the amount of software required to solve a problem. A developer who discovers that an existing capability can satisfy a requirement with a small modification may create more long-term value than an agent that generates an entirely new service overnight. A team that removes an obsolete workflow may improve the architecture more than another team that automates it. An engineer who simplifies a business rule before encoding it may prevent thousands of lines of future implementation from ever becoming necessary.
This changes the role of deletion as well. Removing code has traditionally been treated as maintenance work, something teams do when they finally have time to clean up after more important feature development. In an AI-heavy development environment, deletion may become part of the core economics of engineering. If generation continuously increases the amount of software entering an organization, somebody needs to create pressure in the opposite direction. Otherwise the codebase expands simply because the cost of adding to it has fallen.
The strongest teams may therefore begin treating software much more like a portfolio. New code needs to justify its future ownership cost. Existing code needs to continue justifying its place in the system. Experimental implementations should have a clear path either toward deliberate production engineering or deletion. Duplicate capabilities should be consolidated before another layer is generated around them. Services that no longer represent meaningful business boundaries should be candidates for removal rather than permanent residents of the architecture.
This is not a call for artificially small codebases. Some businesses are complicated because the problems they solve are complicated, and serious enterprise platforms will always contain substantial amounts of software. The objective is not fewer lines for the sake of fewer lines. It is reducing accidental surface area so that the complexity the organization owns corresponds as closely as possible to complexity the business actually needs.
That distinction becomes more valuable as AI improves. If implementation becomes almost universally accessible, competitors will have access to similar code-generation capability. Being able to produce another feature quickly will no longer be particularly unusual. The advantage may instead come from having a system coherent enough that new capabilities can be introduced without creating another layer of architectural debt.
In other words, AI may make code generation a commodity while making software restraint more valuable.
The company that wins will not necessarily be the company capable of generating the most software.
It may be the company disciplined enough to own the least software necessary to run an exceptional business.
AI Should Reduce the Cost of Engineering, Not Remove Engineering From the Process
There is a tendency in discussions about AI coding to frame the future as a competition between developers and models. If AI can generate an implementation faster and more cheaply, the argument goes, then progressively fewer traditional engineering activities should be necessary. This interpretation makes sense if software development is understood primarily as converting requirements into code. It makes considerably less sense once we recognize that code generation is only one part of building systems that organizations can safely depend on.
The more capable coding agents become, the less valuable manual implementation will probably be as a standalone skill. There is little reason for an experienced engineer to spend hours writing predictable boilerplate if a model can produce it accurately in minutes. The same applies to many tests, migrations, documentation tasks, repetitive integrations and routine refactoring. Engineering organizations should want those costs to fall. The purpose of software engineering was never to maximize the number of hours humans spend typing syntax.
What remains is responsibility for the system.
Someone still needs to decide where a capability belongs. Someone needs to recognize that a requirement conflicts with an existing business invariant. Someone needs to decide whether introducing another dependency is worth its long-term cost. Someone needs to understand why a seemingly redundant piece of logic exists before allowing an agent to remove it. Someone needs to determine whether the generated test proves meaningful behaviour or merely confirms the implementation the model just created. When security, money, customer data or critical operations are involved, someone needs to be accountable for the consequences.
Those responsibilities become more important when implementation accelerates because more decisions can now reach production in less time. AI does not eliminate engineering judgement. It increases the amount of software over which that judgement potentially needs to operate.
This is why the distinction between AI-assisted engineering and unrestricted code generation matters. In a mature development environment, coding agents operate inside a structure deliberately created to make safe changes easier. Automated tests describe important behaviour. Architectural boundaries limit unnecessary dependencies. Observability makes failures visible. Security controls establish what applications and users are allowed to do. Documentation preserves decisions that would otherwise need to be rediscovered. Code review focuses less on whether someone wrote the syntax correctly and more on whether the change belongs in the system at all.
AI can participate in every one of these activities. It can generate tests, review changes, identify suspicious dependencies, explain architectural relationships and help maintain documentation. The point is not that humans must preserve every engineering responsibility forever. The point is that the responsibility itself cannot simply disappear. If AI eventually performs most of the implementation, testing and review, organizations will still need mechanisms that ensure those activities collectively produce software they can trust.
This is also where Custom Software Development changes rather than becomes irrelevant. The value of professional software engineering is moving away from the raw production of code and toward designing systems in which code can be produced, changed and removed safely. AI can make that process dramatically faster. Used properly, it can reduce development cost without transferring an even larger bill into maintenance, security and future modernization.
The objective should never be to preserve expensive development simply because that is how software used to be built.
The objective is to make software cheaper without making ownership more expensive.
Conclusion: The Cost of Code Is Moving From Creation to Ownership
AI coding tools are delivering something the software industry has wanted for decades: more development capacity. Ideas can be tested faster. Small teams can attempt projects that previously required much larger budgets. Engineers can delegate repetitive implementation and spend more time on problems where experience matters. Organizations with enormous backlogs can finally address work that would otherwise remain untouched for years.
That is a genuine productivity improvement.
But every improvement in production economics changes what becomes scarce next.
When writing code was expensive, development capacity was the constraint. Companies worried about how many developers they could hire, how quickly features could be implemented and how much engineering time each new system would consume. As AI reduces those costs, the constraint begins moving toward architecture, review, security, domain understanding and the organization’s ability to decide which software deserves permanent ownership.
That is a very different problem.
A company can generate another application without having enough people who understand why it exists. It can produce another integration without having enough security capacity to review the new access paths. It can add another service without having enough architectural oversight to determine whether the service represents a real business boundary. It can create thousands of lines of perfectly reasonable code without creating enough business value to justify maintaining any of them.
The danger is not that AI will fill enterprise systems with obviously terrible code. Better models, better agents and better development tooling should continue improving implementation quality. The more subtle risk is that good-enough code becomes so inexpensive that organizations accumulate far more of it than they would ever have chosen to own when creation was expensive.
That is why AI Doesn’t Save Time. It Changes Where Your Time Goes applies just as strongly to software engineering. AI does not simply eliminate development effort. It moves effort into different parts of the lifecycle. Less time may be spent producing the first implementation, while more attention becomes necessary for deciding what should exist, reviewing what enters production and keeping the resulting system coherent over time.
The same principle explains why the economics discussed in The Hidden Cost of Vibe Coding: Cheap to Build, Expensive to Own extend far beyond individual developers experimenting with AI. At enterprise scale, the issue is not whether one application can be generated cheaply. It is what happens when hundreds of teams gain the ability to generate software cheaply at the same time.
The answer cannot simply be more code.
It has to be better control over what becomes permanent.
The most effective engineering organizations will use AI extensively. They will allow agents to generate implementations, tests and documentation. They will automate larger portions of routine development and probably ship meaningful changes with teams much smaller than those required today. But they will also become more disciplined about architecture, consolidation, security and deletion because those activities protect the scarce resource AI does not make unlimited: the organization’s ability to understand and safely change the systems it owns.
For years, companies paid heavily to create code.
Increasingly, they will pay very little to create it and much more attention to decide whether they want to own it.
That changes the fundamental question behind software development.
Not:
“How much can we build?”
But:
“How much software can we responsibly afford to keep?”
The companies that answer that question early will get the productivity benefits of AI without turning those gains into the next generation of technical debt.
Frequently Asked Questions
Why can more AI-generated code become a maintenance problem?
Because generating code is only one part of its lifecycle. Production software needs testing, security updates, dependency management, monitoring, documentation and future modification. AI can reduce the cost of many of those activities, but every additional capability still increases the amount of software the organization is responsible for understanding and protecting.
Does AI-generated code create more technical debt?
Not automatically. AI can produce high-quality code and can help teams identify and reduce existing technical debt. The risk appears when generation throughput grows faster than architectural oversight, review and simplification. Teams can then accumulate many individually reasonable changes without maintaining a coherent system.
Should engineering teams limit their use of AI coding agents?
The goal should not be to artificially limit AI usage. Teams should use coding agents where they improve development economics while strengthening the engineering controls around what reaches production. Faster generation makes architecture, automated testing, security review and clear ownership more important, not less.
Is having less code always better?
No. Complex business problems can require substantial software. The objective is not minimizing lines of code but minimizing unnecessary software surface. A smaller system that accurately represents the business is generally easier to understand and maintain than a larger system containing duplicated workflows, unnecessary services and historical functionality nobody is willing to remove.
Can AI also help maintain the additional code it generates?
Yes, and this will likely become an important part of AI-assisted engineering. Coding agents can inspect repositories, update dependencies, generate tests, identify vulnerabilities and help developers understand unfamiliar systems. However, AI maintenance still requires context, computational resources and reliable mechanisms for determining whether changes preserve the intended behaviour of the business.
Why does more software increase security risk even if the code is good?
Every additional endpoint, dependency, integration, permission and execution path increases the surface the security model needs to protect. Good implementation reduces risk, but it does not make additional software free from security responsibilities.
How should companies measure engineering productivity in the AI era?
Output metrics such as lines of code, pull requests or feature volume will become increasingly weak indicators as generation becomes cheaper. More useful measures include business outcomes, reliability, lead time, maintainability, change failure rates and the amount of unnecessary complexity the team avoids or removes.
The Hidden Cost of Vibe Coding: Cheap to Build, Expensive to Own
Written by Logicnord Tech Team
The Logicnord Tech Team designs and builds enterprise software and AI-enabled systems for organizations where long-term maintainability matters as much as development speed. We use AI-assisted engineering to reduce repetitive implementation work, accelerate delivery and help teams understand complex systems, while preserving the architectural, security and operational discipline required for software that becomes part of the business.
Our work across logistics, enterprise operations and custom software development has repeatedly shown that the most expensive software is rarely the software that took the longest to type. Cost accumulates when systems become difficult to understand, difficult to change and too important to replace. AI creates an opportunity to reduce development cost substantially, but capturing that opportunity requires treating code generation as the beginning of software ownership rather than the end of software engineering.