I Can Already Do Most of This in BASIC

A competent engineer watches a browser agent work for the first time. The agent logs into a supplier portal, copies an invoice number out of an email, pastes it into a search field, downloads the PDF, and keys the total into NetSuite. Ninety seconds of watching is enough.

He is right. Completely right, on every point. The integration he is describing would beat the agent on every metric he cares about. If you have him (his time, his priorities, a slot in his backlog), use him.

The objection carries a second claim, usually unspoken: because I could build this properly, the thing I am watching is unnecessary. That half has been wrong every time it has been said for forty-seven years. And it has been said, in nearly identical words, about every tool that ever let non-technical people do technical work.

The engineer is answering a question: how would I automate this task? His answer is correct. The market is asking a different one: how do the people who will never hire him automate their next hundred tasks? Both answers are correct for their question. The rest of this essay is about the second question, because the second question is where the money is.

In the spring of 1978, Dan Bricklin sat in a Harvard Business School classroom and watched a professor build a financial model on a blackboard ruled into rows and columns. When one assumption changed, the professor erased and rewrote every dependent number, cell by cell. Bricklin's idea was to put the grid on a computer, so that when one number changed, everything downstream recalculated itself. He and Bob Frankston shipped it for the Apple II in 1979 and called it VisiCalc.

Then came the demos, and Bricklin has been telling the story of the reactions for decades. They split cleanly in two.

Experienced computer people looked at the first spreadsheet in history and were unimpressed: "Hey, I can already do most of this in BASIC." They could. A working programmer could reproduce any single model VisiCalc produced, with more control and better validation. Nothing on the screen was beyond them. That is what they evaluated, and they evaluated it correctly.

An accountant saw the same demo at a computer store and, as Bricklin tells it, started shaking: "This is what I do all day!"

The programmer compared VisiCalc to himself. The accountant compared it to her Monday. His question was "could I build this?" Hers was "do I still have to wait for him?", and for the first time the answer was no. Before VisiCalc, re-running the numbers meant a request to the data-processing department, or a night of manual recalculation. After VisiCalc, it meant twenty minutes alone with an Apple II.

The accountants won the argument with their wallets. By some estimates a quarter of early Apple II sales were driven by VisiCalc alone: people buying a $2,000 computer to run a $100 program. Steve Jobs, looking back in 1996, credited the spreadsheet as one of the "two real explosions that propelled the industry forward," the thing that "propelled the Apple II to the success it achieved."

By 1984, Steven Levy was writing in Harper's that the spreadsheet was "a tool, and it is also a world view — reality by the numbers." The people running those models were not programmers. That was the entire point.

The BASIC objection never went away. It became a genre, stable enough that you can date specimens by their tooling.

April 2007. Drew Houston posts Dropbox to Hacker News. The reply that followed is now the most famous comment in the site's history:

Every word is true. That is what makes it the type specimen: a correct answer to "how would I sync my files?", delivered as a verdict on a product for people who will never mount anything with curlftpfs. (To his credit, the commenter returned a day later and graciously conceded the point. Nobody in this genre is a bad engineer. They are good engineers answering the wrong question.) Dropbox went on to serve hundreds of millions of users, none of whom have heard of curlftpfs.

June 2012. Zapier launches, and the thread writes itself: "I don't get what you offer, that ifttt don't?" Engineers saw glue code, an afternoon of cron, curl, and API keys. And glue code is what it was. What customers paid for was skipping the person who writes it. Nine years later Zapier passed $140 million in annual revenue at a $5 billion valuation, having raised $1.3 million in total funding, on a product almost any backend engineer could dismiss. Most did.

And Excel is the genre's standing rebuttal. Software teams still groan at what they find running the business: every process audit turns up a load-bearing spreadsheet. Microsoft's own researchers ended the argument in 2021 when the LAMBDA function made Excel's formula language Turing-complete: Excel formulas are written by "an order of magnitude more users than all the C, C++, C#, Java, and Python programmers in the world combined." The most-used programming language on Earth is operated by people who would never call themselves programmers. Somewhere between 750 million and over a billion of them.

"I could build that" sounds like a judgment about a product. It is actually a disclosure about the speaker: it tells you what the speaker's alternatives cost. For the engineer, an API integration costs an afternoon. For everyone else on Earth, it costs an engineer.

So the same sentence answers two different questions:

Only one of these questions has a market attached.

