The AI orientation tax: it's missing context, not discipline

Ese Idukpaye — Sat, 11 Jul 2026 15:17:37 +0000

You have eleven things in flight. Three of them are "almost done." You can't remember which three. Every morning you spend the first ten minutes rebuilding the picture (what was I on, where did I leave it, what's actually next) before you do any real work. And the coding agent you brought in to go faster starts every session asking you the same questions you just answered yesterday.

The usual diagnosis is discipline: you start too much, you don't finish, you're scattered, get a system and stick to it. I think that diagnosis is wrong, or at least aimed one layer too high. The people who actually dug into this landed somewhere else: it's missing context, not discipline. And the interesting part is that your agent now pays the exact same tax, for the exact same reason.

This is a post about that tax: what it is, what it costs (there are numbers), why the AI era makes it worse instead of better, and the small loop where it actually breaks.

The tax you're already paying

Picture a normal day with three projects going at once. Underneath the actual work, you're running a second, smaller loop all day long:

capture: get what's on your plate into view
check state: figure out where each piece actually is
prioritize: pick what's next
review: at the end, see what got done

That loop is cheap when you're running one thing. It gets expensive fast when you're running several phased threads at once, because now you're holding all of it in your head, and your head has a ceiling. Past that ceiling, you start paying what I'll call the orientation tax: the time and attention you burn just staying oriented (re-contextualizing, re-deciding, re-finding your place) instead of moving the work forward.

The tax is small per hit and easy to dismiss. That's exactly why it's expensive: you pay it dozens of times a day and never see the bill.

The misdiagnosis: "just have more discipline"

The dominant framing for this is moral. You have too many half-finished projects. Finish what you start. Stop being a magpie. It shows up everywhere in dev culture, and it feels true, so nobody questions it.

But look at what the people who took the problem seriously actually concluded. The developer behind I Have 47 Unfinished Side Projects expected the lesson to be discipline, then landed on context instead: of the 47, the one project that actually shipped was the one that started from a real problem he had right now ("I literally need this tomorrow"), not from forcing himself to finish the rest. Bonaventure Ogeto keeps what he calls a "projects parking lot": a single place to log every project and its current status, so you always know where everything lives and nothing feels lost. That's not a discipline fix. It's an orientation fix: one honest place where the state of in-flight work lives.

Here's the distinction that matters, because it's easy to blur. Deciding what to start is a selection problem: upstream, real, but not this one. The tax I'm describing starts after you've committed. You've got work you've decided to do, broken into pieces, and the cost is just staying oriented across it. The grassroots fixes all quietly agree the lever is context (a single status home), not willpower. The discipline frame keeps people optimizing the wrong variable.

