Autocomplete as Cognitive Load: On the Price of a Line in the Age of Assistants

Generative code-autocompletion tools are conventionally positioned as a means of increasing productivity: fewer keystrokes, less boilerplate code, more completed tasks per unit of time. Such a characterization is not false, but it is incomplete. It describes a demonstration situation — a controlled environment in which every suggestion is correct by construction. An industrial codebase is arranged differently: the assistant has no knowledge of the project’s architecture, of the team’s conventions, or of the actual purpose of the current change. It models only the statistically probable continuation of a fragment resembling the current one. The gap between local plausibility and global appropriateness is precisely the subject of what follows.

It is more accurate to describe autocomplete not as a productivity tool but as a recurring test of professional judgment — a test the developer takes every few seconds, whether or not he is aware of it.

The key defect of generated code rarely lies in the fact that it does not work. Far more often it works, and is at the same time redundant. A typical scenario reproduces itself in teams with steady regularity: the assistant suggests an auxiliary validation function, the developer accepts the suggestion, the code compiles, the tests pass. A few weeks later it turns out that two nearly identical functions coexist in the codebase — one written by a human earlier, the other generated in the last sprint. Neither one is an error; together they form a duplication of logic that is caught by neither the compiler nor the test suite.

Empirical confirmation of this pattern is provided, among other things, by GitClear’s data: an analysis of hundreds of millions of lines of code over the period of mass adoption of assistants showed a statistically noticeable rise in the share of duplicated and quickly rewritten code (code churn), together with a simultaneous decline in the share of moved and reused code — that is, precisely those operations that characterize mature work with an existing codebase. Generation displaces reuse.

No single accepted suggestion, taken by itself, destroys the architecture. This is precisely the mechanism of the problem. A model trained on averaged samples will, with equal readiness, propose a new abstraction, a new dependency, or a fourth way of solving a problem already solved in the project in three ways, since the notion of “elsewhere in the codebase” does not exist for it. Accepted one at a time, such proposals lead to drift: the system disintegrates into a multitude of small dialects of one and the same idea, each of which is flawless in isolation and vicious in aggregate.

An accompanying cost item is the so-called review tax. It is not the code that is obviously bad that is costly: that gets filtered out quickly. What is costly is code plausible enough to pass a cursory look, and foreign enough to require full verification time later. Accepting suggestions without comparing them against the existing codebase does not save time but shifts the act of thinking from the moment of writing to the moment of review, or — in the worst case — to debugging in production. Teams that measure this balance honestly not infrequently discover that the total cost of checking and cleaning up generated code exceeds the cost of writing a more compact version by hand.

In essence, what has been described is not a problem specific to artificial intelligence. The difference between a beginning and an experienced engineer has historically consisted not in typing speed but in judgment about what should not be written. Junior specialists have always produced more code than senior ones, since a taste for the necessary minimum is a skill acquired through time and dearly paid-for mistakes. Generative tools did not create this gap; they merely sharply accelerated the fall into it, since the suggestion arrives before the developer manages to formulate the question of its necessity.

From this follows a practical conclusion, which is not a universal norm but does call for a conscious decision rather than a default one. Permanently enabled autocomplete is admissible given a stable reflex of rejection and full acceptance of responsibility for every accepted line. On-demand invocation for a limited class of tasks — boilerplate code, tests, migrations — introduces a moment of intention prior to turning to the tool and thereby leaves architectural decisions to the human. Finally, using the model exclusively for analysis and planning removes it entirely from the resulting change: it accelerates reasoning, not typing. All three modes represent a trade-off between speed and friction, and the choice depends on how much the team trusts its own discipline of checking in the moment.

A natural question arises: if the nature of the mechanism described is common knowledge, why does the discussion of “proper use” keep reproducing itself with unfailing regularity and never lead to abandoning the tool? Three persistent reasons can be pointed to.

