4:00. But at 3:45, a Slack message popped up, something you swore would only take twenty minutes. Now an hour has evaporated, there’s no end in sight, and you’re forced to abandon your work mid-thought just to walk away.

Your wife and kids are already waiting in the car. You jump in, but as you drive, you’re trapped in your head, running through a mental checklist of what got done and what’s going to haunt you on Monday morning.

“You were on your laptop all day long and now you can’t even talk to me?” You jerk out of your trance.

“Sorry... long week. Just thinking about work.” She sighs and turns to look out the

This might as well be a video replay of my own life. I’ve spent eight years as a software engineer, almost all of it remote, with my family just on the other side of the door. For years, I felt a constant, nagging guilt that I was dropping the ball everywhere at once. I assumed it was my own personal defect, that if I were just more disciplined, organized, or focused, the weight would lift. Then I decided to check.

The Survey: You Are Not the Only One

I put together an informal survey and sent it to friends, coworkers, and online communities. I wasn't expecting scientific precision just a reality check to see if anyone else felt like they were drowning in plain sight. The results floored me.

Almost every single respondent was carrying the exact same invisible weight. Most indicated they were actively responsible for moving six or more separate tasks forward on a typical day. Majority reported being interrupted at least every hour, with many interrupted several times an hour.

When asked how hard it is to pick work back up after being pulled away, almost no one said it was easy. The single most common response:

"It's draining; switching back and forth wears me down."

The most telling discovery, however, wasn't about dropped project deadlines or missed promotions. While administrative slips happened, the primary damage was internal: a crushing, silent mental toll.

An entire productivity ecosystem exists to tell us that we are the problem. If we just organized better, used a "Second Brain," or bought another app subscription, we’d finally complete our to do list. Yet drowning in tools hasn't saved anyone. And now, AI promises to accelerate our output even further without adding a single slot to our cognitive processing power.

To understand why this feels so unsustainable, I turned to cognitive psychology. It turns out scientists have spent a century documenting every piece of this fatigue.

The Invisible Machinery: Ten Laws of Cognitive Strain

When you look closely at what modern knowledge work asks of the human mind, the exhaustion stops looking like a discipline failure and starts looking like basic physics.

1. The Structure Problem (Insight Restructuring)

When you feel overwhelmed by thirty items on a to-do list, your first instinct is to collect more data or add complex tagging systems. But Edward de Bono proved in 1970 that overwhelm is often an insight restructuring problem, not an information problem. You don't need more details; you need to rearrange the information you already have into a structural arrangement your brain can digest.

2. The Four-Slot Ceiling (Chunking)

George Miller’s landmark 1956 research on Chunking showed that working memory processes information in a small number of meaningful units ("chunks"). Facing thirty flat, unstructured tasks forces your brain to track thirty individual items. Regrouping those tasks into a few clear dependency chains or project clusters reduces the total chunk count, instantly lightening the tracking load.

3. The Unclosed Loop (Zeigarnik Effect)

In 1927, Bluma Zeigarnik demonstrated that incomplete or interrupted tasks intrude on thought far more persistently than completed ones. Your brain treats every unfinished project like a quiet alarm going off. The distress isn't caused by the volume of text on your screen; it’s the unresolved tension from every open loop firing simultaneously in your head.

4. The Pull to Finish (Ovsiankina Effect)

Building on Zeigarnik, Maria Ovsiankina (1928) discovered that humans experience a spontaneous, biological urge to resume an interrupted task even without external rewards. This is why you can't relax in the car on Friday: the interruption itself created an internal pull to finish that your brain cannot simply turn off.

5. The Toll of Context Jumps (Task-Switching Cost)

Research by Monsell (2003) proves that switching between cognitive tasks carries a measurable penalty in time, energy, and error rate. Every time you glance at Slack, check email, and jump back to code, you pay a switching tax. Pay that tax hundreds of times a day, and your brain is bankrupt by 4:00 PM.

6. The Tunnel Vision of Fatigue (Attentional Narrowing)

Under high cognitive stress, Easterbrook’s cue-utilization hypothesis (1959) shows that human attention measurably narrows. You process fewer environmental cues and miss details outside a shrunken focal zone.

Expecting yourself to handle a complex wall of priorities when you are already fatigued ignores how a stressed brain actually functions.

7. Paralysis at the Screen (Choice Overload)

