In my department we have a slogan, printed on t-shirts: Informatics. The other 85 percent. It gets a laugh from people who know the reference and a puzzled look from those who don’t, so let me explain it. It has become a more serious claim than it was when we first made it.

The number comes from an old observation about how the work of building software is actually distributed. In his classic book on software engineering, The Mythical Man-Month, Fred Brooks offered a rule of thumb for scheduling a software project: one-third for planning, one-sixth for coding, one-quarter for component testing, and one-quarter for system testing.

Coding, the activity everyone thinks of as programming, was a sixth of the job, or about 17 percent. Brooks was drawing on his experience managing IBM’s OS/360 in the mid-1960s, but the proportion was not new even then. Herbert Benington’s 1956 account of the SAGE air defense project, the first really large software system, found much the same distribution.

Later estimation models, time-tracking studies, and developer surveys produce different numbers depending on what they count as “coding,” and some put it lower still; the figure moves around between ten and twenty percent. What does not move is the shape of the finding. Across seventy years of radically changing languages, tools, and methodologies, writing the code has remained a minority share of the work of making software. An estimate of about 15% is a pretty fair summary of the literature.

So what is the other 85 percent? It is everything that surrounds the code: finding out what the organization actually needs, which is rarely what it first says it needs; analysis and design; testing, which Brooks assigned fully half the schedule; documentation, training, and rollout; and maintenance, which the industry has known since the early 1970s consumes between half and two-thirds of the lifetime cost of any system. It is also, less officially, the politics: the negotiations among managers, users, and technical staff over what the system is for and who controls it. Most of the work of computerizing an accounting department in the 1960s happened without reference to a computer at all: procedures had to be studied, charted, and reorganized, clerks retrained, manuals written, turf renegotiated. The code was the easy part, or at least the part whose difficulty was easiest to see.

The industry understood this early, even if it rarely acted on it. A 1959 Price Waterhouse study of business computing concluded that “the term ‘programmer’ is unfortunate since it seems to indicate that the work is largely machine oriented when this is not at all the case,” and that “training in systems analysis and design is as important to a programmer as training in machine coding techniques.”

Willis Ware, writing in 1965 about the perennial complaint that programming cost too much, observed that “what we really are unhappy with is the total programming process, not programming (i.e., writing routines) per se.”

Sociologists of technology would later give this insight a name. Software is a product of what John Law called heterogeneous engineering: a system in which machines, people, procedures, and organizational politics are inseparable, and in which most of the engineering is done on the people and procedures.

Why, then, does coding dominate our picture of what computing is? Partly because it is the visible and glamorous part, the “black art” that gave the computer boys of the 1960s their mystique. Partly because of how the discipline named itself. In the United States the emerging field organized itself around the machine, as computer science, and around the algorithm as its foundational concept. In Europe the same field was more often called informatik or informatique, organized around information and its uses rather than the device that processed it. “Informatics,” in the American usage my department inherited, is the descendant of that second tradition: the study of information systems as they are embedded in human and organizational life. The other 85 percent was, in a sense, our founding charter.

Which brings me to the current conversation about artificial intelligence. The claims have been dramatic. AI, we are told, will shortly write nearly all code; software engineers will become supervisors of agents or be dispensed with altogether; students should not bother learning to program. Notice what these claims are about. They are about the 15 percent. Coding is the part of software work most legible to a language model: it is formal, it is written down, and it offers fast, unambiguous feedback from a compiler or a failing test. It is also the part the industry has been trying to automate since the first compilers of the 1950s, whose brochures promised that managers could now write their own programs. If the models succeed where FORTRAN did not, the consequence is not that software work disappears. It is that the other 85 percent becomes the entire job, which, as the numbers have been telling us since 1956, it mostly always was.

The early evidence points the same way. A study of thirty million GitHub contributions published in Science this year found that the productivity gains from AI coding tools accrue almost entirely to experienced developers, the people who already know how to specify, review, and integrate; beginners “hardly benefit at all.”

Surveys of developers report that the time saved in writing code is being spent verifying it. The “AI engineer” who orchestrates a fleet of coding agents is, in everything but title, the systems analyst of 1965: the person who understands the problem, the organization, and the system well enough to say what should be built and to recognize when it has been built wrong. That understanding is the other 85 percent, and no one has yet shown how to generate it from a prompt.

Language models will touch the other 85 percent too; they draft requirements, write documentation, and generate tests. But in those tasks the difficulty was never the writing. It was the deciding: getting a vice president, a compliance officer, and a floor supervisor to agree on what the system should do, and discovering, after it is built, that they were wrong. That work is social before it is technical, and it does not get faster because the code does.

So the slogan has become a thesis. Coding was always the smallest part of computing, and it is the part now most exposed to automation. What remains is the part that was always hardest, least visible, and least well taught: the human and organizational work of making information systems that work. Informatics was built to study that work. We are the other 85 percent, and the percentage is rising.

Follow

• 1
  Frederick P. Brooks, Jr., The Mythical Man-Month: Essays on Software Engineering (Addison-Wesley, 1975), chapter 2. ↩︎
• 2
  Herbert Benington, “Production of Large Computer Programs” (1956), reprinted in IEEE Annals of the History of Computing 5, no. 4 (1983): 350–361. ↩︎
• 3
  B. Conway, J. Gibbons, and D. E. Watts, Business Experience with Electronic Computers (New York: Price Waterhouse, 1959), 89–90; discussed in Nathan Ensmenger, The Computer Boys Take Over (MIT Press, 2010), 39–40. ↩︎
• 4
  Willis Ware, “As I See It: A Guest Editorial,” Datamation 11, no. 5 (1965): 27; discussed in Ensmenger, The Computer Boys Take Over, 109. ↩︎
• 5
  Simone Daniotti, Johannes Wachs, Xiangnan Feng, and Frank Neffke, “Who Is Using AI to Code? Global Diffusion and Impact of Generative AI,” Science (2026), doi:10.1126/science.adz9311. ↩︎