Engineers will do anything to avoid learning from history
TL;DR
David Horn argues that software engineers keep reinventing older disciplines under new names. Managing AI coding agents, he says, is just program management. He thinks engineers should read the classic books on it instead of rediscovering waterfall the hard way.
The article
- Horn sees a pattern. Data science was largely statistics with a cooler name. Crypto speedran the history of finance, as Matt Levine put it. Now engineers are discovering that running several agents feels like running a team.
- He grants two fair reasons for the habit. Older institutional fields can seem arcane. Working from first principles sometimes yields deeper understanding. The bad reasons are money and hubris. In his words, "Nobody raises a round to apply a well understood discipline correctly." And there's always "How hard could it be?"
- Agents push engineers toward work they used to dismiss. People who never took design docs or PRDs seriously now have to spell out every behavior up front. Engineers who mocked managers for not knowing the code can't be bothered to read the 10k-line PRs their AI writes. In Horn's words, "Suddenly, waterfall is the thing to do."
- He predicts the industry will give this a sexier name rather than call it waterfall or program management. Few engineers have read Winston Royce's original paper. So even the process they rejected, they rejected without understanding it.
- Agent orchestration is program management, he says. It means documented requirements, checking that the work is worth the tokens, clear lanes of work and acceptance criteria. It also means regular check-ins, which is the standup engineers have argued about for fifteen years.
- He closes with a reading list. It includes Making Things Happen, the PMBOK Guide, The Mythical Man-Month and Royce's 12-page waterfall paper. It also has High Output Management, which he admits he hasn't read, and The Goal, the source of the theory of constraints.
Why it matters
The post is short and opinionated. The main thing the original adds is the annotated reading list, with Horn's one-line take on how each book applies to running agents. Read it if you lead a team or orchestrate agents and want the program-management canon in one place.
The discussion
A lively, mostly sympathetic thread that drifted quickly. The biggest fight was whether software developers deserve the word "engineer" at all, which several said proved Horn's point. On the actual claim, people with management experience backed him, while others said agents differ enough from teams that old playbooks only partly apply.
Are software developers real engineers?
Many read the title as a dig at licensed engineering. One camp says learning from failures, licensing and legal liability define real engineering, so developers who skip the history aren't engineers. Others pushed back hard, saying licensed engineers also ship bad designs and rarely face consequences, as the Christchurch CTV building collapse showed. Many developers, they added, had the title handed to them by HR. A long side argument over the collapse ended with both sides agreeing the prosecutions failed but disagreeing on whether certification means anything.
Engineering schools showcase failures of the past as a teaching tool. I still remember learning about the bridge that shook itself apart during my freshman year. Engineers value safety margins and failure analysis.
The vast majority of engineers have no consequences for their shite. Neither is certification a panacea against bad engineers.
Is managing agents really program management?
An engineering lead with about 20 reports has spent six months pushing PRD-heavy workflows that limit agent-to-agent talk, which baffles engineers who never managed anyone. Critics said agents add new problems like token budgets, drift and extreme literalism, though one reply mapped each of those onto ordinary engineers. Others agreed on scoping and check-ins but thought full waterfall is overkill when agents work this fast. One asked how delegation works when you can't hold an LLM accountable.
On Friday we had a coffee hour to share how we've been working recently and they all seemed perplexed at the workflows I've been adopting. It seems natural to me as someone who's been a manager for some time now, but very alien to all those who've never gone down that path.
I do agree that it's important to do things like scope out your demands of your AI agent, check-in on progress, give as clear a requirement and test cases as you can. But you've always been able to do that with agile methods, and LLMs are fast enough that you don't need to go full waterfall (and if anything it would be counter productive).
Over-splitting work, for people and for agents
One subthread blamed a botched Agile, since Lean and Agile say to limit work in progress and avoid context switching. Most shops instead run scrum against fixed marketing deadlines and split tasks across different people. One commenter described a day's work split into four hour-long tickets for four people, which doubled the man-hours while the WIP metric looked great. He sees people splitting work across agents the same way when one session could hold the whole problem.
I'm thinking some people are approaching agentic development in the same manner, splitting work up across agents too aggressively, giving each agent new context/upfront plans, when the one session could have done the whole problem in the one context window.
Software forgot what expensive mistakes cost
A related complaint was that software thinks other industries are slow because they're less smart. But a cast part that takes months to make has to be right the first time. Veterans of boxed software and console games said shipping used to work that way too, since nobody could patch a pressed disc. In a long tangent on whether 3D printing now beats casting, an aircraft-parts designer's break-even numbers showed it mostly doesn't, except for tiny runs.
It drives me nuts the number of people in software who think that people in other industries are slow because they’re just not as smart as us, rather than because when it takes months to get a cast part made, it better be right the first time.
getting a game past Sony testing was so fricking difficult, but it was because once that black disc was cut, there was no way to get an update. You had to be on the money, first release.
Why reinventing happens anyway
Commenters offered reasons Horn missed. Building things is fun, nobody can know every field well enough to recognize prior art, and nobody gets rewarded for rejecting the new thing. Others blamed ego and VC money, saying novelty is what gets funded. A chemistry professor's line about calling the same work nanotechnology to get grants showed the habit isn't limited to software.
There’s a good list of reasons why we do this, but it leaves out the biggest one, at least for me: building stuff is fun. Reinventing stuff is fun.
You can't not reinvent something if you don't know it exists in the first place.
Consensus
Most agreed that the industry rediscovers old knowledge under new names. They also agreed that working with agents needs clear requirements, scoping and regular check-ins, the things managers have always done.
Dissent
Some said agents differ from human teams in ways old process books don't cover, such as token cost and drift. They also said full waterfall is wrong when iterations take minutes. Others said licensed engineers already learn from history, so Horn's target is programmers, not engineers.