When options are undifferentiated, research by Iyengar and Lepper (2000) demonstrates that choice overload leads directly to decision paralysis. Facing twenty unorganized tasks at the end of the day forces your exhausted mind to evaluate every single option from scratch, driving complete mental shutdown.

8. The Energy Drain of Re-reading (Recognition over Recall)

Classic memory literature (Mandler, 1980) shows that recognizing familiar context takes drastically less cognitive effort than recalling information unaided. Seeing a vague note like "Bob email" forces your brain to expend precious energy recalling what the issue was. Without immediate, restated context, your brain experiences friction before you even begin.

9. Missing the Trigger (Implementation Intentions)

Peter Gollwitzer (1999) proved that simple goal intentions fail without specific "If X, then Y" plans. A note that says

"Waiting on Bob" keeps the loop open because your mind doesn't know when to resurface it. Linking a task to a concrete trigger ("When Bob replies to the invoice, then send approval") pre-links the action and removes in-the-moment deliberation.

10. The Personal Fault Delusion (Affect-as-Information)

Perhaps the most damaging effect of all is the Affect-as-Information Heuristic (Schwarz & Clore, 1983).

Research shows that people frequently misattribute their internal mood to whatever they are currently evaluating.

When you feel worn down, irritable, and mentally drained at 5:00 PM, your brain misinterprets that physiological exhaustion as a personal judgment:

"I am bad at managing my life."

It Was Never a Discipline Problem

Look at what those ten findings add up to. The switching taxes you. The unfinished loops intrude. The interruptions trigger a relentless urge to finish. The cognitive load narrows your focus, while choice overload paralyzes your decisions. And when the day ends, your mind misinterprets the physical heat thrown off by this overworked engine as a personal moral failure.

The exhaustion was never the problem. It’s the byproduct. Run any engine hard enough and it throws off heat, not because it's broken, but because that's what doing work costs. The tiredness you feel on Friday afternoon isn't weakness. It’s physics.

Knowing this won't automatically clear your inbox or close every loop. But it changes the single most important thing: it removes the shame.

The next time you find yourself sitting in the car on a Friday, unable to shake the ghost of an unfinished task, you don't have to apologize for a private defect. You don't have to say "Long week" and watch the distance widen between you and the people you love.

You can recognize the feeling for what it truly is, the natural result of a mind that spent all day holding twenty open threads on a floor that wouldn't stop moving.

We can't always change the speed of modern work. But we can stop believing we are the only ones drowning under it. And sometimes, just having a name for the weight makes it a whole lot lighter to carry.

Atkinson had just spent weeks refactoring the region-calculation engine. He had replaced a clunky, original algorithm with something elegant, faster, and significantly smaller. When it came time to fill out his weekly status report, in the box for “Lines of Code Written,” he didn’t put a positive integer.

He simply wrote: -2,000.

While history never repeats it often rhymes. 40 years later we have come full circle to LOC being used as a measure of developer productivity.

If this were just a one-off opinion from a fringe person, it could be dismissed as a misunderstanding of the craft. But when Garry Tan, the CEO of Y Combinator, tweets a dashboard boasting 37,000 lines of code per day as proof of “agentic engineering” speeding up, it’s clear the rot has reached the highest levels of tech leadership. This idea has metastasized across Slacks, forums, and boardrooms: the belief that AI has magically “solved” software by making it effortless to generate mass quantities of it.

We are mistaking token burn for value creation. We are celebrating the expansion of our attack surface and the explosion of our maintenance burden as if it were progress. I’m writing this in the hope that those in leadership might step back from the dashboard and realize that vanity metrics like LOC will never tell you how much value was created only how much technical debt was financed.

This leads into a natural question, if we can not use quantity as a metric how do we define the value of software, and those who are paid to create it? Based on my own personal experience combined with ideas borrowed from experts I have the following 3 suggestions.

• User Outcomes

• Time-to-Value (TTV) and Feedback Loops

• Utility to Maintenance

1. User Outcomes: The “Windows” Litmus Test

The most obvious way to describe valuable software is the value a user receives from using it. This sounds like a platitude until you realize that all software without users is, by definition, worthless. The source code itself holds zero intrinsic value. If you don’t believe this, imagine Microsoft open-sourced the entirety of Windows tomorrow. Would Windows users immediately jump to a new startup selling that exact same code? Of course not.

