In 2026, most software companies have handed their engineers AI with the instructions to deliver more, faster. Regardless of if it is good enough or not, AI coding is here and is being used. Like any change to a system, AI introduces new modes of failure and the software and companies that persist will be the ones that adapt. These new failure modes will shift the bar for software engineering, not to best practices, but only enough to prevent the failures.
AI Coding is being sold as the way to 10x engineers and potentially grow revenue without bounds. But historical examples already can provide limits on the return on investment.
While at a previous job I pushed CI/CD much further than I have ever seen and my teams were near to the mythical 10x teams. We could get features built fast, deploy in minutes, fuzzed before deployment, could automatically detect failures in production, would automatically fix some issues, and we actually took action on our postmortems. Even during my time at Google (pre-ai coder) I never saw anything comparable (it must have existed, but I searched and never found it). But eventually we found ourselves struggling with determining what to build because organizational experimenting had disconnected the website from manufacturing. No amount of velocity could fix the loss of that signal.
Sometimes the environment changes and the company is doomed and even AI coding couldn’t have helped them. Sun had some of the best engineers (they built Java, DTrace and ZFS). They were founded in the 80s to undercut multi-million dollar mainframes, but by the late 90s the environment shifted, x86 and Linux both became “good enough”. I started using Linux in ’96 and it was a curiosity watching Sun try to compete with my leftover desktop computer turned server. Better software wouldn’t have changed the economics.
Like organizational or environment changes AI coding brings new risks and the hype is drowning out the very realistic new failure modes.
New AI coding failure modes including codebase erosion (from the explosion of new code), increasing token cost (as more complex codebases are harder to maintain), and comprehension debt (where engineers don’t understand how the code works). Most immediately, AI coding speeds up code generation and is creating a review bottleneck.
In the worst case engineers will generate code and merge it in sight unseen with a Google style LGTM. The codebase doesn’t immediately fail, but erodes and bloats. AI bots constantly scan and try to one-shot fixes for issues, opening many PRs for review and zapping engineering time. And shipping features this fast means many are never used and never removed. As the codebase rapidly ages tasks start requiring more and more tokens to make changes. Lastly, if no new junior engineers are hired in a few years there will be no senior engineers.
This can go on for much longer than you would think. Companies that are profitable will tolerate growing costs and production incidents right up until the meeting where the project is suddenly canceled. There have always been new technologies that get big budgets lasting years that are finally canceled with nothing to show. While often the damage is just a canceled project, occasionally a company goes bankrupt and makes the news.
AI also makes some software cheap to clone. A clone is only a threat if it persists, and to persist, it has to solve the same maintenance problems. But a cheap clone can still be deadly as we saw with Sun.
Every new failure will show up the way failures always have: outages, incidents, and surprise bills. When a failure reaches a tipping point, managers will notice and will push for fewer of them. In Persistence Mechanics I show that what persists isn’t the best, it’s whatever doesn’t get filtered out. Companies are complex systems with many failure points beyond software. Past the point of avoiding AI failures the pressure to adapt falls off quickly and in fact overhauling to best practices has costs and pressures against it. So the new normal won’t be across the board best practices, but more mundane. Using this we can review failures and make almost boring predictions about what will become the new normal for the software industry. Depending on the company and the work different failures will be hit first.
Bad AI code reaching production. CI/CD gets a lot of the attention in AI software engineering, embracing more verification, more linting, and anything to help AI work and prevent bad AI code from accidentally getting out. Rather than waiting for a PR from agents it helps guide the entire process from ticket triage all the way to PR. It also extends to monitoring production environments for failures, managing agents, and the bug backlog. Ironically the CI/CD systems might get slower the exact moment we want them to be faster to match AI speed.
Too many agent PRs. With agents able to open countless PRs that humans have to review, every manually rejected AI PR will be seen as an opportunity to improve the CI/CD system. As backlogs grow teams will make improvements to reduce the volume of PRs agents can open such as cleaner APIs, batching or auto-merging. The end game for many PR’s will be the elimination of human review.
Comprehension debt. Code remains the source of truth and so new ways of understanding it will appear. Reviews that are not rubber stamped will shift to focus on specifications, property tests, or unit tests that verify behavior. Coding harnesses that teach engineers about the codebase and what the AI is doing will replace coding harnesses that simply require the user to hit ‘enter’. Modularization will help compartmentalize knowledge based on API boundaries. Tooling or AI is used to explain how the code works.
The missing junior engineers. Juniors have always needed to gain skills and judgment through mentorship and feedback. The new apprenticeship will be that juniors translate messy product requests into evals (examples: unit test suites, OpenAPI schemas, Pydantic models, state machines, and fuzzing corpuses) for AI to implement. Between seniors reviewing and the AI implementations junior engineers will be forced to learn how to think through problems.
Runaway token costs. To reduce runaway token costs, using local, cheap, and expensive AI lab models together will become common. CFOs will look to have predictable costs and we will start seeing things like a shared Mac Studio appearing in offices or fixed bucket pools.
Code bloat. Cheap AI code results in much more code quickly which can degrade code bases over time and results in increasing costs (See SlopCodeBench). Modularization, isolation, etc will be employed to reduce the cost curve. New pruning pipelines or skills/tools will be made entirely around shrinking the codebase. Already teams are exploring ways to regenerate modules to solve aged code.
Security. The AI instigated security crisis will result in more standard modularization, containerization, and sandboxing to reduce the blast radius when things go wrong along with some form of automatic preemptive self-attacking by AI.
Where the Market Goes. Things that do not harmonize with AI coding will move out in favor of those that do harmonize with AI. For example looking at languages:
From the security aspect, slow compile times, and the higher token costs, C++ will be avoided. Some existing C++ will be stripped down to only a library and put inside WASM or fully converted to another language like Rust.
C# or Go, which AI handles reasonably well, probably won’t convert to anything else.
Typed languages like TypeScript will continue its adoption over Javascript.
BEAM languages like Elixir and Gleam, whose isolation keeps maintenance costs and blast radius small, won’t take over, but they’ll grow.
Language features that help AI such as runtime observability, fast compile, isolation or Go’s built in fuzzing will grow in usage.
As teams adapt a wave of postmortem blogs will follow describing how to prevent the new class of failures. A tiny group will push the limits and rave about how they use a mix of Elixir/Gleam with Antithesis to test their work. I am guilty of this and previously I wrote a Manifesto for AI Software Development on optimizing for AI engineering and Fitness-Driven Software Engineering outlined how to exploit AI velocity in a mathematically optimal way to go even beyond “AI Loops”. While there is value in understanding how to really take advantage of change, persistence matters more than being optimal.
Dark software factories where no human reads or writes code is being touted as a possible solution.
Most engineers would define it to mean that at least one type of change can ship with no human involved. A crash is seen in the logs, AI writes the fix, and it goes out on its own is one example. In manufacturing terms, that’s a dark line, not a dark factory. By that definition, I was building them before AI. We just called it insanely good CI/CD. I even had tools that could parse, modify and generate some C++ for some basic “AI-like” behaviors. This had (and still has) immense value: the faster validation and deployment were, the more a small team of engineers could deliver. Give those same engineers AI, and rather than writing boolean pass/fail tests they define a fitness function and let AI loop trying to beat the previous high scores.
Not many companies historically invested to capture this value. When an engineer took a week to write a change, a very slow CI/CD process of weeks or months didn’t stand out. When AI delivers the change in an hour, the pipeline becomes most of the wait. That’s Amdahl’s law: speed up one part, and the parts you didn’t speed up dominate. Just because the potential value is more visible (especially visible given AI hype) doesn’t mean there is actual value to capture. If the company never found it worth capturing even when it was paying expensive engineers to wait, that suggests speed might never have been the constraint. For many, building a dark line to capture this velocity will be good enough, if they get that far.
While I can build a dark line with human engineers monitoring and setting goals today, making a fully AI managed dark software factory that can persist is a fundamentally different beast and most won’t attempt to build one. The AI needs to preserve maintainability, recognize obsolete requirements, manage costs, and respond when the business changes. And the hardest problem of all, removing code. Inability to purge trash is one of the most common ways complex systems fail such as in cells, companies, or software. While each problem is tractable and I have experiments on each, many require deep changes in the way software is developed. There is a reason I have spent the last two years working on a scientific paper on the mechanics of persistence. Today if you let AI churn on a codebase unsupervised for a year, it won’t survive.
Chasing a dark software factory can be a shiny distraction from a competitor who will start with a clean codebase, a dark line, and smaller margins. Everyone loves to talk about what AI can build, but competing with new competition will require the opposite: removing code, features, even whole product lines. The difficulty of simplifying a persistent dark factory is the exact same systems problem companies will face. These new competitors with their dark line first attitude also create a new evolutionary pressure on the standards for software engineering.
AI coding as seen today is being bolted onto existing processes. Most teams will adapt their process just enough to avoid failures working to build a dark line. They get a better velocity, a growing token bill, a more opaque codebase, all for similar business outcomes. Dark lines are the realistic future of coding and are impressive, becoming standard for security patching and incident remediation first. Teams that get it working will be celebrated but they will stop short of any further drastic change. Against the sweeping promises of 10x engineers and growing revenue, the emperor has no clothes. The future of AI coding is familiar and boring.
But boring doesn’t mean safe. The questions worth asking at every level are less about the velocity AI might bring and much more about survival:
Engineers: How do you prevent bad generated code from getting out and would you know if it did?
Managers: Can you tell what changes actually matter to customers? What can be removed?
Directors: What metric will you use to pull the plug on a failed AI coding project?
VPs: What teams and codebases are most vulnerable to AI code? How quickly and accurately do customers needs reach engineers? What products should be sunset?
CEOs: Are your customers leaving for something your business model doesn’t produce?
It doesn’t matter if it is easy to build things if the system doesn’t persist.