LLMs Haven't Solved the Software Maintenance Problem

In 2025, 60% of code committed to production is generated by large language models. This has not reduced headcount or shortened timelines. Instead, it has shifted the bottleneck from writing code to reviewing it.

We are seeing a massive increase in PR volume without a proportional increase in product velocity. Engineers are now janitors for model-generated boilerplate. The cost of maintaining a line of code remains constant, even if the cost of writing it fell to zero.

The LLM Landscape

The market has consolidated around four distinct categories of tools. Most teams use a combination of local execution and cloud orchestration. The performance floor has risen, making basic completion a commodity.

• Autocomplete extensions like Cursor and GitHub Copilot remain the primary interface for individual contributors.
• Agentic workflows through tools like Devin or OpenDevin handle discrete tickets but require high-latency supervision.
• Context injection layers like Greptile and Sourcegraph Cody attempt to solve the repository-scale knowledge problem.
• Fine-tuned local models using llama-3.1-70b or deepseek-v3 running on private infrastructure allow for data sovereignty.

Context windows now exceed 200k tokens regularly. This permits loading several modules and their documentation directly into the prompt. However, larger windows increase the risk of the model ignoring specific edge cases or constraints.

Context Sensitivity Issues

Retrieval-Augmented Generation (RAG) is the primary way tools understand your codebase. Most implementations rely on vector databases like Pinecone or Milvus. They chunk code into blocks, which often breaks the semantic meaning of classes and methods.

If your RAG system chunks a file at src/utils/auth.ts mid-function, the model loses the logical flow. We see an average of 14% hallucination rate in internal PRs when the context window misses relevant type definitions. Cross-file dependencies are the most common failure point.

1. The tool searches for relevant files based on user input. 2. It ranks fragments based on cosine similarity.

1. It injects these fragments into a system prompt. 4. The model predicts the next tokens based on this incomplete picture.

This process is lossy. You cannot replace a senior engineer's mental map of a 500k LOC repository with a simple vector search. The tools lack a global understanding of the architectural constraints.

Real World Impact

Quality metrics across the industry are trending downward. While build success rates remain high, logical errors in production are up 22% year-over-year. Engineers are approving PRs they do not fully understand because the diff looks clean.

Unit tests are also being generated by the same models that write the implementation. This creates a circular logic loop. If a model writes a bug and then writes a test to confirm that bug, your CI pipeline will still pass.

Engineers at git11 analyzed 10,000 repositories using openai-o3-mini for code generation. We found that 40% of the suggested fixes for security vulnerabilities introduced a different, secondary vulnerability. The models optimize for syntax and local logic, not global security posture.

The Architecture Tax

We are seeing a return to monolithic architectures. AI tools struggle with microservices because the context is fragmented across multiple repositories. It is easier for a model to reason about one large main.go file than 20 distinct services with separate proto definitions.

• Models perform better on repetitive, standard patterns like CRUD operations.
• Non-standard architectures lead to higher failure rates in code generation.
• Standardizing on a single library for data fetching or UI components improves model accuracy.

Teams are now forced to write code that is "AI-readable." This means flattening deep inheritance trees and avoiding overly clever abstractions. If a human finds a code pattern complex, a model will likely fail to maintain it.

Tooling Evolution

Integrated Development Environments (IDEs) are becoming thinner. The heavy lifting happens on remote clusters. Tools like Cursor have shown that the IDE must be built around the model, rather than the model being a plugin for the IDE.

When you use cmd+k in Cursor, the tool sends a snapshot of your current file and recently visited files to an inference server. It uses LSP (Language Server Protocol) data to provide type-safe completions. Without high-quality LSP metadata, the model is guessing.

We recommend maintaining an updated tsconfig.json or pyrightconfig.json. These files serve as the ground truth for both your compiler and your AI assistant. If your types are any, your AI output will be garbage.

The Review Bottleneck

Technical leads are spending 4-6 hours a day on PR reviews. This was unheard of in 2022. The volume of code being moved is too high for meaningful human oversight. We are reaching a point where we need AI to review the AI.

Automated review tools like Codium or PR-agent catch low-hanging fruit. They can find missing error handling in a try-catch block. They cannot tell you if a new feature makes sense for the roadmap or if it breaks a subtle business rule.

1. Model generates code. 2. Linter catches syntax errors. 3.

CI runner executes unit tests. 4. Automated reviewer flags obvious logic gaps. 5. Senior engineer performs a final sanity check.

Each step in this chain is a filter. Even with these filters, the sheer volume of code means more bugs make it to the main branch. Velocity is an illusion if it leads to a week-long outage.

Benchmarking Accuracy

Generic benchmarks like HumanEval are useless in 2025. These datasets are part of the training data for every major model. To get a real sense of performance, you must test against your internal, private codebase.

At git11, we track a metric called Code Acceptance Rate (CAR). This measures how many suggested lines of code remain in the repository after 30 days. Most tools hover around 45%. The other 55% is deleted or rewritten during the debugging process.

• gpt-4o maintains high general logic accuracy.
• claude-3.5-sonnet excels at UI and frontend components.
• o1-pro handles complex algorithmic tasks but is too slow for real-time completion.

Choosing the right model for the specific task is now a core engineering skill. You don't use a hammer for a screw, and you shouldn't use a reasoning model for basic CSS fixes.

Security and Privacy

Security is the biggest barrier to adoption in enterprise environments. Sending source code to third-party APIs is a non-starter for many regulated industries. This has led to the rise of inference-at-the-edge.

Running llama-3-8b locally provides zero-latency responses and keeps data on the machine. The trade-off is intelligence. Local models still struggle with complex refactoring that spans multiple directory levels.

We expect companies to begin training small, specialized models on their own high-quality code. This creates a flywheel. You use a large model to clean your legacy code, then train a small model on that cleaned code for daily use.

The Future of the Engineer

The role of the Junior Engineer is disappearing. Companies are hiring fewer entry-level developers because AI can do the work of a junior faster. This creates a talent gap. If we don't train juniors today, we will have no seniors in five years.

Senior engineers are becoming system architects and editors. You must be able to read code faster than you can write it. You must be able to spot a subtle flaw in a 200-line diff in seconds. This requires more fundamental knowledge, not less.

Stop focusing on syntax. The syntax is solved. Focus on system design, data structures, and state management. These are the areas where AI still fails most frequently.

Engineers who rely solely on AI to solve problems will eventually find themselves unable to debug the output when things break.