DEV Community: Ese Idukpaye

The Human Harness: Your Loop Runs First

Ese Idukpaye — Wed, 02 Sep 2026 18:29:23 +0000

Every serious agentic coding setup is running a harness right now. Not the model itself, but the machinery around it. The loop it runs in, the tools it can access, the context it receives, and the state it records so the next session doesn't start cold. The tech industry has settled on an equation for this: Agent = Model + Harness, and calls the practice of building the machinery: harness engineering.

This post is about the half of the system that equation doesn't cover. Every agentic setup has two workers, and only one of them is a model. The other one is you, the person deciding, across many tasks and many sessions, what all of those agents should build. So the equation has a missing twin. Operator = Human + Harness. On this side, you are the raw capability; on the other, the model. The human harness is the machinery around you.

Before we dive in, here are the key takeaways and steps you'll find in this article:

What a human harness is, and how it complements the agentic harness
Why orienting your work is essential before automating execution
The core components that make up a human harness
How to build a minimal, effective human harness in practice, complete with a concrete example you can implement in your own workflow

What a harness actually is

To understand what a harness is in an agentic system, we have to understand it from a physical standpoint. Picture a horse harness. Its purpose is to provide the mechanism needed for a horse to do work by transmitting power that already exists and turning it into useful work. Without it, you have a strong animal and a cart that goes nowhere. Call this the transmission function.

Now picture a rock climber harness. This one transmits nothing. Its purpose is to secure the climber to a safe working condition (climbing without falling to the ground). It does this by catching a failed state (losing your grip) and taking a securing/remediating action. Without it, you have an unsafe working condition, one where a fail state is not caught and unremediated. Call this the securing function.

Therefore, we can say a harness is something with these two functions, and in software the two live together in one environment. Look inside the agent harness you already use. Claude Code transmits for a language model. The raw model can reason but can't act, and the loop, tools, and context management around it are what turn reasoning into shipped work. The same harness also secures. Hooks block a dangerous command before it runs. Sandboxes limit what can be touched. LangChain's own anatomy of a harness lists both kinds of parts in one breath: tools and state to enable the work, "enforceable constraints" to secure it. The pattern is older than agents, too. Your IDE transmits for you, because nobody ships production software from Notepad. And every pre-commit hook, every CI wall, every branch protection rule is the securing function pointed at your code.

So here is the definition this whole series stands on. A harness is a system that enables safe execution. It does that in two ways at once. As the environment that turns a worker's power into work, and as the gates that secure the work to safe conditions.

What a loop actually is

If a harness is a system that enables safe execution, then a loop is a component of that system that defines or manages repetitive execution/work cycles inside a harness. In agentic systems, this is quite apparent. For example, Boris Cherny, who created Claude Code, describes his job as writing loops now, not prompts, highlighting the importance of loops in agentic systems.

We can think of a loop as an execution tool. It is created or takes place when one run of a cycle of work shares its state with the next cycle. A for loop is one body of work run many times, sharing a counter. Your Tuesday is a run of you that inherits Monday's state, meaning what shipped, what broke, what you decided. An agent session is a run that inherits whatever the previous session wrote down. Same tool at every scale.

Loops consist of four main components. Something that starts a work cycle. Call that the trigger. It might be a user prompt, a morning, a bug report landing. Then there is the work cycle itself where work gets done. An agent session calls one of these a turn. Something decides whether to go again or stop. That's the exit condition. The tests pass, the day ends, the goal is met. And something survives into the next work cycle. That's the shared state. The first three give you repetition. Only the fourth makes repetition into a loop.

What this adds up to is that a loop can also be defined as a repetition with shared state. Without it, you have no aggregated result, no compounding effect; each work cycle begins at zero, re-derives everything, deposits nothing. Hold that distinction, a loop versus starting over, because it's the entire agent-tooling industry in one sentence. A model's sessions are starting-over by nature, and the first job of the agent's harness is to carry state across the reset so those sessions become a loop.

Now, if we take a step back to see how it all fits, we see that the harness enables safe execution. The loop is the execution tool that needs exactly what a harness provides. The transmission function gives the loop somewhere durable for its state to live between runs. The securing function checks conditions at the boundaries between runs. A harnessed loop compounds. An unharnessed one decays into starting over.

