The focus paradox: why AI-assisted developers are getting more done and feeling worse about it

Joe Masilotti, who writes about shipping mobile apps with Rails and running a solo business, published a short confession this week that has been circulating among indie developers. The setup sounds like a productivity win. The ending sounds like a warning.

Masilotti spent years religiously tracking his time. Client work in one bucket, personal branding in another, side projects in a third, with sub-categories inside each. At year's end he had a complete map of where his hours went, cross-referenced against revenue so he could calculate his effective billable rate. Empowering for client work. Depressing for the pile of side projects that earned nothing.

Then the tracking itself became the problem. Every time an idea sparked, he hit a speed bump. Is this personal branding? Marketing? An unsolidified side project? That tiny act of categorization, a context switch stacked on top of the real context switch, was enough to kill the idea before he started. So in 2026 he stopped tracking entirely. And it was, in his words, the most freeing thing he had ever done for his business.

The twist is what makes the post worth reading. Freedom did not produce focus. It produced fragmentation.

The friction was load-bearing

Masilotti's key realization is that the annoyance he eliminated was doing quiet work. "Turns out, the friction I felt around picking one thing may have actually been beneficial," he writes. "Perhaps it was actually helping me stay focused." The few seconds of admin before starting a task forced a decision: this thing, not that thing. Remove the toll booth and suddenly every road is free, so you drive down all of them.

This is a recognizable pattern in software, and it has a name in other contexts. Constraints shape behavior. Remove a constraint and you do not just get the freedom you wanted, you get all the second-order effects you did not account for. The interesting question is why this is surfacing now, for so many developers at once.

Masilotti points at the obvious suspect. "With AI-assisted development? It means I can bounce around like all freaking day working on whatever I want without any repercussions!" When the cost of starting a new project collapses, the number of projects you start expands to fill the space. "Why work on one thing when I could work on ten things? Why limit my creativity to a single project that doesn't make money when I could be building twenty things that don't make money?"

He is honest about not knowing the cause. "I'm not sure if AI caused this or just threw lighter fluid on an existing fire."

A pattern others are reporting

The reason this post resonated is that it is not an isolated complaint. Across developer communities, a particular flavor of exhaustion keeps coming up: the feeling of high output paired with low coherence. People report shipping more, finishing fewer things, and ending the day mentally fried despite never having done hard manual labor. Tools like Claude, Cursor, and GitHub Copilot have made the act of producing code so cheap that the bottleneck moved. It used to be implementation. Now it is attention and judgment.

The mechanism is straightforward once you name it. When building something took a full afternoon, the cost of switching projects was high enough that you mostly did not. The time investment was a commitment device. AI assistance compresses that afternoon into twenty minutes, which means the commitment evaporates. Each new project becomes a cheap dopamine hit, as Masilotti himself wonders, half-joking about his ADHD: "maybe all this is just my ADHD getting dopamine hit after dopamine hit when I'm working with Claude."

There is a real psychological literature behind that joke. Variable rewards and low-cost task initiation are exactly the ingredients that produce compulsive switching. A developer who can spin up a working prototype in minutes is, neurologically, not that different from someone pulling a slot machine lever that occasionally pays out in working software.

The counter-argument

It would be easy to read this as a tidy morality tale: AI makes us scattered, friction was good, go back to tracking your time. That reading is too clean, and Masilotti does not fully endorse it either. He ends on a genuine open question rather than a lesson: "Or maybe this is just the new way of working?"

There is a case for the optimistic interpretation. Exploration has value that is invisible on a billable-hours spreadsheet. The twenty unmonetized projects are not necessarily waste. They are reps, experiments, and surface area for luck. A developer who builds ten small things learns things a developer who grinds on one thing never encounters. The old model, where every hour had to justify itself against a revenue column, may have been quietly suppressing exactly the kind of play that produces breakthroughs. Masilotti's depression over unprofitable side projects was, after all, a direct product of measuring them by money.

There is also a question of whether the exhaustion is a transition cost rather than a permanent state. People who have worked one way for a decade do not instantly develop the self-regulation that a frictionless environment demands. The discipline that used to be supplied by the tooling now has to be supplied by the person, and that muscle is underdeveloped because nobody needed it before. It is plausible that developers will build new internal constraints, new rituals and self-imposed limits, to replace the external ones the tools removed. Some already are, with practices like single-task days, deliberate project caps, or returning to manual planning specifically to slow themselves down.

And there is the skeptical take worth holding onto: maybe the feeling of getting "so much done" is partly an illusion. Output is not outcome. Twenty started projects and one finished one is not obviously better than two finished ones. The dopamine of starting is real and immediate; the satisfaction of finishing is slower and easier to skip when starting something new is always one prompt away. The genuine risk is not exhaustion, it is a portfolio of half-built things that never reach anyone.

What the post actually documents

Strip away the AI angle and Masilotti has described something developers have always known and consistently underrate: that the systems we build to manage our work shape the work itself, often in ways we only notice when we remove them. His time tracker was never just measurement. It was a governor on his attention, and he did not understand its second function until it was gone.

The reason it matters now is timing. A large number of developers are simultaneously removing friction from their workflows, not deliberately but as a side effect of adopting assistants that make starting trivially easy. Whatever quiet governing functions that friction performed are disappearing all at once, and the bill is arriving as a diffuse, hard-to-name fatigue.

Masilotti does not resolve it, and that honesty is the most useful thing about the piece. He is getting more done than ever and has never felt more scattered, and he is genuinely unsure whether that is a problem to fix or the texture of a new way of working that everyone is going to have to learn. The developers reading along and nodding suggest he is early to describing something, not wrong about it. You can read the full post on his Substack.