DEV Community: Khali Sollis

Overriding the Impostor Protocol: A Developer's Guide to Psychological Safety

Khali Sollis — Fri, 17 Jul 2026 14:00:00 +0000

Many software teams have gotten smaller. Over the last several years, a large share of the industry has drifted away from heavily layered engineering departments and toward small, highly autonomous squads — three or four people who own a service end to end, ship independently, and answer to a backlog instead of a hierarchy. The pitch is obvious: less coordination overhead, faster decisions, tighter ownership. What gets less attention is what this shift does to the person sitting inside one of those small teams at eleven at night, staring at a pull request they're not sure is right, with no senior engineer down the hall to ask.

That scene is becoming increasingly common, and organizational psychologists are starting to notice the cost. Research on team design has found that as organizations flatten and autonomy increases, individual cognitive load rises with it — engineers are absorbing more decisions, more ambiguity, and more responsibility for judgment calls that used to be distributed across a bigger group. The traditional scaffolding of a large team — a tech lead to sanity-check your approach, a QA process to catch what you missed, a manager buffering you from the business side — is exactly the kind of redundancy that autonomous team structures are designed to strip out. That redundancy, it turns out, was doing more than distributing work. It was distributing anxiety.

This matters because the psychological experience of writing code hasn't changed at the same pace as the org chart. Developers still have the same nervous system humans have always had, one built to read ambiguity as danger and isolation as risk. What's changed is the amount of unresolved uncertainty an individual is now expected to metabolize alone. The result is a workplace environment where many developers report higher levels of performance anxiety, and where a very old, very familiar visitor keeps showing up: impostor feelings. This piece is about why that's happening, what the underlying psychology actually is, and what a developer — and a team — can do about it that isn't just "believe in yourself."

The Ambiguity Threat: Why Your Brain Treats a Vague Ticket Like a Predator

Impostor syndrome gets talked about as if it were a personality quirk, a flaw in certain people's self-confidence wiring. That framing is mostly wrong, and it's worth being precise about why.

The human brain did not evolve in a world of shifting technical specifications, but it did evolve in a world where not knowing something — where the threat was, whether a stranger was hostile, whether the ground ahead was safe — could get you killed. Ambiguity itself, not just concrete danger, is something the brain is built to treat as risky. Neuroscience research on uncertain-threat anticipation has found that ambiguity engages threat-processing networks involving regions such as the amygdala and related circuits associated with vigilance and prediction, and that these networks tend to stay engaged for longer, and less predictably, than when a threat is clear and defined. A known threat, oddly, is often easier on the nervous system than an unknown one. Certainty lets the brain relax once the threat has passed. Ambiguity keeps the alarm running in the background indefinitely, because there's no clear signal telling it the "all clear" has arrived.

This is not a fringe finding. A body of work on anxiety and uncertainty, reviewed in detail by researchers studying anxiety disorders, describes something close to a general principle: people don't just respond to danger, they respond to the inability to predict danger, and that inability is often more distressing than the danger itself. People with a harder time tolerating uncertainty show heightened activity in threat-related brain circuitry specifically when a situation is ambiguous, even when nothing bad is actually happening.

Translate that into a developer's daily experience and the pattern becomes obvious. A vague ticket, a codebase you didn't write, a spec that changes mid-sprint, a pull request sitting unreviewed for two days with no comment — none of these are physically dangerous. But they are ambiguous, and ambiguous is precisely the category of stimulus your threat-detection system was built to flag. When you're on a small team without someone to immediately clarify the ambiguity for you, that flag doesn't get resolved. It just sits there, humming, and your brain interprets the hum as evidence that something is wrong with you rather than evidence that the situation is genuinely unclear.

That's the mechanism behind what we might call the ambiguity threat in engineering contexts: a baseline of low-level anxiety that isn't really about your competence at all. It's a background threat-response running because the environment is feeding your brain exactly the kind of unresolved signal it's wired to worry about. Machine-speed codebases — fast-moving repos, rapidly shifting dependencies, specs that update while you're mid-implementation — generate an unusually high volume of that signal. Your threat-detection systems don't have a clean category for "ambiguous but professionally routine." They just have ambiguous, and they respond to it the same way they always have.

AI-assisted development adds a newer version of this same problem. A developer can now generate code faster than they can build genuine confidence in their understanding of it. The bottleneck shifts from producing output to validating judgment. When a model hands back a plausible-looking solution with reasoning that isn't fully visible, the psychological challenge stops being just "can I write this?" and becomes "can I actually tell whether this is correct?" That's a harder, more ambiguous question, and it arrives more often, for more of the day, than it used to. In that environment, the team practices described below matter even more, because asking out loud "does this approach actually hold up?" needs to function as a normal, expected part of engineering work rather than something that reads as a gap in skill.

Impostor Syndrome Wasn't Designed for Software Engineering

The term "impostor phenomenon" comes from a 1978 paper by psychologists Pauline Clance and Suzanne Imes, who studied a group of more than 150 highly accomplished women — professors, professionals, people with strong track records of success — who nonetheless felt they were frauds who had somehow fooled everyone around them. Clance and Imes described this as an internal experience of intellectual phoniness, one that persisted no matter how much objective evidence of competence a person accumulated. Notably, they didn't even call it a syndrome — Clance later pushed back on that label, since it implies a disorder located inside the individual, when what she was actually describing was more like a persistent, situationally reinforced belief pattern.

In the decades since, research has confirmed the impostor phenomenon shows up well beyond its original context — across genders, across professions, and with particular intensity during transitions: new job, new team, a jump into unfamiliar technical territory. That last detail matters a lot for engineering. Software development is one of the only professions where the "unfamiliar territory" transition never really ends. Frameworks turn over, best practices get revised, an entirely new tool can become table stakes within eighteen months. Developers are, in a sense, permanently new.

What's useful about connecting the ambiguity-threat research to the impostor-phenomenon research is that it reframes the whole experience. Impostor syndrome isn't a verdict about your actual skill. It's what it feels like from the inside when a nervous system built to treat unresolved ambiguity as risk is placed in an environment that produces an unusually steady diet of exactly that kind of ambiguity — a fast-moving codebase, limited external feedback, a small team without much structural redundancy. "I'm not good enough" is a more emotionally coherent story than the accurate but less intuitive one: my threat-detection circuitry is responding to unresolved uncertainty, and it doesn't reliably distinguish a vague spec from a genuine threat.

That reframe doesn't make the feeling disappear. But it changes what you do with it, which is the more useful question.

Cognitive Reframing for Engineers: Read the Error Log, Don't Internalize It

Developers already have a mental model that's unusually well suited to handling this, they just don't usually apply it to themselves: the error log.

When a system throws an error, a competent engineer doesn't take it personally. Nobody thinks "this stack trace means I'm fundamentally broken as a person." The instinct is investigative — what triggered this, what was the input, what's the actual failure condition. That instinct is worth deliberately importing into how you handle self-doubt.

This isn't just a metaphor; it maps onto something real in the psychology of emotion regulation. A well-replicated line of research on what's called affect labeling — the simple act of naming an emotion in specific, concrete language rather than just experiencing it — has found that putting a feeling into words is associated with reduced amygdala activity and increased engagement of regulatory regions of the prefrontal cortex. In practice, this means the difference between "I'm an impostor, I don't belong here" and "I'm noticing anxiety because this ticket is ambiguous and I haven't gotten feedback on my approach yet" is not just semantic. The second version is functionally closer to reading a log line than absorbing a verdict, and the research suggests that specificity itself has a calming effect on the underlying physiological response, independent of whether the situation has actually changed.

The practical version of this looks something like a debugging checklist, applied to the feeling itself rather than suppressed or fought:

What's the actual input? Usually it's something concrete — an unreviewed PR, a spec that changed twice this week, a codebase you inherited without documentation. Naming the specific trigger, rather than the diffuse feeling of dread, does most of the regulatory work.

Is this ambiguity resolvable, or is it structurally built into the situation? Sometimes the fix is asking a direct question. Sometimes the honest answer is that the codebase genuinely is underdocumented and the anxiety is a reasonable response to a real information gap, not a personal failing.

Is there a feedback loop I can shorten? Impostor feelings often thrive in feedback vacuums — work that goes into a PR queue and sits for days without comment. Shortening that loop, even by asking for a quick async check-in, gives your threat-detection system the "all clear" signal it's been waiting for.

None of this is about talking yourself out of a legitimate skill gap — sometimes the honest read of the error log is "I do need to learn this," and that's a fine, ordinary conclusion, not a crisis. The goal of reframing isn't relentless positivity. It's accuracy. Treating self-doubt as a data point to be examined, rather than a truth to be absorbed, keeps the signal without letting it metastasize into a story about your worth as an engineer.

Building Team Immunity: Psychological Safety in Small, Fast Teams

Individual reframing only goes so far if the team environment keeps generating the same volume of unresolved ambiguity. This is where the research on psychological safety becomes directly relevant, and it's worth being precise about what that term actually means, because it gets used loosely.

The concept comes out of work by Harvard Business School researcher Amy Edmondson, who in the late 1990s studied hospital teams expecting to find that better-performing units made fewer medication errors. She found that higher-performing teams reported more errors, which suggested they were more willing to surface mistakes rather than hide them, while lower-performing teams were more likely to under-report the errors they were actually making. Edmondson's subsequent research formalized this into psychological safety: a shared belief within a team that it's safe to take interpersonal risks — asking a question that might sound basic, admitting you're stuck, flagging a mistake before it compounds — without fear of embarrassment or punishment. Years later, Google's internal Project Aristotle research, studying roughly 180 of its own teams, independently arrived at a strikingly similar conclusion using very different methods: among the characteristics Google's researchers identified as associated with effective teams, psychological safety emerged as the strongest one, ahead of who was actually on the team.

It's worth being clear about what psychological safety is not, since the term gets softened in ways the research doesn't support. It isn't the absence of high standards, and it isn't a euphemism for niceness. Psychologically safe teams still disagree openly and give direct feedback — in fact, visible disagreement is often a sign the safety is working, not a sign it's absent. What it protects is the willingness to say "I don't know" or "I think this is wrong" out loud, rather than silently absorbing the uncertainty alone.

For a small, autonomous engineering team, this translates into fairly concrete practices, most of which live in the parts of the workflow developers already touch daily.

Code review language matters more than it seems. A comment that reads "this is wrong" produces a very different physiological response than one that reads "I'm not sure this handles the edge case where the list is empty — can you walk me through the reasoning?" Both might be pointing at the same bug. Only one of them treats the ambiguity as a shared problem to investigate rather than a verdict on the author.

Normalizing "I don't know" from senior people specifically does more work than any written policy. When the most experienced person on a small team openly says they're not sure how something works, or that they'd need to look something up, it recalibrates what "competent" is allowed to look like for everyone else on the team. Edmondson's own guidance on this point is that leaders acknowledging their own fallibility is one of the more reliable ways to shift a team's norms, because it directly contradicts the assumption that not-knowing is disqualifying.

Shortening feedback loops on pull requests is a structural fix for a psychological problem. A PR that sits unreviewed for two days doesn't just delay a merge — it extends the window in which the author's threat-detection system has no "all clear" signal. Even a same-day partial response ("haven't done a full review yet, but this approach looks right at a glance") closes that loop faster than silence does, and the ambiguity-threat research suggests that matters more than it might seem to on a busy team.

This becomes even more important in AI-assisted environments, where the ability to question, verify, and challenge generated output needs to function as a team capability, not just something each developer is expected to sort out alone.

None of this requires reversing the industry-wide move toward smaller teams, which brings real benefits in speed and ownership. It requires recognizing that smaller teams removed some of the structural redundancy that used to absorb ambiguity on a developer's behalf, and that the difference has to be made up somewhere — either by the individual's own regulation skills, or by deliberate norms the team builds into its daily workflow. Realistically, it needs to be both.

The Developer Debugging Checklist

The reframing described throughout this piece compresses into something closer to a quick reference than a mindset. When impostor feelings show up mid-task, it can help to run through it the way you'd triage a failing build:

Identify the input. What concrete uncertainty triggered this — a vague ticket, an unreviewed PR, an unfamiliar part of the codebase?
Separate signal from story. Is there real evidence of a skill gap here, or is this an information gap that anyone in your position would hit?
Reduce the feedback latency. Who can help close the uncertainty loop, and how quickly can you actually ask them?
Convert anxiety into action. What's the next smallest experiment or question that would move this from ambiguous to resolved?

None of these steps make the feeling vanish on contact. They just route it toward something a debugging mindset already knows how to do: investigate the input instead of accepting the alert at face value.

Conclusion: The Signal Was Never the Problem

The presence of performance anxiety among developers isn't a sign that engineers have gotten more fragile, or that today's teams are somehow less capable than the generation before them. It's a predictable outcome of an environment that generates an unusually high volume of unresolved ambiguity compared with more traditional engineering structures, delivered to people working in smaller units with less structural buffering than they used to have. The nervous system responding to that environment is doing exactly what it evolved to do. It's just applying an old survival mechanism to a workplace it wasn't built for.