First, knowing about a problem and living through the experience of it are different things. The thesis that the assistant does not understand architecture remains an abstraction right up until the developer personally spends days eliminating three coexisting variants of one validation function. Each new wave of publications is, as a rule, the recording of freshly acquired personal experience rather than the addition of new knowledge.

Second, the tool is unreliable inconsistently. A calculator that always errs by one would be discarded immediately. A calculator that errs in one case out of ten and in the other nine works faster than the user gives rise to the opposite reaction: the suspicion that it is not the device that is at fault but the method of using it. It is precisely on this effect of partial reliability that a considerable part of the accompanying how-to literature rests: the uncertainty is localized in the user rather than in the tool.

Third, publication itself performs a compensatory function. A suggestion accepted without verification that turns into a defect gives rise to a need for rationalization, and a how-to article about “modes of human-model interaction” serves as a form of that rationalization. This is more a form of group therapy for the community than an operating manual. As long as the tool retains partial usefulness, coming to terms with it will be preferred over abandoning it, and the stream of texts will not run dry.

A historical contrast is useful here. Programmable calculators like the HP-65–100 steps, 9 memory registers — excluded the very possibility of redundancy. Writing an extra auxiliary function was physically impossible: there was not enough memory. The programmer was forced to solve the problem of compressing meaning: what in the algorithm was critical, what could be excluded, how to make a single register store three values in succession. Platforms like the ZX Spectrum, with its 48 kilobytes, worked in an analogous way. This was a systematic training of taste through the harsh constraint of resources.

The generative assistant is arranged in mirror fashion: its resource is practically unlimited, and it therefore trains the opposite skill — the inflation of meaning. Why bother thinking about how to fit the logic into a single function, if in two seconds one can obtain three auxiliary ones, two abstractions, and a factory to go with them? An inversion of roles arises: the limited machine made one forget about architectural beauty for the sake of the essential blocks, and thereby taught programming; the unlimited machine makes one forget about the essential blocks for the sake of an architecture that it itself has spawned, and thereby unteaches programming. Previously the struggle was against the limitations of the hardware; now it is against the excess of code that the same hardware has obligingly generated.

It is not hard to notice that specialists who went through the school of scarcity recognize the trap described immediately: they have formed a reflex of “expensive,” since every line once cost memory. In the generation for which a line is free, this reflex has not been developed — and the muscle responsible for the question “does this need to be written at all” has atrophied through the transition from scarcity to surplus.

A related training ground was work in assembly or in bare-metal C for specific hardware without an operating system. Its value lies in the impossibility of self-deception. A data-transfer instruction has a known cost in clock cycles and bytes; a 256-byte buffer means that 128 remain for everything else; there is no intermediate layer that “will sort itself out” — there is the programmer and the silicon, and an error manifests as a silent hang with no stack trace. Such an environment forms the quality that is scarcest today: a feel for the price of a line. Code ceases to be perceived as text and comes to be perceived as clock cycles, bytes, heat, lifetime in the cache.

A person with such experience reads a generated factory of validators with immediate questions: how much does this consume, why does this exist, where will this land in memory, who will maintain it. A person without such experience perceives code as text in a merge request: it compiles, the tests are green — therefore acceptable. Assembly for specific hardware was, in this sense, not an archaism but a calibrated detector of insane code: the insane simply did not fit or did not work. The modern environment has removed this detector, replacing it with a tool that assures one that everything will fit, and offers to write still more.

The considerations set out here do not form an argument against generative assistants as such; they form an argument against interpreting them as a neutral accelerator. A tool that supplies plausible code faster than the user manages to assess its necessity shifts the critical point of the development process from writing to selection — and thereby raises, rather than lowers, the demands on professional judgment. The historical experience of ages of scarcity shows that this judgment was trained by constraints which the modern environment has removed without offering a replacement. The practical conclusion comes down not to abandoning the tool, and not to yet another methodology for its use, but to restoring the question that the age of scarcity used to ask automatically and which now has to be asked consciously: should this line exist.