What AI Cannot Replace in Software Development

The Tipping Point What AI Cannot Replace in Software Development, Part 3 In a previous article in this series, I proposed a redefinition of legacy: legacy is not a property of the code itself, but a state of the relationship between the code and those expected to maintain it. A system becomes legacy the moment no one in the organization mentally inhabits what they are nonetheless expected to evolve. The problem lies less in the age of the technology than in the developer’s lack of deep cognitive engagement with their own code. ...

What AI Cannot Replace in Software Development, Part 2 What the developer must retain, what can legitimately be delegated, and why confusing the two leads to the erosion of knowledge. An Operational Distinction I have spent a significant part of my career working with organizations whose human foundation is unstable: high turnover, frequent reassignments, temporary teams assembled for a project and dissolved at its close. In these organizations, something specific happens to software systems over time. The knowledge of why the code is the way it is gradually disappears. ...

What AI Cannot Replace in Software Development, Part 1 A perspective on the structural limits of automated test generation, and what they reveal about the nature of work in software engineering. The Problem Nobody Names A few years ago, I reviewed a software development contract between an organization and a vendor. The terms were standard: a fixed delivery date, a penalty clause for late delivery, and an obligation to maintain 80% code coverage. The intent was twofold. It would protect the organization from negligence, and guard against the kind of deliberate opportunism that governance frameworks exist precisely to prevent. ...

A sociotechnical perspective on what makes code legacy, and what actually keeps it alive. In the organization where I work, there is a mainframe COBOL system that has been running at the core of operations for decades. By every conventional definition, it should be legacy: old language, old architecture, a technology that most developers under forty have never touched. It is not legacy. The team responsible for it is among the most mature and capable in the organization. They understand every decision embedded in that system: the constraints that shaped it, the business rules it encodes, the edge cases it handles. They can explain why a specific field is structured a certain way, what regulatory requirement drove a particular branching condition, and exactly what would happen downstream if you changed it. There is no question about the system they cannot answer. ...