Long Live the Vibes (or: SDLC isn’t dead, you just automated the easy part)

When I was in high school, I worked at a place called the Elastic Corporation of America. It was a manufacturing facility that made elastic bands (eg, bra straps, underwear bands) for brands like Fruit of the Loom, Victoria’s Secret, and Hanes.

The facility had four departments: Weaving, Dyeing, Finishing, and Shipping. Thread came in one end. Finished elastic went out the other. I worked in Finishing.

My job was to take dyed fabric and get it to the exact right shade, stretchiness, and poundage that the brand specified. I’d tie the fabric on one end, let it run through a trough of dye and chemicals, then feed it through a series of massive drums heated to 300°F or higher. The fabric would snake back and forth across these drums until it came out dry on the other side, dropping into boxes.

None of this was done by hand. A hundred years earlier, it would’ve been. But by the time I got there, machines handled the weaving, the dyeing, the drying, the feeding. I didn’t rub dye into fabric with my hands. I didn’t hold a hairdryer up to it. I didn’t haul buckets of water. The machines did all of that.

But I still had to read the paperwork to understand what temperature the drums needed, which chemicals went into the trough, how fast the fabric should move. I still had to take samples to my boss so he could evaluate how close we were to spec. If it was off, we’d tweak the chemicals and run it again. And if a machine broke, I had to stop the line, fix it, and throw out the fabric that had been sitting on 300-degree drums too long, because that fabric was ruined.

The machines were precise. They were fast. They were repeatable. But they had no idea whether what they were producing was correct. That was my job.

The part that doesn’t automate away

There’s a narrative going around right now that AI has killed the software development lifecycle. The argument goes something like this: coding agents are so capable that the old stages – requirements, design, implementation, testing, review, deployment, monitoring – have collapsed into a single tight loop. Intent in, working code out. The SDLC is dead. Long live the vibes.

I think this is wrong, and I think the manufacturing floor is a good lens for understanding why.

When industrial automation arrived in manufacturing, it didn’t eliminate the production process. It eliminated the manual labor within the process. The stages still existed: you still needed raw materials, you still needed to transform them, you still needed quality control, you still needed to ship. What changed was who, or what, performed each step.

The lifecycle didn’t collapse. The human role within it shifted. You went from doing the work to supervising the work. From pulling cranks to reading specs and adjusting parameters, from producing output to evaluating output.

That’s exactly what’s happening with AI and software development.

AI automates the mechanical, not the judgment

Coding agents are genuinely good at the mechanical parts of software development: generating boilerplate, writing CRUD endpoints, producing test scaffolding, wiring up deployment pipelines. The stuff that, frankly, was always the least interesting part of the job.

But the SDLC was never really about those mechanical steps. It was about the judgment calls that happen between them. What should we build? Does this design hold up under the constraints we actually have? Is this code correct? Not just syntactically, but semantically? Does this change break something downstream that the tests don’t cover? Are we done?

Those questions don’t go away because an agent can generate code faster. If anything, they get harder. When an agent generates 500 changes in a day, the question isn’t “how do we review all of these?” It’s “how do we know which ones matter?” That’s not a tooling problem. That’s a judgment problem. And judgment is exactly what the SDLC exists to structure.

Knowing when you’re done is the actual job

The trickiest part of working in Finishing wasn’t running the machines. It was knowing when the fabric was right. Close to spec isn’t on spec. Even though the shade on the sample looked fine under the fluorescent lights in the factory, it might look wrong in a retail store. Stretchiness that passes a quick pull test could fail under the brand’s more rigorous standards, which meant the fabric would be rejected by the brand’s quality control and returned to us, costing us time and money.

Getting to “done” required iteration, evaluation, and the accumulated knowledge of what “right” looked like for each brand, each product, each color. The machines couldn’t tell me that. My boss could, and over time, I learned to see it myself. When I first started, white was white was white was white. But by the time I left, I could differentiate between mother of pearl and eggshell and ivory, and I could tell you which one was right for any given product.

Software works the same way. An agent can generate a feature in minutes. But knowing whether that feature actually solves the problem? Whether it handles the edge cases that matter? Whether it fits into the existing system without creating debt? Whether it meets the actual need and not just the stated requirement? That’s the real work. That’s what requirements gathering, design review, code review, and QA exist to answer, however imperfectly.

The ceremony around those stages might be bloated, sure. Sprint planning might be theater, if you want to put it that way. Story points might as well be astrology, if we’re being honest with ourselves. But the underlying questions of what are we building, is this right, are we done? That’s the job! That’s not just ceremony!

The lifecycle shifted, it didn’t die

If I were writing a more honest version of “the SDLC is dead” take, it would be this: the SDLC is shifting away from engineers and toward the people who define intent.

When code generation is cheap, the bottleneck moves upstream. The hard part isn’t writing the code, just like the hard part isn’t weaving the fabric or dyeing it exactly the right color. It’s knowing what code to write. It’s providing the right context, defining the right constraints, evaluating the output against the actual goal. That sounds a lot like product management to me. Or systems design. Or – get this – engineering, just with different tools.

The role changes but the lifecycle doesn’t disappear. You still need to figure out what to build, how to build it, and perhaps most importantly, when you’re done. You still need to evaluate whether what you built is correct. You still need to monitor it in production and respond when it breaks. You might do all of those things faster, with better tools, with agents handling the mechanical parts. But the stages exist because the problems they address exist, and those problems don’t care how the code was generated or how many PRs you can put up in a day.

Calling the SDLC dead because agents can write code is like saying manufacturing died because machines can weave fabric.

The weaving was never the hard part.