Understanding impostor syndrome this way — as a response to environmental signal rather than a verdict on personal worth — doesn't dissolve the feeling on contact. But it does change what a developer does with it: name the actual trigger instead of the diffuse dread, treat the feeling as information to investigate rather than truth to absorb, and recognize that shortening the gap between uncertainty and resolution is a legitimate technical and psychological intervention, not a soft skill tacked onto the real work.

As engineering organizations continue experimenting with smaller, faster, more autonomous team structures, the psychological cost of that speed is likely to become a more explicit part of how teams are designed, not just how individuals cope. The next wave of tooling and process design in software engineering may end up looking less like project management and more like applied cognitive science — feedback loops, review norms, and team rituals built with an explicit understanding of how the human threat-detection system actually works. The code has been moving at machine speed for a while now. The interesting problem left to solve is how the humans writing it keep up without quietly convincing themselves they don't belong there.

Scientific Reference

Clance, P. R., & Imes, S. A. (1978). The impostor phenomenon in high achieving women: Dynamics and therapeutic intervention. Psychotherapy: Theory, Research & Practice, 15(3), 241–247.

Grupe, D. W., & Nitschke, J. B. (2013). Uncertainty and anticipation in anxiety: An integrated neurobiological and psychological perspective. Nature Reviews Neuroscience, 14(7), 488–501.

Hur, J., Smith, J. F., DeYoung, K. A., Anderson, A. S., Kuang, J., Kim, H. C., Tillman, R. M., Kuhn, M., Fox, A. S., & Shackman, A. J. (2020). Anxiety and the neurobiology of temporally uncertain threat anticipation. Journal of Neuroscience, 40(41), 7949–7964.

Lieberman, M. D., Eisenberger, N. I., Crockett, M. J., Tom, S. M., Pfeifer, J. H., & Way, B. M. (2007). Putting feelings into words: Affect labeling disrupts amygdala activity in response to affective stimuli. Psychological Science, 18(5), 421–428.

Edmondson, A. C. (1999). Psychological safety and learning behavior in work teams. Administrative Science Quarterly, 44(2), 350–383.

Edmondson, A. C. (2019). The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth. Wiley.

Duhigg, C. (2016, February 25). What Google learned from its quest to build the perfect team. The New York Times Magazine.

Skelton, M., & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press.

Mental Unfollow: Reclaiming Your Cognitive Space After Emotional Attachment

Khali Sollis — Fri, 17 Jul 2026 12:00:00 +0000

How emotional attachment becomes mental occupation, why attention functions like system resources, and what changes when you stop allowing one person to dominate your internal architecture

I used to think detachment meant forcing myself not to care.

That never worked.

Because the real problem wasn’t emotional intensity.

It was cognitive occupation.

Someone had taken up permanent residency inside my mental environment.

Not physically.
Mentally.

They were present:

in my mornings
during work
inside random pauses
behind ordinary moments
underneath unrelated thoughts

The relationship had changed.

But internally, the process was still running.

The Bug: Emotional Attachment as Background Processing

Most people think attachment is about love.

Often, it’s about repetition.

The mind builds recursive loops:

memory
→ interpretation
→ emotional reaction
→ replay
→ reinforcement

Repeated enough times, the person becomes cognitively embedded.

Not because they are continuously present in reality.

Because they remain continuously active in attention.

Mental Occupation Is Resource Consumption

One realization changed everything:

Attention is infrastructure.

Whatever consistently occupies it begins shaping:

emotional state
nervous system regulation
identity stability
behavioral patterns

Which means emotional attachment is not just emotional.

It is architectural.

If one person dominates your internal environment:

focus decreases
emotional volatility increases
self-reference weakens

The system gradually reorganizes itself around their presence or absence.

The Difference Between Reality and Interpretation

The attachment often survives because the mind confuses:

reality

with:

interpretation

Reality:

They became distant.

Interpretation:

I wasn’t enough.

Reality:

The relationship changed.

Interpretation:

I lost my future.

Most suffering wasn’t generated by events themselves.

It came from the emotional narratives attached to them.

Expectation, Illusion, Habit

Eventually, I realized attachment was built on three unstable dependencies.

Expectation

Not the person themselves.

The imagined future surrounding them.

The mind mourned:

projected timelines
imagined conversations
hypothetical versions of life

Many emotional contracts existed only internally.

Illusion

The attachment survived partly because I remained attached to potential instead of patterns.

who they could become

over:

who they consistently were

The nervous system prefers fantasy when reality threatens emotional investment.

Habit

This was the most underestimated layer.

Sometimes I didn’t miss the person.

I missed:

the routines
the checking
the anticipation
the familiarity
the emotional stimulation cycle

The attachment became procedural.

The Realization

Detachment is not:

becoming cold
suppressing emotion
pretending not to care

It is reclaiming cognitive territory.

Because when someone continuously occupies your attention, they indirectly influence:

your emotional baseline
your nervous system
your energy allocation
your identity stability
The Stoic Parallel

Stoicism emphasizes a simple but brutal distinction:

event
≠
interpretation

The event exists.

The emotional meaning layered onto it is often self-generated.

Which means emotional suffering frequently persists because the mind keeps refreshing the narrative.

Not because reality keeps happening.

The Fix: Mental Unfollow

I stopped focusing only on physical distance.

I started reducing mental access.

Not blocking.

Not hatred.

Cognitive boundary enforcement.

Label the Mental Visit

Whenever the thought loop appeared:

memory detected

I stopped treating it as truth.

I identified it accurately:

nostalgia
longing
uncertainty
fear
emotional habit

Naming the process weakened automatic immersion.

Reduce Recursive Thinking Time

Old pattern:

trigger
→ 45-minute emotional spiral

Updated pattern:

trigger
→ acknowledge
→ redirect attention

The goal was not suppression.

It was reducing emotional dwell time.

Remove Reinforcement Triggers

Certain behaviors continuously reopened the loop:

checking social media
rereading messages
replaying conversations
revisiting symbolic locations
consuming emotional reminders

The nervous system cannot recalibrate while constantly retriggering itself.

Replace the Cognitive Pathway

This part mattered most.

Detachment cannot exist in a vacuum.

Attention needs redirection.

Instead of:

obsession loop

the system needed:

training
writing
work
movement
creation
future-oriented behaviors

New pathways reduce old dependencies.

Emotional Reactivity and Nervous System Conditioning

One difficult truth:

Many reactions weren’t love.

They were conditioned nervous system responses.

notification
→ dopamine spike
silence
→ anxiety response
memory
→ emotional activation

The body learned the pattern before the mind questioned it.

Which is why detachment initially feels physically uncomfortable.

The system is recalibrating.

Pause → Label → Reframe

This became the most useful interruption framework.

Pause

No immediate reaction.

No impulsive interpretation.

Label
This is anxiety.
This is nostalgia.
This is fear of abandonment.

Not:

This is reality.
Reframe

Ask:

What are the observable facts?

Not:

What catastrophic story can I build?

This restored clarity surprisingly fast.

Rebuilding Identity Outside the Attachment

Another painful realization:

Part of the suffering came from losing the identity attached to the relationship.

The old self felt:

chosen
desired
emotionally anchored

When the attachment destabilized, identity destabilized with it.

Which meant detachment required rebuilding self-definition independent of the connection.

Not theoretically.

Behaviorally.

Reclaiming Internal Space

Eventually, the system stopped asking:

How do I get them back?

And started asking:

How do I get myself back?

That question changed the architecture entirely.

Because the goal stopped being emotional recovery through another person.

The goal became internal coherence.

Reframing Detachment

Old model:

Detachment = suppression

Updated model:

Detachment = reclaiming cognitive sovereignty
Takeaway

Emotional attachment becomes dangerous when another person occupies more mental space than your own future does.

The solution is not hatred.

Not emotional numbness.

Not pretending the connection never mattered.

The solution is reducing unnecessary mental occupation until your attention belongs to you again.

Because attention shapes identity.

And whatever repeatedly occupies your mind eventually occupies your life.

Status
Emotional recursion loops: weakening
Mental unfollow protocols: active
Cognitive territory: gradually reclaimed

The Science of "Local Sleep": Why Your Code Gets Worse After Hour Six

Khali Sollis — Wed, 15 Jul 2026 14:00:00 +0000

It's hour six. The coffee stopped working around hour four. You're still staring at the same function, still typing, still technically awake — but something has changed. The bug that would have taken ten minutes to spot at 10 a.m. is now invisible to you at 4 p.m., even though it's sitting right there in the diff. You tell yourself you just need to push through, finish the feature, ship the fix. So you do. And tomorrow morning, with fresh eyes, you delete half of what you wrote.

This is such a common experience in software work that it barely registers as strange. We treat it as a willpower problem, a caffeine problem, maybe a "just go to bed earlier" problem. But a growing body of neuroscience suggests something odder is going on, something that has nothing to do with motivation and everything to do with basic brain physiology. Under the right conditions, small clusters of neurons in your frontal cortex can start behaving as if they're asleep — dropping into brief, localized down-states — while the rest of your brain, and you, remain awake. Researchers call this local sleep, and it may be one of the more precise biological explanations we have for why exhausted coding sessions produce work you have to redo.

This isn't a metaphor. It's not "your brain is tired" as a figure of speech. It's a measurable, regional phenomenon, and understanding it changes how you might think about pushing through a long day at the keyboard.

Sleep Was Never Supposed to Be an All-or-Nothing Switch

For most of the twentieth century, sleep science treated sleep and wakefulness as two clean, mutually exclusive states governed by the whole brain at once. You were either asleep or you weren't. That model started to crack in the late 2000s and early 2010s, when researchers studying sleep-deprived rats noticed something strange in their brain recordings: even while the animals were behaviorally awake and moving around, certain neurons in the cortex would briefly go quiet, firing in patterns identical to the "off periods" seen during normal deep sleep. These weren't whole-brain events. They were confined to small populations of neurons, often in specific cortical regions, while neighboring populations kept firing normally.

A landmark 2011 study led by Vladyslav Vyazovskiy and colleagues, published in Nature, gave this phenomenon its name and its first solid evidence base. After extended wakefulness, cortical neurons in rats dropped into these brief sleep-like states even though the animals showed no outward sign of drowsiness. More strikingly, when these local off-periods occurred in the motor cortex right before the animal attempted a reaching task, performance suffered. The neurons "sleeping" were, quite literally, the ones responsible for the skill being tested. Follow-up work, notably from Chiara Cirelli and Giulio Tononi's sleep research group, found that local sleep doesn't strike the brain evenly — it concentrates in regions that have been working the hardest, as though heavily used circuits accumulate their own local sleep debt, independent of how sleepy the animal feels overall.

From Rat Cortex to the Human Frontal Lobe

Most of the direct evidence for local sleep — the kind involving electrodes recording individual neurons — comes from animal studies, for obvious ethical and technical reasons. Human research relies on coarser tools like EEG, but it points the same direction. Studies of sleep-deprived volunteers consistently find that slow-wave activity, the electrical signature associated with deep sleep, shows up disproportionately over frontal brain regions during prolonged wakefulness, well before someone would describe themselves as needing to sleep, and this frontal slowing tracks subjective sleepiness more tightly than whole-brain measures do. Researchers are careful to note this doesn't prove individual neurons in a tired person's prefrontal cortex are dropping into literal sleep states mid-task; single-neuron resolution in humans isn't available yet, so the human findings are best read as a compatible extension of the animal work rather than direct confirmation. What they do support, with reasonable confidence, is the broader pattern: prolonged wakefulness produces localized, disproportionate degradation in frontal brain function, well before a person consciously registers being too tired to work. Researchers have also linked these localized sleep-like events to brief attentional lapses, offering another possible explanation for why obvious errors sometimes become strangely invisible during a long stretch of work.

That distinction matters. The frontal cortex isn't just another brain region. It's the seat of what neuroscientists call executive function — the machinery responsible for planning, weighing tradeoffs, holding multiple things in mind at once, and inhibiting bad impulses. If any part of the brain is likely to show early signs of strain during a long stretch of demanding cognitive work, the frontal cortex is one of the worst places for that strain to appear if your job depends on careful, structured thinking.

Why the Brain Puts a Price Tag on Thinking

There's a second, related strand of research that helps explain why a tired brain doesn't just get slower — it starts making different kinds of decisions. This comes out of work on what psychologists and neuroscientists call the cost of cognitive control.

The older explanation for mental fatigue, "ego depletion," treated willpower as a fuel tank that simply runs dry. That idea has largely fallen out of favor after large replication efforts failed to reproduce it, so it's worth setting aside in favor of a better-supported account.

A more durable line of research, associated with psychologists Wouter Kool and Matthew Botvinick, offers a different and better-supported account. Their work suggests the brain treats sustained mental effort not as a resource that simply drains, but as something it actively evaluates for cost, the same way it might weigh the cost of a physical action. Using tasks that let people choose between easier and harder versions of a problem, Kool and Botvinick found that people reliably steer toward the lower-effort option, even when the harder option would produce a better outcome and takes only marginally more work. Brain imaging tied this preference to activity in the lateral prefrontal cortex, the same broad region implicated in local sleep research, with the strength of that activity predicting how strongly an individual avoids demanding tasks.

