There's an idea in software that refuses to die. It doesn't die because it isn't wrong — it's just never quite finished, and every fifteen or twenty years the industry forgets it was already tried, gives it a new name, wraps it in whatever the current decade's hot technology happens to be, and re-launches it as if for the first time.
The idea is this: a person who understands a problem shouldn't have to learn a general-purpose programming language to get a working application out of that understanding. They should be able to describe what they want — fill in a form, answer some questions, draw a picture, now, type a sentence — and have a machine generate the actual, running thing.
We've called this a lot of names over the years. Report generator. 4GL. CASE tool. RAD environment. Low-code platform. Vibe coding. Each generation is convinced it's discovered something new. None of them have been, not really — and tracing why the same idea keeps resurfacing, and what actually changes each time it does, tells you something more interesting than any one tool's biography ever could.
The Punch Card Prophets (1959)
The story doesn't start with a shiny 1980s CASE vendor. It starts with a very unglamorous problem: what do you do with a room full of people who know how to wire a plugboard on a tabulating machine, but have never written a line of code, when the company just bought a stored-program computer?
That was IBM's problem in the late 1950s, and their answer was RPG — the Report Program Generator — released in 1959 for the IBM 1401. Its predecessor, a tool called FARGO, existed for the exact same reason. Neither asked the operator to write a program in the modern sense. You filled in fixed-format specification sheets: here are my input files, here's the calculation, here's what the output should look like. The machine took it from there.
Notice the name. Not "Report Programming Language." Generator. The claim, right there in 1959, was that the tool would generate the application — you supplied the what, it supplied the how. That's the whole idea, fully formed, seventy years ago, aimed at people who'd spent their careers wiring control panels rather than writing code. RPG didn't fade quietly either; it kept evolving in place for decades and is, remarkably, still running production business logic on IBM i systems today.
Business Data as a Grammar (the 1970s)
Through the 1970s, the same instinct shows up wearing database clothing: FOCUS, NATURAL, RAMIS, MAPPER. These tools let someone who thought in terms of "give me total sales by region for last quarter" get that report without learning a procedural language — you described the question, not the loop that would answer it.
This is also where the terminology starts to fracture in a way that's worth knowing if you ever go looking for primary sources. The people building these tools called them "generators." The academics studying them called the same territory "fourth-generation languages" — and even they couldn't agree on what a 4GL actually was. To practitioners, a 4GL was a language that pulled reports out of a database. To academics, it was a non-procedural language where you specified what should happen and left the order of operations to the machine. Same territory, two incompatible maps. It's a good reminder that when you're doing tech archaeology, the label on the box and the definition in the paper often don't match — and neither is wrong, they're just from different tribes.
The CAD Analogy and the CASE Gold Rush (1981–1993)
The idea's biggest, loudest, and most expensive incarnation arrived under a new banner: CASE, Computer-Aided Software Engineering, a term coined in 1982 explicitly modeled on the success of Computer-Aided Design in hardware. If CAD could let engineers describe a circuit and get a chip layout, the reasoning went, CASE could let analysts describe a business process and get software.
The tool most historians point to as the archetype predates the term itself. Telon, introduced in 1981 by CSI (later sold to Pansophic Systems), is widely regarded as one of the first commercially successful application generators for business software, and one of the first CASE tools on the market, full stop. You designed your screens and data through something called the Telon Design Facility, and it generated real COBOL running under CICS — and, unusually for the era, it could also generate PL/I.
The industry then split the idea into two tiers — Upper CASE for modeling and design, Lower CASE for the actual code generation and testing — and the market genuinely exploded. By 1989, Excelerator from Index Technology was the best-selling CASE tool on the market. By January 1990, trade press was counting well over one hundred companies selling nearly two hundred distinct CASE products, with heavyweights like IBM, KnowledgeWare, and Texas Instruments' Information Engineering Facility all competing for the same accounts. The market itself went from a handful of specialty vendors to a multi-billion-dollar industry within five years. IBM's own entry, AD/Cycle, was the most ambitious version of the dream: an entire development lifecycle organized around a central DB2 repository, everything generated from one shared model.
And then it fell apart, in the way these things always seem to. The U.S. government, one of the biggest CASE buyers of the era, became one of its loudest critics: a 1993 GAO report on the Department of Defense's use of CASE tools found little evidence they'd actually improved software quality or productivity. The standing joke of the period was "shelfware" — tools bought with great fanfare and then quietly shelved. The diagnosis, with the benefit of hindsight, is familiar: the generators mapped poorly onto the platforms they were supposedly targeting, they didn't scale to genuinely large systems, and — this is the important bit — each vendor's modeling language and code generator was hard-coded to that vendor's assumptions about your domain. The moment your business didn't fit the mold, you were stuck.
The Generator Comes Home (1987 onward)
While the enterprise CASE vendors were burning billions of dollars trying to model entire corporations from a repository, a much humbler and, it turns out, much longer-lived version of the same idea was quietly taking root one rung down the ladder: on personal computers, aimed at one person at a time.
Bill Atkinson's HyperCard shipped free with every Macintosh starting in August 1987, built on the premise that regular people — not trained programmers — could build interactive software by linking "cards" together, scripted in HyperTalk, a language deliberately designed to read like plain English rather than like code. It wasn't marketed as a CASE tool or an application generator at all, but it was doing exactly the same trick RPG did in 1959: hand someone a constrained, domain-shaped way to describe what they wanted, and let the tool handle the mechanics.
The same decade gave us Visual Basic and PowerBuilder, both leaning on drag-and-drop screen design to generate the scaffolding of a working desktop application, and the built-in application generators inside dBASE, FoxPro, and later Access — wizards that would take a data model and a few choices and hand you a working, if modest, application. None of these tried to be AD/Cycle. None of them tried to model your entire enterprise. They just generated one person's application, for one person's problem, and that more modest ambition is exactly why they survived the CASE bust that killed their more grandiose cousins.
Low, No, and Somewhere In Between (2001–present)
Give the idea twenty more years and a cloud subscription model, and it comes back again as "low-code" and "no-code." OutSystems, founded in 2001, and Mendix, founded in 2005, are usually credited as the platforms that got the modern wave moving, years before anyone had a name for what they were doing — OutSystems' own marketing in the mid-2000s talked about stopping the "proliferation of Shadow IT," which is just a more corporate way of describing the same gap RPG was built to close in 1959: people who need software faster than the programming department can deliver it.
The name came later and from an unexpected source: market analysts. "Low-code development" shows up in a Forrester report as early as 2011, and Forrester formally coined "low-code" as a category in 2014. "No-code" followed close behind, distinguishing platforms with zero hand-coding (Bubble, launched in 2012, is generally credited as the first true no-code web-app platform) from ones that still allow a developer to drop into real code when the visual tools hit their limit. Microsoft's PowerApps arrived in the mid-2010s, and by the back half of the decade the acquisitions started — Siemens bought Mendix for a reported $700+ million in 2018 — the same signal the 1980s CASE market gave off right before its own peak, money pouring in from people betting the pattern would finally stick this time.
Prompts as Specification (2020s)
Which brings us to now, where the "specification" that goes into the generator is a sentence typed in plain English, and the generator is a large language model instead of a code-gen engine reading a repository. The people writing about this today aren't shy about the parallel either — there's commentary explicitly comparing today's AI-driven "vibe coding" tools to the CASE boom of the 1980s: the same promise (non-specialists building working software), the same early surge in adoption, and warnings of the same kind of disillusionment that turned CASE into shelfware, should the generated output turn out to be as hard to maintain as anything else once you look under the hood. Some current products even frame themselves explicitly as returning to Atkinson's original 1987 premise — one describes itself as finishing what HyperCard started, just with an AI co-pilot standing in for HyperTalk.
Whether the AI version escapes the failure mode that caught CASE is, honestly, the open question of our moment — and it's the same question you could have asked about Telon in 1985, or PowerBuilder in 1993, or Mendix in 2010.
What Never Changes, and What Always Does
Line all of these up — RPG, Telon, HyperCard, Mendix, whatever's shipping this year — and a pattern falls out that's more interesting than any single tool's feature list.
What never changes:
- The trade being made. Every one of these tools buys speed by giving up generality. You get a huge amount of leverage as long as your problem fits the shape the tool assumes; the moment it doesn't, you're fighting the tool instead of using it.
- Who it's actually for. Not professional programmers — tab-machine operators, business analysts, one-person shops, "citizen developers." The target user is always someone who understands the domain deeply and the machine only shallowly, and the whole point of the tool is to make that enough.
- The failure mode. Every generation eventually tries to escape its own constraints — 4GLs that tried to become general-purpose languages, CASE tools that tried to model the entire enterprise instead of one process, low-code platforms straining under "citizen developer" apps that quietly became mission-critical. The tools that hold their scope tend to survive quietly for decades (RPG is still running production systems seventy years later). The ones that reach for generality tend to collapse under their own ambition within a decade.
What changes every single cycle, though, is worth naming too, because it's the actual engine of reinvention:
- What gets generated. A report, then a mainframe transaction screen, then a desktop app, then a website, then a cloud service, then — now — an entire running product from a paragraph.
- Who's allowed to hold the pen. Trained tab-machine technicians, then business analysts, then any individual with a Mac, then literally anyone who can describe what they want in a sentence.
- How the specification gets captured. Fixed-format coding sheets, then screens and wizards, then drag-and-drop canvases, then natural language.
- Who owns the lock-in. A hard-coded, vendor-specific code generator, then a managed cloud runtime you rent forever, then — an open question right now — a foundation model whose behavior you don't fully control either.
Every cycle looks like a breakthrough because the what and the who and the how genuinely are new. But underneath, it's the same seventy-year-old bet: that the gap between "hire a programmer" and "just describe it" is real, permanent, and worth building a machine to close — over and over again, in whatever the current decade's silicon happens to allow.
That's really the throughline worth sitting with, more than any one product's rise or fall: this was never a story about a technology. It's a story about an economic gap that never closes for long, and about how every generation rediscovers it and is genuinely surprised, all over again, that someone already tried this in 1959.
Richard Roberts is the founder of DataPublisher LLC. He has been building document automation systems since 1994 — the same seventy-year idea this piece traces, one generation later. He lives and works in McKeesport, Pennsylvania.