The SDLC Steps That Resist Automation Longest, and Why

Order the software lifecycle by how automatable each step is and the ordering isn't about difficulty. Some intellectually demanding steps automate readily; some trivial ones resist completely. The variable is what each step needs as input and whether its output can be checked.

The two properties that decide it

Input completeness. Is everything needed to do this step present in artifacts a machine can read? Or does it require context held by people — history, plans, relationships, what someone meant rather than wrote?

Output verifiability. Can correctness be determined mechanically? Compiles, passes, reconciles, validates? Or does it require judgment that itself needs the missing context?

A step with complete inputs and verifiable output automates readily regardless of complexity. A step missing either resists regardless of how simple it looks.

The lifecycle, sorted

Automates first — complete inputs, verifiable output:

• Implementation from a precise specification
• Test generation against a stated contract
• Mechanical refactoring
• Format and style enforcement
• Dependency updates with a passing test suite
• Documentation of what code does

Automates next — mostly complete inputs, partly verifiable:

• Test generation against loose requirements
• Code review for mechanical properties
• Investigation and hypothesis generation
• Migration planning where the target is defined
• Performance analysis, where the measurement is the check

Resists — incomplete inputs, unverifiable output:

• Deciding what to build
• Prioritizing among things worth doing
• Resolving genuine ambiguity in a requirement
• Judging whether a change is the right change
• Deciding when to deploy
• Choosing an architecture whose rightness depends on where the business is going
• Deciding something isn't worth fixing

⚠️ Note that the third list is mostly deciding and mostly short in duration. These steps take minutes and gate hours. That's why automating everything else changes the shape of the work so much without removing the humans — the remaining steps are small, frequent, and load-bearing.

Why the resistant ones stay resistant

The inputs aren't written down, and mostly can't be. Not through neglect. "This customer is fragile," "we're rewriting this next quarter," "the last person who tried this left" — these are real inputs and they live in conversation and memory. Documentation helps at the margin and doesn't close the gap, because the tacit part is defined by resisting articulation.

There's no oracle. A prioritization decision can't be checked in seconds. It's evaluated over months, confounded by everything else that happened, and often never conclusively. Without a feedback signal, there's no iteration loop — which is the mechanism that makes agents strong everywhere else.

Accountability requires a subject. Some decisions need someone who can be asked to explain and who bears the consequence. That's a structural requirement, not a capability question, and it doesn't move with model quality.

What would change the ordering

Being concrete about what would move a step from the third list to the second, rather than treating the boundary as permanent:

• An oracle appearing where there wasn't one. If a class of product decisions became cheaply testable — fast, reliable experimentation with clean attribution — prioritization would partly move.
• Tacit context becoming captured as a side effect of work, rather than requiring deliberate documentation. Meeting transcripts, decision logs, and richer artifacts push at this, unevenly.
• Accountability structures adapting, which is a social and legal question rather than a technical one, and moves slowly.

None of those are impossible. All are slower than model capability improvements, which is why the boundary is likely to persist longer than benchmark trends alone would suggest.

✅ What to do with the ordering

• Automate aggressively in the first list. No reason to hold back; the checks are mechanical.
• Assist deliberately in the second, with human confirmation, since the verification is partial.
• Invest in people for the third, and recognize it's a small fraction of hours and most of the leverage.
• Watch for oracles you could build. Anything you can make mechanically checkable moves up a tier — and building the oracle is often the highest-value engineering work available.

The takeaway

Automatability tracks input completeness and output verifiability, not difficulty. What resists is the deciding: what to build, what's right, when to ship, what's not worth doing — short steps with missing inputs and no mechanical check. Automate the first tier without hesitation, assist the second, staff the third, and treat "can I build an oracle for this?" as the question that moves work between them.