The SDLC Didn’t Go Away. It Became the Floor.
The prediction, repeated confidently by people who had not shipped production software in some time, was that AI would render the traditional software development lifecycle obsolete. That Git, Jira, Scrum, pull requests, code review, test coverage, deployment pipelines, and runbooks were artifacts of an era when humans had to type code, and that in an era when AI typed the code, these artifacts would wither.
The prediction was wrong in a specific way that is worth naming.
The SDLC did not go away. What changed is that the SDLC stopped being the specialized skill of a tenured engineer and became the entry requirement for anyone who wants to do the work at all.
The same tools. The same rituals. Different reason for their existence.
What AI actually removed
It is true that AI removed some things. It removed the typing. A developer who used to spend three hours writing a CRUD endpoint now spends fifteen minutes describing what the endpoint should do and reviewing what the AI wrote. The typing is gone, and it is not coming back.
AI also removed the syntax memorization. The specific declension of arrow functions, the exact import path of a utility, the right regex flag for this situation. These small frictions used to constitute a meaningful fraction of a day, and AI abolished them. The developer does not have to remember things the AI can look up. That is a real and permanent gain.
What remains is everything else. And the everything else is where the work has always lived.
What AI did not remove
Read a pull request AI generated this morning. You will find:
Code that looks right but references a function that does not exist. Code that calls an external API with the wrong authentication pattern. Code that handles the happy path and has no idea what the error cases are. Code that introduces a dependency the rest of the codebase does not use. Code that duplicates a utility that already exists elsewhere in the repo. Code that works in isolation and will not compose with the three adjacent modules when they are all integrated. Code that passes the tests the AI also generated, because the tests were derived from the same misunderstanding as the implementation.
Catching these things is the work. It has always been the work. Before AI, you had to read pull requests from colleagues who were capable of the same errors, and the act of reading those pull requests was where senior engineers earned their seniority. After AI, the pull requests come faster and in higher volume, and the errors are subtly different in texture, but the act of reading and judging remains. It is now the highest-leverage skill in the work.
Git stayed because history matters. You need to know what changed, when, why, and by whom. AI-generated commits make the history denser, not clearer. The engineer who cannot navigate a git log is now blind in a way they were merely short-sighted before.
Jira stayed because work needs to be decomposed. The story point estimation has become less useful, because AI collapsed the actual doing. But the decomposition remains, and the decomposition is now the harder part, because AI will happily generate code against any decomposition, including bad ones. The skill of reading a spec and noticing that the spec cannot be built from what it contains, that skill survived intact. It is more valuable than before.
Scrum or whatever its descendant becomes, stayed because teams still need rhythm. AI did not remove meetings. AI removed typing. These are different problems. A team that ran badly before AI runs badly after AI with more code output to show for it.
What became more important
Reading code became the single most important individual skill on a software team. Before AI, reading was a sub-skill under writing. You read code your colleagues wrote, and you read it with the assumption that they had understood what they were doing. After AI, you read code that was generated without understanding, and you are the first human in the loop. Your reading is not reviewing their reasoning. It is supplying reasoning the code did not have.
Architectural judgment became load-bearing in a way it was not before. AI operates at the level of files and functions. It does not hold the shape of a system. Someone has to. That someone is now the person whose decisions determine whether twenty thousand lines of generated code cohere into a system or drift into a pile. The ability to say “this function is in the wrong layer” or “this module should not know about that module” used to be an opinion senior engineers held. It is now the structural work of keeping the whole from collapsing.
Code review became the operational surface. A review comment on a pull request used to be feedback. It is now direction. The reviewer is not suggesting changes to a peer who will think about them; the reviewer is instructing a system that will regenerate against the new direction. Review comments that used to be editorial are now executable. A sharp reviewer with Miracle running in the background can steer a codebase with the leverage that previously required running a whole team.
Versioning discipline became a survival skill. When the code arrives faster than a human can internalize it, the only way to maintain a mental model is through disciplined branching, clean commit messages, small-step PRs, and change logs that explain the why. The engineers who treated version control as bureaucratic ritual are now drowning in their own generated code, because they cannot find the moment they broke something.
The skills that look the same are doing different work
This is the subtle point, and it is the point most of the current discourse misses. The SDLC skills look the same on the surface. A pull request review before AI and a pull request review after AI both involve opening a diff, reading code, and leaving comments. The procedural appearance is identical.
The work inside the procedure is not identical.
Before AI, reviewing a pull request was checking whether a colleague had correctly implemented something they both understood. The colleague had already done the understanding. The reviewer was auditing.
After AI, reviewing a pull request is supplying the understanding. The AI did not understand. The reviewer is not auditing; the reviewer is completing. The same activity, pull request review, is now doing twice the work because it has absorbed a task that used to be upstream of it.
This is why senior engineers who thought they could step back from code review because AI would “handle the small stuff” are finding they cannot. The small stuff is not small anymore. The small stuff is where the system’s coherence lives. AI can type the small stuff. It cannot supply judgment about whether the small stuff is coherent with the rest. The senior engineer who stepped away is stepping back in, and doing so with some surprise at how much has changed.
The floor is not a barrier. The floor is where the practice starts.
There is a reading of this essay that sounds like gatekeeping. That the SDLC skills are a threshold you must cross before you can work in software, and anyone who has not crossed is unwelcome.
That is not the argument.
The argument is that the skills that used to be optional polish are now the place where the real work happens. This is not a barrier. It is a relocation. A person who did not know Git well a decade ago could contribute to a team by writing code that a senior engineer would clean up. A person who does not know Git well now contributes less, because the senior engineer is spending their review capacity on AI output, not on tutoring a junior who refuses to learn rebase.
The invitation is different. It is not “learn these things before you are allowed to participate.” It is “learn these things because they are where the participation has moved to.” The typing has been abstracted. The craft has surfaced. The craft is what the SDLC always pointed at, and the SDLC tooling is how we hold it.
A new practitioner arriving today can cross this floor faster than any previous generation, because they do not have to fight the typing while they learn the reasoning. They can spend their first year doing nothing but reading pull requests, thinking about architecture, and watching experienced reviewers work. The typing is not their problem. The reasoning is the work they get to focus on from day one.
This is a better position than any generation of new practitioners has ever occupied. It is also an exposed position, because there is no typing layer to hide behind if the reasoning is not there yet.
What this means for the Modern Principal
The Modern Principal is not the engineer who stopped using Git because they do not need to type code anymore. The Modern Principal is the engineer whose use of Git has become more precise, not less, because the code moving through their branches is no longer code they wrote from scratch, which means their review discipline, branching strategy, and commit hygiene are the mechanisms that keep the generated output coherent.
The tools are the same. The operator is the same. The purpose of the operation has shifted from producing code to coordinating generated code into a system.
That shift is not a demotion for the SDLC. It is a promotion. The SDLC used to manage the output of a team of typists. It now manages the output of a system producing more code per hour than any previous team of typists could, which means the SDLC is doing exponentially more work than it used to. The tools that carry this load are the same tools. The practitioners who wield the tools are the same practitioners. The work is unrecognizable.
The practitioner who understands this is standing on the floor and looking up at the practice. The practitioner who does not is standing on the same floor and wondering why the ceiling fell.