What Developers Did Before

Software development did not begin with AI, and neither did the argument about how developers should organise themselves. A developer, a tech lead or an engineering manager who asks what AI does to the role inherits seventy years of answers to an earlier question: how should people who make software, and answer for it, work together so that it is correct, changeable and still understood when its authors have gone? This chapter sets out those answers as the baseline for Chapters 5 to 12. It concerns all five developer functions, D1 Frame, D2 Design, D3 Build, D4 Prove and D5 Steward, because every practice described here placed its weight on one or two of them, and AI moves that weight again.

The chapter makes one argument that the rest of the book relies on. Each practice in the lineage answered a scarcity: of skill, of the ability to reason about code, of predictability, of feedback, of ownership, of reusable parts, of attention. When AI makes one of these scarcities cheaper, the part of the role that existed to relieve it is the part that changes. The parts that answered a scarcity AI does not touch stay, and they weigh more. That reading is the book's own, drawn from the evidence below; it is not a finding of any single study, and the chapter says so where it matters.

Three reasons make the history useful here, and completeness is not one of them. The first is that claims about AI and developers repeat older claims. Statements that a new tool will make programmers unnecessary, or that a method will make projects predictable, have been made before, and the earlier outcomes are evidence even where they are modest. Frederick Brooks, in the essay "No Silver Bullet" (1986), reprinted in the anniversary edition of The Mythical Man-Month, distinguished the essential difficulty of software, which lies in specifying, designing and testing a conceptual construct, from the accidental difficulty of representing it in a language on a machine, and argued that earlier breakthroughs such as high-level languages had removed accidental difficulty and that no single development would remove the essential kind (215, Brooks, 1995). That distinction returns in every section that follows, and in Chapter 4.

Primary topics explored

1. Why start with the past
2. A lineage of development practice
3. What each practice answered
4. Earlier automation of code
5. How developers spend their time
6. You build it, you run it