Every profession that absorbed a transformative tool followed the same three-act pattern. Software engineering is in Act One. Here's what happens next.
Someone recently asked in a LinkedIn thread whether AI tools are truly changing software engineering or just making existing work faster. The comment thread was more interesting than the question itself — hundreds of experienced developers, torn between “this changes everything” and “this changes nothing.” What struck me is that both camps were right, and neither seemed to realize it. We’ve seen this exact debate before, in professions that already absorbed their version of this moment. The pattern has three acts, not two — and the third one is the part nobody wants to talk about.
Act One: The Tool Arrives
In 1979, Dan Bricklin released VisiCalc, the first electronic spreadsheet for personal computers. Before VisiCalc, accounting was a physical process. Rows and columns in paper ledgers, pencil in one hand, calculator in the other. Changing a single number meant recalculating everything that depended on it — by hand. Bricklin later recalled showing VisiCalc to accountants and watching them react: people who had spent entire weeks on manual calculations immediately understood what they were looking at.
VisiCalc, and later Lotus 1-2-3 and Excel, didn’t just speed up the arithmetic. They collapsed the time between asking “what if?” and seeing the answer. A financial model that took days to recalculate could be updated in seconds. The tool didn’t change what accounting was about — it changed how much of the work was mechanical repetition.
The same pattern played out in engineering and architecture. Before CAD software, drafting was an entirely manual craft — pen, protractor, compass, and years of training to produce a single set of technical drawings. CAD didn’t reduce the need to understand structural integrity, materials, or spatial reasoning. It automated the mechanical act of translating that understanding onto paper. The knowledge stayed; the medium changed.
Act Two: The Profession Elevates
Here’s where the story usually stops in the optimistic retelling: the tool automates the tedious parts, and the profession rises to its real potential.
And that part is genuinely true. When spreadsheets handled the arithmetic, accountants could finally spend their time on the work that the arithmetic was always supposed to serve — financial modeling, strategic planning, forensic analysis, and advisory work. The thinking that was perpetually squeezed out by the calculating finally had room to breathe.
In engineering, CAD didn’t just make drafting faster — it merged the previously separate roles of draftsman, designer, and engineer. Professionals who understood the underlying principles could now iterate rapidly on designs, simulate stress loads, and collaborate on three-dimensional models. The tool expanded what was possible, and the profession moved toward higher-judgment work.
This is the act that people like to cite when they talk about AI and software engineering. And they’re right to — the parallel is clear. AI coding tools are automating the mechanical layer of software development: boilerplate, scaffolding, repetitive refactoring, test generation. The knowledge underneath — system design, debugging intuition, understanding trade-offs at scale — isn’t going anywhere. The profession has room to elevate.
Act Three: The Part We Skip
But the historical record has a third act, and skipping it makes the first two less credible.
When spreadsheets transformed accounting, the US lost roughly 400,000 accounting clerk positions — the roles that were predominantly defined by manual calculation. At the same time, the number of accountants working in higher-level roles grew by about 600,000. The profession didn’t shrink; it shifted. But that shift wasn’t painless. The accountants whose value was concentrated in the mechanical work — the precision of their arithmetic, the speed of their calculations — found that their specific skill was no longer scarce. The tool did it better and faster.
The same thing happened with manual drafting. As CAD tools became more accessible, the demand for specialized drafters whose primary value was in the physical act of producing drawings declined. The profession didn’t disappear, but it absorbed into broader roles — designers and engineers who could now do their own drafting. The standalone mechanical skill lost its premium.
Here’s the uncomfortable parallel: in every case, the dividing line wasn’t seniority or years of experience. It was whether the practitioner understood the purpose beneath the process. Accountants who understood financial reasoning adapted. Those whose expertise was fundamentally in the mechanics of spreadsheets, ironically, didn’t have the same advantage. Engineers who understood structural principles used CAD to amplify their judgment. Those who primarily knew how to produce clean drawings on a drafting board had a harder transition.
The Question That Matters
Software engineering is in the middle of Act One right now. The tool has arrived, and it’s automating the mechanical layer — the boilerplate, the scaffolding, the syntax-level work. Act Two is already visible: developers who understand the systems underneath are using AI to move faster toward the work that always mattered. The profession is elevating.
But Act Three is coming too, and pretending otherwise is a disservice to anyone navigating this moment honestly. The developers whose value is primarily in typing code — in the mechanical act of converting known specifications into working syntax — are in the same position as the accounting clerks of 1979. Not because they’re bad at their jobs, but because the definition of the job is changing.
This doesn’t have to be a pessimistic framing. In every historical case, the profession ended up stronger, more interesting, and more valuable overall. But the transition wasn’t automatic. It required practitioners to move toward the harder, higher-judgment work that the mechanical work had always crowded out.
The question isn’t whether AI will change software engineering — that pattern is already repeating. The question is which version of software engineering you’ve been practicing: the arithmetic, or the financial modeling. Now is a good time to be honest about the answer.
Next Step: Audit where your time goes this week. Track the split between mechanical implementation (writing boilerplate, updating configs, translating specs to code) and judgment work (architecture decisions, debugging complex behavior, evaluating trade-offs). The ratio tells you something important about where you sit in this shift.
Learning Path: Tim Harford’s analysis of VisiCalc and the accounting profession provides a more detailed look at the economic data behind these transitions. For a developer-focused perspective, the next article in this series explores what the shift actually looks like in practice — including the professional debt that AI tools are about to call in.