Reports of Its Death Are Exaggerated

Undead SDLC?

The Software Development Lifecycle, SDLC for short, is a hot topic at my company right now. A colleague sent me a link this week, The Software Development Lifecycle Is Dead, and asked what I made of it.

The thesis: requirements, design, implementation, test, review, deployment – with agents, this train of separate phases collapses into one tight loop. A human describes their intent, the agent builds, tests and deploys, the human looks at the result and sets the next direction. No tickets, no sprints, no pull requests waiting for a human review.

My first reaction: Come on. I set up an AI-assisted one-man project at home, with nobody talking over me – and still I make it too complicated. My second: What this article describes isn’t professional software development. It’s vibe coding.

So, am I making it too complicated? What does the lifecycle of a new feature at Televism actually look like?

What Has Already Collapsed at My Place

I’ve written about implementation in The Dark Factory: ticket in, agent implements, a second model reviews the merge request, I decide in the threads what gets fixed. Meanwhile I’m long busy with the next idea.

Here the article has a point: what used to be separate phases with waiting time in between is now so tightly coupled that the boundaries hardly matter. I no longer plan when someone writes code, tests it or fixes a review finding. It happens in one go.

Deployment is classic, in the sense of: no AI. The main pipeline can ship the current state to QA manually. There, bots play a season, and a check confirms it finished cleanly. If needed I log in and test by hand, mostly on the data the bots generated. Another job takes the tested version to prod – as soon as there is a prod.

So what about requirements and architecture?

Talking to the Dark Factory

In my earlier attempts to build Televism, I really was a one-man team: the idea went straight from my head through my fingers into the keyboard. Now we are a team, and I have to tell my agent what to implement.

That interface, for me, is a ticket. Tickets in a project this small? It looks oversized, but it came from pragmatism: the description of what to do has to live somewhere before the Dark Factory starts. I didn’t want that place to be the repository:

• Old planning documents can be read by the agent as current documentation and lead it astray. The same goes for humans with a full-text search.
• They would have to go through the MR process themselves – or need a second, leaner process just for them.

So not the repo, but where then? Even with agents, changes shouldn’t get too big. The agent can absolutely build a large feature in one go. But the bigger and more mixed the merge request, the harder it is to understand, check and correct. Five decisions and three thousand lines at once is something I don’t want from an agent either. So I split a larger feature into steps, each of which still tells a coherent story: this is the goal we’re working towards. This is what we’re doing now. These are the constraints.

So I need a place outside the repository for an undertaking with its intent – and beneath it, the steps that get it there. In GitLab that’s an issue with child tasks.

Guardrails or Completeness?

Architecture and design therefore happen at the subtask level. The question is: how much of it? You can also give the agent just the what and add: “No questions, build it.” Then something reliably comes out. For a small change or a project that has settled in, that’s even enough.

The subtask isn’t meant to dictate to the agent, down to the last detail, how something is built. It records what matters to me as the person technically responsible – the more so, the newer and riskier the change. For the seventh CRUD screen, three bullet points will do. When game time advances and triggers events that produce serious load, I set the guardrails for the implementation tighter.

A four-hundred-line plan generated by the agent doesn’t help me here; I wouldn’t review it in full. And whatever the agent can generate locally, it can generate in the cloud before it starts. Better twenty lines in the subtask with what really counts: the desired interface, a business or technical invariant, a deliberate non-decision, relevant tests, and the line where the agent should stop.

The story, by contrast, describes completely, in good old product-owner fashion, what should change about the game: intent, desired outcome, business rules, decisions, and what is explicitly out of scope. Not a blueprint, but a gapless what.

Here’s the flow, with the hat I’m wearing at each step:

Does That Scale?

Back to the discussion at my company. When I look at how much time at Televism goes into game rules, click dummies and balancing, and how little into architecture and implementation, a PO would struggle to keep six developers supplied with stories at this level of detail. In a bigger team I would have to delegate some of these decisions.

What does that mean for teams? Just one PO and one or two developers, or straight away a single technically minded PO on their own? From the perspective of knowledge distribution and risk management, that can’t be the goal, at least not for core software.

Then developers need more product context and more room to decide. Not in the sense of six developers each developing their own product vision and each interviewing the customers; the what stays with the PO. But stories can no longer be spelled out the way developers are used to. Starting with dialogues like this one:

Refinement.
Dev: “Should X be configurable too?”
PO: “Yes, good idea, do that.”
Dev: “Which time zone should it run in?”
PO: “What’s the default?”
Dev: “UTC.”
PO: “Fine, do it that way.”

For recurring decisions like this, the room to decide can be settled up front. Then it doesn’t take a question to the PO every time. The bigger shift, though, is that stories set guardrails and hand over responsibility within them. The range goes from “Which settings are configurable is your call; the defaults must allow sensible operation without any configuration” to “This feature is subject to the GDPR; how personal data is handled still has to be worked out, and open questions must be cleared with the data protection officer before implementation.”

That doesn’t mean fewer details everywhere. The decisions the responsible person can’t or won’t delegate must be complete. Everything else is handed over as a guardrail.

Taken to its conclusion, you do end up at the article. Business guardrail: I have an intent. Technical guardrails: none. An agent builds, the human looks and iterates.

For a prototype or a deliberately open exploration, that may be exactly right. For a long-lived product it isn’t enough. What’s needed there is not less lifecycle but a different one: fewer handovers of fully spelled-out details, but clearer handovers of guardrails and responsibility.