The human harness and the agentic one

Anthropic wrote the clearest picture of the agentic harness in Effective harnesses for long-running agents. A coding agent works in discrete sessions, and each new session begins with no memory of what came before, like a project staffed by engineers working in shifts where every engineer arrives with no memory of the previous one. Their harness does three concrete things about that. It writes the agent's state to disk, compacts the context so nothing important falls off the end, and leaves a handoff note for the next shift. In our vocabulary, it carries shared state across the reset. It turns the agent's starting-over into a loop.

Read the scene once more, though, and count the workers. There are two. The agent is the executor. It takes one task and runs it, inside its harness. You are the operator. You decide what's worth doing at all, you hold every work thread at once (what's captured, what's in flight, what's half-finished, what's next), and you hand tasks down. That isn't supervision from somewhere outside the system. It's a second worker inside it, running its own loop on its own clock. The agent's runs are sessions, and they reset in minutes. Your runs are mornings, days, weeks.

Which gives the human harness a precise definition. It is the same machinery, pointed at the upstream worker. An environment that carries your state across your resets, and gates that secure your work to safe conditions. That's the twin equation to Agent = Model + Harness. Operator = Human + Harness. And the two harnesses aren't strangers. Yours lives exactly where the agent's lives, in the same repo, on the same filesystem, built from the same hook primitives. It's less a second system than one more layer of the system you already run, the layer where the decisions come from.

The relationship between the two can best be described as the human harness essentially being the frontrunner to getting work done; it runs whatever loop (orientation loop) that lives inside it first and passes that down to the agentic harness, which triggers execution loops for N threads of work or tasks it gets until the work reaches a done state.

So both harnesses provide the system for safe execution of work; the only difference is one runs first and is used by the operator, and the other runs second and is used by the agent.

What a human harness serves

So what is the work of the upstream worker? If a harness enables execution, what execution does the human harness enable?

The constant management of every task being executed (Execution management aka Orientation). In an agentic setup, this job is irreducibly yours. Knowing where everything stands, which tasks exist, which are moving, which are stuck, which matter today. And maintaining a picture true enough to hand down for execution. The interesting thing is that the relationship between orientation and execution is domain-agnostic; it's the same for a software engineer working with agents as for a content creator or a product manager. Whatever your role requires you to execute, you must first orient that task.

I've written about what it costs to run that job from memory, in the orientation tax. The short version: once several threads of agent-driven work are in flight, just staying oriented gets expensive, and the faster you ship, the steeper it gets. Kief Morris places the human "on the loop", shaping the harness rather than inspecting every artifact, and that's the right position. But position isn't the point here. Work is. Orienting is a real workload; it's yours alone, and today it runs bare.

The human harness and the orientation loop

The human harness exists to keep the operator oriented across work. Orientation is the loop that runs before execution: you keep a current picture of the work, use it to decide what matters next, and carry the updated picture into the next run.

For a builder running parallel threads, that loop has four steps. Capture what is on your plate. Check where each piece actually stands. Prioritize what needs attention next. Review what changed after the work runs. Then the cycle starts again. The work itself happens between the steps. The steps are what carry the state from one stretch of work to the next.

That gives us the anatomy of the orientation loop. The trigger is usually a morning, a context switch, or some other moment when you need to re-establish the picture. The run is the four-step orientation process. The shared state is the current picture of the work: what exists, what is moving, what is stuck, and what comes next. The loop persists because each run leaves that picture for the next one.

Without shared state, orientation is not a loop. It is starting over. Every morning, every context switch, you reconstruct the picture from memory, scattered notes, and whatever you can still remember from the last run. That is the orientation tax in structural form. The problem is not that you failed to pay attention. The problem is that nothing carried the state forward.

The difficulty is that there are two reset cycles in the system. Your orientation runs across days and weeks. An agent's execution resets every session. Both workers need the same picture of the work, but neither worker can carry that picture across the other worker's reset. The state therefore has to live outside both of them.

That is where the human harness comes in. Its transmission function gives the orientation loop a durable place to keep its state, one that the human can update and the agent can read. Its securing function controls the handoff from orientation into execution, so the agent does not start from a picture that has already gone stale.