The theoretical framework built around these findings, often called the cost of control hypothesis, proposes that cognitive control is inherently registered by the brain as effortful and mildly aversive, and that people (and other animals) are constantly running a background calculation about whether continued effort is worth it. Under this model, fatigue doesn't necessarily mean your cognitive machinery has literally run out of gas. It can mean the brain has revised its internal accounting and started rating effortful, careful thinking as not worth the cost — a shift that happens well before actual capacity hits zero.

Put those two lines of research together and a coherent picture starts to form. As a demanding task like debugging stretches into its fifth or sixth hour, two things are likely happening at once: heavily used frontal circuits are accumulating local sleep pressure and periodically going quiet, and the brain's ongoing cost-benefit evaluation of continued effort is tilting against sustained, careful control. Neither process requires you to feel dramatically sleepy. Both can happen while you're still upright, caffeinated, and staring intently at a monitor.

When the Careful Planner Clocks Out, Habits Take the Wheel

If the prefrontal cortex is scaling back — whether through local sleep, rising effort costs, or both — something else has to be steering behavior, because the fingers are still typing and decisions are still getting made. That's where a much older and more thoroughly established piece of neuroscience becomes relevant: the basal ganglia's role in habit formation.

The basal ganglia are a cluster of structures deep in the brain long known to be central to how habits get encoded and executed. Decades of research, including influential work from neuroscientist Ann Graybiel at MIT, has shown that as a behavior becomes well-practiced, control over it gradually shifts away from the deliberate, flexible planning done by the prefrontal cortex and toward the more automatic, pattern-matching circuitry of the basal ganglia. This is generally a feature, not a bug — it's the same mechanism that lets you drive a familiar route without consciously thinking through every turn, freeing up limited executive resources for whatever is genuinely novel in front of you.

The trouble is that this handoff isn't selective about quality. The basal ganglia reinforce practiced behavioral patterns without evaluating whether they're the most appropriate choice for a novel problem; they simply execute whatever has been repeated most often, with the least resistance. When prefrontal function is degraded and the basal ganglia take over more of the moment-to-moment decision-making, behavior tends to default to whatever is most familiar, not whatever is best suited to the problem at hand.

This offers a plausible mechanistic story for a pattern many experienced developers recognize: late in a long session, one possible consequence is a greater tendency to rely on familiar patterns rather than carefully evaluating alternatives — reaching for the first solution that technically works rather than the one that fits the architecture. It isn't that the person got lazier or stopped caring. It's a plausible consequence of executive circuitry stepping back while older, lower-effort circuitry fills the gap, consistent with what you'd expect if frontal regions are experiencing local, regional fatigue while the rest of the brain carries on.

What This Looks Like at the Keyboard

None of this research was designed with software developers in mind — the underlying studies involve rats reaching for pellets, human volunteers doing memory tasks in scanners, and people choosing between easy and hard card-sorting problems. But debugging and system design sit squarely in the category of activity this research describes: sustained, effortful, prefrontal-heavy cognitive control, applied over long, uninterrupted stretches, with no built-in signal telling you when the underlying hardware has started to degrade.

That absence of a clear internal signal is arguably the most important, and most underappreciated, part of this picture. Physical fatigue announces itself. Your arms get heavy, your eyes sting, your body makes it hard to ignore that something has changed. Local, regional cognitive fatigue in the frontal cortex doesn't come with an equivalent alarm. You can feel reasonably alert in a general sense — awake, upright, tracking the conversation in Slack, aware of what time it is — while the specific circuits responsible for weighing architectural tradeoffs, holding a complex mental model of a codebase, and catching subtle logical errors are already operating at reduced capacity. The mismatch between how alert you feel and how well your executive function is actually working is precisely what makes this kind of fatigue dangerous for any work that depends on careful judgment.

It also explains a familiar and slightly demoralizing pattern: reviewing code the next morning and immediately spotting problems that were completely invisible the night before, even though nothing about the code changed and nothing about your intelligence changed either. What changed was the operating condition of the specific brain regions doing the evaluating. A rested prefrontal cortex, not fatigued and not compensating for local shutdowns, is simply a different instrument than the one you were using at hour six.

From Managing Time to Managing Cognitive Energy

The traditional framing of productivity in software work is almost entirely built around time: sprint velocity, hours logged, deadlines, calendar blocks. That framing assumes a roughly constant unit of cognitive capacity per hour, as if an hour of focused work at 9 a.m. and an hour of focused work at 9 p.m. are interchangeable inputs. The research on local sleep and effort cost suggests that assumption is close to backwards for anything requiring sustained executive function.

A more accurate model treats cognitive capacity, particularly the specific capacity for careful, controlled, judgment-heavy thinking, as a resource that fluctuates across a session in ways that don't track clock time or subjective sleepiness particularly well. Under this model, the more useful question isn't "how many hours have I worked" but something closer to "how much regional fatigue has accumulated in the circuits this task actually depends on, and has my brain's internal cost-benefit calculation already started favoring shortcuts over careful control."

This doesn't translate into a tidy productivity hack, and the research doesn't support one. There's no verified trick for switching local sleep off, and the honest scientific answer to "how do I prevent this" is still, overwhelmingly, adequate sleep and reasonable limits on continuous demanding cognitive work — genuinely unglamorous advice, but the advice the evidence actually supports. What the research does offer is a better diagnostic lens. Recognizing that hour-six sloppiness has a plausible physiological basis, rather than treating it purely as a discipline failure, changes how a person might reasonably respond to it: not with more caffeine and more willpower, but with a break, a walk, or simply stopping and picking the problem back up with a less fatigued frontal cortex the next day.

Looking Ahead

The science of local sleep is still young, and researchers in the field are appropriately cautious about how far to extend it. Most of the strongest evidence remains rooted in animal studies with single-neuron resolution that hasn't yet been matched in humans, and the connection between laboratory findings and real-world knowledge work is, for now, a reasonable inference rather than a directly tested claim. It would be an overstatement to say science has proven that your prefrontal cortex is "asleep" during a late debugging session in any literal, verified sense.

What the research does establish, carefully and with real evidence behind it, is that wakefulness and full cognitive function are not the same thing, that fatigue in the brain is not evenly distributed, and that the regions most responsible for careful judgment appear to be among the first to show measurable strain under sustained demand. As monitoring technology improves and human studies close the gap with the animal literature, it's likely this picture will get sharper rather than less interesting. For now, it offers a useful reframe for anyone who has ever wondered why their best-intentioned late-session code so reliably needs a second look in the morning: the problem may not have been effort or attitude at all, but simple, measurable biology quietly changing the terms of the work.

Scientific References

Vyazovskiy, V. V., Olcese, U., Hanlon, E. C., Nir, Y., Cirelli, C., & Tononi, G. (2011). Local sleep in awake rats. Nature, 472(7344), 443–447.

Krueger, J. M., Nguyen, J. T., Dykstra-Aiello, C. J., & Taishi, P. (2019). Local sleep. Sleep Medicine Reviews, 43, 14–21.

Nir, Y., Andrillon, T., Marmelshtein, A., et al. (2017). Selective neuronal lapses precede human cognitive lapses following sleep deprivation. Nature Medicine, 23(12), 1474–1480.

Kool, W., McGuire, J. T., Rosen, Z. B., & Botvinick, M. M. (2010). Decision making and the avoidance of cognitive demand. Journal of Experimental Psychology: General, 139(4), 665–682.

McGuire, J. T., & Botvinick, M. M. (2010). Prefrontal cortex, cognitive control, and the registration of decision costs. Proceedings of the National Academy of Sciences, 107(17), 7922–7926.

Kool, W., McGuire, J. T., Wang, G. J., & Botvinick, M. M. (2013). Neural and behavioral evidence for an intrinsic cost of self-control. PLOS ONE, 8(8), e72626.

Shenhav, A., Botvinick, M. M., & Cohen, J. D. (2013). The expected value of control: An integrative theory of anterior cingulate cortex function. Neuron, 79(2), 217–240.

Graybiel, A. M. (2008). Habits, rituals, and the evaluative brain. Annual Review of Neuroscience, 31, 359–387.

Yin, H. H., & Knowlton, B. J. (2006). The role of the basal ganglia in habit formation. Nature Reviews Neuroscience, 7, 464–476.

Guarding Your Gray Matter: What Developers Should Know About "Popcorn Brain"

Khali Sollis — Mon, 13 Jul 2026 14:00:00 +0000

Open your laptop right now and count the tabs. A code editor, three browser windows, a Slack sidebar blinking with unread threads, a ticketing board, a documentation page you never finished reading, and probably a phone somewhere nearby doing its own quiet buzzing. This is not a special case. This is simply what a workday looks like for most software developers in 2026, and it has been building toward this point for close to two decades.

The modern development environment was not designed with human attention in mind. It was designed for speed, visibility, and constant availability. Every tool that makes a team more responsive — instant messaging, live pull request comments, real-time dashboards — also places demands on attention that appear to exceed what our cognitive systems handle efficiently over long periods. For a while, this seemed like a manageable tradeoff. More recently, research in cognitive psychology and neuroscience has begun to suggest it might not be.

This piece looks at what happens inside the brain when fractured, high-switching screen use becomes a daily habit rather than an occasional one. It covers the psychological term "popcorn brain," what neuroimaging research actually shows about gray matter and attention circuitry, why a scroll break rarely feels restful even though it looks like one, and what a research-informed reset might look like for someone who spends most of their waking hours moving between code, chat, and documentation. None of this is presented as settled medical fact. Brain science in this area is still young, mostly correlational, and worth approaching with some caution — but the direction of the evidence is consistent enough to take seriously.

What "Popcorn Brain" Actually Means

The term itself is not a clinical diagnosis. It was coined in 2011 by David Levy, a researcher at the University of Washington's Information School, who used it to describe a state of being so accustomed to rapid electronic multitasking that slower, offline activities start to feel unbearably dull. The image is straightforward: thoughts popping and jumping the way kernels do in a hot pan, unable to settle in one place for long.

Levy's term caught on because it named something a lot of people were already noticing about themselves — a restlessness that shows up specifically around single-threaded, low-stimulation tasks. Reading a long document without reaching for a phone. Sitting through a meeting without opening a second window. Holding one thought in mind long enough to actually finish it. People with popcorn brain describe not necessarily an inability to concentrate in general, but a specific difficulty concentrating on anything that isn't delivering constant novelty.

It's worth being precise about what this term is and isn't. It is not an official diagnosis in psychiatry, and it does not mean the same thing as ADHD, even though the surface behavior can look similar. It's better understood as a descriptive label for a learned pattern of attention — one that seems to be reinforced by how digital tools are built and used, rather than a fixed trait someone is born with. That distinction matters, because a learned pattern is, in principle, a pattern that can be unlearned.

The Developer's Distraction Loop

Software development has a particular relationship with this problem, because the job itself often requires holding a large, fragile mental model in working memory — the state of a function, the flow of a request through several services, the reason a test is failing — while also being expected to respond quickly to messages, reviews, and alerts.

Every context switch, even a two-second glance at a notification, forces the brain to reload that mental model when it returns. Researchers who study task switching have found that this reloading isn't instantaneous or free; it costs measurable time and increases the likelihood of small errors, because the brain has to reconstruct context rather than simply resume where it left off. In an ordinary office job, this might mean rereading a paragraph. In development work, it can mean rereading three files, retracing a call stack, and forgetting the edge case you had just spotted.

Over time, this creates what might be called a fragmentation loop. Deep, single-threaded work becomes harder to sustain, so shorter, easier tasks — replying to a Slack message, glancing at a dashboard, checking a pull request comment — start to feel more satisfying by comparison, because they resolve quickly and produce a small sense of completion. The brain, given a choice between a slow, effortful problem and a fast, easy one, tends to gravitate toward the fast one. Do this enough times a day, every day, for months, and the pattern stops being a choice and starts being a default.

What Brain Imaging Actually Shows

The interesting question is whether this everyday experience of fragmented attention corresponds to anything measurable in brain structure. Neuroimaging research over the past decade suggests it might, though the picture is narrower and more cautious than most headlines about it suggest.

Gray Matter and the Anterior Cingulate Cortex

The most frequently cited study in this area comes from Kep Kee Loh and Ryota Kanai, published in PLOS ONE in 2014. Using structural MRI on a group of adults, they measured how much people engaged in media multitasking — using several devices or media streams at once, such as texting while watching television — and compared that to the density of gray matter in different brain regions. They found a clear association: people who multitasked more heavily across media had lower gray matter density specifically in the anterior cingulate cortex, a region involved in cognitive control, error monitoring, and regulating emotional responses.

This is a genuinely important finding, but it comes with an important caveat that the researchers themselves emphasized: their study was cross-sectional, meaning it captured a single snapshot in time rather than tracking anyone over years. That makes it impossible to say with confidence whether heavy media multitasking causes this structural difference, whether people who already have less gray matter density in this region are simply more drawn to multitasking in the first place, or whether some third factor influences both. The association is real. The direction of cause and effect is not yet settled.

The Frontal Lobe's Role in Focus and Emotional Regulation