The numbers (it's expensive, and some of it is measured)

"Staying oriented" sounds soft. The cost isn't.

What	Figure	Source
Re-teaching the agent at the start of every session	~12 min/session ≈ one workday/month	Ma (self-tracked)
Refocusing after a single interruption (complex work)	up to 23 min	Gloria Mark / APA
A 10-dev team losing 20% to switching	~$240,000/year	onehorizon

Three angles on one cost: per session (the agent), per interruption (you), per year (the team). Two honest caveats, because the credibility is the point. The 23-minute refocus comes from Gloria Mark's interruption research, usually reported second-hand, so treat it as directional, not gospel. The 12-minute/session figure is newer and thinner: one developer's week of self-tracking. Strong as illustration, not yet replicated. I'm citing both as what they are.

But the direction is unambiguous, and the two tiers point at the same thing: the cost of losing the thread, multiplied by how often you lose it.

The AI era makes it worse, not better

You'd expect a coding agent to reduce this. It does the opposite, in two ways.

First, it raises the thread count. Agents let you start more and ship faster than you can stay oriented. Every capability jump (faster models, parallel agents, longer task horizons) increases how many pieces a solo operator can have in flight at once. That's the exact input that drives the tax. More throughput, more to keep straight.

focus / context-switching research (decades, pre-AI)
        |  attention is serial; switching is costly
        v
indie-maker "too many threads" culture (2010s ->)
        |  more starts than you can hold
        v
agent era (2024-2026)   <-- the amplifier
        agents let you START more and SHIP faster than you can orient,
        AND the agent itself loses the thread between sessions

Second, and this is the new part: the agent pays the tax too. It starts every session cold. As one tooling write-up puts it, model weights are frozen, the context window rebuilds from scratch, and "most tools do not write cross-session memory by default. Manual files like AGENTS.md help, but they drift." That drift is the same staleness that rots your own notes, now happening to the agent.

And it's not a one-way street where your mess flows downhill into the agent. The sharper read: you and the agent are running the same loop on the same work, on two different clocks. Your clock spans days and weeks. The agent's clock is the session, and it resets every time. When you ship fast, you spin up many sessions, often parallel, across days. Nothing inside a single session can carry the picture across all those resets. The agent reaching for AGENTS.md, the threads asking "how do you handle context loss between Claude Code sessions?": that's the agent trying to run check-state and review and failing for lack of a durable, shared list. Same break as yours, different clock.

It's one loop, and it breaks in the same place every time

Step back and the whole thing collapses into a single mechanism. The tax isn't five unrelated annoyances. It's one loop breaking for one reason: there's no single honest list to run it on. Take the list away and watch each act fail in order:

No list → capture fails. Committed work never lands in one place, so you orient on a partial view.
→ check-state fails. State isn't updated, so the list (such as it is) lies: it says "in progress" for things that are done or dead.
→ prioritize fails. What matters shifted; nothing flagged it; you keep working yesterday's order.
→ review fails. Closure was never recorded, so "what did I actually ship this week" is unanswerable, and it stays invisible until the shame shows up.
→ it cascades. Every break above is inherited by the agent, which is reading the same broken picture.

That's the give-away here, the part worth keeping even if you never touch any tool: when your multi-threaded work feels like it's slipping, don't reach for more discipline. Find the act of the loop that's breaking, and notice it's breaking because nothing holds one honest list.

Why nobody's built the fix

If the problem is this legible, why is the slot empty? Because the field inherited the discipline frame. Orientation got filed as a pre-existing human-character problem (be more focused, start fewer things), so when agents arrived, nobody built the AI-native answer for it. The tooling that did get built lives one layer down, on execution: making the agent build a single task correctly (spec files, rules files, memory stores). All useful. None of it keeps you and the agent oriented across the whole board of in-flight work.

So the pain is mainstream and well-documented, but the solo-operator-plus-agent framing is young and mostly open. The vocabulary is even splitting in real time: "context switching" on the productivity side, "agent memory" and "persistent context" forming on the tooling side, both circling the same hole from opposite directions.

The reframe, in one line

Your scattered board and your forgetful agent are not two problems, and neither is a discipline problem. They're one orientation problem: nothing holds a single honest picture of what's in flight, so you keep rebuilding it from memory and the agent keeps inheriting a broken copy.

The fix isn't to want it more. It's to give the loop one surface to run on: honest, shared, and gated, so the honesty doesn't ride on memory. A board you reconcile before you build on it, instead of one you hope you updated. That's a design problem, not a character flaw. I've been building toward an answer to it, and that's the next post. This one only had one job: to get you to stop blaming your discipline for a context bug.

Sources

Agent context loss: Augment Code, "Why AI Agents Keep Asking the Same Questions"; Marvin Ma, "Why Your AI Coding Agent Keeps Forgetting Everything" (the ~12-min/session figure).
Interruption and team cost: Gloria Mark / APA interruption research (via secondary reporting); onehorizon (the ~$240k/yr figure).
Maker self-diagnoses (the 47-projects and parking-lot pieces) are linked inline. Full source ledger lives in the problem-convention dossier.

Javascript (JS) Pass by Reference and Pass by Value

Ese Idukpaye — Sat, 28 Jan 2023 20:28:35 +0000

Terms

Passing: To assign a value to a variable or, pass it to function as a parameter.

Pass by Value

Anytime a variable containing another value which is not an object or an array is passed along to let's say a function as a parameter, the variable being passed becomes a copy of the value it holds. As a result, the variable passed to the function will have its value unchanged despite whatever the function does with it, for example, reassign’s it or updates it.

let x = 60 
console.log (x) // 60

function boo (y){
    y = 70 
    console.log (y) // 70
}

foo(x) 
console.log (x) // 60 : unchanged value of the x variable

Pass by Reference

Anytime a variable containing another value which is an object or array is passed along to let say a function as a parameter, the variable is passed to the parameter as a ref to its object/array value. As a result, the variable passed to the function will have its value changed if for example it is updated with a new element of the key/value pair.

let x = {
    name:"john",
    age:22
} 
console.log (x) // {name:"john",age:22} 

function boo (y){
    y.statue = true
    console.log (y) // {name:"john",age:22, status:true} 
}

foo(x)
console.log (x) // {name:"john",age:22, status:true}

5 Debugging Tips that can Save you 5hrs of Debugging Time

Ese Idukpaye — Fri, 21 Oct 2022 23:14:17 +0000

1. Document Everything

You should always document everything from instructions on how to replicate the bug, to defined strategies on how to resolve the bug, to any side effect that results from a solution implementation. This is probably the most important one and I learnt this from working at Loxe Inc.

2. Error Logging

Always log your errors through a properly implemented error handler middleware and when an error occurs be sure to check your logs. I don't also forget the remove log statements from your debugged code. I learnt this from working at Loxe Inc.

3. Only refactor working code

When debugging it is best to work with the most simplistic-looking code piece of code to speed up the refactoring process and refactor after the code has been debugged.

4. Fix one problem at a time

This is also one major mistake most people make including myself of trying to resolve all the bugs at the same time before testing or grouping a lot of small bugs into one big bug, never do this. Always fix one bug at a time

5. Take Breaks

This can be linked to the spacing effect which refers to the finding that long-term memory is enhanced when learning events are spaced apart in time, rather than massed in immediate succession.
What this translates is that when trying to resolve bugs don't feel that you have to do it all in one go. it's okay to take breaks while resolving a bug.

DEV Community: Ese Idukpaye