The point is not to make the human do more processing. It is to give the loop somewhere to persist and a boundary that keeps execution attached to the current state. The human runs the orientation loop first. The agent runs its execution loops from the picture that the loop produces.

Build one in twenty lines

Grounding this in practice, these harness concepts can be directly implemented in code using current agentic frameworks. For example, in LangChain or Claude Code, you can write hooks or callbacks that save the agent's state to disk at the end of each session, load the relevant context at the beginning of the next, and log explicit handoff notes as structured data or markdown files inside your project directory.

This not only keeps the agent oriented, but also lets other agents or humans resume work seamlessly. Most frameworks provide APIs or configuration points to plug in these actions as part of the execution loop, so you can use their built-in storage, event hooks, and context management features to realize your own harness, both for models and humans.

To paint the picture more clearly, here is a complete human harness at prototype size, running a one-step orientation loop. It uses Claude Code hooks, the same primitive a pre-commit hook gives you (a script that fires before an action and can refuse it), pointed at your orientation instead of your code.

The rule it enforces is one line long: before your agent touches a file today, you write down what you did yesterday and what you're doing today.

Two pieces. First, tell Claude Code to check before it edits anything:

// .claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/orient-gate.sh" }
        ]
      }
    ]
  }
}

Then the gate. Has today's orientation been written? If not, refuse, and tell the human exactly how to clear it.

#!/bin/bash
# .claude/hooks/orient-gate.sh  (chmod +x)
FILE="$CLAUDE_PROJECT_DIR/.orient/$(date +%F).md"

# Oriented today? Say nothing, get out of the way.
[ -f "$FILE" ] && exit 0

cat <<'EOF'
{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "You haven't oriented today. In your terminal, run: ./orient  — it asks what you did yesterday and what you'll do today, writes it down, and clears you to work. Then retry."
  }
}
EOF
exit 0

The hook can't prompt you itself, because Claude Code hooks don't get a terminal. So it hands you a one-liner to run. That's orient, the piece that actually asks:

#!/bin/bash
# orient  (chmod +x) — say what you did + what you'll do; get cleared to work.
DIR="${CLAUDE_PROJECT_DIR:-.}/.orient"; mkdir -p "$DIR"
FILE="$DIR/$(date +%F).md"
[ -f "$FILE" ] && { echo "Already oriented today → $FILE"; exit 0; }
read -rp "Yesterday I… " DID
read -rp "Today I will… "  WILL
printf '# %s\n\n**Did:** %s\n\n**Will:** %s\n' "$(date +%F)" "$DID" "$WILL" > "$FILE"
echo "Oriented → $FILE. You're clear to work."

The whole loop, from the agent's side:

you: "edit the config"
  → DENIED: you haven't oriented today. run ./orient, then retry.
you: ./orient
     Yesterday I… shipped the loop-map post
     Today I will… revise the flagship
     Oriented. You're clear to work.
you: "edit the config"
  → allowed.

Now let's see how this prototype ties back to the orientation loop and human harness. There's a trigger: the first time your agent tries to touch a file today. There's an exit condition: today's note exists. There's shared state, because the note lands in .orient/, dated, so tomorrow's run starts with yesterday's answer sitting right there. Which means there's a loop. Each day reads the last one and feeds the next, and your days compound instead of starting over. And both functions of a harness are present. The orient script is the transmission, the environment that makes the act take thirty seconds. The hook is the gate, the securing function that makes it non-skippable. Environment plus gate, wrapped around a loop, pointed at a human. A complete human harness, at prototype size.

What a complete human harness looks like

The prototype gives you mostly the gate, but a complete human harness is a system. It provides one current picture of the work tasks, kept where you and your agents can both read it. I keep mine as a board: a simple view of work moving from backlog to done. You then run the orientation loop against that picture, once a day and again at a wider lens when needed. And the gate sits at the boundary between orienting and executing, refusing to let work continue when the picture is stale.

That is the whole shape. Durable state gives the orientation loop somewhere to persist. The orientation routine keeps that state current. The gate makes the handoff into execution explicit. Updating the picture stays free; only building on a picture you have not checked is gated.

At this point you might be asking yourself: I have seen the prototype, but what does the actual thing look like in a live environment? My answer to that is 4loops, a tool I've been building for quite some time. It exists because I found myself paying the orientation tax. My orientation used to live outside the environment where the work happened, in tools like Asana and Notion, in a browser tab far from the repo. Good tools, wrong place. My agents couldn't read them natively; hence, it was difficult to build an orientation loop around them, enabled by the transmission and securing function of the agent's harness.