Clay Christensen's school gave the market's question a name, nonconsumption: when people who need something are "unable to purchase and use a product or service that could address an important need due to factors like cost, inconvenience, and complexity." The accountant in 1979 was not choosing between VisiCalc and a programmer. She had never had a programmer. She was choosing between VisiCalc and nothing. Nothing was the incumbent, and nothing had one hundred percent market share.

Chris Dixon compressed the supply side of the same pattern in 2010: "Disruptive technologies are dismissed as toys because when they are first launched they 'undershoot' user needs." The expert measures the new thing against his own alternatives and finds it wanting: flakier than the integration he would build, sloppier than the report he would write. The measurement is accurate. The comparison set is wrong. The market the toy serves does not have his alternatives. It has nothing.

How big is "nearly everyone"? Count.

One professional developer for every thirty-four people who work at a screen. Most of those developers are busy building products, not internal automations for the other thirty-three. The imbalance is old and stable: in 2005, researchers at Carnegie Mellon projected 90 million end users of workplace computing in America against fewer than 3 million professional programmers. Gartner expects 70 percent of new enterprise applications to be built on low-code or no-code platforms by 2025, up from under 25 percent in 2020, and put the conclusion in one sentence on a conference stage: "Applications of the future will be assembled and composed by the people that actually use them."

Now price the engineer's answer. A single production API integration takes weeks to build and, once you count maintenance, breakage, and the support tickets that never stop, runs $50,000 to $150,000 a year. At that price, which tasks get automated? The ones large enough to justify the invoice. A two-million-dollar reconciliation pipeline clears the bar. The hundred small tasks that make up an actual job (check the portal, download the statement, re-key the total, chase the confirmation) never do. They stay manual. Automating them was always possible. Paying an engineer's rate for each one never was.

"I could build that" is true task by task and false in aggregate: the engineer cannot build a hundred integrations for each of thirty-four people, and nobody could afford it if he tried. His answer prices automation at his rate, and everything under his rate stays manual. That is the market: everything below the cost of an engineer, multiplied by everyone who never had one.

If the unserved majority can't have the API, what do they get instead? Look at what actually exists.

ProgrammableWeb spent seventeen years cataloguing the world's public APIs and shut down in 2022 with roughly 24,000 listed. There are more than 30,000 SaaS companies alone, before you count the supplier portals, the government filing systems, the insurance sites, the bank back-ends, the healthcare payers. The average enterprise runs 897 applications, and only 29 percent of them connect to anything else.

Every one of them ships an interface, though. Complete, documented by its own screen, maintained by the vendor, tested on millions of humans a day. If a task can be done at all, it can be done through the GUI. That is what the GUI is for.

We already know demand pools in exactly that gap, because an entire industry grew there before AI arrived. RPA, software robots that click through user interfaces, spent years as what Gartner called the fastest-growing segment in enterprise software, and Gartner was blunt about why: "The ability to integrate legacy systems is the key driver for RPA projects." Telecom operators had a name for the underlying job back in the 1990s: swivel-chair integration, a person reading from one screen and re-keying into another. UiPath rode the un-APIed world to a $35 billion valuation.

But RPA never escaped the priesthood. The robots were scripts; scripts need script-writers; the "citizen developer" studio always ended up back in the hands of consultants, and the scripts shattered whenever a button moved. RPA proved two things at billion-dollar scale: the demand is real, and the GUI is the right surface. Then it moved the engineer bottleneck instead of removing it.

Browser agents remove it. The interface is the one that already exists for everything. The programming language is the one everyone already speaks. "The hottest new programming language is English," as Andrej Karpathy put it. A person who can explain a task to a new hire can now delegate it to software, on any system with a login page, without filing a ticket. VisiCalc turned modeling into something an accountant could do alone; agents do the same for integration.

If this essay stopped here, it would be the same essay every no-code vendor has published for a decade. Here is the part the enthusiasm always skips: every one of these democratizations set off a governance crisis. The crisis was real. It never stopped the wave. And this wave is different in one way that matters.

The spreadsheet crisis has a body count of audits. Field audits since 1995 have found errors in 94 percent of the spreadsheets they examined. JPMorgan's London Whale value-at-risk model, the one supervising billions in synthetic credit positions, "operated through a series of Excel spreadsheets, which had to be completed manually, by a process of copying and pasting data from one spreadsheet to another," and at one step divided by a sum where it should have divided by an average, cutting its volatility estimate roughly in half. Reinhart and Rogoff's most-quoted austerity statistic fell to a spreadsheet range error found by a graduate student. In October 2020, Public Health England lost 15,841 positive COVID cases, along with tens of thousands of untraced contacts, to the 65,536-row limit of a .XLS file. When Forbes ran the headline "Microsoft's Excel Might Be The Most Dangerous Software On The Planet," the article underneath was reasonable.