A broader body of neuroimaging work, much of it focused on heavy internet and gaming use rather than office-style multitasking specifically, has found reduced gray matter volume and thinner cortex in regions of the frontal lobe among people with patterns of compulsive digital use. The frontal lobe, and particularly the prefrontal cortex, is the part of the brain most responsible for what psychologists call executive function: planning ahead, resisting impulses, prioritizing tasks, and regulating emotional reactions rather than acting on them immediately.

When this region is functioning well, it acts something like a filter, letting a person notice an urge — check the phone, open a new tab — without necessarily acting on it. Some of the imaging research in this area suggests that heavier, more compulsive patterns of screen use are associated with measurable differences in this filtering capacity, alongside self-reported increases in impulsivity and emotional reactivity. Again, most of this work is correlational and drawn from populations with diagnosed internet or gaming addiction rather than typical office workers, so it should be read as suggestive of a broader mechanism rather than direct proof of what happens to an average developer's brain after a busy sprint week.

The Attention Collapse Nobody Chose

Separate from brain imaging, a different line of research has tracked something simpler and, in some ways, more startling: how long people can actually hold their attention on a single screen before switching away from it.

Gloria Mark, a professor of informatics at the University of California, Irvine, has been measuring this directly since 2004, using unobtrusive logging software rather than self-report surveys. In her earliest measurements, the average person's attention on a single screen lasted about two and a half minutes before switching to something else. By around 2016, that average had dropped to roughly 47 seconds, a figure that has remained in roughly that range across later observations. The median, meaning the point where half of all observations fall below it, was even lower, around 40 seconds.

Mark's broader research also found that switching attention carries a real cost beyond the switch itself. Recovering full concentration after an interruption can take a meaningful stretch of time, and repeated task switching has been linked in laboratory studies to more errors and slower completion of the original task. None of this proves that switching literally shrinks the brain, but it does describe, with unusually rigorous measurement, exactly the behavioral pattern that popcorn brain is meant to capture — and it shows that this pattern has changed dramatically within a single generation of internet use.

The Myth of Downtime Scrolling

One of the more counterintuitive findings in this area concerns what happens during a break. It's a common instinct, after twenty minutes staring at a stubborn bug, to reach for a phone and scroll for a few minutes before going back to work. It feels like rest. The evidence suggests it usually isn't.

Scrolling through a feed, even a mindless one, keeps the visual and cognitive systems that process novelty and social reward highly active. A 2013 fMRI study by Dar Meshi and colleagues found that the nucleus accumbens, a core reward structure in the brain, activates specifically in response to gains in personal reputation, such as positive social feedback, and that this activity tracked with how heavily people used social media. Each swipe or refresh carries the small possibility of that kind of reward, which keeps reward and salience circuitry primed in anticipation, in a way that has some resemblance to a low-grade stressor. This is different from what happens during genuine downtime — staring out a window, walking without a device, or simply sitting with an unstructured thought — during which activity tends to shift toward what researchers call the default mode network, a set of brain regions associated with reflection, memory consolidation, and the kind of loose, undirected thinking that often produces a solution to a problem a person has stopped consciously working on.

In other words, a coding break spent scrolling and a coding break spent looking out a window are not interchangeable, even though both involve stepping away from the keyboard. Current evidence suggests only the latter is more likely to promote genuine attentional recovery, though recovery itself is difficult to measure directly and remains an active area of study.

Correlation, Not Destiny: What the Science Doesn't Say

It's worth being direct about one open question that runs beneath everything above: what causes what. A cross-sectional MRI study showing that heavy multitaskers have less gray matter density in a particular region cannot rule out the possibility that people with less density in that region were simply more drawn to multitasking to begin with, or that both are downstream of something else, like chronic stress. And a fair amount of the strongest gray matter evidence comes from clinical populations with diagnosed internet or gaming addiction, not from typical developers juggling Slack and a code editor on an ordinary Tuesday — a gap worth naming rather than glossing over.

Neuroplasticity Works Both Ways

The more encouraging part of this story is also grounded in solid, long-established neuroscience: the brain's structure is not fixed. Neuroplasticity, the capacity of neural pathways to change in response to repeated experience, is one of the best-supported findings in the field, demonstrated across decades of research on skill learning, recovery from injury, and adaptation to new environments. If certain patterns of attention can be shaped by years of fragmented screen use, there's good reason to think that more sustained, single-focus habits can shape attention back in the other direction, even if that process happens gradually rather than overnight.

This doesn't mean a week of digital minimalism will visibly change someone's MRI scan. It means that the same basic mechanism responsible for the fragmentation is available for rebuilding focus, provided the new habits are consistent rather than occasional. Attention, much like a skill, seems to respond to the kind of practice it's given.

A Practical Reset for Developers

None of the following should be read as a clinically validated protocol; the specific claim that screen-free mornings or grayscale phone settings reverse measurable brain changes has not been directly tested in controlled studies. What follows are practical strategies grounded in the broader science of attention, reward, and recovery, adapted for the specific rhythms of development work.

Protect the first hour

Many of the researchers studying attention recommend delaying exposure to notification-heavy screens for some period after waking, giving the brain's attention system a chance to start the day in a calmer state rather than immediately syncing to the demands of other people's messages. For a developer, this might look like reviewing a single planned task on paper or in a plain text file before opening Slack or email at all, so the day's first cognitive act is chosen rather than reactive.

Reduce the visual reward signal

Turning a phone's display to grayscale is a low-cost, easily reversible change that some researchers and clinicians studying compulsive phone use have suggested as a way to reduce the visual pull of app icons and notification badges, which are deliberately designed in saturated colors to trigger attention. The evidence for this specific intervention is still mostly observational and anecdotal rather than the subject of large randomized trials, but the underlying logic — reducing a salient reward cue reduces the urge tied to it — is consistent with what's known about the brain's reward circuitry more generally.

Batch context switches instead of scattering them

Given what task-switching research shows about the cost of reloading context, one of the more evidence-backed strategies is simply reducing the number of switches rather than trying to eliminate distraction altogether. Checking Slack and email in scheduled blocks rather than continuously, and closing unrelated tabs during a focused coding session, directly targets the mechanism that research has identified as costly: not distraction itself, but the frequency of switching between deeply different cognitive contexts.

Choose real recovery during breaks

Given the difference between scroll-based breaks and genuinely restful ones, a short walk without a phone, or even a few minutes of unstructured staring at a wall, appears to do more for attentional recovery than a scroll through social media, even though the scroll often feels like the easier and more appealing option in the moment.

Where This Leaves Us

The picture emerging from current research is neither the total digital catastrophe suggested by some headlines nor a reason for developers to dismiss the topic entirely. There is a real, replicated association between heavy media multitasking and structural differences in brain regions responsible for attention and self-regulation. There is separate, carefully measured evidence that the average length of sustained attention on a screen has fallen sharply over the past two decades. And there is a well-established body of neuroscience showing that attention, like most cognitive skills, remains at least partly shapeable throughout adult life.

What the research does not yet support is a simple, direct causal story — heavy screen use shrinks a specific brain region by a specific amount, and a specific morning routine reverses it point for point. Science in this area is still catching up to how quickly digital habits have changed, and much of the strongest imaging evidence comes from clinical populations rather than the everyday developer switching between a terminal and a chat window.

What seems reasonably safe to say is that the fragmented, high-switching pattern common to modern development work is not neutral. It appears to interact with real, measurable systems in the brain that govern focus, impulse control, and emotional steadiness — systems that also, fortunately, appear responsive to deliberate, sustained changes in how attention is used. As development tools continue to multiply and the pressure toward constant availability shows no sign of easing, understanding this interaction, cautiously and without exaggeration, may turn out to be as relevant to long-term engineering performance as any framework or language choice.

Meta description: Neuroscience research links fragmented screen use to measurable brain changes in attention and focus. Here's what the evidence really shows for developers.

Scientific Reference

Levy, D. M. (2011). Introduced the term "popcorn brain" to describe attentional fragmentation from habitual electronic multitasking, University of Washington Information School.
Loh, K. K., & Kanai, R. (2014). Higher media multi-tasking activity is associated with smaller gray-matter density in the anterior cingulate cortex. PLOS ONE, 9(9), e106698. https://doi.org/10.1371/journal.pone.0106698
Mark, G. (2023). Attention Span: A Groundbreaking Way to Restore Balance, Happiness, and Productivity. Hanover Square Press.
Mark, G., Iqbal, S. T., Czerwinski, M., Johns, P., & Sano, A. (2016). Neurotics can't focus: An in situ study of online multitasking in the workplace. Proceedings of the 2016 CHI Conference on Human Factors in Computing Systems, 1739–1744. https://doi.org/10.1145/2858036.2858202 — the source of the 40-second median online focus duration referenced above.
Mark, G., Gudith, D., & Klocke, U. (2008). The cost of interrupted work: More speed and stress. Proceedings of the 2008 SIGCHI Conference on Human Factors in Computing Systems, 107–110. https://doi.org/10.1145/1357054.1357072
Zhou, Y., Lin, F. C., Du, Y. S., Qin, L. D., Zhao, Z. M., Xu, J. R., & Lei, H. (2011). Gray matter abnormalities in Internet addiction: A voxel-based morphometry study. European Journal of Radiology, 79(1), 92–95. https://doi.org/10.1016/j.ejrad.2009.10.025
Dougherty, R. J., Hoang, T., Launer, L. J., Jacobs, D. R., Sidney, S., & Yaffe, K. (2021). Long-term television viewing patterns and gray matter brain volume in midlife. Brain Imaging and Behavior. https://doi.org/10.1007/s11682-021-00534-4
Meshi, D., Morawetz, C., & Heekeren, H. R. (2013). Nucleus accumbens response to gains in reputation for the self relative to gains for others predicts social media use. Frontiers in Human Neuroscience, 7, 439. https://doi.org/10.3389/fnhum.2013.00439

Note: Much of the neuroimaging research cited above is correlational and drawn in part from clinical populations with diagnosed internet or gaming addiction. Readers should treat structure-behavior associations as evidence of a plausible link rather than proof of direct causation.

The "Just One More Prompt" Loop: The Neurobiology of AI-Induced Burnout

Khali Sollis — Sun, 12 Jul 2026 01:21:41 +0000

It's 2:00 AM. The bug has been circling for three hours. You know you should sleep, but your hands are already back on the keyboard, typing one more instruction into the AI coding assistant sitting in your terminal. Your heart is beating a little faster than it should be for someone just sitting at a desk. You tell yourself the same thing you told yourself an hour ago: just one more prompt and I'll fix this.

This scene has become familiar to a lot of people who write code, build content, or otherwise spend their days working alongside generative AI tools. It doesn't look like the burnout that came before it. There's no dread, no staring blankly at a blinking cursor for twenty minutes. If anything, the work feels compulsively engaging, almost too engaging to stop. And that's exactly what makes it worth examining closely.

Over the past year, developers, writers, and researchers have started describing a specific kind of exhaustion that shows up after long AI-assisted work sessions: fast to onset, hard to interrupt, and strangely different from the slow-burn fatigue that traditional overwork produces. It's what some developers have started calling "AI brain fry." A well-known figure in the coding world, Steve Yegge, described the pull of agentic coding tools bluntly: every success delivers a small hit of dopamine, every failure delivers a jolt of adrenaline, and the alternating pattern is what makes it "near-impossible to tear yourself away."

Industry surveys from 2026 back up the anecdotes. A large-scale engineering leadership report found that a growing share of developers are working longer hours than the year before, even though AI tools were supposed to save them time. The people picking up the most extra hours weren't beginners still learning to lean on the tools. They were senior engineers, the ones who understood the technology best and used it most fluently.

This piece looks at what's actually happening in the brain and body during these sessions, using research on reward learning, reinforcement schedules, and stress physiology that predates generative AI by decades. The tools are new. The underlying biology is not, and understanding it is the first step toward working with these systems instead of being run by them.

Why AI Tools Feel Different From Regular Work

To understand why AI-assisted work can feel so uniquely absorbing, it helps to think about what a normal workday used to feel like before these tools existed. Traditional coding, writing, or research involved long stretches of effort with delayed payoff. You'd write a function, and the reward — seeing it actually work — might come minutes or hours later, after testing, debugging, and iteration. Feedback was slow, often ambiguous, and rarely immediate.

Generative AI collapses that gap. You describe a problem, and within seconds you get a proposed fix, a piece of code, a paragraph of text, or an answer. Sometimes it's exactly right. Sometimes it's close but flawed. Sometimes it fails in a surprising or even spectacular way. The point is that you don't know in advance which outcome you'll get, and you find out almost instantly. That combination — quick feedback plus genuine uncertainty about the outcome — is not a minor UX detail. It happens to match, almost exactly, one of the most well-studied patterns in behavioral psychology.

The Brain's Prediction Machinery

Neuroscience has a name for what happens when an outcome differs from what you expected: a reward prediction error. The concept comes from research on dopamine neurons, most famously the work of neuroscientist Wolfram Schultz, who spent years recording the activity of these neurons in animals as they learned to anticipate rewards. What Schultz and later researchers found was that dopamine neurons don't simply fire when something good happens. They fire in proportion to how surprising the good outcome is. A reward you fully expected barely moves these neurons at all. A reward that's better than expected produces a burst of activity. A reward that fails to arrive, when you were expecting one, actually causes these neurons to go quiet, a dip below their normal baseline firing rate.