The source code isn’t what makes Windows valuable, it is the Outcome the user achieves. An average user pays for Windows because they can open a laptop and work immediately. They are paying for Distribution, Support, and Trust. They are paying for a “Job” to be “Done.”

No matter how many tens of thousands of lines you generate with an AI agent, no customer will ever pay you more for it. In fact, if those lines don’t move the needle on the user’s “Time to Joy,” you haven’t created a single cent of value—you’ve just increased your own overhead.

2. Time-to-Value: Physics of a feedback loop

If you want to understand why your expensive engineering team feels slow, stop looking at their output and start looking at their feedback loops.

The quintessential catalyst for software value isn’t a new framework or an AI agent it’s the refinement of the loop the time it takes for a developer to make a change and see if it actually worked.

I learned this lesson by accident. Years ago, I took a “step back in time” to help a family member with a website running on a basic LAMP stack managed via FTP. Coming from a world of enterprise Kubernetes clusters and hour-long CI/CD pipelines, I expected to be frustrated. Instead, I was faster than I’d been in years. Because there were no massive dependency graphs or 20-minute build steps, I could try an idea and see the result in seconds. I was in a constant state of flow.

In his research on developer effectiveness, Tim Cochran emphasizes these “micro-feedback loops” the actions a developer performs 100 or 200 times a day. When those loops are fast, you get “Flow.” When they are slow, you get “Friction.”

This is where the “37k lines of code” metric becomes truly dangerous.

• More code = more dependencies.

• More dependencies = slower test suites.

• Slower test suites = broken feedback loops.

When a developer’s loop is interrupted by a slow build or a failing agent-generated test it takes an average of 23 minutes to return to a state of focused productivity. If your AI agent is dumping 37,000 lines of code into your repo, it isn’t just adding value it’s adding “noise” that clogs the pipes. It forces the human engineers to spend their day waiting for CI, debugging “hallucinated” edge cases, and losing their flow.

Instead of measuring how many lines the AI wrote today, measure how long it takes a human to validate those lines. If the “Time-to-Value” is increasing, your productivity is actually decreasing, regardless of what the LOC dashboard says.

3. Utility to Maintenance: Use it or Lose it

In the pre-agentic era, building a feature was expensive. That high cost acted as a natural filter. Because it took weeks of human engineering to implement an idea, we were forced to validate it first. We spoke to users, ran prototypes, and asked: “Is this worth the effort?”

That “friction” was actually a massive business benefit. It prevented us from cluttering the product with “invasive species” features that no one asked for but everyone has to maintain.

Now, with agents capable of pumping out thousands of lines of code in a single afternoon, that filter has vanished. New features are being shoved into products without a second thought. But here is the reality: If you are generating tons of code for features that aren’t being used, you aren’t creating value. You are burning money and financing technical debt.

In a “Garden,” a healthy plant provides shade, food, or beauty. A weed just takes up space and nutrients. Every unused “AI-generated” feature is a weed. It makes your documentation longer, your UI more confusing, and your test suites slower.

Conclusion

To be clear I am not anti-AI. These tools are the equivalent of high end power tools for a master tradesperson. They have slashed the time it takes to solve niche problems, automated the tedious boilerplate required for compilation, and can replicate a human defined pattern across a codebase in seconds. Used correctly, they are a massive win for the individual engineer.

However, we are biologically wired for the path of least resistance. Evolution taught us that cognitive energy is a scarce resource. If we can avoid thinking deeply about a complex architectural trade off by pressing a “magic solve it for me” button, we usually will.

The danger is that today’s models are just good enough to hide the rot. In a corporate environment driven by quarterly goals, a massive pile of technical debt scheduled for next year is often ignored in favor of the “velocity” shown on a dashboard today. When leadership adopts “Lines of Code” as a success metric, they aren’t just rewarding laziness they are incentivizing the industrialization of bloat.

We must return to the fundamental truth The source code is not the product. The product is the Outcome the user achieves. The code is merely the expensive, high-maintenance machinery required to deliver that outcome. If you can deliver a $1,000,000 outcome with 10 lines of code, you are a hero. If you deliver that same outcome with 37,000 lines, you have just created a $1,000,000 liability.

As we move deeper into this “agentic” era, the winners won’t be the companies that burn the most tokens or generate the most files. The winners will be the ones with the discipline to measure what matters: Does the user’s life get better, or did we just make our repo bigger?