I have been around computers long enough to remember when their limitations were not abstractions but physical facts. On machines built around the 6510 and Z80, memory was measured in kilobytes, registers mattered, and a wasteful instruction was not a theoretical inefficiency but something you could feel in the behavior of the machine. You learned how the computer worked because there was not enough machinery between you and the hardware to hide it.
Later came modems and bulletin board systems. Before the internet became something we barely noticed, there was something extraordinary about dialing another computer and hearing it answer. Connecting two machines over a telephone line felt less like using a service and more like making contact. Then there was the demoscene. We made demos that squeezed every last cycle out of the machine to show creativity, play music, display video sequences, and communicate ideas and messages. We used computers to express something from our human core. We shared our demos and competed on BBSes. And because the machines gave us so little room to waste, we had to understand how they worked. If you wanted more from the hardware, you had to know exactly what was standing in the way.
And imagine this: the underlying basic principles haven’t changed. They’re the same in 2026, but the abstraction has changed radically. Then came the commercial web, search engines, large databases, broadband, better compilers, cheap storage, statistical machine learning, neural networks, and eventually large language models.
I watched most of this happen in sequence, and sequence matters. Technologies look different when you remember the problem that existed before they arrived.
What interests me here is necessity in a fairly practical sense: whether a technology removed a substantial constraint that was already preventing us from doing something important at an acceptable cost. The personal computer answered an obvious constraint: access to computation. Networking answered another: computers were isolated. Search engines emerged because the web had grown too large to navigate manually. Databases made it practical to store and manipulate quantities of structured information that no filing system could handle. Compression, graphical interfaces, broadband and smartphones each removed limitations that had already become visible.
None of this happened cleanly. Every technological wave had hype, speculative investment, bad products, monopolistic behavior and wasted capital. There has never been an engineering meritocracy in which only necessary inventions survive. But beneath the commercial noise there was usually a recognizable pressure. People wanted more computation, easier communication, faster retrieval, cheaper storage, better interfaces or access to information that had become impractical to reach by older means.
When large language models arrived, I kept looking for the equivalent pressure. I didn't find it.
The technology was clearly impressive. A machine that could write, summarize, explain, translate, classify, imitate styles, generate code and respond to arbitrary instructions through ordinary language was unlike anything most people had used before. The commercial appeal was equally obvious. A sufficiently general language interface could be inserted into almost any software product, which meant that every large technology company could plausibly imagine it as the next platform. What was harder to identify was the bottleneck that had demanded its arrival.
When I use an LLM, there is one thing I immediately appreciate: software had always made us pay heavily to translate messy human intention into schemas, rules, interfaces and code. LLMs could often accept the mess directly. They lowered the cost of formalizing ambiguity, and therefore lowered the cost of automating things that had previously been too irregular or too trivial to justify custom software. That was a pain in the ass. But it was a bottleneck in the economics of automation, not a general crisis in knowledge work.
Software development was difficult, but the central problem was not that programmers could not produce enough code. Search had serious shortcomings, but its defining limitation was not the absence of generated paragraphs. Science had bottlenecks everywhere, but researchers were not stalled because they lacked conversational text generators. Businesses had mountains of repetitive work, yet databases, search systems, workflow engines, statistical models, APIs, classifiers and ordinary software already automated large parts of it.
By late 2022, there was no general crisis in knowledge work caused by an inability to generate language. That is the unusual part of the LLM story: the capability arrived first, and the search for indispensable applications followed.
Once enough money is committed, however, this order becomes difficult to see. Datacenters are built, accelerator supply becomes strategically important, products are redesigned, investors demand AI plans, operating systems gain assistants, software companies add chat interfaces, universities create policies for their use and businesses begin discussing how to restructure work around them. After a while, the scale of the response itself starts to look like evidence that the technology must have answered an equally large need.
But scale is not evidence of prior necessity.
That distinction is easy to lose because we tend to rewrite technological history from the present backward. Once a capability becomes normal, the world before it begins to look incomplete. We forget that people were not necessarily waiting for the thing that eventually became ubiquitous. Sometimes a problem creates a technology. Sometimes a technology creates a market around the fact that it can now exist. LLMs belong unusually strongly to the second category.
This does not make them useless. It does not make them a fraud, and it does not imply that they will fail commercially. It means only that usefulness should not be confused with necessity, especially when the infrastructure being constructed around that usefulness is so large.
The relevant question is not whether an LLM can help with something. Almost any sufficiently general system will eventually find useful applications. The more revealing question is what additional capability we are buying, at what cost, and compared with what we could already do.
That question becomes more interesting the closer one looks.
The tiny interface and the enormous system behind it
An LLM presents itself as one of the lightest interfaces ever built. You type a few words into a box and receive an answer. The experience is so frictionless that it encourages a peculiar illusion: the computation seems to disappear.
Behind that box, however, sits one of the most hardware-intensive forms of mainstream computing ever deployed. Frontier models depend on advanced semiconductor fabrication, specialized accelerators, dense networking, large datacenters, substantial power delivery, cooling infrastructure and server fleets that are expensive to build and rapidly replaced. Training large systems concentrates enormous quantities of computation into a relatively small number of facilities. Serving them at global scale turns inference itself into a continuing infrastructure problem. The physical size of the system is easy to forget because the visible result is often only a paragraph.
That contrast should make us more careful about what we call efficiency. If a person asks for an email rewrite and receives one in two seconds, the interaction is efficient from the person's point of view. That does not tell us whether the computational architecture behind the interaction is efficient relative to the task. A frontier language model can classify a document, but so can a much smaller classifier. It can perform arithmetic, but a calculator will do it exactly. It can answer a question about a document collection, but a retrieval system can expose the source directly. It can create a SQL query, but the database remains the system that actually determines the answer.
This does not mean the LLM contributes nothing. Its contribution is generality. The same system can perform all of these tasks through the same interface, often without requiring the user to know which underlying mechanism is appropriate. That is genuinely powerful.
But generality has an odd economic effect. Once a single system can do thousands of things reasonably well, it becomes tempting to use it for things that cheaper, narrower and more predictable systems already do better. The convenience of having one universal interface can hide the inefficiency of using one universal machine.
Computing spent decades building specialized systems because constraints are useful. A database is reliable partly because it is not trying to write a poem. A compiler is dependable because it is not interpreting vague intentions. A calculator does not improvise. A search index retrieves rather than invents. These systems do less, and their limitations are precisely what make their behavior easier to understand.
LLMs invert that philosophy. Their value comes from refusing to be narrow. They accept language instead of schemas, intent instead of formal instructions, approximation instead of exact specification. This is why they are unusually good at sitting in front of other software. A user can describe a goal in natural language and let the model choose which tool, database, search system or API should handle the details. The model becomes a linguistic coordination layer over systems that were already there.
That is a meaningful innovation, but it is worth seeing clearly what happened. The calculator still calculates. The database still executes. The search index still retrieves. The compiler still compiles. The specialized systems continue to perform the operations where correctness is easiest to define. The LLM translates between the ambiguity of human intention and the precision those systems require.
In other words, much of what looks like a new machine is actually a new interface to existing machines. That is useful. It may even be transformative in some domains. But it is a different claim from saying that the underlying work required generative models in the first place.
Generation became cheap; verification did not
The most obvious advantage of LLMs is speed. They can produce text, code and structured outputs far faster than a person can type them. That speed is real, and for many tasks it creates real productivity gains. The difficulty begins when we confuse producing an output with completing a task.
A legal paragraph is not useful merely because it exists. A piece of code is not finished because it was generated. A technical explanation is not correct because it sounds coherent. A citation is not valid because it has the visual shape of a citation. A medical summary is not trustworthy because its prose is fluent. Generative systems reduce the cost of producing candidate answers. They do not remove the cost of establishing whether those answers deserve to be trusted.
This is a subtle shift in where work occurs. Before generative AI, much of the effort in knowledge work was spent constructing the answer. With an LLM, construction can become almost free while checking the answer remains expensive. The work has not necessarily disappeared; part of it has moved downstream.
The asymmetry matters because falsehood is cheap to generate and often expensive to discover. A fabricated API call may take seconds to produce and much longer to debug. A plausible but incorrect technical claim may require an expert to recognize the flaw. A fake citation can be created instantly, while confirming that no such source exists takes deliberate checking. In a high-stakes domain, a fluent answer may increase rather than reduce the burden because its surface quality makes errors harder to notice casually.
The right measure of productivity is therefore not how quickly a system can generate output. It is how quickly a person can reach a trustworthy result.
Software development makes this especially clear. Writing code is visible, which makes it easy to measure, but much of the cost of software engineering lies elsewhere: understanding requirements, choosing architecture, integrating systems, testing behavior, debugging failures, securing interfaces and maintaining what has been built over time. Code generation can accelerate one stage of that process while increasing the volume of material that must later be understood and verified.
A developer who produces twice as much code has not necessarily become twice as productive. If the additional code creates more review work, more integration risk or more hidden assumptions, the gain may be smaller than the output suggests. The bottleneck simply moves.
This becomes even more pronounced when the task itself is vague. LLMs are especially good at work that traditional software finds awkward: a strangely phrased support request, a messy contract, an unfamiliar codebase, a document with inconsistent structure, an instruction that no developer explicitly anticipated. These are important capabilities because human communication is messy and the world rarely arrives as clean input.
But ambiguity has a price. The less precisely a task can be specified, the harder its output is to verify automatically. If nobody can define exactly what the correct answer should be, a model can produce something useful where ordinary software might fail, but a human often still has to judge whether the result makes sense.
This is one of the deepest patterns in generative AI. It is strongest precisely where formal correctness is weakest. The model absorbs the messiness of human intent, but it does not make that messiness disappear. It relocates uncertainty into the output and asks someone, eventually, to decide whether the result is good enough.
That is often a worthwhile trade. It is still a trade.
We are using intelligence where architecture used to be
For most of the history of software, solving a problem meant modeling it. You identified the structure of the task, designed data representations, defined rules, built interfaces and decided what should happen when inputs fell outside the expected range. Good software engineering was largely the discipline of removing ambiguity from a problem until a machine could execute it reliably.
LLMs make another strategy possible: leave more of the ambiguity in place and ask the model to interpret it at runtime.
This is enormously attractive because modeling is expensive. Requirements gathering is expensive. Designing schemas is expensive. Building parsers, edge cases and interfaces is expensive. A general language model can often produce an acceptable result without requiring developers to formally describe the entire problem. That reduces the cost of automation, especially for the enormous long tail of tasks that were never valuable enough to justify custom software.
This may turn out to be the most economically important thing LLMs do.
But it changes the character of software. Instead of making the system increasingly explicit, we are allowing part of its behavior to remain probabilistic. Instead of encoding every decision into architecture, we delegate some decisions to a model whose behavior emerges from training rather than from rules we wrote ourselves. This can make software more flexible. It can also make the boundary between specification and interpretation less clear.
A conventional system fails when an input falls outside what its designers anticipated. An LLM often produces something anyway. That is one of its great strengths, but it also changes our expectations. We begin to value graceful improvisation over refusal, coverage over certainty, generality over guarantees.
The more useful this becomes, the more natural it feels to place the model everywhere. That is how a convenience turns into an architectural default. And defaults do not remain neutral. Once organizations train employees around them, vendors redesign products around them and infrastructure is built to support them, choosing not to use the default becomes expensive. What began as one way of solving a problem gradually becomes the assumed way.
That process can happen even if the underlying technology was never necessary to begin with.
We spent decades treating brittleness as a defect. In retrospect, some of that brittleness was also a boundary. A machine that refused to continue when its specification ended was a machine whose possible behavior was easier to understand and contain.
The information problem is the mirror image of the computation problem
LLMs did not emerge from nowhere. They were trained on an enormous accumulation of human-created material: documentation, books, articles, research papers, forums, tutorials, source code, discussions and the countless small explanations people placed on the open web over decades. The internet became valuable partly because so many people contributed knowledge without requiring every use of that knowledge to become a transaction.
Generative AI changed the economics of that environment.
Human-created information is expensive. Someone has to know something, experience something, test something, observe something or think carefully enough to produce it. Synthetic text is cheap because it can reproduce the form of informative writing without incurring the original cost of acquiring the knowledge behind it. That difference matters more than whether individual AI-generated pages are good or bad.
Plausible textual material can now be produced at unprecedented scale, almost entirely disconnected from human attention. Articles, product descriptions, reviews, comments, explanations, summaries and answers can be generated faster than people can meaningfully evaluate them. The web already had spam, low-quality SEO pages, propaganda, fake reviews and automated content. Generative models did not invent information pollution. They changed its cost structure.
Producing something that looks informed is now dramatically cheaper. Determining whether it is informed is not. Again, generation becomes inexpensive while verification remains human work.
At internet scale, that changes what abundance means. More text no longer reliably implies more information. Search systems have to work harder to distinguish useful material from imitation. Readers have to become more cautious about polished explanations. Communities have stronger reasons to restrict automated participation. Publishers have more reason to control crawling and license archives. Provenance becomes more valuable precisely because fluent text is no longer strong evidence that anyone actually knew what they were talking about.
There is an uncomfortable circularity here. LLMs were trained on the information commons produced by people. Their success made synthetic substitutes for that information extraordinarily cheap. Cheap synthetic production makes the commons noisier and increases the value of trusted, original human material. The more valuable that material becomes, the more incentive its owners have to restrict access to it.
A technology made possible by a relatively open information environment can therefore contribute to conditions that make high-quality information more closed. That is not a paradox caused by malicious intent. It is simply what happens when the cost of imitation falls much faster than the cost of trust.
Usefulness is not the difficult question
The easiest response to all of this is to point out that LLMs are useful. They are.
They help people write. They help people code. They make unfamiliar technical material easier to approach. They lower the cost of summarization. They let non-programmers interact with structured systems through ordinary language. They can accelerate research, brainstorming, document analysis and many kinds of routine office work. None of that is seriously in dispute.
The mistake is assuming that usefulness answers the larger question. Useful things are everywhere. An additional researcher would be useful to almost every research team. A personal assistant would be useful to millions of people. More computing power is useful. More storage is useful. Faster networks are useful. Convenience is almost always useful.
The important issue is proportionality.
In the sense relevant here, a technology becomes necessary when it removes a substantial pre-existing bottleneck that was preventing important economic, scientific, or social goals from being achieved at an acceptable cost. When such a constraint becomes severe enough, people feel it before the solution appears. There is obvious demand for the limitation to be removed.
With LLMs, much of the pressure appeared after the invention. Once the capability existed, organizations began looking for places to insert it. Once the infrastructure existed, companies needed enough applications to justify it. Once competitors adopted it, avoiding it began to look risky. Once users became accustomed to it, software without it began to feel incomplete.
The ecosystem started producing its own necessity. Adoption can create the conditions that later make adoption appear inevitable. We build systems around a capability, reorganize work around those systems, allow older practices to atrophy and then point to our dependence as evidence that the capability must have been necessary all along.
That is not necessity. It is path dependence.
A dependency can become completely real without proving that the thing which created it was necessary in the first place.
Roads create car dependence. Platforms create platform dependence. File formats create software dependence. Communication networks create network dependence. Once enough surrounding infrastructure changes, opting out becomes harder regardless of whether the original transition answered an unavoidable problem.
Generative AI is moving through this process unusually quickly. A few years ago, writing without an LLM was simply writing. Programming without an LLM was programming. Searching without generated summaries was searching. Studying without an AI tutor was studying. Now these ordinary activities are increasingly described by comparison with the AI-assisted version, as though the original activity were a reduced mode.
That should make us curious. Not because technology should remain static, and not because older methods deserve sentimental protection, but because necessity can be manufactured by dependency.
The last dependency is the most personal one
There is one cost that does not appear in capital expenditure, electricity use, water consumption, inference prices or server utilization. It is what happens to the person on the other side of the machine.
Human beings have always used tools to extend themselves. Writing externalized memory. Books allowed one mind to encounter another across centuries. Calculators removed mechanical arithmetic from problems where arithmetic was not the point. Search engines made information accessible without requiring anyone to remember where every fact was stored. Those tools changed human work, sometimes profoundly, but they generally acted on something we had already decided to do. We formed the question, chose the method, made the judgment and used the tool to extend our reach.
The distinction is whether the tool removes effort that was only friction, or removes the activity through which we acquire the judgment needed to understand, evaluate and eventually work without the tool. A calculator can save me from arithmetic without preventing me from understanding what arithmetic means. A system that writes, reasons, interprets and proposes before I have learned to do those things, or understood them for myself, is a different kind of delegation.
LLMs enter earlier. They can intervene before the question is fully formed, before the method has been chosen, before the first bad attempt has exposed what we do not understand, before an idea has acquired enough shape to be called our own.
That distinction matters because much of what we call thinking does not occur after uncertainty has been removed. It occurs inside the uncertainty. The awkward first paragraph, the failed design, the argument that collapses halfway through, the program that refuses to work, the sketch that reveals the original idea was wrong—these are not merely obstacles between intention and output. They are part of the process by which judgment is formed.
A programmer does not become good merely by producing correct code. Skill accumulates through debugging, false starts, architectural mistakes, ugly solutions, maintenance, and the gradual recognition of patterns that no textbook can transfer whole. A writer does not develop a voice by selecting polished sentences from a menu of plausible alternatives. Voice develops through years of choosing badly, noticing why, rewriting, reading, discarding, imitating, resisting imitation and eventually learning what one actually wants to say.
A scientist does not acquire judgment merely by obtaining answers. Judgment grows through failed hypotheses, badly designed experiments, ambiguous results, disagreements with evidence and the slow development of intuition about what is worth asking next. An artist does not discover a method by requesting the fastest route from intention to finished image. Method emerges through contact with material, limitation, error, repetition and the surprising consequences of decisions that could not have been specified in advance.
Much of human capability is produced by activities that look inefficient when measured only by output. That makes them unusually vulnerable to automation.
If the objective is simply to produce acceptable code, text, analysis, images, presentations, plans and decisions as quickly as possible, then many of the activities through which people acquire skill begin to look like waste. Why struggle with the first draft when a model can supply one? Why trace the bug through the system when an assistant can suggest the likely cause? Why wrestle with the structure of an argument when the structure can be generated instantly? Why develop visual technique when the desired result can be described?
The answer cannot simply be that humans enjoy doing things the hard way. The answer is that the process changes the person doing it.
Work has never been valuable only because of the artifact left behind. It is also one of the ways human beings acquire competence, independence, taste, patience, judgment and a sense of agency. The carpenter is not merely a slow machine for producing furniture. The programmer is not a biological intermediate between a specification and a repository. The writer is not an inefficient text generator. The researcher is not a costly retrieval system attached to a laboratory.
When we describe all of these activities only in terms of output, automation appears to be an uncomplicated victory. If two methods produce the same artifact and one is faster, the slower method seems irrational.
But the artifacts are not the only outputs. The other output is the person who learned how to make them.
That is what disappears from most discussions of AI productivity. A junior developer who delegates every difficult function may ship more code while accumulating less understanding of software. A student who generates competent essays may produce better-looking assignments while becoming less capable of constructing an argument alone. A designer who begins with generated possibilities may explore more variations while gradually outsourcing the formation of visual intuition. A manager who receives synthesized recommendations may decide faster while losing contact with the underlying material from which judgment used to develop.
Nothing dramatic has to happen for this loss to occur. Nobody needs to become incapable overnight. The process can be incremental and perfectly rational at every step.
One difficult task is delegated because time is short. Then another because the tool did well the first time. Eventually the workflow is reorganized around delegation. Skills that are rarely exercised become less reliable. People entering the field learn the supervised version of the work rather than the work itself. Organizations adjust expectations around the new speed. What began as assistance becomes the assumed method, and the old method survives only as an inconvenience invoked when the machine fails.
At that point, dependence has acquired a deeper meaning. We are no longer merely using a tool. We have begun removing the conditions under which the ability to work without it would have developed.
This is especially consequential because LLMs do not merely automate mechanical steps. They automate portions of activities through which people express and construct themselves: language, reasoning, programming, explanation, interpretation, composition and imagination.
That is new territory.
Industrial machines replaced physical labor. Traditional software replaced countless clerical and computational operations. Those changes had enormous social consequences, but generative systems reach directly into the preliminary stages of intellectual production. They can propose the sentence before we have found the thought, the solution before we have understood the problem, the image before we have developed the technique, and the argument before we have decided what we believe.
The danger is not that the outputs will always be bad. The danger is that they will often be good enough.
Bad automation creates resistance. Good automation creates surrender. When the generated result is obviously poor, we retain ownership of the task because we must correct it. When it is polished, plausible and immediately usable, the temptation is to move directly to approval.
Human work then changes character. Instead of originating, we supervise. Instead of constructing, we select. Instead of exploring, we request variations. Instead of developing a method, we optimize prompts. Instead of learning why something works, we learn how to obtain a result that appears to work. The human being remains in the loop, but increasingly as a quality-control mechanism around machine production.
There is something profoundly reductive in that arrangement. For centuries, we have treated education, practice and craft as processes for enlarging human capability. The emerging logic of generative AI reverses that direction. Rather than asking how tools can extend what a person has learned to do, we increasingly ask how much of the process can be removed from the person while preserving an acceptable output.
The ideal worker in such a system is not necessarily more capable. The ideal worker is easier to separate from the production itself. They provide intent, inspect results and accept or reject what the machine returns. That may be economically efficient. It may also be a remarkably impoverished description of human work.
And the same logic reaches imagination
An LLM does not encounter the world. It has no childhood, body, mortality, embarrassment, boredom, obsession, private memory or experience of discovering something that mattered before there were words for it. Its extraordinary ability comes from finding structure in the residue of human expression and predicting what can plausibly follow from what has already been expressed.
That is why it is so useful. It is also why handing every unfinished idea to such a system changes the environment in which imagination develops.
Before an idea has become distinct, it is exposed to a machine whose greatest talent is supplying statistically coherent continuations from the accumulated past. The missing example appears. The expected structure appears. The familiar analogy appears. The awkwardness is repaired. The strange edge is rounded off. What feels like assistance can quietly become normalization.
Human imagination has always borrowed from the past; originality has never meant creation from nothing. But there is a difference between living among influences and inserting a machine optimized for plausible continuation into the earliest stages of nearly every act of creation.
Some thoughts need time before they become legible. Some ideas are valuable precisely because their first form is clumsy. Some methods emerge because the obvious method failed. Some discoveries begin as mistakes that nobody would have selected from a ranked list of plausible answers.
A culture that optimizes too aggressively for immediate coherence may become extremely productive while becoming less capable of producing the genuinely unexpected. That is the part of the AI transition that concerns me most: not that machines will become human, but that humans will gradually reorganize themselves around what machines are good at producing.
We will write in ways that are easy to generate, structure work in ways that are easy to automate, formulate questions in ways that produce clean answers, value outputs that can be measured quickly and discard processes whose benefits appear only years later in the abilities of the people who went through them.
The result would not be machines becoming more like us. It would be us becoming easier for machines to substitute.
That would be a strange conclusion to the history of computing. We built computers because human beings had ideas that exceeded what their hands could calculate. We built networks because human beings wanted to communicate across distance. We built databases because human beings wanted to preserve and organize more knowledge than any individual could hold. We built search engines because the information we had created had become too vast to navigate unaided.
Those machines extended human intention. The danger with Large Language Models is that we begin reversing the relationship: shaping human intention around what the machine can conveniently provide.
That is why the question of whether we ever needed LLMs matters.
There is a difference between solving a problem the world gave us and building a system whose consequences become a new problem we must then solve.
We did not reach some final boundary of human thought and discover that progress could continue only if machines began writing, reasoning and imagining on our behalf. We learned how to build systems that could imitate large portions of those activities convincingly, discovered that doing so was commercially useful, and then began treating the replacement of human participation as progress wherever the resulting output remained acceptable.
There is a profound difference between freeing people from meaningless labor and removing them from the activities through which meaning, competence and imagination are formed.
If we fail to preserve that distinction, the endpoint is not simply a society that uses powerful tools. It is a society increasingly populated by people who receive finished answers to questions they never learned to wrestle with, approve work they no longer know how to produce, inherit methods they never had to discover and consume culture whose creation has been progressively detached from lived human experience.
Everything may become faster. Everything may become cheaper. Everything may become more polished.
And somewhere in that optimization we may discover that we have treated the development of human capability itself as an inefficiency.
That would be the real cost.
Not that machines learned to do what humans do, but that, having built them, we decided humans no longer needed to.