What it changed was simple. The state I hand down is current, so agents start from the same picture I am working from instead of reconstructing it. Execution became faster, but more importantly, it became easier to keep moving in the right direction. The most direct proof came while writing these posts. I let the board drift behind the real work, and the gate stopped me mid-edit: you're about to build on a picture you haven't checked. Orient first.

That is the point of the harness. It turns orientation from something you have to remember to something the system carries and enforces.

Your loop runs first

The agent's harness solved one problem: it gave the executor an environment that carries state forward and gates unsafe execution. The human harness applies the same idea one level upstream, to the worker that decides what gets executed in the first place.

That ordering matters. Your orientation loop runs across days and weeks. It produces the picture from which the agent's execution loops begin. If that picture is wrong or stale, the agent's harness can preserve it, enforce it, and execute against it perfectly. It cannot correct the decision that produced it.

So the problem is not that agents need more supervision. The operator needs the same machinery we already built for the agent: a durable state that turns repeated work into a loop, and a gate that keeps execution attached to that state.

Okay guys, that's it for this one. If there's one thing I want you to remember from this long post is your loop runs first, so you have to find a way to harness it.

Part 3 of 3. The cost: the orientation tax. The map: everyone harnesses the agent's loop, here's the human's. This one: the foundations and the answer.

Sources

Agent = Model + Harness: LangChain, The Anatomy of an Agent Harness ("a harness is every piece of code, configuration, and execution logic that isn't the model"). Its component list carries both functions in one harness: tools and state to enable the work, "enforceable constraints" to secure it. The practice is named by Birgitta Böckeler (Thoughtworks), Harness engineering for coding agent users. Addy Osmani's Agent Harness Engineering is the practitioner synthesis the Claude Code description draws on.
The shift-change picture and the agent harness's three jobs (state to disk, context compaction, handoff notes): Anthropic, Effective harnesses for long-running agents (Nov 2025).
"My job is to write loops": Boris Cherny, via productmarketfit.tech.
The human "on the loop": Kief Morris, Humans and Agents in Software Engineering Loops (hosted on martinfowler.com, not written by Fowler).
Orientation as the pivot of a decision cycle: John Boyd's OODA loop.
The gate primitive: Claude Code hooks, specifically PreToolUse, which fires before a tool call and can deny it. The twenty-line example was tested before publishing (deny, then orient, then allow, plus idempotency). Build-side gates referenced: pre-commit · Husky · Trunk · branch protection.

AI coding agents: everyone harnesses the agent's loop. Here's the human's.

Ese Idukpaye — Sat, 18 Jul 2026 06:32:47 +0000

If you work with a coding agent, count the things watching it right now. Linters. Git hooks. CI. Specs. A memory store. A rules file it's supposed to obey. Half a dozen systems, all making sure the agent builds the right thing the right way.

Now count what keeps you oriented across the eleven things you have in flight. For most of us it's a markdown file we hope we remembered to update.

We spent two years building harnesses for the agent and left our own work on the honor system. Map the tooling on two axes and that gap turns into a specific, hard-to-unsee hole. This post is the map.

(This is part two of three. Part one, The AI orientation tax: it's missing context, not discipline, argued that the cost you're paying is a context bug rather than a character flaw. If you haven't read it, you don't need to. This one stands alone.)

Two loops, not one

The thing people lump together as "agent workflow" is really two loops at different altitudes:

The execution loop: "is the agent building **this one task* right?"* Scope it, design it, write it, test it. One unit of work.
The orientation loop: "do you and the agent share an honest picture of **what you're working on* across all the units?"* Capture, check state, prioritize, review, run over the whole board, daily and weekly.

Almost every tool you've heard of lives in the first loop. That's not a criticism. It's just where the money and the visible pain were. But it means when people say "we solved agent memory" or "we solved context," they solved it for the execution loop. The orientation loop got left to you and a markdown file.