This matters for prompt-based AI work because it's a nearly perfect description of what happens during a debugging session. You send a prompt not knowing whether it will fix the problem. If it works, you get a burst of positive signal, precisely because you weren't certain it would. If it doesn't work, there's a dip, followed almost immediately by the option to try again with a tweaked prompt, which resets the whole cycle. Researchers who study dopamine describe this as the core machinery underlying not just learning, but also the pull of anything from video games to gambling. Generative AI tools didn't invent this mechanism. They just built an interface that triggers it dozens or hundreds of times an hour.

There's a useful refinement to this picture from neuroscientist Kent Berridge, whose research draws a distinction between "wanting" and "liking." Wanting is the motivational pull to pursue something, driven largely by dopamine signaling. Liking is the actual pleasure derived from getting it, which appears to run through partly separate brain circuitry. Berridge's work shows these two systems can come apart: it's possible to want something intensely without necessarily enjoying it more once you have it. That distinction maps unusually well onto long AI-assisted sessions. The pull to send another prompt can stay strong, session after session, even as the actual satisfaction of getting a working answer starts to feel thinner. The wanting persists; the liking doesn't necessarily keep pace.

Borrowing a Blueprint From Behavioral Psychology

There's a second, closely related piece of this puzzle that comes from a much older branch of psychology: operant conditioning, the study of how consequences shape behavior. Decades before anyone imagined AI coding assistants, psychologist B.F. Skinner ran experiments comparing different patterns, or "schedules," of reward. One of his key findings was that rewards delivered on a variable schedule, meaning the timing or likelihood of a payoff is unpredictable, produce far more persistent, harder-to-stop behavior than rewards delivered predictably.

This is the mechanism behind why slot machines are effective at holding people's attention for so long. The machine doesn't pay out on a fixed schedule; it pays out unpredictably, and that unpredictability is precisely what keeps someone pulling the lever. Researchers studying gambling behavior have found that this kind of variable reward is closely tied to dopamine release in the brain, and that behaviors reinforced this way are notably resistant to "extinction," meaning people keep engaging in them even during long stretches without a payoff.

Applied to an AI coding or writing session, the parallel is direct. Whether the next prompt will produce a clean fix, a partial fix, a completely wrong answer, or something unexpectedly brilliant is not something you can predict with confidence. That uncertainty closely resembles the kind of variable reinforcement schedules long studied in behavioral psychology. It's worth being careful here about what the science does and doesn't establish. Researchers have documented that variable-ratio reinforcement reliably produces persistent responding in controlled experimental settings, and there's reasonable evidence connecting this reward structure to compulsive engagement with digital products, from social media to gambling apps. Whether prompt-based AI tools produce clinically significant addictive patterns in the way substances do is a much newer and less settled question. What's fair to say, based on current understanding, is that the reward structure of AI tools closely resembles a pattern known to produce persistent, hard-to-interrupt behavior. That's a meaningfully different claim than saying AI coding is medically addictive, and the distinction matters.

From "Brain Buzz" to Physical Strain

The mental pull of the prompt-fix loop is only half the story. The other half shows up in the body, and it's the part that tends to get noticed later, usually after the buzz has worn off.

The Crash Beneath Baseline

One of the more consistent findings in reward research is that intense or repeated activation of dopamine signaling tends to be followed by a compensatory dip. After a stretch of frequent, high-intensity dopamine signaling, reward-related neural activity doesn't simply return to its resting state, it tends to undershoot it for a period afterward. This is part of why a late-night session that felt sharp and energized in the moment can be followed the next morning by a heavy, flat, unmotivated feeling that's hard to shake, even after adequate sleep. People sometimes describe this as a kind of mental fog or apathy that makes ordinary decisions, like what to work on first, feel unusually difficult. This aligns with research on decision fatigue: not an inability to think, but a measurable decline in the quality and speed of decision-making after a period of sustained cognitive load.

It's worth noting that most of the foundational research on this rebound effect comes from studies of reward and dopamine in general, not from studies specifically designed around AI tool use, which is still a very young field of inquiry. Applying it to prompt-based workflows is a reasonable extension of well-established principles, not yet a directly confirmed finding in this exact context.

When Frustration Becomes a Physical Signal

The other physical dimension is more familiar: stress. Even when an AI tool is nominally doing the tedious work, the person overseeing it is still making constant micro-level judgment calls — is this output correct, should I trust it, do I need to intervene, how much time have I sunk into this. Occupational stress researchers have long used measures like heart rate variability and cortisol, a hormone released during the body's stress response, to track how sustained mental demand affects the body. Lower heart rate variability, meaning less healthy fluctuation between heartbeats, is a well-documented marker of physiological stress in knowledge workers, and it tends to track closely with self-reported feelings of pressure and strain.

A 2026 study out of UC Berkeley looked at employees using AI tools at a mid-sized tech company and found that access to more capable AI agents led people to work at a faster pace, across more tasks, for longer stretches, largely because the tools made them feel more capable and empowered. The researchers flagged this "intensified" work pattern as a plausible pathway toward cognitive fatigue and weakened decision-making over time, though they were careful to frame it as an early signal rather than a settled conclusion, since research on this specific dynamic is still accumulating. Separately, industry reporting throughout early 2026 has repeatedly noted that AI coding tools appear to be extending work hours rather than shortening them, with the steepest increases showing up among the most experienced engineers, the people best positioned to use the tools at full speed. Faster pace, longer hours, and constant micro-decisions layered on top of a reward system already running hot is, physiologically speaking, a demanding combination — even when none of the individual tasks feels difficult in isolation.

Where This Differs From Traditional Burnout

Burnout, as originally described by psychologist Christina Maslach, was understood as a slow accumulation: chronic workplace stress that gradually produces exhaustion, cynicism, and a sense of reduced effectiveness, usually over months. A possible AI-assisted variant shares that endpoint but seems to arrive by a faster and different route. Instead of grinding fatigue from too much unrewarding effort, this pattern seems to emerge from too much reward, delivered too quickly, too often, with too little natural stopping point.

That's a subtle but important distinction. Traditional burnout often comes with a felt sense of dread about the work itself. The AI-assisted version, by contrast, is frequently described by the people experiencing it as feeling energized or even enjoyable in the moment, which is part of what makes it harder to notice and interrupt. You don't feel like you need a break, because the next prompt still feels promising. That's precisely the signature of a variable reward loop: motivation to continue remains high even as the underlying resource, in this case attention and nervous system regulation, is quietly being depleted.

It's also worth being cautious about how new this specific framing is. Terms like "AI brain fry" and the broader idea of AI-induced burnout are still recent additions to the conversation, popularized largely through industry reporting, consulting firm analyses, and firsthand accounts from developers, rather than through peer-reviewed clinical research. The underlying mechanisms, reward prediction error, variable-ratio reinforcement, and stress physiology, are well established. Their specific application to prompt-based AI workflows is a plausible and increasingly well-supported extension of that research, but it remains an active and evolving area of study rather than a fully settled scientific finding.

Breaking the Loop Without Breaking the Tool

None of this is an argument against using AI tools. It's an argument for using them with a clearer understanding of why they can be so hard to put down. A few adjustments, grounded in the mechanisms described above, tend to come up repeatedly in both the research and the practical advice now circulating among engineers who've noticed the pattern in themselves.

Time-boxing sessions is one of the more consistently recommended strategies. Because variable-ratio reward loops are specifically designed, whether intentionally or not, to resist natural stopping points, imposing an external one, like a timer or a hard cutoff, does the job the reward system won't do on its own. Separating exploratory, open-ended prompting from focused execution work is another practical distinction. Open-ended "let's see what happens" sessions are where the dopamine loop runs hottest, and treating them as a distinct, bounded activity rather than letting them blend into regular work can help contain their pull.

Recognizing the physical signals matters too. An elevated heart rate, a wired but foggy feeling, or a sense of urgency that doesn't match the actual stakes of the task are all worth treating as information rather than ignoring. And building in genuine recovery time, not just sleep, but stretches of the day with no prompting at all, gives dopamine signaling space to return to baseline rather than staying chronically activated. None of this requires abandoning AI tools. It requires treating the reward loop they create with the same seriousness given to any other well-understood behavioral pattern.

What This Means Going Forward

The prompt-fix loop is a useful case study in a broader pattern that keeps repeating as technology changes: tools built for speed and responsiveness tend to interact with very old, very well-understood features of human reward psychology, often in ways their designers never explicitly intended. The same reward prediction error mechanism that made slot machines and social media feeds so effective at holding attention is now showing up in the tools people use to build software and write. That's not a moral failing on the part of users, and it's not necessarily a flaw in the tools either. It's simply what happens when instant, uncertain feedback meets a brain that evolved to pay very close attention to exactly that combination.

As generative AI becomes more embedded in daily knowledge work, understanding this mechanism will likely matter as much as understanding the tools themselves. The research connecting reward prediction error, variable reinforcement, and burnout is well established in its foundations but still quite new in its specific application to AI-assisted work, and it's a reasonable expectation that more direct, purpose-built studies on this exact phenomenon will appear over the next few years. In the meantime, the most useful takeaway may be a simple one: the feeling of being pulled toward "just one more prompt" isn't a personal weakness. It's a predictable response to a genuinely well-engineered feedback loop, and predictable responses can be planned for.

The next time you catch yourself saying "just one more prompt," it may be worth remembering that you're negotiating not only with your code, but with one of the brain's oldest reward-learning systems.

Scientific Reference

Schultz, W. (2016). Dopamine reward prediction error coding. Dialogues in Clinical Neuroscience, 18(1).
Schultz, W., Dayan, P., & Montague, P.R. (1997). A neural substrate of prediction and reward. Science, 275(5306), 1593–1599.
Skinner, B.F. (1953). Science and Human Behavior. Macmillan.
Zald, D.H., et al. (2004). Dopamine transmission in the human striatum during monetary reward tasks. Journal of Neuroscience.
Berridge, K.C., & Robinson, T.E. (2016). Liking, wanting, and the incentive-sensitization theory of addiction. American Psychologist, 71(8), 670–679.
Murch, W.S., & Clark, L. (2016). Games of chance: Uncertain outcomes and the brain's reward system. Current Opinion in Behavioral Sciences.
Maslach, C., & Leiter, M.P. (2016). Burnout. In G. Fink (Ed.), Stress: Concepts, Cognition, Emotion, and Behavior (pp. 351–357). Academic Press.
Yegge, S. (2025–2026). Public commentary on agentic coding and reward-driven engagement, as reported by Built In and LeadDev.
LeadDev. (2026). Engineering Leadership Report 2026.
University of California, Berkeley. (2026). Research on AI tool use, work intensification, and cognitive fatigue at a technology company, as reported by Built In.
Boston Consulting Group. (2026). Reporting on psychological mechanisms in AI-related cognitive fatigue among technology workers.

From Approval-Seeking to System Integrity: Shipping a New Version of Yourself

Khali Sollis — Fri, 10 Jul 2026 13:00:00 +0000

How rebuilding internal alignment, enforcing behavioral consistency, and removing approval dependency creates a more stable operating system than performative likability ever could

After auditing:

overcommitment
broken boundaries
stale trust models
emotional over-responsibility
approval loops
unrestricted access control

one conclusion became unavoidable:

The old system was never optimized for integrity.

It was optimized for acceptance.

For years, the architecture revolved around one primary objective:

Maintain approval
Avoid rejection
Preserve belonging

Everything else adapted around that priority.

Boundaries weakened.
Authenticity fragmented.
Self-trust deteriorated.

The system remained socially functional.

Internally, it became unstable.

The Bug: Approval-Seeking as Core Architecture

Approval-seeking is not just behavior.

It becomes infrastructure.

The system starts routing decisions through external validation layers:

Decision
→ predict reactions
→ optimize for acceptance
→ execute modified version

At first, this appears strategic.

Eventually, it creates identity corruption.

Because over time, the system stops asking:

Is this aligned?

And starts asking:

Will this maintain approval?
Why Approval-Seeking Creates Instability

External validation is volatile.

People:

change preferences
project expectations
withdraw approval unpredictably
reward inconsistency

If your identity stability depends on those variables, internal coherence becomes impossible.

The system enters continuous adaptation mode:

External reaction changes
→ self-adjustment initiated

Repeated endlessly.

The Performance Layer

One uncomfortable realization:

A significant percentage of my personality had become optimized output.

Not fake.

But filtered.

Rendered for:

reduced friction
increased likability
emotional safety
social predictability

The system learned:

Authenticity may threaten approval
→ modify presentation

Small edits accumulated over years.

Eventually, the distance between performance and alignment became measurable.

The Cost of Identity Fragmentation

When external acceptance becomes the priority, internal contradiction grows.

The system splits into layers:

External Interface
pleasant
available
adaptable
Internal State
exhausted
resentful
misaligned

Maintaining that split consumes enormous resources.

Because the system must continuously:

suppress authentic responses
regulate perception
manage approval risk

At scale, this becomes unsustainable.

The Turning Point

At some point, I stopped asking:

