The Future of Programming, as Seen From 1982: Which Forecasts Held Up

Every few years someone announces that programming as a job is about to end. The tools will write the code, the users will build their own applications, and the specification will become the program. From the early 1980s this was a common forecast, and it is common again now that language models can produce working functions on request.

The 1982 forecasts are useful because the outcome is known. Some predictions came true in a form nobody expected. Some failed outright. Most came true for one class of problem while the total amount of programming kept growing. An engineer judging today's claims about AI-generated code can learn more from that record than from either side of the current argument.

Below are the main predictions of that era, what happened to them, and how to use the pattern when someone tells you what your team will not need to do in five years.

Why 1982 is a useful vantage point

By the early 1980s the field had seen enough change to make extrapolation tempting. High-level languages had replaced much hand-written assembly. Structured programming had moved from argument to accepted practice. Personal computers were reaching offices, and spreadsheets were already letting people outside IT build models that, functionally, were programs.

Every one of those shifts supported a straight-line forecast. If compilers removed most of the assembly, something else would remove most of the source code. If accountants could build spreadsheets, they could build applications. These forecasts were not foolish. Each projected a real trend forward, and each missed the second-order effect: when a layer of work gets cheaper, people ask for much more software.

Prediction one: programming will be automated away

The most persistent claim was automatic programming. You describe what you want at a high level and a generator produces the code. Products of the era sold as fourth-generation languages, report writers and application generators made this promise for business data processing. Within a narrow domain they delivered. Generating a report from a database or a data-entry screen from a record layout became largely mechanical.

The prediction failed at the edges of that domain. Generators did well on the cases their designers had anticipated. They did poorly on the exception: the discount rule that applies only to one customer class, or the integration with a system built a decade earlier. Teams ended up writing escape-hatch code in a general-purpose language and then maintaining two things, the generator configuration and the custom code around it.

The lesson is that automation absorbs the routine cases and leaves the exceptions behind. In most real systems, the exceptions are where the engineering effort goes.

Prediction two: users will write their own software

End-user programming is the forecast that came truest, though not in the form predicted. The idea was that managers and clerks would stop waiting on the data-processing department and build what they needed. Spreadsheets made that happen on a huge scale. Today an enormous amount of business logic lives in workbooks maintained by people who would never call themselves programmers.

What the forecast missed was the cost of success. End-user programs have the same problems as professional ones: no version control, no tests, logic duplicated across copies, and a single author who eventually leaves. Organisations then pay professionals to rescue, migrate or replace those programs. End-user tools did not reduce demand for engineers. They moved it, and a lot of professional work became turning working prototypes into maintainable systems.

• What held: non-specialists can and do build useful software when the tool fits the domain.
• What did not: the idea that this removes the need for engineering discipline.
• What followed: a steady stream of work migrating end-user systems once they became business-critical.

Prediction three: specification will replace code

A more academic version of the forecast held that programs would be derived from formal specifications, or that very high-level and logic-based languages would let you state the problem and let the machine find the procedure. If the specification is precise enough, the reasoning went, writing code becomes a translation step that a machine can do.

The flaw sits inside the premise. A specification precise enough to generate correct code from is itself a program, written in a different notation, and someone has to write it, debug it and change it when requirements move. Formal methods found a lasting place in areas where an error is very expensive, such as protocols, hardware design and safety-critical control. They did not become the everyday way business software gets written, because for most systems the hard part is not translating a clear specification. The hard part is finding out what the specification should be.

What the forecasts underestimated: existing systems

Almost every 1982-style forecast pictured new software being built in new ways. It took far less account of the software already running. Systems written in that era, and earlier, kept running for decades because they encoded business rules nobody had fully documented and because replacing them carried more risk than keeping them.

This changes how programming time gets spent. A large share of professional work goes to reading, changing, integrating and migrating code that already exists, not writing new code from a blank page. A tool that speeds up greenfield development does not shrink that share, and it can grow it, because faster creation means more code to maintain later. Anyone who has run an ERP upgrade knows that the custom modules, not the core product, decide how long the project takes.

How to read today's version of the forecast

The current claim, that models will write most code, has the same shape as the earlier ones, so the same questions apply. They are more useful than trying to predict the outcome directly.

1. Which cases does the tool handle, and which does it hand back? Generators of every era did well on the routine path. Measure performance on your own exceptions, not on demo tasks.
2. Who maintains the output? Generated code still has to be read, reviewed and changed by someone who understands it. If nobody on the team can explain it, it is a liability.
3. Does it change the bottleneck? If your delays come from unclear requirements, review queues or integration with other systems, faster code production does not help much.
4. What happens to demand? Cheaper software has historically meant more software, not fewer people building it.

None of this says the current tools are weak. Like spreadsheets and report generators, they will probably change who writes certain kinds of code and how fast. The record suggests they will not remove the need for people who can judge whether the result is correct.

Where the retrospective lens does not fit

Reasoning from history has limits, and leaning on it too hard is its own mistake. The fact that earlier automation forecasts overreached does not prove the current one will. Tools that produce general-purpose code from natural language differ from domain-bound report generators: they work across languages and problem types, and the old argument about failing at the domain boundary applies less cleanly. A team that dismisses them because previous waves disappointed will fall behind on work these tools really do speed up.

Watch for two opposite failure modes. One is adopting generation wholesale and finding, a year later, a codebase nobody understands and a review process that never had the capacity to check it. The other is refusing to change practice and paying for routine work that could be automated. The 1982 record supports a middle position. Automate the routine cases, keep humans responsible for the exceptions and for correctness, and plan the maintenance budget for a codebase that will grow faster than before.

Finally, test any forecast against your own system. Look at where your engineering hours actually go this quarter, split between new features, maintenance, integration and requirements work. That breakdown will tell you more about how much a new tool can change your programming workload than any general prediction.

This article draws on What exactly is RESTful programming? and answers to it (1, 2), on the Stack Exchange network, licensed under CC BY-SA 4.0.