You feel the difference the moment each one breaks. When the execution loop breaks, something yells: a failing test, a red build, a review comment. When the orientation loop breaks, nothing yells. The agent confidently re-suggests the thing you rejected yesterday. You rebuild a mental map you already had this morning. The only signal is a vague sense that you're moving slower than the tools promised. One failure is loud and tooled. The other is silent, so it got moralized instead.

Kief Morris, writing on martinfowler.com, maps this carefully in Humans and Agents in Software Engineering Loops. His subject is where the human sits inside the agent's loop: in the loop (inspecting every artifact) or on it (shaping the harness that produces them). As he puts it, "the 'on the loop' way is to change the harness that produced the artefact." Birgitta Böckeler gives that practice a name in the companion piece, Harness engineering for coding agent users.

This post is the next square over. Not where you sit in the agent's loop, but the loop that's yours, and whether anything harnesses it the way we've now learned to harness the agent's. Harness engineering, pointed back at the operator.

The map

Two axes do the work.

Horizontal, what layer the tool serves: Execution (one task) to Orientation (across tasks).
Vertical, how it holds: Advisory (you hope it gets read and kept current) to Harnessed (it's hooked on, so it can't quietly drift or go stale).

That vertical axis is the one that matters, and researchers at ETH Zurich put a number on it. Testing four coding agents across 138 tasks, they found that AGENTS.md files barely help: a developer-written one buys a marginal gain, an AI-written one slightly hurts, and either way the context costs over 20% more to run. The reason is the axis. A file is just advice. Nothing forces the agent to follow it, and nothing checks whether it did, so it follows sometimes and skips other times. A harness doesn't ask. That difference is why every enforced tool below exists, and it's exactly what the empty corner is missing.

Walk it corner by corner.

Execution and advisory, the crowd. CLAUDE.md and AGENTS.md, spec-driven dev (Spec Kit), external memory stores, Claude Code's native Tasks, agent-orchestration boards like Vibe Kanban. Enormously useful, and advisory by design: a file you hope the agent reads, a spec you hope stays current. This is where almost everyone is.

Execution and harnessed, productized enforcement for builds. This corner is real and mature: Husky, Lefthook, pre-commit, Trunk, GitHub branch protection, on top of the underlying primitives (git, Claude Code hooks, CI). These don't hope your code is clean. They refuse the commit, fail the build, block the merge until it is. Enforcement isn't exotic. It's a solved, shipping product category.

Orientation and advisory, hand-rolled and honest by discipline. Here's where your own loop lives today: a STATUS.md or CURRENT-FOCUS you re-read each session, todo.txt, Taskwarrior, a Linear board you run solo. All operator-facing, all real, and all kept honest by you remembering to update them. No enforcement.

Orientation and harnessed, empty. A harness for the loop you run: one honest, shared picture of what you're working on that you can't quietly let rot and keep building on, that you and the agent both read. Map every tool you can think of and this corner stays blank.

Try it on tools you actually use

The lens is only worth anything if you can run it yourself, so place a few real tools.

Take a memory MCP, an agent that stores and recalls context across sessions. Genuinely useful, and tempting to file under "solved orientation." But put it on the axes. It serves the agent's recall inside a task, so it sits execution-side. And it's advisory: it surfaces what it guesses is relevant, and nothing forces you or the agent to reconcile the whole board before acting. Bottom-left. It makes execution smoother; it doesn't hold your orientation loop honest.

Take Claude Code's native Tasks, or a board like Vibe Kanban (whose hosted product is now winding down, though the project continues as open source). Closer to orientation, because they track units of work across a session. Still advisory, though: the board reflects reality only as well as whoever last updated it, and nothing blocks the next action when it's stale. Left of center, low.

Take a Linear board you run solo. Now you're genuinely orientation-layer: operator-facing, across tasks. It lands bottom-right. But it's still advisory. Linear will never refuse to let you start work because your statuses are three days old. The honesty rides entirely on you.

Do this with any tool you like and the pull is the same. Things drift left toward execution and down toward advisory. The top-right stays empty. And you start to see what would move a tool into it: the thing would have to gate (refuse the next build until the board is reconciled, the way pre-commit refuses a dirty commit), and it would have to serve both readers off one surface (the list you prioritize is the one the agent reads to re-orient). Bolt a gate onto Linear-for-one and you're most of the way there.

Why three corners filled and one didn't

It's not an accident, and it's not that the orientation problem is small. Two forces left this corner empty.