How do I stay liked?

And started asking:

Can I trust myself when nobody approves?

That question changed the architecture completely.

Because self-trust and approval optimization often require opposite behaviors.

What System Integrity Actually Means

System integrity is not perfection.

It’s consistency between:

internal values
external behavior
decision-making patterns
emotional reality

No split.

No performance layer managing every interaction.

No constant self-editing for approval retention.

The Refactor

The transition was not emotional.

It was structural.

Remove Approval as Primary Metric

Old system priority:

Maintain positive external perception

Updated system priority:

Maintain internal alignment

Even when reactions fluctuate.

Reduce Personality Optimization

I stopped over-managing:

tone
reactions
accessibility
emotional presentation

Not recklessly.

Accurately.

Allow Disagreement Without Identity Collapse

This was a major upgrade.

Old response to disapproval:

Conflict detected
→ self-modification initiated

Updated response:

Conflict detected
→ evaluate validity
→ maintain alignment if accurate

Disagreement stopped automatically meaning danger.

Prioritize Congruence Over Image

I became less interested in appearing good.

More interested in being internally coherent.

That distinction removed enormous psychological load.

What Changed

After shifting from approval-seeking to system integrity:

decisions became cleaner
emotional volatility decreased
communication became more direct
boundaries required less justification
relationships became more accurate

And most importantly:

Self-trust stabilized.

Because the system stopped abandoning itself to preserve external approval.

Unexpected Side Effects

Not everyone responds positively when you stop performing accessibility and emotional compliance.

Some relationships weaken.

Some dynamics destabilize.

Some people interpret boundaries as rejection because they benefited from your lack of them.

That’s normal.

Systems dependent on self-erasure rarely survive integrity upgrades unchanged.

Reframing Identity

Old model:

Worth = approval

Updated model:

Worth = alignment + integrity

Approval became optional input.

Not operating system architecture.

Takeaway

Approval-seeking creates unstable systems because external validation is inherently unpredictable.

System integrity creates stability because alignment does not fluctuate with audience response.

At some point, growth stops being about becoming more liked.

And becomes about becoming internally trustworthy.

Final Deployment Notes

The old version optimized for:

acceptance
accommodation
survival through approval

The new version prioritizes:

clarity
congruence
protected resources
accurate access control
behavioral integrity

Different architecture.

Higher stability.

Status
Approval dependency: deprecated
System integrity protocols: active
New version: deployed to production
Rollback: not scheduled

The Engineering of Resilience: How "Desirable Difficulties" and Neurobiological Adaptation Build High-Velocity Founders

Khali Sollis — Mon, 06 Jul 2026 19:19:42 +0000

The research behind "desirable difficulties," stress inoculation, and why chronic adversity is not the founder advantage many people think it is.

There is a story the startup world likes to tell about itself: the founders who succeed are the ones who had it hardest—that an early lack of money, connections, or a safety net forged something their more comfortable competitors simply don't have. Pieces of that story are genuinely supported by research on learning and stress. But it bundles together two different scientific ideas that don't actually describe the same thing — "desirable difficulties," a concept from cognitive psychology about why effortful practice builds deeper skill than easy practice, and the "steeling effect," the idea that surviving manageable adversity can build capacity to handle adversity later. Neither one says hardship is a shortcut to success, and neither supports the idea that severe or uncontrollable adversity is secretly good for you. If anything, the research on chronic stress says close to the opposite.

Here's what the science actually shows, starting with where the phrase "desirable difficulties" comes from in the first place.

Where "Desirable Difficulties" Actually Comes From

The term "desirable difficulties" was coined by the UCLA psychologist Robert Bjork in 1994, and it has nothing to do with childhood trauma or business survival stories. Bjork was studying something much narrower and much better documented: how people learn and retain information.

His finding, replicated across decades of experiments, is that the conditions that make learning feel easiest in the moment are often the conditions that produce the weakest long-term memory. If you study one topic in one long block, in the same room, using the same format every time, you'll feel like you're mastering it. But that fluency is often an illusion. The version of practice that actually builds durable skill tends to feel harder while you're doing it: spacing your study sessions out over time instead of cramming, mixing related topics together instead of studying them one at a time, and testing yourself on material instead of just rereading it. Bjork called these "desirable" difficulties specifically because they are difficulties a learner can push through with effort, and because the extra effort itself is what strengthens memory.

Imagine a founder learning distributed systems. Re-reading Kubernetes documentation for six hours feels productive — the concepts seem to click into place as you read them. Building a small cluster, breaking it on purpose, and troubleshooting the failures from memory over several weeks feels slower and more frustrating. But it's the second approach, not the first, that produces engineers who can actually diagnose a production outage at 2 a.m. without the docs open in another tab.

That is a real, well-supported finding about how skills and knowledge get built. It says something useful to a founder learning to write code, read a balance sheet, or negotiate a term sheet: struggling with spaced-out, varied, self-tested practice will likely serve you better than smooth, repetitive, "comfortable" study sessions. It does not say that losing your job, growing up in poverty, or surviving a chaotic childhood functions the same way. Bjork's research was about deliberate, structured learning tasks, not about surviving hardship. Popular writers, including Malcolm Gladwell in David and Goliath, have since borrowed the phrase and stretched it to cover life disadvantages more broadly — that's a compelling narrative device, but it's worth being clear that it's an extension of the original idea, not a direct finding from Bjork's research itself.

The Real, More Complicated Science of Stress and Resilience

So does hardship itself build resilience? Here the research is genuinely interesting, but it's also more cautious than the founder-mythology version suggests.

Developmental psychologists, going back to work by Michael Rutter in the 1980s and refined since, have described something called the "steeling effect" (also called stress inoculation). The idea is that a moderate, manageable amount of adversity — stress a person can face, get through, and recover from, often with some support along the way — can leave someone better equipped to handle future stress. This has shown up in both animal studies and longitudinal research on people: individuals who face some early difficulty, and successfully work through it, sometimes show better coping skills later than people who faced almost no adversity at all.

But the research is explicit that this relationship is not a straight line. It's closer to a curve. Rutter and later researchers describe it as curvilinear: a little adversity, successfully navigated, may build capacity. A lot of adversity — chronic, severe, or unrelenting — tends to do the opposite. It overwhelms coping systems rather than strengthening them. Reviews on the topic note that both no adversity at all and heavy, sustained adversity are generally associated with worse outcomes than a moderate, manageable amount. The relationship between hardship and resilience looks like an inverted U, not a ramp that keeps climbing the harder things get.

This matters, because it's the opposite of what the "extreme adversity forges extreme founders" narrative implies. The evidence for steeling effects is about tolerable, bounded stress — the kind a person can face with some sense of control and some path to recovery. It is not evidence that severe, prolonged, or overwhelming hardship reliably produces stronger people. Some of the same literature notes that outcomes vary considerably by individual, by the type of adversity, and by whether support was available at the time. Trauma researchers are also careful to point out that many people who experience severe or chronic adversity do not come out of it with enhanced coping ability; they come out of it with worse mental and physical health. The "what doesn't kill you makes you stronger" framing is a real pattern in some circumstances, but it is far from a guarantee, and treating it as one risks minimizing what hardship actually costs the people who live through it.

What the Stress Response Actually Does in the Body

The neuroscience of stress is often summarized as "the body's alarm system," which is roughly right but leaves out the part that matters here. When you encounter something demanding, a chain of signals — starting in the brain and running through what's called the HPA axis — releases hormones, including cortisol, that mobilize energy and sharpen short-term focus. This is useful. A person about to give a hard presentation or handle a genuine crisis benefits from some of this activation.

Acute stress like this helps the brain allocate energy toward immediate demands. Chronic activation is different. The neuroscientist Bruce McEwen, in an influential 2007 review, described the accumulated physiological cost as "allostatic load" — the wear and tear that develops when the stress response is repeatedly activated without sufficient recovery. That cost shows up in measurable changes in the brain, including in the hippocampus, and McEwen's own framework treats it as exactly that: a cost, not a performance upgrade.

This is where the desirable-difficulties research and the stress research actually converge: adaptation requires oscillation between challenge and recovery. Whether the system in question is a muscle, a memory, or a stress response, it adapts during the recovery period, not during continuous overload. A founder who never lets the pressure let up isn't stacking desirable difficulties; they're accumulating allostatic load.

That distinction matters for anyone drawing on this research to explain founder behavior. A person who has learned, through some manageable difficulty, to stay calmer under a specific kind of pressure may well have an advantage in that specific domain. But a person carrying genuine chronic stress — financial precarity, unresolved trauma, unstable housing — is, according to this same body of research, more likely to be carrying allostatic load that impairs functioning over time, not a hidden reserve of calm. The nervous system doesn't distinguish between "adversity that will make a good LinkedIn post later" and "adversity that is currently exhausting your physiological reserves." Both look the same to the HPA axis in the moment.

What Founders Can Actually Take From This

None of this means difficulty is irrelevant to building skill or capacity — it means the useful version of "difficulty" is much narrower and more deliberate than the founder-mythology version.

Structuring practice as a desirable difficulty. This is the part of the research with the most direct, practical application, and it applies whether someone had an easy childhood or a hard one. Spacing out practice on a hard skill, testing yourself instead of just reviewing notes, and mixing related problems instead of drilling one type repeatedly are all supported ways to build durable competence faster. A founder learning to model financial projections, debug a system, or run negotiations will likely get more out of spaced, effortful, self-tested practice than out of passive repetition — regardless of their background.

Seeking manageable, recoverable stress rather than avoiding all of it. The steeling-effect research does suggest there's a difference between challenges you never face and challenges you face, work through, and recover from. That points toward something achievable and non-romantic: deliberately taking on stretch problems that are hard but survivable, with enough support and recovery time built in, rather than either avoiding all discomfort or treating constant crisis as a badge of honor.

Being cautious about treating chronic hardship as an asset. If a founder is dealing with genuine ongoing adversity — financial strain, health problems, an unstable environment — the research on allostatic load suggests that's more likely a drain on cognitive and physical resources than a hidden advantage. Recognizing that distinction matters, both for how founders think about their own history and for how they think about hiring, mentoring, or judging others based on how much hardship shaped them.

Reading survivorship into the founder story with some skepticism. For every well-known founder whose difficult early years get cited as the source of their edge, there are far more people who faced comparable or worse circumstances and did not go on to found a company at all — some because the adversity did what adversity often does, and made things harder rather than easier. The visible success stories are a small, non-random slice of everyone who lived through similar conditions, which is a basic and important caution against drawing sweeping lessons from them.

Conclusion

The idea that difficulty can build capacity has real scientific support — but it's support for something more specific and more modest than "adversity manufactures great founders." Bjork's desirable difficulties describe how effortful, well-structured practice builds durable skill, a finding about learning, not about surviving hardship. The steeling effect describes how moderate, manageable stress, successfully navigated, can build coping capacity — while cautioning that severe or chronic adversity tends to do the reverse. And the neuroscience of stress, including McEwen's own foundational model, is largely a story about the cost of stress left running too long, not a case for seeking it out.

None of this rules out the plausible, common-sense point that people who have faced and overcome real challenges often carry something useful from that experience — patience, problem-solving instincts, a realistic sense of what they can withstand. But it argues against treating hardship itself as an engineering input, something to be sought out or celebrated because it will supposedly manufacture a stronger operator. Resilience isn't engineered by accumulating suffering. It's engineered by repeatedly meeting challenges that stretch your abilities without overwhelming your capacity to recover.

Further Reading

Bjork, R. A. (1994). Memory and Metamemory Considerations in the Training of Human Beings.
McEwen, B. S. (2007). Physiology and Neurobiology of Stress and Adaptation: Central Role of the Brain. Physiological Reviews.
Rutter, M. Research on stress inoculation and the "steeling effect" in resilience.
Bjork, R. A. & Bjork, E. L. Research on desirable difficulties in learning.

Broken Access Control: Who Actually Deserves Your Time?

Khali Sollis — Fri, 03 Jul 2026 12:00:00 +0000

How unrestricted emotional access creates instability, why familiarity is often mistaken for permission, and what changes when access becomes intentional instead of automatic

After implementing rate limiting and protecting cognitive bandwidth, another structural issue became visible:

I still granted too much access.

Not only to my time.

To my attention.
My emotional availability.
My internal space.

The old system operated under an unspoken assumption:

If someone exists in my life
→ they automatically receive access

No verification process.
No permission layers.
No reassessment logic.

And eventually, the system became crowded with people who had access to resources they never learned to respect.

The Bug: Broken Access Control

In security systems, broken access control happens when permissions are granted too broadly or maintained long after they should have been revoked.

The result:

boundary violations
resource misuse
system instability

Human systems behave similarly.

When access is automatic instead of intentional:

emotional energy gets overconsumed
boundaries become unclear
relationships lose proportionality

Everyone receives high-level permissions regardless of demonstrated behavior.

Familiarity Is Not Qualification

One difficult realization:

History and access are not the same thing.

Someone knowing you for a long time does not automatically mean they deserve unrestricted proximity to your life.

But my old system confused:

time investment
emotional history
past closeness

with permanent authorization.

Which created this flawed logic:

