DEV Community: Ese Idukpaye

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.