Effort pooled where the pain was visible and monetizable. "The agent wrote bad code" is loud, demoable, and sellable, so the execution loop got tools. "I lost track of what I was working on" reads as a personal failing, so it got advice: be disciplined, start fewer things.
Enforcement never got pointed at orientation. Look again at the harnessed column. Every occupant enforces build correctness: lint, tests, secrets, merge rules. The enforcement primitive, a hook that blocks until a condition holds, is sitting right there, productized, in wide use. Nobody aimed it one layer up, at the question of whether your board is telling the truth.

So the empty corner isn't "enforcement is rare." It's "enforcement is everywhere, for builds, and absent for orientation." That's a much more specific, and more fixable, gap. And the split is worth naming plainly: the agent's job is execution, and ours is orientation. We decided execution was too important to leave to advice, so we made it enforceable. Orientation, the part that decides what the agent works on at all, we left to memory.

It's worth being concrete about how close the missing piece actually is. A pre-commit hook is just a script that runs before an action and can block it. Claude Code ships the same primitive: a hook that fires before a tool runs and can deny it. The entire enforced column is built on that one idea, pointed at code. Pointing it at orientation isn't a research problem. It's the same hook with a different condition: has the board been reconciled today, before you build on it. Nobody shipped it not because it's hard, but because nobody framed staying oriented as a thing you enforce rather than a thing you should just have.

The empty corner is the interesting one

Put the two findings together and the shape of what belongs there is obvious.

It's orientation-layer: story-grained, across the whole board, not inside one task.
It's harnessed: a deterministic gate, the way a pre-commit hook gates the commit. It blocks the next build until you've reconciled. You don't hope the board is current; you reconcile it before you build on it. The gate doesn't keep it honest for you. It makes you.
It serves both readers off one surface: you set priority and capture; the agent reads the same list to re-orient each session and marks state as work lands.

None of those properties is new on its own. Files are a solved substrate. Agent-readable state exists (CC Tasks, AGENTS.md). Boards exist. Enforcement exists (hooks). What's missing is the combination, aimed at the orientation loop. The rarest ingredients are the two this map makes visible: harnessed and serves-both-off-one-surface.

Take the map, not just the conclusion

The useful thing to keep here isn't "4loops goes in the empty corner." It's the map. Next time you evaluate an agent tool, a memory MCP, a kanban, a rules-file convention, place it on these two axes. Which loop does it serve: the agent's task, or your orientation across tasks? And does it hold (gate, enforce, can't-drift), or merely advise (hope it's read)? Almost everything clusters in the same three corners, and you'll feel the fourth one's emptiness yourself.

What goes in that corner, a harness for your orientation loop with honesty enforced the way builds already enforce correctness, is the next post. This one only had to draw the map clearly enough that the hole is impossible to miss.

Sources

The framing this post branches off

Kief Morris, Humans and Agents in Software Engineering Loops (martinfowler.com, 4 March 2026) — in the loop vs. on the loop.
Birgitta Böckeler, Harness engineering for coding agent users (martinfowler.com, 2 April 2026) — where the term "harness engineering" comes from.

The measurement of the advisory corner

Gloaguen, Mündler et al. (ETH Zurich), Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents? (Feb 2026) — arXiv · InfoQ summary. Four agents, 138 tasks: developer-written context files give a marginal gain, AI-written ones slightly hurt, and both add 20%+ to cost.

The advisory corner (execution-layer, hope-it-gets-read)

AGENTS.md — the open convention for agent instruction files, now stewarded by the Agentic AI Foundation.
Spec Kit — GitHub's spec-driven development toolkit.
Vibe Kanban — agent-orchestration board (hosted product winding down; continues as open source).
Claude Code's native Tasks — cross-session agent state.

The harnessed corner (enforcement, productized, for builds)

Husky · Lefthook · pre-commit · Trunk · GitHub branch protection
The underlying primitive: Claude Code hooks — a script that runs before a tool call and can deny it. The whole enforced column is this one idea, pointed at code.

The hand-rolled orientation corner

todo.txt · Taskwarrior · hand-rolled STATUS.md / CURRENT-FOCUS conventions.

Part one of this series

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

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: everyone harnesses the agent's loop, here's the map of the human's. 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.