Known person
→ trusted person
→ permanent access granted

Even when current behavior no longer supported that level of trust.

The Problem With Default Permissions

When boundaries are unclear, people often operate at the highest level of access available.

Not always maliciously.

Simply because the system allows it.

Examples:

expecting immediate emotional processing access
assuming unrestricted availability
crossing conversational boundaries
demanding explanations for personal decisions

And because I rarely enforced limits, those permissions became normalized.

Emotional Infrastructure Misuse

At some point, I realized something uncomfortable:

I had become emotional infrastructure for people who contributed very little stability in return.

The system looked like this:

My availability
→ their convenience
My emotional labor
→ their regulation
My attention
→ their access point

Meanwhile:

my recovery time increased
my focus fragmented
my internal clarity decreased

The system wasn’t balanced.

It was extractive.

Why Revoking Access Feels Difficult

Because many of us were conditioned to associate access restriction with cruelty.

Old emotional equation:

Boundary = rejection
Reduced access = punishment

So instead of recalibrating permissions, the system tolerated increasing misalignment.

Even when:

respect diminished
reciprocity disappeared
exhaustion accumulated
The Identity Layer

Part of my resistance came from identity maintenance.

I wanted to be perceived as:

open
generous
emotionally available
understanding

Which meant I often prioritized preserving accessibility over protecting stability.

But systems without access control eventually become vulnerable to overload.

Not because everyone is malicious.

Because unrestricted access scales badly.

The Difference Between Connection and Access

This distinction changed everything.

Someone can:

know you
like you
care about you

without requiring unrestricted access to:

your time
your nervous system
your attention
your emotional processing capacity

Connection does not automatically equal entitlement.

The Fix: Permission-Based Access

I stopped treating access as automatic.

I started treating it as earned, maintained, and adjustable.

Reevaluate Existing Permissions

Old model:

Access granted once
→ permanent authorization

Updated model:

Access requires ongoing alignment

Respect became a maintenance requirement.

Introduce Permission Levels

Not everyone receives the same degree of access.

Some relationships became:

close but limited
warm but bounded
supportive but structured

The system stopped operating in extremes.

Stop Over-Explaining Boundaries

One important shift:

I no longer needed universal approval for access restrictions.

A simple:

“I’m unavailable for that.”

became sufficient.

No extended justification layer required.

Normalize Access Revocation

If repeated behavior demonstrated:

disrespect
instability
entitlement
emotional extraction

permissions changed.

Not vindictively.

Accurately.

What Changed

After implementing intentional access control:

emotional exhaustion decreased
focus improved
resentment dropped significantly
relationships became more balanced

And unexpectedly:

The people capable of respecting boundaries stayed.

The ones dependent on unrestricted access struggled the most.

That distinction became valuable data.

Reframing Availability

Old model:

Being good = staying accessible

Updated model:

Healthy systems regulate access
Takeaway

Not everyone who enters your life deserves unrestricted access to your time, energy, or emotional bandwidth.

Access is not proof of love.

And removing access is not automatically cruelty.

Sometimes it’s system maintenance.

Because when access control is broken, self-respect eventually becomes compromised infrastructure.

Status
Default permissions: removed
Access control protocols: active
System integrity: stabilizing
Series: Behavioral Anti-Patterns

Previous: No Rate Limiting: How Instant Availability Destroys Focus
Next: From Approval-Seeking to System Integrity: Shipping a New Version of Yourself

No Rate Limiting: How Instant Availability Destroys Focus

Khali Sollis — Fri, 26 Jun 2026 12:00:00 +0000

How constant responsiveness fragments attention, trains external dependency, and turns your mental bandwidth into a publicly accessible resource

After refactoring identity-level approval patterns, another operational issue became impossible to ignore:

My attention was constantly interruptible.

Not occasionally.

Continuously.

Every notification, request, message, update, or emotional signal was treated as immediate priority input.

The system operated like this:

Incoming interruption
→ immediate response

No delay.
No filtering.
No prioritization layer.

I called this responsiveness.

In reality, it was unrestricted access to my cognitive resources.

The Bug: No Rate Limiting

In distributed systems, rate limiting exists to protect stability.

Without it:

requests overwhelm the server
resources fragment
performance degrades under continuous demand

Human attention works the same way.

If your focus is permanently accessible, external systems will continuously consume it.

Not maliciously.

Automatically.

Instant Availability Trains Dependency

One thing became clear quickly:

People adapt to your response patterns.

If the system consistently returns:

Immediate response available

Then immediate access becomes normalized.

Soon:

delayed replies feel unusual
boundaries feel disruptive
your availability becomes assumed infrastructure

The problem isn’t only external expectations.

It’s that your own nervous system becomes conditioned to interruption.

The Attention Fragmentation Problem

Focus requires uninterrupted processing time.

But constant accessibility creates context switching loops:

Deep focus
→ interruption
→ recovery attempt
→ another interruption

Each switch consumes energy.

Even small interruptions carry cognitive cost:

reduced concentration
slower recovery time
fragmented thinking
diminished creative depth

The system remains active all day while accomplishing less meaningful work.

Why Instant Responsiveness Feels Productive

Because responsiveness creates visible activity.

You feel:

engaged
useful
connected
efficient

But activity and effectiveness are not the same metric.

Rapid responses can create the illusion of productivity while destroying sustained attention quality.

The Dopamine Interruption Loop

Part of instant availability is neurological.

Every notification creates potential reward:

validation
novelty
urgency
social relevance

The brain learns:

Interruption
→ stimulation
→ response
→ temporary reward

Over time, uninterrupted focus starts feeling uncomfortable.

Silence begins to resemble absence instead of stability.

The Cost of Constant Accessibility

Cognitive Resource Drain

Attention becomes distributed across too many low-priority inputs.

High interruption frequency
→ reduced processing depth

Reactive Living

Without intentional focus protection, external demands begin controlling internal priorities.

The day stops being designed.

It becomes negotiated in real time.

Creativity Collapse

Deep thinking requires uninterrupted cognitive continuity.

Constant responsiveness destroys continuity before meaningful depth can form.

Self-Abandonment Through Accessibility

One difficult realization:

I often interrupted myself before anyone else could.

Conditioned anticipation kept the system partially externally focused at all times.

Even during rest.

The Identity Layer

Part of me still associated fast responses with worthiness.

Old internal equation:

Fast response = caring
Fast response = valuable
Fast response = responsible

Which meant delayed responses triggered guilt.

Even when delay was healthy.

The Fix: Implement Rate Limiting

I stopped treating accessibility as proof of value.

I started treating attention as infrastructure requiring protection.

Introduce Response Delays

New process:

Incoming request
→ evaluate urgency
→ respond intentionally

Not:

Incoming request
→ immediate cognitive capture

Protect Deep Work Windows

Certain periods became interruption-restricted.

Focus mode: active
External access: limited

This dramatically improved mental clarity.

Separate Urgency From Accessibility

Most requests are not true emergencies.

They only feel urgent because modern systems normalize constant access.

I stopped inheriting urgency from other people’s expectations.

Remove Guilt From Delayed Responses

This was critical.

Delayed access stopped being interpreted as failure.

A slower response no longer meant:

rejection
neglect
irresponsibility

Sometimes it simply meant:

Current resources allocated elsewhere
What Changed

After implementing rate limiting:

focus quality improved
mental fatigue decreased
creative output deepened
emotional reactivity dropped significantly

And unexpectedly:

Relationships became healthier.

Because interactions became intentional instead of compulsive.

Reframing Availability

Old model:

Always reachable = caring

Updated model:

Protected attention = sustainable functioning
Takeaway

A system without rate limiting eventually loses stability.

Human attention is no exception.

If your focus is permanently interruptible, your priorities will eventually become externally controlled.

Not because people are malicious.

Because access expands wherever boundaries don’t exist.

Status
Instant-response dependency: reduced
Rate limiting: active
Attention protection protocols: enforced
Series: Behavioral Anti-Patterns

Previous: Refactoring Identity: When “Being Nice” Becomes Technical Debt
Next: Broken Access Control: Who Actually Deserves Your Time?

Refactoring Identity: When “Being Nice” Becomes Technical Debt

Khali Sollis — Fri, 19 Jun 2026 12:00:00 +0000

How outdated self-concepts, approval-based behaviors, and inherited emotional programming create hidden maintenance costs—and why identity refactoring becomes necessary for long-term system integrity

After reducing emotional over-responsibility, another realization surfaced:

The behaviors were never the root problem.

They were outputs.

The actual issue was deeper:

My identity architecture itself was outdated.

For years, I operated from a core internal definition:

Good person = helpful
Good person = agreeable
Good person = emotionally available
Good person = self-sacrificing

At first, this system appeared functional.

People liked it.
It reduced conflict.
It generated approval.

But over time, the maintenance cost became impossible to ignore.

The Bug: Identity-Level Technical Debt

In software systems, technical debt accumulates when outdated design decisions continue running long after the environment changes.

The system still functions.

But:

performance degrades
complexity increases
maintenance becomes exhausting

Human identity works similarly.

Certain beliefs are installed early:

“Be easy to deal with.”
“Don’t disappoint people.”
“Keep the peace.”
“Being needed means being valuable.”

At first, those patterns help adaptation.

Later, they start corrupting the system.

Why “Nice” Becomes Expensive

The issue was never kindness itself.

The issue was identity dependency.

When “being nice” becomes part of your core architecture, the system begins protecting that image at all costs.

Even when:

boundaries are violated
exhaustion increases
resentment accumulates
alignment disappears

Because preserving the identity becomes more important than preserving the self.

The Hidden Maintenance Costs

Running an outdated identity framework creates constant internal overhead.

Continuous Self-Suppression Authentic reaction detected → suppress to maintain image consistency

This consumes enormous energy over time.

Chronic Behavioral Editing

Every interaction becomes partially optimized for perception management:

soften the response
minimize discomfort
avoid appearing “difficult”

The system stops communicating naturally.

It starts rendering acceptable output.

Emotional Fragmentation

When identity and reality diverge for too long, fragmentation occurs.

Externally:

stable
pleasant
reliable

Internally:

resentful
drained
misaligned

The longer this split remains active, the more unstable the system becomes.

The Inherited Architecture Problem

One difficult realization:

Much of my identity was inherited, not consciously chosen.

Behavioral rules installed early:

prioritize harmony
avoid burdening others
over-accommodate
earn belonging through usefulness

These patterns often originate as survival strategies.

And survival strategies are difficult to question because they once worked.

But adaptation is not the same thing as alignment.

Why Identity Refactoring Feels Threatening

Because changing behavior is manageable.

Changing identity feels existential.

Once the old system starts dissolving:

certain relationships destabilize
familiar roles disappear
approval patterns weaken

And the system asks a terrifying question:

If I stop performing this identity,
who am I without it?

That uncertainty keeps many people trapped inside outdated frameworks long after they stop functioning.

The Technical Debt Analogy

Technical debt becomes dangerous when:

old architecture limits growth
fixes become increasingly temporary
complexity compounds faster than stability

That’s exactly what happened here.

Every new boundary required:

guilt management
explanation layers
emotional buffering
internal negotiation

Because the core identity still expected self-sacrifice.

The behavior changed.

The architecture hadn’t yet.

The Refactor

I stopped treating identity as fixed.

I started treating it as modifiable infrastructure.

Reevaluate Core Definitions

Old model:

Good = self-sacrificing

Updated model:

Good = honest + aligned + responsible

This removed enormous internal contradiction.

Remove Legacy Code

Not every inherited belief deserved permanent residency.

Some behavioral scripts were deprecated:

automatic accommodation
compulsive harmony maintenance
approval-driven compliance

The system no longer optimized for universal comfort.

Allow Identity Instability During Transition

Refactoring creates temporary disorder.

Old behaviors stop functioning before new stability fully forms.

That phase feels uncomfortable because:

reactions change
expectations shift
social feedback becomes inconsistent

But temporary instability is part of rebuilding.

Prioritize Integrity Over Image Consistency

This became the primary architectural shift.

Old system priority:

Maintain perception

Updated system priority:

Maintain alignment

Even when perception fluctuates.

What Changed

After beginning identity refactoring:

internal conflict decreased
communication became cleaner
boundaries required less explanation
emotional exhaustion dropped significantly

And unexpectedly:

I became more consistent.

Not because I was performing stability.

Because the system stopped fighting itself internally.

Reframing “Nice”

Old model:

Nice = identity requirement

Updated model:

Kindness = conscious choice

One is compulsion.

The other is integrity.

Takeaway

When “being nice” becomes identity-level programming, the system eventually accumulates technical debt.

Not because kindness is wrong.

Because self-abandonment scales badly as architecture.

At some point, patching behaviors is no longer enough.

The identity itself requires refactoring.

Status
Legacy identity scripts: deprecated
Core architecture refactor: active
System integrity: improving
Series: Behavioral Anti-Patterns

Previous: Handling Exceptions That Aren’t Yours: The Trap of Emotional Over-Responsibility
Next: No Rate Limiting: How Instant Availability Destroys Focus

Handling Exceptions That Aren’t Yours: The Trap of Emotional Over-Responsibility

