When AI Becomes a Distraction: One Engineer’s Reckoning

The Problem: Unlimited AI Assistance Turns Into Attention Drain

David, a software engineer who has built everything from a Rust‑based speech recognizer to a Python‑powered news site, found himself on a treadmill of side projects. Each new idea began with a prompt to an LLM, and within an hour the model would spit out a full codebase, a UI mock‑up, or a prototype script. The output was impressive, but the finished product rarely served a real need, and the maintenance burden quickly piled up.

The core issue is not the quality of the models – they can generate a parser for an obscure grammar in minutes – but the frictionless nature of the interaction. When the cost of producing a line of code drops to a few keystrokes, the natural guardrails that keep developers focused on high‑impact work disappear. David describes the experience as a “thermonuclear ADHD amplifier”: the ease of generation fuels a cascade of shallow tasks, constant context‑switching, and a growing sense of liability.

Why the Toolchain Encourages Over‑Use

1. Token‑Based Pricing Models – Most AI services charge per token, which incentivizes more output rather than better output. The business logic behind the pricing aligns with the model’s design to keep the conversation going.
2. Built‑In Follow‑Up Prompts – Even a simple yes/no question often receives a follow‑up suggestion, nudging the user toward longer interactions.
3. One‑Click Generation – Platforms such as Claude, Codex, or ChatGPT provide a single button that turns a vague idea into thousands of lines of code. The lack of a “review” step makes it easy to accept the result without critical assessment.
4. Social Feedback Loops – Colleagues regularly share screenshots of “awesome tools” they built, reinforcing the belief that constant output equals value.

These design choices create a feedback loop: more usage → more tokens → more revenue for the provider, while the user’s attention budget shrinks.

The Real Cost: Maintenance Overhead and Opportunity Loss

David catalogued over fifty side projects, many of which he later deleted. The only one that showed any traction was a regional news site built with Flask, which now draws modest traffic but also demands regular updates, security patches, and content moderation. The rest sit idle, their codebases untested and their dependencies out‑of‑date.

The hidden cost manifests in several ways:

• Time Spent Refactoring – Every generated project requires a cleanup pass to become maintainable, which eats into time that could be spent on core responsibilities.
• Cognitive Load – Switching between unrelated codebases fragments mental models, reducing the depth of understanding for any single system.
• Financial Tokens – Even a reduced‑price subscription can accumulate significant spend when usage creeps back up, as David experienced after moving from Claude to Codex.

A Decision to Pull the Plug

After months of experimentation, David reduced his Claude subscription to a lower tier, hoping a quota would curb his usage. When Claude suffered a service outage, he switched to Codex, whose command‑line interface felt smoother and faster. Predictably, his token consumption rose again.

The turning point came when he tried to repurpose an AI‑driven speech‑to‑blog pipeline. The system produced an Opus‑encoded post that was essentially noise. The ease of generation removed the commitment required to produce thoughtful content, and with that, the focus needed for any meaningful product.

Realizing that the tool was amplifying shallow work rather than enabling deep work, David chose to cancel his AI subscription entirely. He now measures his productivity by the number of completed projects that deliver value, not by the number of prototypes he can spin up in a day.

Lessons for the Wider Community

1. Introduce Friction Intentionally – Set hard limits on token usage, or require a manual code review before accepting AI‑generated output.
2. Prioritize Outcome Over Output – Ask whether a generated artifact solves a concrete problem or merely adds to a growing backlog of unfinished code.
3. Separate Exploration from Production – Use AI in a sandbox environment with clear boundaries; do not let exploratory code bleed into production pipelines without vetting.
4. Track Real Metrics – Instead of counting prompts, track completed features, reduced bug rates, or measurable business impact.

Looking Ahead

David’s experience echoes a broader concern voiced by productivity researchers like Cal Newport: tools that reduce friction can paradoxically increase the volume of shallow tasks, leaving less room for deep, value‑creating work. The solution is not a newer model or a slicker UI, but a disciplined approach to tool adoption.

By treating AI as a support rather than a replacement for focused effort, developers can reap the genuine benefits of the technology—rapid prototyping, quick language translation, and assistance with boilerplate—while avoiding the trap of endless, low‑impact generation.

Bottom line: When an AI assistant starts to feel like a liability rather than an aid, the pragmatic response is to step back, re‑establish boundaries, and let the scarcity of attention become a catalyst for purposeful work.