Predictions we are willing to be wrong about
Seven claims about where the ADLC goes next, each with a date and a stated condition that would prove it wrong. A prediction nobody can check is not a prediction.
Clearing out a shared drive last year, someone on our team found a slide deck from 2021 called Engineering in 2025. It had eleven slides and forty-odd bullet points, and by the time we read it the future it described had already arrived and gone. So we did the obvious thing and marked it. We tried to score every claim right and wrong.
We could not score a single one.
Not because the deck was stupid. It was a perfectly respectable deck. It said things like “tooling will consolidate,” “developer experience becomes a strategic priority,” “AI-assisted workflows move from novelty to norm.” Every one of those is arguably true. Every one of them is also arguably false, depending on what you count and where you look, and there is no measurement anyone could have made in 2025 that would have settled it. The deck was not a forecast. It was a mood, written in the future tense.
This is the last series in a library of a hundred pieces about the Agentic Development Life Cycle, and the whole library rests on a set of claims about where software development is going. It would be cowardly to end without writing those claims down in a form that can be marked. So here are seven. Each has a date. Each has a stated condition under which we would have to say, in public, that we got it wrong.
The final section is the one that matters most, because it names the prediction we think is most likely to fail, and that prediction is closer to the centre of our argument than we would like.
Why bother with falsifiability
There is a reason vendor predictions are vague, and it is not laziness. Vagueness is load-bearing. A claim like “AI will transform software delivery” cannot be wrong, which means it can be repeated indefinitely, which means it costs nothing to make. The moment you attach a date and a threshold, you have created something that can embarrass you later.
That is exactly the point. The argument running through this library is that a definition of done which cannot be checked is not a definition of done, it is a hope. The piece on why “works correctly” is now a production incident makes that case about acceptance criteria. It applies with at least as much force to the people writing about acceptance criteria. If we ask engineering teams to convert their vague intentions into machine-checkable outcomes, we should be willing to do the same to our own opinions.
So each prediction below has three parts.
One honest caveat before we start. Several of these are about industry-wide behaviour, and industry-wide behaviour is hard to observe cleanly. Where we can, we have anchored the falsifier to something publicly checkable: shipped product features, published metric definitions, job postings, the visible contents of open repositories. Where we could not, we have said so and marked the prediction as weaker for it.
One: the tracker stops being the system of record
Claim. By the end of 2028, at least one of the four major issue trackers will ship a first-class ticket state that is derived from repository activity and cannot be set by hand.
Not an automation rule you configure. Not a webhook someone wires up. A state whose only legitimate source is the code, presented in the product as such, with the manual drag-and-drop path removed for that state specifically.
The reasoning is in the Foundations piece on why the tracker became the weakest link. Trackers were designed around an assumption that a human moves the card, and that assumption is now false for a growing share of the work. Vendors will notice this the way vendors always notice things, which is slowly and then all at once when a competitor does it first.
Falsifier. If January 2029 arrives and every mainstream tracker still treats manual state change as the only first-class path, with repository-derived state available exclusively through user-configured automation, this prediction is wrong. We will also count it wrong if a vendor ships something with the right label but leaves manual override on by default with no audit distinction, because that is the old model with new packaging.
Confidence. Moderate. Incumbents move slowly, and the workaround layer is good enough that the pressure on them is indirect.
Two: acceptance criteria move out of the ticket
Claim. By the end of 2029, storing acceptance criteria as versioned files alongside the code will be a recognisable mainstream practice rather than an unusual one, in the same way that infrastructure-as-code moved from odd to obvious between roughly 2013 and 2018.
The Open Knowledge series argues this at length. Criteria in a ticket description are trapped: they are not diffable, not reviewable in the same pass as the code they govern, not portable when you change tools, and not readable by an agent without an API call and a permission grant. Criteria in the repository are all of those things. Once teams need agents to read the criteria on every run, the friction of the ticket field starts to bite in a way it never did when only humans read it.
Falsifier. This one is harder to check, so we will make the test concrete: if by the end of 2029 the widely used agent development tools do not have a documented, conventional place to look for acceptance criteria in a repository, and the dominant pattern is still fetching prose from a ticket API at run time, we were wrong. A convention emerging and then being ignored also counts as wrong. Adoption, not existence.
Confidence. High, with a caveat. We think the direction is close to inevitable and the timing is the risky part. Five-year practice shifts routinely take eight.
Three: review splits into two different jobs
Claim. By the end of 2028, teams operating at high agent output will treat “review every change equally” as a visibly obsolete practice, and the split described in the SDLC-versus-ADLC piece on review moving from gatekeeper to sampler will be normal enough to appear in job descriptions.
Two jobs, not one. Sampling, which is statistical and asks whether the population of changes is healthy. Adjudicating, which is deep and applies to the small subset of changes where the risk actually lives. Those are different skills, different tools and different cadences, and pretending they are the same activity is the root of the review fatigue described in the Failure modes series.
Falsifier. If mature agent-heavy teams in 2029 still describe review as one undifferentiated activity, with one reviewer per pull request and no risk-based routing, we were wrong. A weaker version of wrong: the split happens but purely through tooling defaults, with no change in how teams describe the work or who does it. We would count that as half right at best.
Confidence. High. This one is already visible in early form.
Four: a criteria-conformance metric joins the standard set
Claim. By the end of 2030, at least one widely cited engineering-performance framework will include a measure of whether delivered work matched its stated criteria, alongside the throughput and stability measures everyone already reports.
The Metrics series makes the argument. The four keys measure how fast and how safely change moves. None of them measures whether the change was the change anyone asked for, which was a reasonable omission when a human author held the intent and simply knew. It is not a reasonable omission now. A team can post excellent delivery numbers while shipping a steady stream of work that satisfies the letter of a badly written ticket, which is the elite-scores-rotting-board problem.
Falsifier. If the major published frameworks in 2031 still contain no measure of conformance to intent, and practitioners still treat throughput and stability as the complete picture, we were wrong. We are not predicting that our preferred name for it wins. Any conformance measure, under any label, counts as us being right.
Confidence. Moderate. Metric frameworks are conservative by design, and rightly so.
Five: governance theatre arrives before governance does
Claim. By the end of 2027, there will be a visible market in AI-development-governance attestations that can be obtained without any inspection of an actual repository: policy documents reviewed, controls described, questionnaires completed, badge issued.
This is not cynicism, it is pattern recognition. Every previous compliance wave produced a paperwork layer first and an evidence layer second, because paperwork is cheap to sell and evidence is expensive to produce. The demand is real: boards will ask what controls exist over agent-authored code, and someone will need to answer by a deadline.
Falsifier. If the attestation schemes that emerge by 2028 all require artefact-level evidence, sampled from real repositories, we were wrong and pleasantly so. We would also count ourselves wrong if the paperwork layer appears but is broadly rejected by buyers rather than bought.
Confidence. High, unfortunately.
Six: brownfield agent share plateaus, and stays plateaued
Claim. Through the end of 2029, the share of merged code authored by agents in large, old, poorly documented codebases will remain substantially below the share in new codebases, and the gap will not close through model capability alone.
The Transition playbook piece on brownfield-first covers the mechanism. Agents do not fail in legacy systems because the code is hard to write. They fail because the constraints are undocumented, the dependencies are undeclared, and the reasons behind twelve years of decisions live in the heads of four people. That is a knowledge problem, not a capability problem, and knowledge problems do not get solved by a better model. They get solved by writing things down, which is slow, human and unglamorous.
Falsifier. If a well-instrumented team working in a codebase more than a decade old sustains a majority of merged changes as agent-authored for a year, with change failure rate flat or improved, and does so without a preceding investment in written-down constraints, we were wrong. That last clause matters. If they wrote everything down first, we were right about the mechanism and merely early on the timing.
Confidence. Moderate to high. This is the prediction we would most enjoy losing.
Seven: the growth role is specification, not prompting
Claim. By the end of 2028, roles centred on writing and verifying specifications for agent execution will be more common in engineering job postings than roles centred on prompt craft, and “prompt engineer” as a standalone title will be in visible decline.
Prompting is a skill that is being absorbed into tools and into general competence, the way “knows how to use a search engine” stopped being a differentiator. What does not get absorbed is the ability to state precisely what a system must do, decide what is worth building, and check whether the thing that arrived is the thing that was needed. The Foundations piece on the bottleneck moving from typing to verifying is really about this.
Falsifier. Job posting data is public and countable. If prompt-craft titles are still growing relative to specification and verification titles at the end of 2028, we were wrong. If both decline because the whole function reorganises under some name neither of us has thought of yet, we will call it wrong rather than argue.
Confidence. Moderate. Job titles are noisy and follow fashion more than function.
Where this breaks down
Now the part that matters.
Not all seven of these will survive. That is the expected outcome of making real predictions, and if all seven came in we would suspect we had made them too safe. But they are not equally exposed, and it would be dishonest to leave you to guess which one we are worried about. So here it is.
The prediction most likely to be wrong is number two, and its failure would take a lot of this library with it.
The claim was that acceptance criteria become explicit, versioned, machine-readable artefacts because agents need them that way. The mechanism underneath is that vague criteria produce confidently wrong software, so teams are forced to write precise ones. The whole Definition of done series depends on that mechanism holding.
Here is the scenario in which it does not hold. Models keep getting better at inferring intent from thin context. They read the codebase, the git history, the past six months of similar tickets, the way this team names things, the conventions nobody wrote down. They ask a clarifying question when the request is ambiguous, and they ask a good one. And “the checkout works correctly” turns out to be a perfectly adequate instruction after all, because the system fills the gap the way a good senior engineer fills it: from context and taste rather than from literal text.
If that happens, the pressure that was supposed to force precision simply evaporates. Nobody writes structured criteria for the same reason nobody writes assembly. The layer got smart enough that the formalism became unnecessary overhead, and the teams who invested heavily in criteria discipline will have built a careful cathedral around a problem that dissolved.
We do not think this is the most likely outcome, and it is worth saying why, briefly, without pretending the argument is airtight. Inference from context is very good at recovering conventions and quite bad at recovering decisions. A model can work out how this team names things because the naming is present in the artefacts. It cannot work out that the finance team agreed in a meeting in March that partial refunds are out of scope until the ledger migration lands, because that fact exists nowhere it can read. Precision about intent is not a compression problem, it is an information problem, and no amount of capability recovers information that was never recorded. The knowledge-drift piece makes this case in more detail.
But we might be wrong about how much of real-world intent is genuinely unrecorded versus merely inconvenient to find. If most of it is discoverable from artefacts we already produce, and only a thin residue is truly absent, then a very capable system plus a good clarifying question covers nearly all of it, and the formalism only earns its keep in regulated contexts where you need the audit trail for its own sake. That would make explicit criteria a compliance artefact rather than an engineering one. Much narrower than what we have argued.
Two more places we are exposed, more briefly.
Prediction one may be right in substance and wrong in venue. We predicted trackers change. They might not, ever, and the reconciliation layer might simply live permanently outside them while the tracker degrades into a reporting view that executives look at and engineers ignore. The underlying claim, that hand-maintained state cannot survive agent-speed work, would still be right. Our claim about who fixes it would be wrong. We have written the falsifier so this counts as a loss, because a prediction you can reinterpret into a win after the fact is the vagueness problem again.
Predictions three and seven both assume the current shape of teams persists. They are claims about how a role divides and what job titles appear, and both presuppose that engineering organisations in 2029 are recognisably descended from engineering organisations today: pull requests, reviewers, sprints, postings on job boards. If the unit of work itself changes shape, if the pull request stops being the atom of change in the way the governance piece describes it, then these predictions are not so much wrong as inapplicable. We will mark inapplicable as wrong. It is the more honest scoring.
There is also a structural bias here that you should weigh. We build tooling in this space. Every one of these predictions, if it comes true, describes a world where that tooling matters more. That is not a reason to dismiss them, since people who work on a problem usually see it earlier than people who do not, but it is a reason to read the falsifiers more carefully than the claims. The falsifiers are the part we had to write against our own interest.
What we are not predicting
Three things we have deliberately left out, because we do not have a defensible view and would rather say so.
We are not predicting a number for how much code agents write in five years. Everyone wants that number, nobody can measure it consistently, and every published version of it means something different depending on whether you count lines, changes, accepted suggestions, or reverted work. A number nobody can measure the same way twice is not a prediction, it is a talking point.
We are not predicting the shape of the model market: who wins, what things cost, whether capability curves bend. We have no advantage there and neither does anyone else selling you a life cycle framework.
And we are not predicting headcount. The question of whether engineering teams get smaller is genuinely open, it depends far more on demand for software than on the productivity of building it, and anyone claiming confidence in either direction is guessing with a straight face.
The takeaway
Seven claims, four dates, seven stated conditions for being wrong. The one we expect to lose is the one about acceptance criteria becoming explicit artefacts, and if we lose it, a meaningful part of the argument in this library needs rewriting rather than defending.
We would rather be legibly wrong than illegibly right. The 2021 deck we found in the shared drive was probably right about most things. It will never get credit for it, because it never said anything specific enough to be marked. That is a worse fate than being wrong.
The final piece in this collection looks at the same horizon from the other side. Not what changes, but what does not: the judgement about what is worth building, the taste that separates adequate from good, and the person who still has to answer when an agent gets it wrong.