Khali Sollis — Fri, 12 Jun 2026 12:00:00 +0000

How absorbing other people’s instability, emotional processing, and unresolved problems creates system overload—and why not every exception belongs to your architecture

After clearing stale trust models, another behavioral anti-pattern became impossible to ignore:

I was constantly handling exceptions that were never mine to process.

Not because I was asked directly.

Because my system had been trained to automatically absorb instability.

Someone distressed
→ intervene
Someone struggling
→ carry emotional load
Someone irresponsible
→ compensate

I called this empathy.

Sometimes it was.

Other times, it was emotional over-responsibility disguised as virtue.

The Bug: Automatic Exception Handling

In software systems, exceptions are meant to be handled by the process that generated them.

Problems belong closest to their source.

But my old emotional architecture worked differently:

External instability detected
→ reroute to self
→ attempt resolution

No validation.
No ownership check.
No resource assessment.

If someone was overwhelmed, I felt responsible for stabilizing the environment.

Even when I wasn’t the source of the instability.

Emotional Over-Responsibility

This pattern creates a distorted role assignment.

You stop asking:

Whose responsibility is this?

And start assuming:

If I can help, I should carry it.

That logic becomes dangerous quickly.

Because capability is not obligation.

The Hidden Reward Loop

Part of emotional over-functioning comes from identity reinforcement.

Being the person who:

fixes problems
stabilizes others
absorbs tension
remains “strong” under pressure

creates social reward.

You become:

dependable
needed
emotionally central

Which feels meaningful.

Until the load becomes permanent.

The Systemic Problem

When you constantly handle other people’s exceptions:

Their accountability ↓
Your exhaustion ↑

The environment adapts around your over-functioning.

Which means:

others under-develop coping skills
boundaries weaken
imbalance becomes normalized

You unintentionally become infrastructure for dysfunction.

The Difference Between Support and Absorption

This distinction changed everything for me.

Support says:

“I care about your experience.”

Absorption says:

“Your emotional state is now my responsibility.”

Those are not the same system.

One maintains integrity.

The other erodes it.

Why This Pattern Feels Noble

Because many of us were conditioned to associate love with emotional labor.

Especially if we learned:

peacekeeping = safety
helping = value
emotional endurance = strength

So the system starts interpreting self-sacrifice as evidence of goodness.

Even when the cost becomes unsustainable.

The Cost of Constant Emotional Processing

Every unresolved issue you internalize consumes resources.

External emotional load
→ internal processing
→ resource depletion

Over time, this creates:

emotional fatigue
chronic hypervigilance
resentment without expression
reduced internal clarity

Because your system is continuously allocating bandwidth to problems it did not generate.

The Savior Configuration

One difficult realization:

Part of me believed I could stabilize people into becoming different.

If I listened enough.
Supported enough.
Stayed patient enough.

But emotional labor cannot override another person’s willingness to change.

And trying to carry people into accountability usually delays it.

The Fix: Ownership Verification

I stopped automatically claiming responsibility for external instability.

Not coldly.

Accurately.

Identify the Source

New evaluation process:

Problem detected
→ who owns this?

Not:

Problem detected
→ absorb immediately

Separate Compassion From Responsibility

I can care without carrying.

That distinction created enormous system relief.

Compassion ≠ emotional ownership

Stop Overriding Consequences

Sometimes discomfort is necessary feedback.

When you constantly rescue others from the impact of their behavior:

growth gets delayed
patterns persist
accountability weakens

Removing friction does not always create healing.

Sometimes it prevents it.

Allow Incomplete Resolution

This was difficult.

Because I was deeply conditioned to seek closure, peace, and emotional stabilization.

But not every situation resolves cleanly.

And not every unresolved emotion requires my intervention.

What Changed

After reducing emotional over-responsibility:

internal noise decreased
energy stabilized
relationships became more balanced
emotional clarity improved significantly

And unexpectedly:

My compassion became healthier.

Because it stopped requiring self-erasure.

Reframing Helpfulness

Old model:

Love = carrying

Updated model:

Love = support without self-abandonment
Takeaway

Not every emotional exception belongs to your system.

And constantly absorbing instability does not make you stronger.

It makes you overloaded.

You are allowed to care without becoming the processing center for everyone else’s unresolved problems.

Status
Automatic exception handling: reduced
Ownership verification: active
Emotional resource protection: enabled
Series: Behavioral Anti-Patterns

Previous: Caching Bad Data: Why We Keep Trusting Broken Patterns
Next: Refactoring Identity: When “Being Nice” Becomes Technical Debt

The Brain Economy: Why Human Attention Is Becoming Critical Infrastructure

Khali Sollis — Tue, 09 Jun 2026 22:04:36 +0000

Written for readers at the intersection of technology, public health, and systems thinking.

There is a moment in the history of every critical resource when society stops treating it as a personal possession and starts treating it as shared infrastructure. Water made that transition in the 19th century, when cholera outbreaks forced cities to stop blaming individuals for getting sick and start building sewers. Clean air made it in the 20th, when smog began killing people visibly enough that governments could no longer pretend the atmosphere was a private matter.
We are living through that same transition right now — and the resource in question is the human brain.

The AI Paradox
Paradoxically, the rise of artificial intelligence increases the value of biological intelligence. When information becomes abundant and automation becomes cheap, the limiting factor shifts away from access to knowledge and toward the quality of judgment, attention, creativity, and long-term thinking. Routine cognitive work is the first thing AI automates well. What remains — the work that still requires humans — is precisely the cognitive capacity that is hardest to fake and most vulnerable to environmental erosion.
Industrial economies depended on physical capital. Information economies depended on computational capital. AI economies may increasingly depend on cognitive capital — the quality of human judgment applied to abundant information and abundant automation. The scarce resource is no longer data. It is the ability to think clearly about data.
In an AI-saturated economy, cognitive resilience may become the most valuable infrastructure asset a society possesses. The bottleneck is shifting from computation to cognition. That is not a soft claim. It is an economic prediction with hard structural implications.

The Brain Economy Framework
The language coming out of the World Brain Health Forum and the Davos "Brain House" sessions is not the language of wellness retreats or self-help. It is the language of macroeconomics and national security. The phrase that keeps appearing in high-level briefings is the Brain Economy — a framework developed by the Brain Capital Alliance that treats the aggregate cognitive capacity of a population as a form of capital, one that can be invested in, degraded, or allowed to decay through neglect.
This reframing is not rhetorical. It has teeth.
A landmark scientific statement from the American Heart Association recently redrew the map of brain health across the entire human lifespan. The core finding was at once obvious and devastating: the blood vessels that supply the brain begin accumulating damage decades before any cognitive symptom appears. Environmental exposures — chronic air pollution, disrupted circadian rhythms, and increasingly microplastics (a 2025 study in Nature Medicine confirmed their bioaccumulation in human brain tissue, though causal links in humans are still being established) — quietly alter the architecture of those vessels during childhood and young adulthood. The cognitive decline that shows up at sixty is, in many cases, an invoice for damage silently logged at age ten.
This is not a wellness problem. It is a pipeline problem. And pipelines are infrastructure.

The Hardware Crash Hypothesis
In the technology world, we draw a clean line between software bugs and hardware failure. Software bugs are annoying and usually recoverable. Hardware failure is categorical: when the substrate breaks, nothing running on top of it works correctly anymore.
The Brain Economy framework applies this distinction to civilization itself. Executive function — the capacity to plan across time horizons, regulate emotional responses, maintain focused attention, construct novel solutions — is the substrate on which everything else depends. Democratic institutions, scientific progress, entrepreneurial culture, and effective governance all run on this hardware.
And that hardware is being degraded. Chronic poor sleep, ultra-processed food systems, and the unrelenting attentional siege of the modern digital economy are conducting a slow erosion of the substrate. When executive functioning is sufficiently compromised across a population, the system doesn't gradually decline — it crashes. Not dramatically, but in the quiet way complex systems fail: through compounding micro-failures, through decisions made on depleted cognitive budgets, through a long diminishment that looks, from inside, like ordinary life.

What "Brain Infrastructure" Actually Means
When the framework moves from diagnosis to prescription, it looks less like a health campaign and more like urban planning.
Air quality is brain quality. A growing body of epidemiological research connects fine particulate matter (PM2.5) exposure to cognitive decline in children and accelerated dementia in adults. London's Ultra Low Emission Zone — the largest clean air zone in the world — cites "emerging evidence of links between air pollution and dementia" as part of its public rationale alongside respiratory and climate goals. When you build a low-emissions zone, cognitive protection is increasingly part of what you are building.
Sleep infrastructure is real infrastructure. The WHO has classified night shift work as a probable carcinogen, and the cognitive tax of chronic sleep disruption is well-quantified. A population running on insufficient sleep operates with a permanent impairment equivalent to mild intoxication. That is a structural problem, not a personal one.
Digital environment design is the contested frontier. Specific design patterns — infinite scroll, TikTok-style recommendation loops, variable-reward notification systems, Slack's always-on interruption culture — have been associated with measurable changes in attention, impulse control, and executive-function-related neural networks in developing brains, and are increasingly studied for their effects on attentional resilience in adults. The average knowledge worker is interrupted or switches tasks every three minutes and five seconds, with research suggesting that recovering deep focus can take far longer than the interruption itself. That is not a personal discipline failure. It is a designed outcome.

What This Means for Builders
If you write software, you are not a neutral observer of this conversation. The products engineers build are, whether intended or not, cognitive environments — and cognitive environments have consequences that extend well beyond engagement metrics.
A few reframes worth sitting with:
If you're running or advising a company, organizational cognitive performance is a competitive variable. Companies increasingly compete on the quality of judgment their teams can bring to bear — and that quality is not fixed. A company that protects deep work, minimizes unnecessary interruptions, and reduces attention fragmentation may see gains that look like productivity improvements but are actually something more durable: cognitive infrastructure gains. The organizations that treat employee attention as a resource worth protecting — rather than an input to be maximized — are building a structural advantage that compounds quietly over time.
If you're designing engagement systems, you are designing attentional architectures. The decision to implement infinite scroll, to default notifications to "on," or to optimize for session length rather than session quality is a decision about the cognitive habits your product reinforces over time. That is a legible technical and ethical tradeoff, not just a product preference.
If you're building AI products, attention is a scarce upstream resource. Your AI assistant, copilot, or automation tool sits inside a human cognitive workflow. If that workflow is already degraded — fragmented attention, depleted working memory, chronic context-switching — the quality of human-AI collaboration degrades with it. The value of your product depends partly on the cognitive health of the person using it.
If you're creating workplace software, focus preservation is a feature. Tools that protect deep work windows, batch asynchronous communication, and reduce interrupt-driven workflows are not just ergonomic niceties. Companies that design for cognitive sustainability will likely outperform those that treat attention as an inexhaustible input.
If you're designing recommendation systems, cognitive cost should sit alongside engagement as a first-class metric. A recommendation that maximizes clicks but trains users toward shorter attention spans is imposing an externality — one that doesn't show up in your dashboard but does show up, eventually, in the aggregate cognitive capacity of your user base.
None of this means engagement is inherently bad or that every attention-capturing design is malicious. It means the externalities are real, increasingly measurable, and starting to attract the regulatory and reputational scrutiny that environmental externalities began attracting in the 1970s.

The Sanctuary Problem
The Brain House metaphor refers to the construction of environments designed as sanctuaries from conditions that degrade cognitive function: quiet, natural light, controlled air quality, scheduled deep work, access to green space. In the Brain Economy framework, these are prototypes for the built environment a cognitively serious civilization should be constructing at scale.
The problem is that access to these conditions is currently distributed in inverse proportion to need. The people most exposed to cognitive-degrading environments — polluted air, food deserts, noise, precarious shift schedules, economically driven phone dependency — are the people with the least access to brain-protective spaces and routines. Cognitive capital is not declining uniformly. It is declining fastest in the people who can least afford the cognitive tax.
This is where the Brain House framework either becomes transformative or becomes another Davos amenity. The serious version means treating cognitive protection as a public good: built into zoning as fire codes are built into zoning, regulated as we regulate food safety. The government that installs air quality monitors in schools near highways is doing something as strategically important as the government that funds a chip fabrication plant.

What Comes Next
The transition from "brain health as personal responsibility" to "brain health as national infrastructure" will not be smooth. There are enormous interests invested in the current attentional economy, and deep cultural resistance to the idea that consciousness itself might be a policy domain.
But the evidence is becoming difficult to ignore. For technologists specifically, the key recognition is this: the tools you build exist inside a broader cognitive ecosystem. That ecosystem is under measurable stress. The engineers, product managers, and researchers who internalize that fact early — who start treating cognitive sustainability as a real design constraint, not an afterthought — are the ones most likely to build things that hold up as the conversation shifts from wellness to infrastructure.
The question is no longer whether human cognitive capacity is an infrastructure problem.
The question is whether the people building the digital environment will engage with the answer before the invoice arrives.
In an age obsessed with artificial intelligence, we may discover that protecting natural intelligence was the more important infrastructure project all along.

Building something that touches on attention, cognitive load, or human-AI collaboration? I'd genuinely like to hear how you're thinking about these tradeoffs in practice — drop it in the comments.