The two assumptions the SDLC was built on, and why agents break both
A human wrote the change. A human kept the plan honest. Take those apart one at a time and you can see exactly which load-bearing wall agents removed.
Open any pull request written by a person in 2019 and read only the description. Not the diff. Just the description.
You will usually find something like this: a sentence about what the change does, a sentence about why this approach and not the other one, a note that says “I left the caching alone for now because it interacts with the session logic and I want to do that separately,” and a link to a ticket. Four lines. Maybe six.
Those four lines are doing an enormous amount of work, and almost none of it is documentation. They are a compressed transfer of judgement from one head to another. The reviewer reads them and immediately knows what to look at, what has already been thought about, and what the author is nervous about. The review that follows is short because most of the expensive thinking already happened and the description is a receipt for it.
Now open a pull request written by an agent. The diff is often better. The description is a summary of the diff.
That difference is small on the page and structural underneath, and it is the first of the two assumptions coming apart. This piece takes both apart properly, one at a time, because the failure modes are different and the fixes are different, and teams that treat them as one problem end up solving neither.
Assumption one: a human writes the change
The software development life cycle never says “a human writes the code” out loud. It does not have to. Every mechanism in it is shaped around the fact.
Consider code review. Code review is not primarily a correctness check. If it were, we would have automated it decades ago, and the parts of it that are genuinely correctness checks (types, lint, tests, static analysis) we did automate, immediately, and stopped thinking about. What remains in human review is a bundle of things that are hard to name: does this fit how we do things here, is this the right layer for this logic, is the author about to walk into a problem they cannot see yet, is this the change we actually wanted.
All of that rests on a scarcity assumption. Writing a change was slow. Because it was slow, it was rare. Because it was rare, a team could afford to look at each one with real attention. The economics of review worked because production was the constraint.
Three things travelled inside a human-authored change, and it is worth being specific about them because they are what actually went missing.
Intent. The author knew what problem they were solving, in the full messy sense, including the version of the problem that was never written down anywhere. They knew the ticket said “add retry logic” but the actual thing that happened was that the payments provider had a bad Tuesday and someone senior got a phone call. That context shapes a hundred small decisions inside the change.
The negative space. What the author considered and rejected. This is the most valuable and least recorded part of any change. A human developer who chose approach B has, in the process, learned why approach A does not work, and that knowledge sits in their head where it will be available in three weeks when someone suggests approach A again. The change itself never shows it. The person does.
Calibrated uncertainty. Humans know which parts of their own work they are unsure about. The uncertainty is unevenly distributed and the developer knows the distribution. “The parsing is fine, the concurrency I am less sure about.” A reviewer given that map reviews well. A reviewer without it reviews uniformly, which means shallowly.
An agent-authored change can carry the first one if you give it to it properly, which is the entire argument for machine-readable acceptance criteria. It can be made to carry a version of the second if you ask it to record what it tried. The third is the hard one. Model confidence and model correctness are only loosely related, and a fluent, well-structured, confidently worded description of a wrong change is exactly what you get by default. The failure is not that agents are less capable. On many tasks they are more capable. The failure is that the signal a reviewer used to triage with is gone, and the volume that signal was protecting against went up at the same time.
So the first assumption breaking is not a quality problem. Treating it as a quality problem is the standard mistake, and it leads teams to argue about whether the code is good, which is the wrong argument. It is a triage problem. You have lost the mechanism that told you which of the forty changes this week deserve an hour and which deserve ninety seconds.
Assumption two: a human updates the plan
The second assumption is even quieter, because it hides inside a piece of furniture everyone stopped seeing years ago: the board.
Every tracker ever built assumes a person moves the card. That is not a design flaw. It was the correct design for a world where the act of moving a card was cheap relative to the act of doing the work. If a change takes two days and updating its status takes four seconds, the four seconds are free, and you can build an entire management discipline on top of them.
Agile ceremony is, viewed unkindly, a set of scheduled interventions to correct for the fact that those four seconds do not always happen. Standup is a daily reconciliation between the board and reality. Sprint planning is a weekly one. Retro is a monthly audit of the reconciliation process itself. It is a lot of machinery, and the reason it survived is that it worked well enough at the speed things used to move.
The economics have inverted. When a change takes twenty minutes and updating its status takes four seconds, the overhead is no longer negligible, it is a fifth of a percent that arrives forty times a week and always at the moment of lowest motivation, which is immediately after the interesting part is finished. And the person best placed to update the record may not have been meaningfully involved in producing the change at all. They reviewed it. They approved it. Asking them to also narrate it into a second system is asking for clerical work in exchange for nothing they can feel.
So it does not happen. Not because anyone is lazy, but because the incentive was always thin and the volume finally made the thinness visible.
Here is the part that matters more than the inconvenience. A board that is somewhat out of date is not a mildly degraded board. It is a board with an unknown error rate, and an unknown error rate is functionally an unusable one for any decision that carries risk. If you cannot say whether the drift is two hours or two weeks, you cannot use it to decide what to cut, what to staff, or what to tell a customer. You will use it anyway, because it is the only thing available, and that is the actual damage.
Why breaking them together is different
Take them separately and each has a known remedy.
The first assumption breaking on its own gives you a review load problem. Teams have handled review load problems for a long time: sample, pair, tighten CI, push more checks left, define ownership boundaries so fewer people need to look at each thing.
The second breaking on its own gives you a data hygiene problem. Also familiar. Someone owns the board. There is a Friday tidy-up. A project manager chases. It is annoying and it works.
But look at what each remedy quietly assumes. The review remedies assume you can prioritise, which requires knowing what each change is for, which is exactly what the first break removed. The board remedies assume a human bottleneck slow enough that a weekly sweep catches up, which is exactly what the second break removed.
Each remedy leans on the assumption the other break destroyed. That is why teams report this as a strange, hard-to-name friction rather than as two solvable problems. Every individual fix feels like it should work and does not quite, because the thing it was resting on is no longer there.
Break one, alone
A review load problem. Sample, pair, tighten CI, push checks left. Familiar and solvable.
Break two, alone
A data hygiene problem. Someone owns the board, a Friday tidy-up, a PM chases. Annoying and it works.
Why the first remedy fails
It assumes you can prioritise, which needs to know what each change is for. Break one removed exactly that.
Why the second fails
It assumes a bottleneck slow enough for a weekly sweep to catch up. Break two removed exactly that.
There is also a nastier interaction. Because the board is drifting, nobody has a reliable view of what is in flight. Because nobody has a reliable view of what is in flight, work gets duplicated and re-specified. Because work gets duplicated, more changes get generated. More changes make the review triage problem worse and the board drift faster. It is a loop, and loops do not respond well to being attacked at one point.
What has to be true instead
If both assumptions are false, you do not patch them. You replace what they were providing.
The first assumption was providing a signal of what a change is for and how much it should worry you. Replacing that means intent has to be attached to the change by construction rather than reconstructed by a reader afterwards. Every change points at the thing it is meant to satisfy, and the thing it is meant to satisfy is specific enough to be checked rather than admired. This is why the definition of done stops being a wiki page and becomes an interface. Not because documentation got more important, but because the human who used to carry the intent in their head is no longer in the loop at the point where it matters.
The second assumption was providing a plan that roughly tracked reality. Replacing that means the record has to derive itself from something that cannot drift. There is exactly one artefact in a software team that is definitionally true, and it is source control, because it is not a description of the work, it is the work. Branches, pull requests, reviews, merges, deploys. Everything else in your stack is a copy of that, and copies drift at a rate proportional to how much human effort keeps them in sync. So you stop maintaining the copy and start deriving it. This is the whole idea behind reading ground truth from the repository and writing status back into the tracker rather than asking people to type it twice.
Neither replacement is exotic. Both are unglamorous. Both are considerably more work than they sound, and the second piece of work is mostly organisational rather than technical, which is why it tends to be underestimated by exactly the people best equipped to do it.
Where this breaks down
I want to be careful here, because “two assumptions broke” is a tidy story and tidy stories are the ones you should push on hardest.
The first assumption was never as strong as I have made it sound. Plenty of human-authored pull requests carried no intent at all. Copy-paste changes, rote refactors, changes made by a contractor on their second week, changes made by someone at 6pm on a Friday. The context transfer I described was the good case, not the average case. If your team was already shipping large volumes of low-context changes, agents did not break your first assumption. They just made it obvious that it had been broken for years, and the honest framing is that you are now paying attention to a debt you already had.
The second assumption breaking is not always bad. There is a real argument, and I have some sympathy for it, that the board was never worth its cost and that a team which stops maintaining it and starts talking to each other is better off. Small co-located teams with high trust genuinely can run on conversation. If that is you, the correct response to board drift may be to delete the board, not to automate it. The automation argument gets strong specifically when the number of people who need to know exceeds the number of people who can be in one conversation, which is an organisational threshold and not a technical one.
And the replacements have their own failure modes. Deriving status from source control means the derivation can be wrong, and a confidently wrong automated status is worse than an obviously stale manual one, because staleness is visible and confident wrongness is not. This is the reason any system doing this needs to be inspectable and reversible from day one rather than as a later feature. If you cannot ask why the machine moved that ticket, and undo it, you have traded a slow honest record for a fast opaque one.
Finally, the whole framing assumes agents are doing enough of the work to matter. At ten or fifteen percent of changes, both assumptions are bruised, not broken, and ordinary discipline outperforms new machinery by a wide margin. The threshold where this stops being true is not a number I can give you honestly. You will notice it as the week where the board stops being something you glance at and starts being something you argue about.
The takeaway
The SDLC assumed a human wrote the change, which supplied intent, negative space and calibrated uncertainty. It assumed a human maintained the plan, which kept the record roughly true. Agents removed both, at once, and the remedies for each break depend on the assumption the other break destroyed.
What replaces them is not ceremony. It is intent attached to changes by construction, and a record derived from source control rather than typed into a second system by hand.
The next piece gets uncomfortably concrete about the first half of this. Before you can decide how much of a problem you have, you need to know what share of your changes are actually being authored by something other than a person, and most teams have never counted.