Share
Make useful personal workflows visible to the whole team.
Internal presentation
Agent Harness at each::labs
How we use tools, specifications, sequential implementation, verification and measurement to improve our daily engineering work.
Purpose
Share the tools and practices we use, explain why they matter, and use data to decide what to improve.
There are many CLI tools. A list of tools is not enough. We need to ask: does this tool improve the speed, quality or correctness of our daily work?
The goal is to notice recurring problems, try a change, measure the result, and share the changes that work with the rest of the team.
Measure
Bring data so adoption is based on outcomes, not enthusiasm.
Reuse
Turn one person’s improvement into a shared team practice.
Agents are now part of daily work
The workflow around an agent affects every task the agent performs.
Agents now help with reading, implementation, testing, review, documentation and repository operations. A slow tool, unclear instruction or missing check can affect many tasks.
A faster search command, a clearer specification or a better verification step can also improve many future tasks. This is why the surrounding workflow deserves regular attention.
Tools
Reduce friction in search, review, navigation, context and handoff.
Practices
Give the work a stable loop: spec → thin slice → independent proof.
Culture
Share useful changes and use data to decide whether they should become team defaults.
Ergonomics changes over time
A chair at minute 10
“Feels comfortable.”
Softness and first impression dominate. The body has not accumulated pressure, fatigue or compensation. Almost any defect can hide.
A chair after eight hours
Pressure, posture and fatigue
Small problems build up over time. A tiny angle creates pain; vibration and heat matter; one fixed posture stops working. A good seat must support adjustment during the journey.
A seat that feels comfortable for ten minutes may become uncomfortable after several hours. Tools have the same problem.
A short test is not enough
A short test cannot tell us how a seat—or a tool—will feel after several hours.
Delayed effect
Pressure and fatigue accumulate slowly. The defect appears hours after the first contact.
Adaptation
People compensate: change posture, take breaks, create workarounds and normalize discomfort.
Many variables
Seat shape, body, vibration, temperature, road, attention and duration interact.
Personal experience
Different people experience comfort differently. We need repeated feedback and observable measures.
Missing feedback
People who stop using a tool may not report the long-term problem that made them stop.
Short evaluation
A demonstration shows initial capability. Daily use also requires predictability, recovery and control.
We should use more than one type of evidence. We can combine team feedback with observable measures such as interruptions, recovery time, error rate, rework and continued use.
Coding sessions are long
During a long coding session, small delays and unclear states are repeated many times.
Physical pressure → interaction friction
A slow search, noisy test log or awkward handoff looks small once. Repeated fifty times, it changes attention and behavior.
Limited tool → workaround
When a tool supports only one path, we change our working method to fit the tool. This adds steps and makes the process harder to understand.
Adjustment → control
Good tools provide small, reversible controls such as scope, filters, worktrees, checks, permissions and stop conditions.
Recovery → resumption cost
After an interruption or failed slice, can another person or fresh agent understand state and continue safely?
A tool may look impressive during a short demonstration. Several hours of real work show its delays, context loss, hidden state, supervision cost and reliability.
Our ergonomic baseline
A good setup makes it easy to see the current state, guide the work, verify the result and recover from problems.
Fast feedback
Search, tests and diffs return before attention drifts.
Visible state
Branch, task, spec, checks and next action are inspectable.
Small controls
Thin slices and narrow permissions limit the cost of a mistake.
Easy to continue
Memory and worklogs let a new session continue without searching for the same information again.
Consistent commands
People can use shortcuts while agents use predictable commands that produce the same result.
Independent proof
The verifier sees the diff and evidence, not the implementer’s confidence.
Tools for people and agents
Tools should make work easier to follow for people and easier to execute consistently for agents.
cmux + worktrees
See parallel sessions; isolate writes; supervise without interrupting.
f · s · changed
Fast human navigation and review, backed by fd, rg and plain Git.
RTK
Compress noisy command output before it consumes model context.
code-review-graph
Structural context, impact radius, affected flows and test relationships.
claude-mem
Cross-session observations and searchable project history.
Specs + rollups
Definition of done, verification plan, work ledger and measurable friction.
Four tools for four daily problems
A useful tool should solve a specific problem in our workflow.
cmux
A programmable macOS terminal built for multiple concurrent sessions, split panes, notifications and an embedded browser.
For us: supervision becomes visible. We can see which agent needs attention, inspect logs, open artifacts and keep independent tasks in separate workspaces.
RTK · Rust Token Killer
A CLI proxy that runs normal development commands and compresses their output before it enters an agent’s context.
For us: tests and diffs stay readable while repetitive success output disappears. The same commands cost less context and are easier to supervise.
code-review-graph
A local-first Tree-sitter knowledge graph that maps files, symbols, calls and tests, then exposes focused context and impact analysis through CLI/MCP.
For us: an agent can ask which flows or tests a change may affect instead of repeatedly reading broad parts of a repository.
claude-mem
A local persistent-memory system that captures session observations, compresses them and makes relevant history searchable later.
For us: decisions and discoveries can survive between sessions. A new session can start from previous evidence instead of repeating the same search.
Links open the official project pages. These tools are examples of the culture: find friction, adopt deliberately, instrument where possible, and keep only what improves real work.
RTK global usage
Fast feedback helps us check smaller changes more often.
When a search, test or diff is slow, we are more likely to switch tasks or group several changes before checking them. Faster feedback helps us stay focused and verify each change sooner.
52,073commands filtered
222.3Moutput tokens removed
64.5%overall token reduction
4.7saverage command runtime
Slow feedback causes more context switching, larger unverified changes and less frequent supervision.
Measured with rtk gain on 2026-07-13. “Tokens removed” means filtered terminal output, not model reasoning saved one-for-one.
Local context infrastructure
We use different tools to reduce terminal noise, select relevant code and remember previous work.
RTK removes unnecessary command output. code-review-graph helps an agent select relevant files and relationships. claude-mem keeps useful observations from earlier sessions. Each tool addresses a different context problem.
code-review-graph · 4 repositories
2,110files
19,831nodes
219,445edges
59,732test relationships
claude-mem · local history
39,574observations
1,020sessions
55projects
4,943summaries
Local snapshots measured 2026-07-13. Counts show available context, not causal productivity gains. That link still needs an experiment.
My standard workflow
Specification → implementation → verification
The harness is the collection of instructions, tools, state, permissions, checkpoints and evidence that turns a capable model into a repeatable engineering process.
In each-claude, acceptance criteria and the verification plan are written before implementation. Together they form a Validation Contract: the definition of what the code must prove.
SpecScope, constraints, non-goals, acceptance criteria and verification plan.
ExecuteOne thin vertical slice. Minimal diff. Evidence recorded at the boundary.
VerifyFresh context reads the spec, diff and checks. PASS, FAIL or BLOCKED.
Each role produces evidence for the next role. An implementation is not complete until it has been verified against the specification.
Published migration results
Implementation is sequential. Read-only research and independent review can run in parallel.
Sequential work is a correctness control, not a rejection of concurrency. Read-only exploration, documentation lookup and independent reviews can run in parallel. Shared implementation state advances only after the current slice is stable.
32sequential implementation slices
0parallel implementation writers
25 / 1 / 0verifier PASS / FAIL / BLOCKED decisions
10human approval gates resolved
We count an implementation slice as complete only after its verification step passes.
From “We Timed Our Coding Agents”: 34/34 production workflow definitions also passed definition-level parse, validation and planning. This was not yet legacy output parity.
A real example from the migration
All automated checks passed, but the design still failed an important production scenario.
Instance AStarts the async run and keeps state in memory.
→
Provider callbackReturns later, potentially after a restart.
→
Instance BCannot find the run → false 404 for completed customer work.
The independent verifier checked the production behavior described in the specification. The existing automated checks had only tested the local implementation.
Where the recorded time was spent
Most recorded time was spent locally, before CI or human review.
Code / Test816m · 43.8%
Info481m · 25.8%
Authoring229m · 12.3%
Orchestration196m · 10.5%
Wait141m · 7.6%
92.4%local work before remote wait
56.2%outside Code / Test
25.8%understanding and verification
7.6%waiting on CI, users or reviewers
Reconstructed estimates from current each-claude rollups; useful as an operational trend, not a controlled benchmark. The published article’s earlier aggregate was 92.5% local / 7.5% wait.
each-claude specification audit
The repository contains more execution logs, but many do not have complete time data.
31 / 90archive files added or updated in the last 14 days / total Markdown files currently in
specs/archive/52specification files with an Execution Log section
9non-duplicate logs with numeric values for all five time buckets
31h 03mtime recorded by those nine complete numeric rollups
How I gather the information
I read the specs and worklogs in each-claude, find the logs with numeric values for all five buckets, remove duplicate and placeholder rollups, add the minutes, and keep the collection limits visible. The nine complete rollups support the percentages on the previous slide; the 52 Execution Logs provide additional task, verification and outcome evidence.
Current local inventory of .claude/specs/. “31” is based on filesystem modification time within the last 14 days, so it means added or updated—not necessarily 31 newly completed tasks. Placeholder bucket tables and the shorter duplicate ENG-1832 spec rollup are excluded from the nine-task time total.
What the current data suggests
The data shows which parts of the workflow we should improve.
Reading is part of implementation
A quarter of the time is understanding and checking. Better indexes, local documentation and memory can reduce repeated work.
CI should confirm local work
Only 7.6% is remote wait. Most checking and correction happens locally before we use shared CI resources.
Review specifications early
A specification review can correct a design before implementation time is spent.
The verifier needs power to say no
Otherwise “independent review” becomes another confidence summary.
Sequential does not mean slow
It minimizes contaminated state, rework and merge ambiguity across slices.
The harness can also fail
Verifiers miss defects and overstep. Boundaries need code, logs and human supervision—not prompts alone.
Users and Workflows Migration (burak/eren)
Does a stronger model help more as the implementer or as the verifier?
This migration gives us a real task with meaningful data-integrity risk, clear boundaries and several comparable slices. Instead of assuming the strongest model should write the code, we can test whether a stronger model provides more value during implementation or verification.
Arm A
Stronger implementer · lighter verifier
- Same approved spec
- Same tools and context pack
- Same slice budget
- Fresh role contexts
vs
Arm B
Lighter implementer · stronger verifier
- Same approved spec
- Same tools and context pack
- Same slice budget
- Fresh role contexts
A final independent verifier compares both results without knowing which model setup produced them. The verifier used inside each arm does not evaluate its own result.
A simple comparison
Give both setups the same task and decide with the same checks.
What stays the same
The approved specification, tools, permissions, starting point and size of each task slice.
What changes
Which model implements the slice and which model verifies it.
What we record
First-pass acceptance, defects found, rework time, total time and human interventions.
How we decide
One final independent review compares both results. We choose the setup that produces more correct work with less rework.
Why a small improvement matters
If verified throughput improves by 20%, five developers could produce roughly the capacity of six.
Not faster typing
More accepted work at the same correctness bar.
Not a demo score
Measured across slices, rework, defects and human attention.
Not literally a hire
A capacity equivalent, subject to coordination and workload constraints.
What changes on Monday
Treat the harness as shared team infrastructure.
Ergonomics baseline
Fast search, fast checks, visible state, easy handoff, deterministic agent commands.
Weekly problem
Use rollups to choose one repeated source of friction instead of relying on the most recent complaint.
Correctness baseline
No “done” without a reproducible proof point tied to the spec.
Our improvement process: identify a recurring problem → try a small change → measure the result → document the useful approach → make it available to the team.
We should improve models, tools, instructions and verification as one workflow. We should use measurements to decide whether a change helped.
Discussion
What should we improve and measure next?
Which parts of our current agent workflow create repeated friction, and which experiment should we run first?
Public note: We Timed Our Coding Agents (opens in a new tab) · Internal sources: each-claude operating contract, incremental implementation skill, verifier protocol, current spec rollups.