The AI Productivity Paradox: When Low Friction Leads to Low Value

The promise of generative AI is speed. We can now go from a vague idea to a functioning prototype in minutes, bypassing the grueling hours of boilerplate, documentation diving, and syntax debugging. But as the barrier to creation drops, a troubling paradox emerges: when the effort to build something vanishes, so does the commitment to maintain it, and often, the value of the thing itself.

This tension was recently highlighted in a candid reflection by developer David (dmw_ng), who listed nearly twenty projects built with AI—ranging from speech recognition systems in Rust to Windows 95 notepad clones. Despite the impressive technical breadth, he reached a sobering conclusion: almost none of them were useful, and he had no desire to maintain them.

The "Thermonuclear ADHD Amplifier"

For many, AI tools act as a force multiplier for curiosity, but for others, they function as a "thermonuclear ADHD amplifier." The ease of starting a new project creates a dopamine loop where the reward is the act of creation rather than the utility of the product.

This leads to a state of "pseudo-productivity," a term echoed by Cal Newport. It is the illusion of progress—sending more messages, generating more drafts, and building more artifacts—while spending less time in focused, uninterrupted deep work. When a tool can "slop out a 10,000 LOC untested Python/JS mess in 5 minutes," the engineer is no longer solving a problem; they are managing a stream of generated output.

Friction as a Filter for Quality

One of the most provocative arguments in this discussion is that friction is a feature, not a bug.

In traditional development, the difficulty of building a feature acts as a natural filter. If a project is too tedious to start, you are forced to ask: Is this actually worth doing? When AI removes that friction, the filter disappears. We end up with a surplus of "garbage" because the cost of production has fallen below the cost of critical thinking.

This is evident not just in code, but in thought. David notes that using AI to turn voice notes into blog posts resulted in "unbridled garbage." Quality writing requires the synthesis of concepts and the intentionality of structure—processes that are inherently high-friction. By removing the effort, the commitment to the output vanished, and with it, the quality.

The Counter-Argument: AI as a Prototyping Engine

Not everyone views this low-friction environment as a liability. Some developers argue that the ability to fail fast is the ultimate advantage.

"One of the best things about AIs is that you can test crazy ideas and create prototypes very fast... Creating the 100 [prototypes] before AI was extremely expensive, and took so much time. For me it is liberating and gives me focus because I can spend so little time testing prototypes and spend real time in what is really important."

From this perspective, AI is a "jig" in woodworking—a temporary tool built to solve a specific problem, used once, and then discarded. The goal isn't to build a library of maintained apps, but to use AI to rapidly iterate until a truly viable idea is found.

Finding the "Force" to Multiply

If AI is a force multiplier, the critical question is: What is the force being multiplied?

If the underlying force is a lack of direction or a craving for dopamine, AI simply multiplies the noise. However, if the force is a clear mission or a rigorous set of requirements, AI becomes a powerful accelerant.

Several strategies emerged from the community to avoid the AI productivity trap:

  • Strict Verification: Using AI for development but maintaining a human-led, strict set of documentation and tests to ensure the product aligns with a real-world need.
  • The "Rubber Duck" Approach: Using LLMs to explain documentation or refine thinking rather than generating the final code, keeping the mental model of the system entirely within the human's head.
  • Intentional Restraint: Treating LLMs like a high-speed car—capable of 1,000 mph, but most useful when driven at 20-80 mph to ensure safety and quality.

Conclusion: The Cost of Cheap Rewards

Ultimately, the danger of AI is not the technology itself, but the "cheap reward" it provides. When we can achieve a semblance of success with minimal input, we risk losing the discipline required for excellence. As one commenter noted, the next stage of engineering rigor will be the ability to reach for excellence even when it is not required by the tool.

To avoid the trap of pseudo-productivity, we must remember that the goal of software is not to write code, but to solve problems. If the tool makes the code effortless, we must make the thinking more effortful.

Sources