A year ago the question was whether coding agents could complete real tasks. Through 2025 they answered it: agents now routinely fix bugs, add small features, write tests and upgrade dependencies in real codebases, and they open pull requests that are merged after review.
The question for 2026 is harder and more important: can AI build and maintain software, keeping a system coherent, secure and operable over months and years as requirements, dependencies and people change?
Building is not the hard part
Most of the cost of software is not writing it the first time. It is everything afterwards:
- understanding why the code is the way it is,
- changing it without breaking something else,
- keeping dependencies, runtimes and APIs current,
- handling incidents and operational surprises, and
- preserving a coherent design as dozens of people (and now agents) change it.
Those are exactly the areas where autonomy is hardest.
Where agents are strong
Agents do best when a task is bounded and the result is cheap to verify:
- Bug fixes with a reproduction. A failing test is a precise specification.
- Dependency and framework upgrades. Mechanical changes across many files, verified by the build and tests.
- Test coverage. Writing tests for existing behaviour, especially characterisation tests before a refactor.
- Migrations. API version changes, deprecated function replacements and configuration format changes.
- Flaky test investigation. Running tests repeatedly and analysing logs is tedious for humans and easy for agents.
- Security fixes for well-understood findings, such as dependency CVEs and SAST alerts with clear remediation.
This is maintenance work that teams chronically under-invest in. It is where agents deliver the most dependable value today.
Where agents struggle
Long-horizon coherence. Each agent task optimises locally. Over hundreds of changes, without a guiding design, a codebase can drift into inconsistency: three ways of doing the same thing, duplicated helpers and leaky abstractions.
Implicit context. Why a feature exists, which customer depends on a quirk, what was tried and abandoned last year: this knowledge often lives in people's heads and old conversations, not in the repository.
Trade-offs. Performance versus cost, consistency versus availability, speed versus safety. These need judgement about the business, not just the code.
Weak verification. Where tests are thin, "the tests pass" does not mean the change is correct. Agents can satisfy the letter of a check while missing the intent.
Operations. Diagnosing a production incident in a live system, under uncertainty, where actions are hard to reverse, is a poor fit for unsupervised autonomy.
Matching autonomy to risk
Rather than asking "should we let agents do X?", ask how verifiable and how reversible the work is.
quadrantChart title Autonomy by verifiability and reversibility x-axis Hard to verify --> Easy to verify y-axis Hard to reverse --> Easy to reverse quadrant-1 High autonomy quadrant-2 Agent drafts, human decides quadrant-3 Human-led quadrant-4 Agent with approval gates Dependency upgrades: [0.8, 0.85] Test generation: [0.75, 0.9] New feature: [0.45, 0.6] Schema migration: [0.6, 0.2] Architecture change: [0.2, 0.35] Prod incident actions: [0.3, 0.1]
- Easy to verify, easy to reverse (upgrades, tests, lint fixes): agents can work with high autonomy, with automated checks and light review.
- Easy to verify, hard to reverse (data migrations, infrastructure changes): agents can prepare the work, with human approval before execution.
- Hard to verify, easy to reverse (new features, UX changes): agents draft and humans decide, with feature flags to limit exposure.
- Hard to verify, hard to reverse (architecture, security-sensitive design, production operations): human-led, with agents in a supporting role.
Making maintenance agent-friendly
Teams that get sustained value from agents invest in the things that make any maintainer effective:
- Architecture decision records in the repository, so the why is available to humans and agents alike.
- Agent instructions files with conventions, commands and areas that need extra care.
- Strong, fast tests, including contract and property-based tests for critical logic.
- Linters and architectural checks that enforce module boundaries and patterns automatically, so drift is caught early.
- Ownership: a human owner for each area, responsible for curating its design.
- Regular "gardening": scheduled agent tasks for upgrades, deprecations and small refactors, reviewed by the owners.
So, can AI maintain software?
Partly, and increasingly. Agents can already carry much of the routine maintenance load, which in many organisations is the work that never gets done. They cannot yet be trusted to own a system's long-term coherence, make product trade-offs or run production unsupervised.
The practical model for 2026 is agents as tireless maintainers under human stewardship: humans set direction, guard the architecture and make judgement calls, while agents do an ever-larger share of the implementation and upkeep.
Our secure SDLC team runs agent-assisted maintenance programmes for client codebases, and our agentic AI security practice helps teams design the guardrails around them.
