Early in the Covid-19 pandemic, the governor of New Jersey made an unusual admission: He’d run out of COBOL developers. The state’s unemployment insurance systems were written in the 60-year-old programming language and needed to be updated to handle the hundreds of thousands of claims. Trouble was, few of the state’s employees knew how to do that. And the crisis went beyond New Jersey, just one of many states that depended on these unwieldy systems. By one rough calculation, COBOL’s inefficiencies cost the US GDP $105 billion in 2020.

You might think New Jersey would have replaced its system after this—and that Covid was COBOL’s last gasp. Not quite. The state’s new unemployment system came with a number of quality-of-life improvements, but on the backend, it was still made possible by a mainframe running the ancient language.

COBOL, short for Common Business-Oriented Language, is the most widely adopted computer language in history. Of the 300 billion lines of code that had been written by the year 2000, 80 percent of them were in COBOL. It’s still in widespread use and supports a large number of government systems, such as motor vehicle records and unemployment insurance; on any given day, it can handle something on the order of 3 trillion dollars’ worth of financial transactions. I think of COBOL as a kind of digital asbestos, almost ubiquitous once upon a time and now incredibly, dangerously difficult to remove.

COBOL was first proposed in 1959 by a committee comprising most of the US computer industry (including Grace Hopper). It called for “specifications for a common business language for automatic digital computers” to solve a growing problem: the expense of programming. Programs were custom-written for specific machines, and if you wanted to run them on something else, that meant a near-total rewrite. The committee approached the Department of Defense, which happily embraced the project.

COBOL’s design set it apart from other languages both then and now. It was meant to be written in plain English so that anybody, even nonprogrammers, would be able to use it; symbolic mathematical notation was added only after considerable debate. Most versions of COBOL allow for the use of hundreds of words (Java permits just 68), including “is, “then,” and “to,” to make it easier to write in. Some have even said COBOL was intended to replace computer programmers, who in the 1960s occupied a rarified place at many companies. They were masters of a technology that most people could barely comprehend. COBOL’s designers also hoped that it would generate its own documentation, saving developers time and making it easy to maintain in the long run.

But what did it even mean to be readable? Programs aren’t books or articles; they’re conditional sets of instructions. While COBOL could distill the complexity of a single line of code into something anybody could understand, that distinction fell apart in programs that ran to thousands of lines. (It’s like an Ikea assembly manual: Any given step is easy, but somehow the thing still doesn’t come together.) Moreover, COBOL was implemented with a piece of logic that grew to be despised: the GO TO statement, an unconditional branching mechanism that sent you rocketing from one section of a program to another. The result was “spaghetti code,” as developers like to say, that made self-documenting beside the point.

Plenty of computer scientists had issues with COBOL from the outset. Edsger Dijkstra famously loathed it, saying, “The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.” Dijkstra likewise hated the GO TO statement, arguing that it made programs nearly impossible to understand. There was a degree of real snobbishness: COBOL was often looked down on as a purely utilitarian language that was intended to solve boring problems.

Jean Sammet, one of the original designers, saw it differently—the language simply had the complicated task of representing complicated things, like social security. Or as another defender wrote, “Regrettably, there are too many such business application programs written by programmers that have never had the benefit of structured COBOL taught well.” Good COBOL was indeed self-documenting, but so much depended on the specific programmer. Fred Gruenberger, a mathematician with the Rand Corporation, put it this way: “COBOL, in the hands of a master, is a beautiful tool—a very powerful tool. COBOL, as it’s going to be handled by a low-grade clerk somewhere, will be a miserable mess.”

Market data from analyst IDC has shown that SuperMicro has leapfrogged established server makers Lenovo and HPE as the second-largest PC server maker behind Dell.

SuperMicro experienced growth of almost 134% for the fourth quarter of 2025 with revenue of $11.7bn, which means it accounts for over 9% of the global server market. Dell was ahead with 10% market share and revenue of $12.6bn, while Chinese manufacturer IEIT Systems took the third spot, with revenue of $5.2bn and a 4% market share ahead of Lenovo, which posted revenue of $5.1bn, and HPE ($3.9bn).

“The race for AI [artificial intelligence] adoption is settling the market pace, and with companies starving for infrastructure looking not only at GPUs [graphics processing units], but also consuming more CPUs [central processing units] among other components in order to feed their needs, we are going to see more price pressures, and that may impact on market dynamics with less units but higher average selling prices going forward,” said Juan Seminara, research director of Worldwide Enterprise Infrastructure Trackers at IDC.

IDC noted that volatile increasing prices on certain components such as GPUs, dynamic random access memory (DRAM) and solid state drives (SSDs) has meant that some companies have been trying to secure prices ahead while the industry is accommodating to the new reality. It predicted that the impact of this price volatility could be hitting harder during 2026 as demand keeps outpacing service capacity in the near term.

Besides Dell, the established server makers seem to be losing ground in the server market. But they appear to be looking at a new market opportunity being pushed by chipmaker AMD, which is the deployment of on-premise PC servers optimised to run agentic AI. 

In a bid to entice IT buyers away from cloud-based AI hardware, AMD has unveiled what it sees as a new category of PC called Agent Computers. In a post on the AMD website, the company described how to run OpenClaw, the open source AI agent, locally on AMD Ryzen AI Max+ processors and Radeon GPUs using a Windows 11 PC with the Windows Subsystem for Linux (WSL).

AMD said the PC system configured with 128GB unified memory is capable of running “cloud-quality AI agent workloads efficiently” using OpenClaw. According to its own benchmark data, with the Qwen 3.5 35B A3B model, the system delivers around 45 tokens per second and processes 10,000 input tokens in about 19.5 seconds. AMD said the configuration supports a maximum context window of 260,000 tokens, and can run up to six agents concurrently, which it said means it is able to deliver scalable local AI experimentation while maintaining strong responsiveness on consumer hardware.

AMD sees such a system running autonomously rather like the pre-cloud era branch office servers, handling tasks sent by users through a browser user interface on another Windows PC, or via Slack or WhatsApp.

PC makers that have “agent-ready” PCs include HP, Lenovo and Asus. The IDC figures show that revenue for servers with an embedded GPU in the fourth quarter of 2025 grew 59.1% year-over-year, representing more than half of the total server market revenue.

The AMD Ryzen AI Max+ has an integrated GPU, and is currently one of the processor options for PCs certified as Copilot+ devices. While these devices are either laptops or desktop PCs with monitors, AMD’s Agent Computer appears to be positioned as more of a traditional desktop Windows PC running as a server, without a screen or keyboard. The setup AMD provides is optimised to run LM Studio. This uses Ubuntu on the WSL to provide access to large language models, which then work with an OpenClaw server running locally on the same hardware.