The institutional version is shadow IT. Gartner puts technology acquired outside the IT department at 30 to 40 percent of IT spending in large enterprises, and the share of employees building or buying their own tools keeps climbing. The spreadsheet never asked permission either. Democratization and governance crisis are the same event, seen from two desks.

Notice what the crisis never did: it never reversed the wave. Excel survived the London Whale. No company responded to Reinhart-Rogoff by re-instating the COBOL report queue. Access, once granted, does not get taken back. Institutions built review practices and controls around the new tool, because the tool was worth it.

Now the difference. A spreadsheet's worst case is a wrong number. The blast radius of a formula is the cells that read it; a human still sat between every model and every wire transfer. A browser agent's worst case is an action. To be useful it holds your logins, it reads content written by strangers (emails, PDFs, web pages), and it can communicate out: send, submit, pay. Private data, untrusted content, external communication. Readers of this blog will recognize the shape: that is the lethal trifecta, and prompt injection turns it into a kill chain.

So the engineer's objection returns here in its strongest form, and this time he is not wrong: "You want to hand everyone in the company a tireless intern that types their passwords wherever a hidden instruction tells it to?"

That objection deserves an architectural answer.

VisiCalc shipped with a security property so obvious that nobody ever had to name it: the cell was safe. A formula could produce a catastrophically wrong number, but it could not act. It could not wire the money, email the model to a competitor, or type the CFO's password into a form. End-user computing was born inside a boundary: computation on one side, consequences on the other, a human between them. The governance crisis it caused was survivable because the worst case was information, never action.

Agents are valuable precisely because they cross that boundary. And crossing it is what makes "give everyone an agent" a non-starter on the systems where the work actually lives: bank portals, payroll systems, patient records, supplier portals, tax filings. Nobody responsible hands a probabilistically obedient process the keys to those systems. The rest of this blog is about exactly that problem.

So this wave has a dependency the previous waves didn't. The spreadsheet needed nothing but an accountant's curiosity. The agent needs a trust layer underneath it, one that makes the agent's mistakes and the attacker's successes equally harmless:

• The agent never holds real data. It works on placeholders like ROUTING_001 and SSN_001 while the real values sit in hardware-encrypted enclaves only the user can unlock.
• Policy decides where real values materialize. On the authorized page, at the moment of action, placeholders resolve to real values. Everywhere else they are silently stripped. The agent cannot tell the difference.
• The successful attack exfiltrates tokens. The injection still fires. A fully compromised agent executing a perfect attack walks away with placeholders.

How that works (the enclaves, the policy engine, the resolve-at-action boundary) is the subject of What If the Agent Never Had Your Data? and Operating Inside the Lethal Trifecta. The short version: the agent works, the attack fires, and the data was never there.

With that floor in place, the reliability half of the objection becomes ordinary engineering instead of a leap of faith. Agents fail; early spreadsheets crashed; both improve on a curve. And reliability can be measured in the open. An automation that carries its own record (success rate, total runs, how many completed without a human stepping in, which models do best) is something the accountant can judge the way she judges anything else: she reads the record, and she never has to read the code.

What happened to the programmers who could already do most of it in BASIC? They did fine. Since 1980, spreadsheets erased roughly 400,000 bookkeeping and accounting-clerk jobs in the United States and added roughly 600,000 accountant and auditor jobs, because once modeling was cheap, everyone wanted more models. The programmers did better than fine: more code is written today than at any point in history. The experts kept their jobs and lost their queues.

The engineer watching the browser agent is right about everything he can see. The integration he would write is better than the agent, for that task, for whoever can hire him. He is the direct descendant of the programmer at the 1979 demo, who was also right. BASIC really could do most of it. The accountant bought an Apple II anyway, because her question was never "is this the best way to compute a margin?" It was "do I still have to ask?"

Forty-seven years later, the answer is becoming "no" for the work that lives behind logins: a hundred tasks at a time, for the billion people whose work runs through systems no engineer will ever be hired to connect. The engineer keeps his job. He will be building the systems the agents operate on, and the trust layer that makes it safe to let them.