The Resistance Metric: Why Developer Experience Researchers Keep Misunderstanding LLM Friction

Inside the research labs of major developer platforms like GitHub and JetBrains, user experience is typically measured through metrics of elimination. Product managers track reduced keystrokes, shorter cycle times, and the speed with which an automated assistant can output functional code. Friction is treated as a defect to be engineered away. Yet this narrow telemetry overlooks a fundamental truth known to craftspeople across every discipline: in many technical fields, cognitive friction is not an obstacle. It is the entire point.

The friction between developer intent and machine execution has become a major point of tension. As explored by software engineer Fogus in an essay titled Born Against, or why hobby programming communities are aggressively against LLM usage, specialized technical subcultures are mounting a fierce resistance against automated code generation. Across communities dedicated to chess engine development, operating system design (OSDev), emulator creation (EmuDev), language development (LangDev), retro demoscene art, and code golfing, the arrival of Large Language Models has been greeted not with enthusiasm, but with explicit hostility.

When the Process is the Product

Traditional developer experience research assumes that running software is the primary objective of any coding session. In niche hobbyist circles, however, a working executable is merely a pleasant side effect. The true product is the hard-won mastery of a difficult domain. In these spaces, peer respect is not granted for sheer volume of output. It is earned slowly over years of active participation in forums, through the demonstration of deep domain knowledge, genuine curiosity, and the publication of elegant code.

When LLM practitioners attempt to engage with these communities by presenting AI-generated solutions, they frequently misread the culture. By bursting into specialized forums to claim quick achievements, they bypass the painstaking learning process that gives the community its value. As noted in the Born Against essay, early attempts to introduce LLMs into these niche groups were rapidly poisoned. The tools provoked a double backlash driven by a persistent lack of deep domain understanding among LLM-reliant contributors, and a vocal subset of community members who view automated generation as a form of cheating.

The Blind Spots of Usability Metrics

Commercial user research is notoriously ill-equipped to measure the value of cognitive effort. Usability frameworks derived from productivity software assume that every second spent struggling with a problem represents a failure of interface design. If an AI assistant can write a memory manager for a custom operating system kernel in three seconds, standard developer experience telemetry records a massive victory. Keystrokes were saved, latency was reduced, and functional code was produced.

What the telemetry fails to record is the total erosion of comprehension. An LLM may serve as an effective force multiplier when placed in the hands of an expert who already possesses a deep structural understanding of a domain. But when deployed as a surrogate for learning, it strips away the exact cognitive exercise required to build expertise in the first place. Generating a finished artifact with an LLM does not make someone a craftsman; it simply robs them of the craft. Crucially, as Fogus points out, prior expertise offers no natural immunity against being misled by plausible LLM outputs, making uncritical reliance dangerous even for experienced practitioners.

Designing for Meaningful Resistance

To build better tools, developer experience researchers must learn to distinguish between useless friction and generative friction. Useless friction includes bad documentation, broken build environments, and convoluted toolchains. Generative friction, by contrast, is the mental strain required to understand memory allocation, balance a search tree, or optimize a rasterizer. Eliminating useless friction empowers the user, whereas eliminating generative friction impoverishes them.

If toolmakers at major platform vendors continue to measure success solely by how quickly an AI can replace human thought, they risk decoupling software development from human understanding. Future developer tools should not aim to eliminate every hurdle. Instead, UX research teams must design systems that act as educational scaffolding rather than total surrogates, preserving the difficult, rewarding friction that turns curious amateurs into genuine experts.