Back in the punched card era, you wrote your program on a coding sheet and gave it to a keypunch operator, who turned it into a deck of cards. Another operator would re-punch the same sheet on a verifier to catch mistakes. If you made a typing error, you had to re-punch the whole card. People numbered columns 73 to 80 in order so that if a deck was dropped, a machine could sort it back. After submitting your deck, you waited, sometimes getting your output back within an hour if the system wasn’t busy.
Usually, you couldn’t spot an error until you ran the program, and running it was the costly part.
That was the last time writing code was mechanically hard. Since then, everything has aimed to make coding easier, and it worked. But clients still ask me: if code almost writes itself now, why do delivery dates stay the same?
Seventy years of making the same step cheaper
Programs moved off cards and into memory as files, and then languages arrived. IBM’s own history of Fortran, released commercially in 1957, puts the change in concrete terms: “What was formerly a laborious task of manually keying as many as a thousand program instructions for a given problem could now be translated, automated and reduced to only 47 in Fortran.”
After that, the focus shifted to speed. Editors started to understand the language’s grammar and could suggest what was valid in each spot. Later, they recognized your APIs. Microsoft introduced IntelliSense features like autocomplete and parameter info in Visual C++ 6.0. To make this work, the IDE used its own parser, separate from the compiler, because “many features of the IDE require code understanding and requiring a build would be an onerous burden.” Eventually, editors began ranking suggestions by context, so the most relevant completion appeared at the top instead of buried in an alphabetical list.
Then came GPT-3, and on June 29, 2021, the technical preview of GitHub Copilot was released. Copilot ran on OpenAI Codex, which GitHub said was “significantly more capable than GPT-3 in code generation, in part, because it was trained on a data set that includes a much larger concentration of public source code.” Instead of just suggesting the next word, it could suggest entire lines or functions.
All these advances focused on the same challenge: turning someone’s idea into something a machine can run. But none of them changed the idea itself.
The code was never the point
People have always written programs to solve their own problems. That’s been true since computers began. Coding was the repetitive, predictable part, and it stayed a human task only because we hadn’t figured out how to automate it yet.
But aren’t software engineers the ones who write code? Actually, no.
If you watched a civil, mechanical, or electrical engineer back then, you’d see someone working through equations. When electronic computers appeared, many thought engineers would become obsolete. But they didn’t, because the math was just the predictable part. Deciding which equation to use, what assumptions to make, what margin to allow, and whether the result made sense—none of that was written down. I’ve written about how this pattern repeats, and now it’s happening to us.
So why hasn’t the date moved?
First, let’s be clear about the premise. Coding time hasn’t dropped to zero. It’s only close to zero for parts we already understand well, which is a much smaller claim. Stack Overflow’s 2025 developer survey found that the top frustration with AI, reported by 66% of developers, is “AI solutions that are almost right, but not quite,” and 45% say debugging AI-generated code takes more time. Drafting is quick, but getting it right is a separate task with its own timeline.
Second, and this is the main point: coding has never been the hard part. The challenges from 1957 are still with us. Generative AI has made them somewhat less hard. It has not made them quick.
Understanding the problem. Requirements almost always arrive incomplete, and the gaps are rarely in the parts anyone thought to write down. Fred Brooks said it in No Silver Bullet in 1987: “The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements.” His whole argument was that the difficulties of representing a design (languages, notation, tooling) are accidental, and that removing them is the most a tool can do. Code generation is the largest removal of accidental difficulty we’ve had. It is still a removal of the accidental kind.
Deciding. Within a team, you need to gather data, find evidence, and make decisions you can stand by. Across teams, it’s even slower because decisions depend on how quickly people communicate. Communication isn’t just extra work; it’s part of the job, and it’s why adding people doesn’t reliably add throughput.
Legacy systems. Most business rules, old decisions, and constraints were never written down, so you can only answer compatibility questions by reading the existing code. In a study of seven real projects, 79 professional developers, and 3,244 working hours, Xia and colleagues found that developers spend about 58% of their time just understanding programs. This was before AI assistants were common. An AI model can explain what a function does, but it can’t tell you why a rule exists, who requested it, or what breaks in accounting if you remove it.
Judging the output. It’s getting cheaper and faster to generate code. But figuring out if that code fits, is correct, secure, maintainable, and actually solves the user’s problem isn’t getting easier at the same pace—which is a question about evidence, not about tests passing.
AI sharpens the line rather than blurring it
The 2025 DORA report, based on nearly 5,000 technology professionals, shows that AI adoption now correlates positively with delivery throughput, a change from the previous year, while its relationship with delivery stability stayed negative. The main point is that “AI accelerates software development, but that acceleration can expose weaknesses downstream.” Teams working in loosely coupled architectures with fast feedback saw gains; teams in tightly coupled systems with slow processes saw little or none.
That’s what a shifted bottleneck looks like. Nothing broke. The constraint just moved to wherever the judgment lives.
I want to be clear about where I might be wrong. Models are getting better at the hard parts too, like reading unfamiliar systems or figuring out what questions a vague requirement leaves open. The evidence on whether AI actually speeds up real work is genuinely mixed, and a tool that eventually holds a whole system and its history in context could make some of this easier. But I don’t think accountability will change. Someone still has to decide what should exist and take responsibility for it. In the same Stack Overflow survey, the top reason developers asked another person instead of AI was that they didn’t trust the AI’s answer.
Coding got cheap the moment we understood it well enough to explain it to a machine. Everything we still can’t explain is the job.
