OpenChamber 1.19.0 was released today, which makes this a good moment to take stock. I have used it almost daily since February 8. Along the way I have opened 99 issues, and since April 16 I have had 29 pull requests merged. I am still using it every day not because it is polished, but because its core loop earns the friction, and because when the friction gets bad enough, I can fix it myself.

What I use it for

#

OpenChamber is an app built around OpenCode: sessions, worktrees, chat, files, and terminals in one surface. My usage is narrow and deep. I run multiple agent sessions in parallel against the same repositories, and I let OpenChamber own the worktree management. Each session gets its own checkout and its own branch, and I steer all of them from one place. Six months of this setup adds up to roughly 2,430 sessions across 61 projects, 54,000 messages, and 3.8 billion tokens, on models that moved from GLM 4.7 to GLM 5.3.

Because OpenChamber is always open, it also works as a scratchpad. When a thought hits, I switch to the right project, write down a few lines, and let a session have a go at it. The 99 issues I mentioned were mostly built that way: I describe the problem, and the session turns it into a detailed issue, sometimes with a follow-up comment containing code investigation. An idea that would have died as a passing annoyance becomes an artifact, within minutes, inside the same window.

Input is also drifting away from the keyboard. I use Handy, a speech-to-text tool, more and more to talk to the agent, which speeds up iteration. And sometimes it is simply how the work continues while my hands are full, eating.

Iterating on ideas got a lot faster once trying a third approach meant spawning one more session instead of doing the stash-and-switch dance by hand. That single property is why I adopted OpenChamber and why I have not stopped. It is also the last part I would give up.

The reliability tax

#

The hardest part of these six months has been that the chat, the one component whose entire job is to hold a long-running conversation, was sometimes unreliable. The causes were varied. Sending a message to a session whose worktree was still being created blocked until the post-creation commands finished, so a message sent at the wrong moment just sat there. At other times the connection between OpenChamber and OpenCode dropped, and a few breakages were regressions in OpenCode itself that surfaced downstream in OpenChamber.

The text editor had its own stretch of problems. It glitched, and it regularly refused to open files it decided were outside the workspace or project, even when they were not. Both classes of problems got addressed over the months.

What still bothers me

#

My main gripe today is the terminal implementation. Terminal sessions end up closed on their own, which is exactly the failure mode a tool like this should never have, because a terminal holds state you cannot reconstruct. On Linux, opening the terminal sidebar sometimes shows nothing at all, and the workaround is creating another terminal.

The editing experience is my other daily friction. The early glitching got fixed, but typing and file navigation in the built-in editor remain clunky next to VS Code. OpenChamber also ships as a VS Code extension, which I have never tried, because the point of OpenChamber for me is steering agents from one surface, not living in two. The practical cost is that I keep an editor open to review diffs before commits and to look at code from time to time, which is exactly the habit I should be trying to break.

Two smaller issues have simply persisted for months. Project selection and filtering in dropdowns remain weak across the app. And the file matcher behind the @ helper is still really bad, which is annoying in a tool where pointing an agent at the right file is a core interaction.

Fixing it yourself changes the math

#

This is where the 29 pull requests matter. A bug in a closed tool is a wall: you file it, you wait, and meanwhile you work around it. A bug in an open tool you already run every day is just a task, and the more it bothers you, the faster it jumps your queue. My 99 issues and 29 merged pull requests are the same friction recorded twice, once as a complaint and once as a fix.

Merging is the part I control least. Getting a pull request adopted in the main repository sometimes takes real effort, and some of mine are still sitting open. Since I find those changes useful regardless, I maintain a local branch where I apply my unmerged pull requests and run ahead of upstream. The tool I use daily is therefore slightly my own build: official releases plus the fixes I was not willing to wait for. It is a small patch queue, the same idea as a distro carrying packages ahead of upstream, and it comes with the same obligation to rebase and drop patches once they land for real.

The relationship with the tool changes as well. I am no longer only a user deciding whether to stay or leave. I am a stakeholder: when a release like 1.19.0 ships with fixes from a handful of outside contributors, I read the notes looking for my corners of the app. That is a much better position than complaining in an issue tracker.

Should you use it

#

If you run one agent at a time in a terminal, you probably do not need OpenChamber yet. If you juggle several agents against the same repositories, parallel sessions plus automatic worktree management alone justify the setup cost, and idea iteration gets visibly faster. Go in expecting rough edges. Then check whether the edge that would bother you most is one you are willing to fix yourself, because that question decides what kind of experience you will have.

See also

#

• My AI Workflow - where OpenChamber sits in my overall setup and why the skills are the part that compounds
• Managing Many Concurrent LLM Agent Sessions - the supervision problem that running parallel sessions creates
• Verifying Code Without Reading It - the argument behind the diff-reading habit I should be breaking

References

#

• OpenChamber - the repository I have been using and contributing to
• OpenChamber 1.19.0 release notes - the release that prompted this retrospective
• OpenCode - the coding agent OpenChamber is built around
• git worktree - the mechanism behind per-session isolation

Your coworker opens pull requests faster than you can read them. Every morning the queue is longer than when you left. Their work piles up behind your name, and everyone can see whose approval is missing. You are not the bottleneck. The process that routes every change through one human reader is the bottleneck, and no amount of reading faster will fix it.

The setup is now ordinary. More than one in five code reviews on GitHub already involve an agent, and a developer driving an LLM can open ten plausible pull requests in the time it takes you to properly review two. The gap between arrival and departure is not a temporary spike. The gap is the new steady state, and it needs a structural answer from both sides of the queue.

The Math Ends Badly on Its Own

#

Review is a queue. Changes arrive at your coworker’s production rate and leave at your review rate. When arrival exceeds service, the queue grows without bound, which is the whole story of your inbox.

The instinctive response is to raise your service rate: read faster, review longer hours, take fewer breaks. Queueing theory says why that response fails even when it works. Kingman’s formula says that waiting time grows with variability divided by spare capacity, so as your utilization approaches one hundred percent, waits explode nonlinearly. A reviewer at eighty percent capacity has a manageable queue. The same reviewer at ninety-seven percent, which is what “keeping up” actually demands, has waits measured in days. A process that only functions when you are never tired, never in a meeting, and never sick is not a process; it is a countdown.

There is a second failure hiding behind the first. An overloaded reviewer does not stop reviewing, the reviewer degrades first. You skim. You approve what the tests already cover. You rubber-stamp the fourth pull request of the evening. The queue does not just grow, it silently stops protecting anything, because code merged by a rubber stamp feels reviewed without being reviewed. Rubber-stamped merges are worse than a visible backlog: the backlog at least admits the work is not being checked.

The Reframe

#

The useful lens here is the theory of constraints. A system’s throughput is set by its constraint, and the prescribed moves are to exploit the constraint (spend constraint time only on work only the constraint can do), elevate the constraint (add capacity or automation), and subordinate everything else to the constraint (upstream steps keep the constraint fed with work worth its time).

Read that list again with names attached. The constraint is you. Exploiting the constraint means your reading time goes only to changes that genuinely need human judgment. Elevating the constraint means automated gates absorb what does not need your eyes. Subordinating to the constraint means your coworker’s job changes: keep the queue full of cheap-to-judge, high-value changes instead of merely full.

Guilt is the wrong response to being the constraint, and so is heroics. Bottleneck is a role in a system, not a verdict on a person, and roles can be redesigned. The question stops being “how do I review faster” and becomes “what should be allowed to arrive at this queue at all, and how should the queue drain”.

What Your Coworker Should Do

#

When generation is cheap, producing more changes is trivial and producing mergeable changes is the actual work. Your coworker’s job is no longer to produce changes; the job is to produce changes that are cheap to say yes to.

Measure time-to-merge, not pull requests opened. A pull request that sits for a week is not output, it is inventory, and inventory that waits long enough rots into rebase conflicts and stale specs.

Concretely, every pull request should arrive with four things.

A specification written before the code. Acceptance criteria that existed before generation started, not a description reverse-engineered from the diff afterward. Reviewing a plan takes minutes; reviewing an unexplained implementation takes an hour, and the plan is where your disagreement is cheap.

Evidence that the change works. A failing test turned green by the fix, a before-and-after recording, a benchmark. A fix is not fixed until something independent of the model says so, which is the acceptance gap in miniature. Evidence converts your review from “verify by hand” to “check the verification”, and those tasks differ by an order of magnitude in cost.

An annotation of the risk. A self-review pass that flags the dangerous hunks, states the blast radius, and says which parts the coworker is unsure about. The risk annotation is the single highest-leverage habit of the four, because it tells you where your scarce attention belongs and proves a human actually read the output before demanding that you do.

A summary that enables a thirty-second judgment. What changed, why, what could break, how to roll it back.

Beyond per-PR discipline, two structural commitments matter more.

Respect a work-in-progress limit. At most two or three open pull requests at a time. When the cap is reached, the surplus capacity goes to writing tests, improving gates, and sharpening the next spec, not to opening a fourth PR that will age out in the queue. The most productive use of a fast producer’s spare time is reducing the review burden itself: gates, encoded conventions, and tooling that make every future change cheaper to judge, not just the producer’s own.

Stay attached after merge. Bugs in generated code route back to the generator for a window of time, because the person who captured the benefit of fast production should carry the first round of the cost.

What You Should Do

#

Your side of the contract is to stop being a per-diff reader and become the designer of how the queue drains.

Classify instead of read. A README typo and a schema migration are both pull requests and do not need the same gate. Compute blast radius and reversibility per change, auto-merge the low-risk class on green, and hold only the risky minority for human eyes. The majority of a flood is routine, and routine work is what machines are for.

Encode your recurring comments. Every review comment you have written more than twice is a gate you have not built yet. Complexity limits, dead code detection, coverage thresholds, forbidden dependency classes. Each encoded check is a category of attention you never spend again, and a category of queue pressure that disappears permanently.

Move your attention upstream. Review the spec before the code is generated, not the diff after. Ten minutes on a plan prevents an hour on a wrong implementation, and your disagreement lands while it still costs a conversation instead of a rework.

Match your coworker’s tools. Your coworker generates with a model; you triage with one. Running a first-pass review that flags anomalies, summarizes each diff, and ranks the queue by risk is not cheating, it is symmetrical. A pipeline where one side is machine-accelerated and the other is capped at human reading speed is broken by construction, whether the asymmetry is malicious or accidental.

Batch reviews into fixed windows. Two scheduled review blocks a day, instead of interrupt-driven approval sessions. Predictable service beats heroic bursts because Kingman’s formula punishes variability itself, and every interruption you remove shrinks the waits more than the raw time saved suggests.

Make the queue visible. Arrival rate versus service rate, time-to-merge, queue depth, on a dashboard both of you see. Numbers turn a feels-bad conversation (“you are slow”, “you flood me”) into an engineering conversation (“our arrival rate is triple our service rate, so we change one of them”).

What You Agree On Together

#

The fix is a contract, not a truce.

Define merge-ready: the checklist a pull request satisfies before it even enters your queue. Set the WIP limit at your sustainable service rate, and treat the limit as the throttle that keeps arrival below service. Agree on the escalation path for the small set of changes (the irreversible ones, the trust-boundary ones) that deserve synchronous human attention while your coworker waits. Agree on where surplus producer capacity goes when the queue is full, because idle generation capacity pointed at more PRs is how the problem restarts.

Then change what you both measure. The unit of team output is merged changes, not opened pull requests, and every metric that rewards opening over merging rebuilds the queue you just dismantled.

What to Do Next

#

Tomorrow, your coworker attaches the four things (spec, evidence, risk annotation, summary) to every new pull request, and you classify the existing backlog into auto-merge-gate versus needs-my-eyes, resolving nothing yet, just sorting.

This week, set the WIP limit and move your two most-repeated review comments into CI.

This month, make spec review the meeting that replaced diff review, and put time-to-merge on the dashboard next to queue depth.

The queue was never a verdict on how fast you read. The queue is a design decision your team made without noticing, and a decision made by accident can be made on purpose.

See also

#

• You Cannot Out-Review a Machine by Hand - the same queue math in its adversarial form, where the tooling asymmetry is deliberate rather than accidental
• The Merge Gate - how to classify changes by blast radius so only the risky minority needs a human approval
• Rethinking Code Review in the Age of LLMs - the case that judgment belongs upstream in specifications and gates rather than downstream in diffs
• The Acceptance Gap - what counts as independent evidence that a change works, the evidence your coworker should attach to every pull request
• Who Maintains the Slop? - why the generator must stay attached to the code after it merges, the ownership window this article’s contract requires

References

#

• Kingman’s formula - the queueing result that explains why waits explode as utilization approaches one hundred percent
• Theory of constraints - the exploit, elevate, subordinate framework applied to the reviewer as the constraint
• Queueing theory - the general study of arrival and service rates, the model underneath the review queue
• GitHub Blog, “Agent pull requests are everywhere” - the data showing agent-generated pull requests are already a large fraction of reviews

A counterparty who uses LLMs to generate changes, documents, and requests has a throughput you cannot match by hand. If they then forbid you from using LLMs to review that same work, they have not raised the quality bar; they have rigged the queue. You will fall behind, and the falling behind is the point.

The Setup

#

The pattern is specific. On their side, a model drafts the pricing changes, the proposals, the redlines, the spec revisions, the follow-up questions, faster and in greater volume than any human would produce alone. On your side, the same work arrives as items to read, reconcile, and answer. And somewhere in the engagement letter, the process doc, or the spoken rule, there is a line: review must be human, no AI.

The asymmetry is not accidental. One side of the pipeline is unbounded. The other is capped at the speed of a single person reading.

The Math Is the Problem

#

Review is a queue. Items arrive at the producer’s production rate and leave at your review rate. If production rate exceeds review rate, which it must when one side uses a model and the other does not, the queue grows without bound.

The only tool that could lift your review rate to match is the one being banned. A model can triage a hundred documents, flag the three that matter, and summarize the rest in the time it takes you to open the first one. That is exactly the capacity the rule removes from your side. Forbid the reviewer’s LLM and you have not protected quality; you have guaranteed the reviewer loses the race.

This is not a question of effort or discipline. No amount of reading faster, staying later, or caring more will close a gap between a human’s reading speed and a machine’s generation speed. The two rates are different categories.

The Rule Is Never Applied to Production

#

Every time I ask what justifies the rule, I get the same reasons. Quality. Confidentiality. “I want a real human looking at this.” Trust.

None of those reasons are applied to the producer. If quality required a human, the producer’s output would be human-written too. If confidentiality forbade a model, it would forbid the model on both sides. A rule that binds only the reviewer is not a rule about quality; it is a rule about leverage.

The tell is the asymmetry itself. A counterparty who genuinely believed human attention was the safeguard would insist on it for the work they send you, not only for the work you send back. When the standard runs in one direction, the standard is a tactic.

Flood Is an Old Tactic; LLMs Made It Cheap

#

Overwhelming a reviewer with volume is one of the oldest leverage moves in negotiation and review. Bury the clause, exhaust the reader, let fatigue do the accepting. It used to cost real effort to produce that volume, which capped the abuse.

LLMs removed the cap. Producing fifty variations, fifty justifications, and fifty follow-up questions now costs minutes and cents. The producer can flood at marginal cost while demanding the reviewer meet each item with marginal human effort. That is not a process; it is a denial-of-service on your attention, dressed up as a quality standard.

What Review Becomes on a Flood

#

Once the queue exceeds what a human can read carefully, the review degrades in one of two directions, and both favor the producer.

You triage, skimming for flags, and the unflagged majority passes unread. Or you tire, and you rubber-stamp. Either way, the work ships with less scrutiny than a smaller, human-paced batch would have received. The flood does not get reviewed more rigorously for being human-reviewed; it gets reviewed less, because humans have a finite attention budget and the producer is spending it for them.

The irony is precise. The rule meant to guarantee careful human review is the rule that guarantees there is not enough human attention to go around.

Push Back on the Symmetry

#

The fix is not to read faster. It is to refuse the asymmetric pipeline.

If they produce with a model, you triage with one, or the queue is illegitimate. Say it out loud, early, before the volume arrives. A review process is only fair when both sides have comparable tools on the queue.

Make the producer carry the cost of their own volume. Require a summary with every batch, written by them, stating what changed and what it means. Require structured, machine-checkable submissions instead of free-form documents. Cap the intake per day the way you would cap any rate-limited service. If the volume is genuine, the producer can absorb the cost of making it reviewable; if it is tactical, the requirement exposes the tactic.

And if the rule forbidding your LLM is non-negotiable, name it for what it is. It is a one-sided throttle, and agreeing to it is agreeing to lose on the schedule.

The Principle

#

Review is not a virtue test. It is a throughput match between two sides of a pipeline. Whoever sets the tooling asymmetry sets the outcome, and a reviewer forbidden the only tool that matches the production rate has already lost.

See also

#

• Keeping Up With AI Is a Losing Strategy - the same production-versus-consumption asymmetry, applied to reading the field; this piece applies it to a single adversarial counterparty
• Rethinking Code Review in the Age of LLMs - why line-by-line review of machine-generated work is low-leverage, the exact assumption the flood-and-forbid tactic exploits
• The Acceptance Gap - why “produced” is not “accepted”; the gap is precisely where a flood-and-forbid tactic hides items you never truly reviewed
• The Shifting Bottleneck - the constraint-moving pattern; here the bottleneck is deliberately pinned on the reviewer and frozen there

References

#

• Information overload - the long-standing name for the underlying problem, here weaponized rather than accidental
• Denial-of-service attack - grounds the metaphor: exhaust a finite resource (reviewer attention) by overwhelming it with cheap requests

A skill file is not done when it ships. The first version of a SKILL.md is a hypothesis: that this sequence of steps, sent to a model, will produce the result you want. Hypotheses get tested every time the agent runs, and most hypotheses fail in small ways you only notice on the fifth or tenth run. A skill is a depreciating asset, and the only thing that keeps it paying off is a deliberate loop you run on it after it ships: notice the failure, explain what happened to a fresh agent session, iterate with the agent on a patch, verify the patch, and periodically shrink the whole library back down.

The rest of this piece is that loop, in the order I run it.

Why skills decay

#

Three forces pull at a skill from the day you write it, and any one of them is enough to make a good skill go stale.

The model changes underneath it. A skill that was necessary to spell out every step for last year’s model is over-specified for this year’s model, and the over-specification starts to fight the model instead of helping it.

The task drifts. The repo layout moves, the tool’s CLI changes, the team’s convention evolves, and the skill keeps calling the old path.

And your own understanding improves. Six months after writing the skill, you know a shorter, cleaner way to express the same instruction, but the file still holds the first, clunkier version.

A skill that nobody touches is a skill that is quietly getting worse, because the world around it is not standing still.

Keeping Up With AI Is a Losing Strategy makes the same argument about filters: the asset you built at the last model generation may be miscalibrated for the current generation, and you will not notice because the failure is silent. Skills fail silently the same way. The agent still produces output. The output is just a little more wrong, a little more verbose, a little more off, and you compensate for the drift in your head without ever feeding the fix back into the file.

The loop

#

I run the same five-step loop on every skill, whether I noticed a failure today or I am doing a monthly sweep. The order matters, because each step is cheap only if the previous step ran.

My part of the loop is the noticing and the judgment. The diagnosing and the patching belong to the agent, and the split is the point: I explain, the agent analyzes, and the skill gets fixed without me becoming the bottleneck the loop exists to remove.

1. Notice the failure

#

A skill only improves when one of its failures gets explained, and most failures never get explained.

The default behavior after a bad run is to fix the output by hand, move on, and forget the skill was ever wrong. The hand fix is the failure mode, because the next run will produce the same bad output the same way, and you will apply another hand fix.

I do not keep failure notes, and I do not stop to work out what went wrong. When the agent produces something I have to correct, I open a new agent session and explain what happened: the bad output, what I expected instead, and which skill produced the run. The explanation is the whole capture. Explaining takes a minute, needs no template, and the session holds the failure so my head does not have to.

The rule is simple: if I had to correct the output, the skill has to hear about the correction.

The rule is the encoding loop from My AI Workflow turned outward. There, the rule was that every time I caught myself remembering to do something, the reminder became a skill. Here, the rule is that every time I catch myself correcting the agent, the correction becomes a session about the skill that produced the output. Both rules turn a private, forgettable moment into a durable, improvable artifact.

2. Explain it to a fresh session

#

The session has to be new, and the newness is doing real work. The session that produced the bad output is the worst investigator of the bad output, because the agent in that session is attached to the reasoning that went wrong. A fresh session reads the skill the way a new maintainer would, with no stake in the run that failed.

My message states what happened, not why. The bad output, what I expected instead, and anything about the run that surprised me. Then I let the session read the skill and tell me what went wrong, and the diagnosis lands on one of a handful of causes.

The skill was missing context the model needed. It referenced a file that was not in scope, or assumed a convention that was never stated.

The skill was over-specified. It pinned a step-by-step recipe that the current model does better on its own, and the pin is now producing worse output than letting go.

The skill was ambiguous. Two reasonable readings of the same instruction exist, and the model picked the wrong reading.

The skill called the wrong tool, or called the right tool the wrong way.

Or the failure was not the skill at all. The model was weaker than the skill assumed, the input was bad, or I asked for the wrong thing.

The diagnosis matters because each cause gets a different patch. Missing context gets added. Over-specification gets cut. Ambiguity gets rewritten with one clear reading. A wrong tool call gets corrected. And a failure that is not the skill’s fault gets parked, not patched, because editing a skill to compensate for a bad input is how skills accumulate defensive cruft they do not need.

Most skill decay is over-specification, not under-specification, and the instinct to add more instructions is usually wrong. The model is almost always more capable than the day the skill was written, and the smallest patch that fixes the failure class is very often a deletion.

3. Iterate to a patch

#

The agent writes the patch, and I iterate with the agent until the patch is right. My job in the session is judgment, not authorship: keep the patch aimed at the failure class, and keep the patch small.

The patch edits the SKILL.md, not the output.

The discipline is to patch the failure class, not the failing instance. A patch that fixes one bad run without addressing the kind of bad run is a patch that will be re-applied, in a different form, to the next bad run, and to the bad run after that. The skill accumulates special cases and never gets cleaner.

Each iteration should end with a smaller diff, not a bigger one. Add the one missing piece of context. Rewrite the one ambiguous sentence. Delete the step the model now does on its own. A small patch is easy to review and easy to revert if the patch makes things worse; a large patch that tries to fix the skill end to end is almost always a sign the diagnosis was incomplete.

The patch is also where the skill gets shorter, not just longer. If the session cannot make the failing skill better without also making the skill longer, the session is probably patching a symptom.

4. Verify

#

A patched skill is another hypothesis, and a hypothesis that is not tested is a guess.

The cheapest verification is to re-run the skill against the run that failed, and to read the new output for the specific problem the session was asked to fix. If the explanation captured the failure well, the check takes a minute.

For skills whose output can render, the pattern from Teach Your Agent Skills to Use Tools That Render pays for itself here. A skill that emits a diagram, a table, or a diff is a skill I can verify by looking, and looking stays cheap when reading the prose would bury me. A skill that emits only paragraphs is a skill I can only verify by reading, and reading is the bottleneck that started the whole problem.

For skills that touch code, the verification runs the project’s own checks. The linter, the type checker, the test suite. The skill does not need its own separate verification when the repository already runs these checks, the same way The Codebase Gardener leans on objective signals from the tools rather than on a human re-reading every diff.

A skill without a verification step is a skill that drifts back to broken the moment you stop looking.

5. Shrink or delete

#

Shrink-or-delete is the step most people skip, and also the step that matters most over the long run.

Every skill is a bet that the model cannot do the task reliably on its own. The models keep getting better. The bet that was correct when the skill was written is incorrect now for some percentage of the library, and that percentage grows every model generation.

When a skill’s failures have stopped, and the agent produces the right output from a prompt alone, the skill is no longer carrying its weight. The skill is scaffolding around a capability the model now holds on its own, and the right move is to take the scaffolding down, not maintain the skill.

My AI Workflow makes the same argument: the skills are a temporary scaffold for the gap between what the model can do today and what the model will do on its own tomorrow, and a good chunk of the work is knowing which scaffold to take down next.

Shrinking applies within a single skill too. A step that the model now does reliably on its own is a step that should leave. An instruction that only existed to work around an old model limitation is an instruction whose time is up. A skill that has not been shortened in six months is almost certainly carrying dead weight from a weaker model generation.

Deletion is not loss. Deletion is the most positive outcome a skill can have, because deletion means the model grew into the capability the skill was propping up.

The review sweep

#

One failure at a time is too slow a pace to keep a library healthy, the same way one pull request at a time is too slow a pace to keep a codebase clean.

I run a periodic sweep over the whole library, the same way The Codebase Gardener describes raking a codebase instead of chasing every leaf. The sweep is a small set of questions asked of every skill, not the deep rewrite of any one skill.

Which skills have I not edited in three months? Skills untouched for three months are the most likely to have decayed, because the world moved and the skill did not.

Which skills reference files, tools, or paths that no longer exist? Broken references are the cheapest bug to find and fix.

Which skills overlap with each other? Two skills that do almost the same thing should become one, because the duplication will drift and one will go stale while the other gets maintained.

Which skills did I not run at all this month? A skill that is never invoked is either redundant or forgotten, and both states are reasons to consider deletion.

Which skills did I run but correct every time? Skills that need correcting every run are the candidates for the next session.

A sweep takes an hour and pays for a quarter, because each finding is an iteration the per-failure loop would have taken months to surface.

Skills about skills

#

The loop has a recursive quality worth naming, because the recursion is where the compounding really lives.

The act of iterating on a skill is itself a repeatable task, and repeatable tasks become skills. I run a review-skills pass that does the sweep described above. I run an improve-skill pass that takes a single skill and proposes high-value, low-risk patches to the skill. The failure session from step 2 is the same move, held by hand: I supply the failure and the judgment, the agent supplies the analysis and the patch.

The recursion is the real multiplier. Once the iteration loop is itself a skill, the library improves itself at the pace the agent can run, not the pace I can read. I still make the calls, because deciding which patch lands and which skill gets deleted is a judgment the model does not yet make well. But the surface I have to hold in my head shrinks every time an iteration step is encoded, and the part I do myself narrows to the calls that genuinely need judgment.

The end state matches what The Self-Evolving Repository describes for codebases, applied one layer up: a library of skills that observes its own failures, proposes its own patches, and shrinks itself as the model grows, with the human left only at the checkpoint that needs taste.

What to Do Next

#

Pick one skill you have already run more than five times. Find the last run where you corrected the output. Open a new agent session, paste the bad output, and explain what you expected instead. You have just run steps 1 and 2 of the loop.

Then let the session read the skill and propose the diagnosis: missing context, over-specification, ambiguity, or the wrong tool call. Push the session until the patch is small and makes the skill shorter, and re-run the skill against the run that failed. You have just run steps 3 and 4.

If you cannot remember the last time a skill failed, you are either very lucky or, more likely, you have stopped noticing. Run a sweep instead. Open every skill, ask when the skill was last edited, and assume anything over three months old has decayed. You will be right more often than not.

And every quarter, ask which skills you can delete. The library that only grows is the library that is losing, because the library is carrying scaffolding for problems the model has already solved.

The goal is not a large library. The goal is a small library that is exactly the size of the gap between the model and the work, and a library that shrinks every time the model catches up.

See also

#

• My AI Workflow: The Skills Are the Part That Compounds - the case that skills are the durable asset, and the encoding loop this piece turns outward onto the skills themselves
• Teach Your Agent Skills to Use Tools That Render - the verification step of the loop, made cheap by rendering output instead of writing more prose
• The Codebase Gardener - the sweep pattern, applied there to a codebase and here to the skill library
• The Self-Evolving Repository - the end state when the iteration loop on skills is itself automated
• Keeping Up With AI Is a Losing Strategy - the argument that any filter built at one model generation must be re-audited, which is exactly what the skill sweep does

References

#

• tomzx/agents - the skills library this loop is run against, including the review-skills and improve-skill passes that operationalize the sweep and the patch
• Agent Skills format - the open skill format that makes each skill small enough to iterate on independently

You know the person. The meeting gets tense, their voice rises, maybe a fist lands on the table, and within a minute the room folds and they get their way. Later someone whispers “that’s just how they are” and the decision stands.

I never believed that framing. Temper at work is rarely just an emotional storm, it is a negotiation move, and the research on it is unusually clear: it extracts concessions from people who cannot walk away, it destroys value everywhere else, and it collapses the moment the target stops playing. Once you see it as a tactic, dealing with it stops being therapy and becomes strategy.

The Outburst Is Making an Argument

#

Start with the finding that explains why the behavior persists: anger works, in the short term, on the people it is aimed at.

In a series of classic experiments, negotiators who were told their opponent was angry conceded more than negotiators who were told the opponent was happy (Van Kleef, De Dreu & Manstead, 2004). The interesting part is the mechanism. The targets were not scared into submission; they did the math. They read the anger as information about the opponent’s limit, concluded the opponent would not move, and adjusted their demands to avoid impasse. Related experiments found that angry negotiators win larger concessions from their counterparts (Sinaceur & Tiedens, 2006).

Anger also buys status. Across four studies, people who expressed anger were judged more competent than people who expressed sadness, and observers conferred higher status and even higher salary offers on them (Tiedens, 2001). We read anger as confidence, and we promote what reads as confidence.

So the person yelling in the meeting is running a computation that has paid out for years: volume signals a hard limit, the limit signals competence, and everyone else absorbs the cost of avoiding the fight. Expecting them to stop out of politeness is expecting them to abandon a winning move.

Where the Tactic Stops Working

#

The same literature that shows anger working also shows precisely where it fails, and the boundary matters more than the effect.

First, the signal only works while the behavior is consistent with it. In the 2004 experiments, when the “angry” opponent started making large concessions, the effect vanished; targets stopped trusting the display and went back to their own numbers (Van Kleef et al., 2004). Anger is an argument about a limit, and any behavior that contradicts the argument wins.

Second, the tactic depends on who is receiving the anger. When researchers pitted anger against power, low-power participants conceded to an angry adversary regardless of whether the anger was appropriate, but high-power participants confronted with inappropriate anger retaliated and demanded more, not less (Van Kleef & Côté, 2007). Anger extracts value downward and invites punishment sideways or upward.

Third, field data from hundreds of real online dispute mediations found that anger expression lowered resolution rates overall, in significant part because it triggered angry responses from the other party; only when the counterpart was especially vulnerable did the anger fail to hurt the expresser’s outcome (Friedman et al., 2004). In relationships that continue past the transaction, anger mostly burns the expresser.

And the flow is almost entirely one-directional. Sutton summarizes the frequency data in The No Asshole Rule: perceived nastiness is estimated to run downward (boss to subordinate) in 50 to 80 percent of workplace occurrences, versus roughly 1 percent upward. Interview studies of workplace anger episodes found the same asymmetry from the other side: subordinates were the least likely to confront the target of their anger and the most likely to consider the incident unresolved (Fitness, 2000).

Aggression survives on a power gradient and on the target’s silence, which is why the people who use it are so often leaders and so rarely peers.

The Bill You Do Not See

#

The defense of these people is always the same: they get results. The research says their results are borrowed against a balance sheet nobody reads.

The founding study of abusive supervision followed 712 employees and found that those who perceived their supervisor as abusive were more likely to quit, and the ones who stayed showed lower job and life satisfaction, lower commitment, and depressed perceptions of justice (Tepper, 2000). Fifteen-plus years of follow-up research, synthesized in Tepper’s Annual Review, established the pattern as one of the most robust in organizational psychology. The abuse also cascades: managers mistreated by their own bosses go on to mistreat their subordinates (Mawritz et al., 2012).

If you think that is soft-outcome stuff, the hard-outcome studies are worse. Researchers randomized 24 neonatal intensive care teams to either neutral comments or a few mildly rude remarks from a visiting “expert,” rudeness deliberately unrelated to the team’s actual performance. The rudeness-only teams’ diagnostic and procedural performance dropped significantly (2.6 vs 3.2 and 2.8 vs 3.3 on the judged scales), with rudeness alone explaining nearly 12 percent of performance variance. The cause was social: the teams stopped sharing information and asking each other for help (Riskin et al., 2015). A few sentences of mild rudeness measurably degraded how well expert teams saved babies, and the mediators were exactly the collaborative behaviors an angry leader suppresses.

Then the rudeness spreads. Witnessing rudeness makes people more likely to judge ambiguous behavior as rude and to behave rudely themselves (Foulk, Woolum & Erez, 2016). Witnesses of bullying report increased stress and fear of becoming targets (Sutton). Prevalence data suggests nearly everyone experiences incivility: across 14 years of polling, 98 percent of workers reported uncivil behavior, and by 2011 half reported being treated rudely at least weekly, up from a quarter in 1998 (Porath & Pearson, HBR).

The aggressor’s visible win is real, but it is financed by invisible withdrawals from everyone else’s judgment, information flow, and retention.

Why They Do It

#

Two findings changed how I read these people.

The first is causal: power plus felt incompetence produces aggression. Across studies, people with power who doubted their own competence were the most aggressive toward subordinates, and competent subordinates were the preferred targets of their put-downs (Fast & Chen, 2009). The boss who lashes out at the strongest engineer in the room is often running from exactly that engineer’s competence.

The second is Sutton’s distinction between the temporary and the certified asshole: someone having a bad day versus someone “persistently nasty” who leaves targets oppressed and humiliated and aims at people less powerful (The No Asshole Rule). The distinction matters because the responses differ. A bad day deserves grace; a pattern is a system that will keep harvesting concessions until someone changes the price.

Read aggression as information: it tells you the person’s other tools are insufficient for the situation, which is exactly why the tactic concentrates at the top, where it is tolerated, and among the insecure, where it is needed.

The Playbook

#

The research maps to a small number of concrete moves.

1. Separate the claim from the volume. The outburst is an argument that a limit has been reached. Answer the argument, not the volume: ask what specifically is unacceptable, what they need, and what would change their position. Asking those questions works because the mechanism is inference; when you engage the substance and your own behavior contradicts the “hard limit” reading, the display loses its informational value (Van Kleef et al., 2004).

2. Do not reciprocate. The field evidence is unambiguous that reciprocated anger is what destroys outcomes (Friedman et al., 2004). Matching their tone converts a solvable disagreement into a status fight, and status fights involving a leader have exactly one winner available. Stay slow, stay concrete, and let the asymmetry between your tone and theirs become visible to the room.

3. Name the behavior once it crosses the line. The dual threshold model of anger in organizations distinguishes an expression threshold (communicate rather than suppress) from an impropriety threshold (display that violates norms and starts doing damage) (Geddes & Callister, 2007). Functional anger sits between the thresholds; the table-pounder lives beyond the second one. Naming it does not have to be dramatic: “I want to solve this, and I need you to lower your voice so we can” is a boundary, not an attack. The key is to do it early, because subordinates who swallow anger consistently rate their incidents unresolved, and unresolved incidents compound (Fitness, 2000).

4. Attack the dependency, not the person. Anger extracts concessions from those who cannot walk away and invites retaliation from those who can (Van Kleef & Côté, 2007; Friedman et al., 2004). The practical translation is simple: build alternatives. Document your contributions where others see them, cultivate sponsors outside your reporting line, keep your skills portable, keep your savings real. You do not need to quit to be less dependent; you need the aggressor’s threat model about you to weaken. Half the power of the tactic evaporates the day they are no longer sure you would stay.

5. Contain the contagion. If you manage anyone exposed to the aggressor, protect their collaborative behavior deliberately. Debrief the incident, keep information flowing, and make help-seeking explicitly safe, because those are the two channels rudeness shuts down first (Riskin et al., 2015; Foulk et al., 2016). Teams absorb an aggressor’s mood by default (Sy, Côté & Saavedra, 2005); somebody has to interrupt the absorption.

6. If you have organizational power, make it a firing matter. The strongest evidence-based organizational response is also the bluntest: refuse the trade. Netflix’s culture memo says it in one line: “No matter how brilliant someone may be, there’s no place in our Dream Team for people who don’t treat their colleagues with decency and respect” (Netflix culture memo). Sutton’s cost arithmetic (he calls it Total Cost of Assholes: HR hours, turnover, witnesses’ lost productivity, legal exposure; one executive’s estimate for a single engineer ran to about $160,000 a year) exists so leaders stop pricing these employees by output alone (The No Asshole Rule). And the ground must be safe before anyone will name the problem: Google’s Project Aristotle found psychological safety the most important of the five dynamics separating its effective teams from the rest (Duhigg, “What Google Learned From Its Quest to Build the Perfect Team”). Psychological safety is precisely what a chronic aggressor destroys.

What to Do Next

#

Pick the next encounter and prepare one sentence for it. Something like “I will engage with the problem when we can discuss it calmly,” said once, neutrally, and then silence.

Inventory your dependency while calm: who else knows your work, how portable are your skills, how many months of runway do you have. The inventory is not defeatism; it converts you from a low-power target, the only kind this tactic works on, into a high-power one.

Write down the incidents, dates included. Patterns need data, and data is what turns “I feel uncomfortable” into a case a leader or HR can act on.

And if you have power over one of these people, stop asking whether they are worth the trouble and start computing what they cost; the research says the invoice is much larger than their manager has ever seen.

See also

#

• When Engineers Disagree on Best Practices - the team-level counterpart: how one resolved disagreement sets the template for whether the loudest person wins from then on

References

#

• Van Kleef, De Dreu & Manstead, “The Interpersonal Effects of Anger and Happiness in Negotiations” (2004) - the mechanism: targets concede to anger because they infer a tough limit
• Van Kleef & Côté, “Expressing Anger in Conflict: When It Helps and When It Hurts” (2007) - the boundary: low-power targets concede, high-power targets retaliate against inappropriate anger
• Friedman et al., “The Positive and Negative Effects of Anger on Dispute Resolution” (2004) - field evidence that reciprocated anger destroys resolution rates
• Tiedens, “Anger and Advancement Versus Sadness and Subjugation” (2001) - anger reads as competence and earns status and salary
• Sinaceur & Tiedens, “Get Mad and Get More Than Even” (2006) - angry negotiators win larger concessions
• Tepper, “Consequences of Abusive Supervision” (2000) - the founding study of what abusive bosses do to retention, satisfaction, and commitment
• Riskin et al., “The Impact of Rudeness on Medical Team Performance” (2015) - randomized evidence that mild rudeness degrades expert teams’ diagnostic and procedural performance
• Foulk, Woolum & Erez, “Catching Rudeness Is Like Catching a Cold” (2016) - rudeness is contagious
• Mawritz et al., “A Trickle-Down Model of Abusive Supervision” (2012) - abuse flows down the hierarchy
• Fast & Chen, “When the Boss Feels Inadequate” (2009) - power plus felt incompetence predicts aggression toward competent subordinates
• Geddes & Callister, “Crossing the Line(s): A Dual Threshold Model of Anger in Organizations” (2007) - the expression/impropriety threshold model used in the playbook
• Fitness, “Anger in the Workplace” (2000) - interview evidence that subordinates suppress anger and leave incidents unresolved
• Tepper, Simon & Park, “Abusive Supervision” (2017) - the 15-plus year synthesis of the abusive supervision literature
• Sutton, The No Asshole Rule (2007) - the practitioner frame: recognition tests, certified vs temporary, and the Total Cost of Assholes
• Porath & Pearson, “The Price of Incivility” (2013) - prevalence trend data on workplace incivility
• Netflix culture memo - the reference policy rejecting brilliant people who fail the decency bar
• Duhigg, “What Google Learned From Its Quest to Build the Perfect Team” (2016) - Project Aristotle: psychological safety was the most important of Google’s five team-effectiveness dynamics

For most of the internet’s life, the rule was simple: make something good, put it somewhere findable, and the channels would carry the rest. That rule assumed a scarcity that no longer holds. When a model can draft a competent essay, tutorial, landing page, or thread in seconds, the supply of “good enough” writing goes effectively infinite, and good stops being the thing that gets you noticed. The scarce thing has moved upstream, from content to the trust that lets any single reader pick your work out of the flood.

The Flood Has Two Sides

#

A flood that is impossible to read is also a flood that is impossible to be read in. These are the same problem seen from opposite ends.

The reader’s version is a filtering problem: too much coming at you, too little time to sort it (see Keeping Up With AI Is a Losing Strategy). The maker’s version is a discovery problem: your work is one drop in a self-replenishing ocean, and the ocean refills faster than anyone can drink.

The root cause is identical. As Herbert Simon put it half a century before LLMs, “a wealth of information creates a poverty of attention.” What changed is that the wealth of information stopped requiring people to produce it, so the supply curve bent from steep to vertical. Attention did not scale with it. That leaves every creator competing for a fixed resource against a supply that has no ceiling.

“Good” Is Now the Floor

#

It used to mean something to publish clear, well-structured, useful writing, because producing it took time, skill, and effort, and that effort was itself a signal. When the median post can be generated in seconds and is, on the surface, as clean as anything a careful human would ship, clarity and structure stop signaling much. They become the default, the price of entry, the thing readers expect and immediately forget.

This is Sturgeon’s law (“ninety percent of everything is crud”) with the dial turned up: not only is most content mediocre, but the mediocre is now polished enough to pass for good, which forces readers to assume everything is mediocre until proven otherwise. The practical effect is that competence no longer earns attention; it merely avoids an immediate bounce. You cannot out-write the flood, because the flood is now competently written.

Compete on What Cannot Be Generated

#

If the surface layer is commoditized, the advantage moves to the layers a model cannot generate, and almost all of them are slow, specific, and human. Kevin Kelly named these the “generatives” in Better Than Free: the qualities that stay valuable precisely because copies are free. His list, written in 2008 about an earlier wave of abundance, maps almost perfectly onto the problem of being noticed now. Four of them do most of the work.

Authenticity is the sense that a real, specific person made this for a reason they will stand behind. A model can imitate a voice, and even the surface texture of the life behind it: a recorded mistake, a hard-won opinion, a detail only someone who was there would notice. What it cannot provide is the underlying record that makes those details checkable, which is why authenticity has to be backed by proof rather than merely asserted (see Proof of Work, below).

Embodiment is the version of the work that lives in the physical, social world: a live talk, a conversation, a workshop, a thing you can point to in a room. It cannot be copied at all because it is not made of text, and it is where the strongest trust gets built.

Personalization is work tuned to a specific reader or community rather than aimed at everyone. The flood is generic by construction; anything that clearly was not, anything that names a particular reader’s problem in a particular context, stands out against it by contrast alone.

Findability is the quality most creators neglect, and the focus of this whole article. As Kelly wrote, “when there are millions of free things requesting our attention, being found is valuable.” In a flood, distribution is not the layer you add after the work is good; it is the work.

Proof of Work Is the Signal That Survives

#

If readers now assume competence is fake by default, the only thing that reliably breaks through is evidence that a real person actually did the thing behind the writing. Call it proof of work, borrowing a term from systems where trust is established by demonstrating costly effort rather than by asserting it (proof of work).

The tempting version of this claim is that the right story reads as authentic and therefore cannot be faked. It does not survive contact with the models. A fabricated postmortem with specific-sounding numbers, a plausible failure chain, and the right tonal markers passes most readers’ filters, because few will check whether the project existed, whether the numbers are real, or whether the author lived it. The cost asymmetry the argument depends on, expensive to produce but cheap to verify, inverts: the story is now nearly free to generate, verification still costs real effort, and readers rarely pay it.

What cannot be faked at scale is not the story but the record it claims to sit on. A real project leaves a wide trail, commits, issues, deployed systems, other people who remember it, a history you can point to. The postmortem itself is cheap to hallucinate; the artifacts it references are not. The durable signal is not “does this read like lived experience” but “can I trace it to something independent of the author’s word,” and that is a harder bar than most writing clears.

That bar is why the familiar examples carry weight only when they are traceable. A postmortem of a project that failed, with real numbers and real reasons, matters if you can link the project, the commit that introduced the bug, the incident report. An experiment you actually ran, with setup and outcome, matters if the setup is reproducible and the data is there. A thing you built and genuinely use matters if the repository exists, has a history, and other people can run it. Strip the traceability and the same sentences are indistinguishable from hallucination. Proof of work is not a quality you can write into a paragraph; it is a verification surface you either leave behind or do not, and the cost that makes it trustworthy is paid in building that record, not in describing it.

Proof of work is the producer’s version of the moat argument elsewhere on this blog: when the easy-to-copy layer is free, the advantage relocates to the layers that compound through time and cannot be cloned (see Feature Parity Is Not a Moat). For a creator, those layers are a track record, a body of specific work, and the relationships built around it.

Be a Source, Not an Echo

#

Most generated content restates things other people already said, which means most of the flood is echo. The way to stop being part of the flood is to be the thing it is restating.

A source is someone who produces a fact, an observation, a measurement, an argument, or a story that did not exist in that form before they wrote it. An echo is everyone, human or machine, who restates it. The flood is almost entirely echo, which means even a small amount of genuine source material stands out clearly against it.

The lever is to bias every piece toward the thing only you could have written: the result you observed, the mistake you made, the opinion you hold and can defend, the specific reader you are addressing. Narrow beats broad here, because narrow is where specificity lives and specificity is what an echo cannot manufacture. A durable body of narrow work also compounds: ten pieces on the same corner of a problem make you the address for that problem, where ten unrelated pieces make you another drop.

Relationships Are the Distribution Layer That Does Not Saturate

#

Every algorithmic channel is now full, and getting fuller, and the curve points one way. The one channel that does not saturate the same way is direct human relationship, the small set of people who know you, trust your work, and pass it on because they want to.

These are not “followers” in the metric sense; they are the thin layer of real acquaintance, parasocial or otherwise, that turns “I made a thing” into “someone I trust made a thing.” Trust is the only distribution medium that the flood dilutes more slowly than it dilutes everything else, because trust cannot be manufactured by a model either. This is why the unglamorous work of replying, citing, collaborating, and showing up over years outperforms any broadcast tactic in a saturated feed. It is also the version of distribution that compounds, while a clever hook compounds for about a day.

The Bottleneck Moved to Trust

#

The uncomfortable reading of all this is that “make good things” was never the whole strategy; it was a strategy that worked while good things were scarce. They are not scarce anymore, and they will not be again.

What is scarce, and getting scarcer, is the trust that lets a reader choose one piece out of a million. Trust is built only from the inputs a model cannot generate: your time, your experience, your track record, and your relationships. Getting noticed in the flood is not a louder version of the old playbook; it is the decision to stop competing on the layer that went free, and to put everything onto the layers that never will.

What to Do Next

#

Stop optimizing for volume. Posting more into an infinite stream makes you more of the stream, not more visible inside it, and the marginal post now competes with machines that post faster, for free.

Bias every piece toward proof of work. If a reader cannot tell whether a real person did the thing behind the writing, they will assume not, so leave a verification surface they can actually check: link the repository, the data, the incident report, the commit, so the claim rests on something independent of your word rather than on how lived the prose sounds.

Write what only you can write, and narrow until that is true. Specificity is the cheapest signal that survives generation, and a narrow, durable body of work is what makes you the address for a problem instead of a drop in the flood.

Treat distribution as the work, not the afterthought. Findability is a generative in its own right, and in a flood it is the generative that decides whether any of the rest gets read.

Build the channels that do not saturate. A small set of real relationships, maintained over years, will carry your work further than any algorithmic tactic, and it is the one distribution layer a model cannot generate.

See also

#

• Keeping Up With AI Is a Losing Strategy - the reader’s side of the same flood; this article is the producer’s mirror image
• Feature Parity Is Not a Moat - when the copyable layer is free, advantage moves to layers that compound and cannot be cloned, the same relocation trust depends on
• The Shifting Bottleneck - the pattern of the constraint moving one level up whenever a lower one is automated, here from content production to trust

References

#

• Attention economy (Wikipedia) - Simon’s “a wealth of information creates a poverty of attention,” the root framing for why a content flood is a trust problem
• Kevin Kelly, “Better Than Free” - the “generatives” that stay valuable when copies are free, including authenticity, embodiment, personalization, and findability
• Sturgeon’s law (Wikipedia) - “ninety percent of everything is crud,” sharpened here by the fact that the crud is now polished enough to pass for good
• Information overload (Wikipedia) - the long-standing name for the reader’s condition this article takes as its starting point
• Proof of work (Wikipedia) - trust established by demonstrating costly effort rather than by assertion, the property that lets real work stand out against generated content
• Parasocial interaction (Wikipedia) - the one-to-many relationship layer that distributes work without saturating the way algorithmic feeds do

The cheapest upgrade I have made to an agent skill was not a better prompt or a bigger model. It was teaching the skill to emit a mermaid diagram instead of a paragraph. Once the skill could draw, I could check its work by looking instead of reading, and looking is the one verification that stays fast when the prose has buried you.

The highest-leverage thing you can do to an agent skill is wire it to a small tool that renders, because a rendered artifact moves verification from reading to looking, and looking is cheap, fast, and hard to fool.

Why prose-only skills plateau

#

A skill that only writes prose hands you prose to verify. Prose asks you to read, and reading is exactly the bottleneck that working with agents moved into the foreground: the scarce, serial, finite attention you have left once generation became free (Attention Engineering).

The trap is that prose feels productive to generate and expensive to check. The agent writes a fluent paragraph describing the data flow, the spec, or the migration plan, and you skim it and approve it, because reading it carefully would cost more attention than you have. A skill that outputs only text is a skill that can only be checked by the slowest checker you own, and the one that tires first, which is you, reading.

The pattern: pair the skill with a tool that renders

#

The fix is to give the skill a tool that turns text into something you can inspect at a glance. The tool does the deterministic part, the layout, the rendering, the syntax checking, and the skill does the generative part, deciding what to put in the diagram. The concerns separate cleanly, and the output becomes inspectable in a way prose never is.

Pairing a skill with a renderer is the same move as Verifying Code Without Reading It, applied to the artifacts a skill produces: stop trying to read, start trying to verify, and pick for each artifact the cheapest checker that catches the failure you care about. For a lot of artifacts, the cheapest checker is a picture.

Mermaid in the SDLC process

#

I started adding mermaid diagrams to my SDLC skills, and the payoff was immediate. A plan that used to be three paragraphs of “first we do this, then that, and this component talks to that one” now ships with a sequence diagram. A spec now ships with a state diagram or a flowchart of the happy path.

The diagrams fail in ways prose hides. A sequence diagram with a message that has no receiver makes a missing step obvious. A flowchart with two boxes that both claim to write the same column makes a race condition visible before a line of code exists. The wrong diagram is obvious in two seconds; the wrong paragraph is buried in the fourth reading, if it ever surfaces.

Mermaid is the right tool for a skill for three reasons. It is text, so the agent generates it directly, the same way it generates any other output. It renders natively where the work already lives, because GitHub renders ```mermaid blocks in Markdown and most static site generators do too. And it diffs cleanly, because the source is text, so a change to the plan shows up in the pull request as a diff you can review instead of a picture you have to compare by eye.

Text-based tools are the sweet spot for skills

#

The mermaid case generalizes into a rule I now follow. When you pick a tool for a skill to drive, prefer a text-based one, because text is the medium the agent speaks, the medium git tracks, and the medium that renders to the artifact you inspect.

DBML is the database-schema version of the same idea. It is a small markup language for tables, columns, and foreign keys, and a few lines of it render to a full entity-relationship diagram on dbdiagram.io. A skill that describes a schema now emits DBML, and I see the structure of the data model, the missing relationship, the redundant table, before I have read a single column definition.

The text basis is what makes it fit an agent workflow. The agent writes DBML the way it writes code, the file lives next to the migration that creates the tables, it reviews and diffs like code, and the rendered diagram is a view on top of it rather than a separate artifact that drifts. When the schema changes, the DBML changes in the same commit, and the diagram is never stale.

Where the visual tool fits: on the human side

#

Preferring text-based tools does not mean GUI tools have no place. drawdb is the mirror image of DBML: a browser editor where you drag tables and draw relationships by hand, and it exports the SQL for whatever you sketched.

The division of labor that works for me is to let the agent drive the text-based tools and let myself drive the visual ones. I sketch in drawdb when I am still figuring the model out, when I want to move boxes around and feel my way through the design, and then the SQL/DBML it exports becomes an input the agent works from. I let the agent drive DBML when the schema is already decided and I want a rendered view of it inside the repository. Text-based tools go in the skill, where the agent is fast and generation is cheap; visual tools go in my hands, where exploration is slow and taste is required.

How to pick the next tool to wire in

#

Three tests decide whether a tool is worth wiring into a skill.

The tool must be text-based, or have a text representation the agent can produce. The whole pattern breaks if the agent cannot generate the source the renderer consumes.

The tool must render to something inspectable, a diagram, a table, a diff, a graph. If the output is still prose, you have added a dependency and gained no new kind of check.

And the tool must be narrow enough that the skill can use it reliably. Mermaid and DBML win here because they are small languages with a fixed grammar, not sprawling APIs the model has to guess at. A tool the model gets wrong half the time is worse than prose, because you spend your attention debugging the tool instead of the idea.

What to Do Next

#

Pick one skill you already run that emits prose and teach it to render. If it describes a flow, teach it mermaid. If it describes data, teach it DBML. If it describes a sequence of messages between components, teach it a sequence diagram.

Then read the next output it produces as a picture instead of a paragraph, and notice where your eye catches in two seconds what your reading would have missed in twenty minutes. That gap, between the cost of looking and the cost of reading, is the whole reason to give your skills tools that render.

See also

#

• My AI Workflow: The Skills Are the Part That Compounds - the case that skills, not models or shells, are the durable asset, and the library where these examples live
• Verifying Code Without Reading It - the larger pattern this applies to artifacts: replace one slow reader with many cheap, tireless checkers
• Attention Engineering - why reading is the bottleneck a prose-only skill quietly pushes onto you
• The Importance of Context When Interacting with LLMs - why a text-based, versioned artifact you can both see beats a transcript as shared context

References

#

• Mermaid - text-based diagramming that renders in GitHub and most docs, the tool I wired into the SDLC skills
• DBML syntax - a markup language for database schemas that renders to entity-relationship diagrams
• dbdiagram.io - the renderer for DBML, where the text turns into a diagram
• drawdb - a browser-based visual ER editor for sketching schemas by hand and exporting SQL

Producing sentences was never the part that made writing worth reading. When a model can produce clean, well-structured prose about anything in seconds, the value of an author stops being the prose and comes down to the one thing the model cannot supply: a reason the words should exist at all.

Writing Was Always Two Jobs

#

For as long as writing was hard, two very different jobs were fused inside it. One was mechanical: choosing words, ordering sentences, hitting the register a reader expects. The other was everything that made the writing worth a stranger’s time: deciding what was true, which detail mattered, what to assert and what to leave out, what claim I would stand behind if someone pushed back.

The two jobs looked like one task because the same person did both, and because the judgment was invisible unless the prose was done well. LLMs did not replace the author; they split the author in two and automated only the half that was always the easier one to learn.

The Model Is Fluent and Has Nothing to Say

#

A model trained on the corpus of everything humans have written can generate plausible text on any subject, and that fluency looks like understanding from the outside. It is closer to a lossy compression of everything already said, as Ted Chiang argued in calling ChatGPT a “blurry JPEG of the web”.

The model can only recombine what exists; it has nothing of its own to add. It has not run the experiment, taken the risk, held the opinion, or been wrong in public and had to fix it. Fluency without experience produces prose that could have been written by anyone, which is exactly the prose the internet now has too much of.

What the Author Brings That the Model Cannot

#

Four things do most of the work, and each is scarce for the same reason: it is paid for in something other than typing.

Something to say. A real piece of writing starts from an observation, a result, a mistake, or a conviction that did not exist in the corpus in that form. The author has lived something the model has not. The trace of that experience, a number that was actually measured, a failure that actually happened, a stance the author will defend, is the only material the model cannot manufacture.

Judgment about what is true. The model will produce a confident answer either way, which is why its confidence is worth almost nothing as a signal. An author commits: this is right, this matters, this is the claim I am making. That willingness to be wrong, narrowing a general cloud of plausibility down to one assertion a reader can check or reject, is the act the model cannot perform, because the model has no stake in being correct.

Stakes and accountability. Writing with a name on it can be wrong, criticized, quoted against its author, and remembered. That risk is precisely what gives the words weight to a reader, who is deciding whether to trust a person, not a process. A model has nothing to lose from a false sentence: the sentence costs it nothing, costs an author something, and readers sense that asymmetry even when they cannot name it.

The thinking that writing forces. Writing is not the transcription of finished thought; for most authors, myself included, it is how the thought gets finished at all. Offload the whole job and I keep the artifact but lose the part that changed me, the slow, uncomfortable work of discovering what I actually believe by being forced to say it precisely.

The Trap of Offloading the Wrong Half

#

Prose generation is so cheap and so good that I am tempted to also let the model decide what to say, and then edit a draft into something shippable. Let the model choose the claim on every piece and the work becomes indistinguishable from the flood, because the work is the flood, recompressed from the same corpus by a slightly different prompt.

The moment you let the model choose the claim, you have stopped being the author and started being the first reader of the model’s writing. That arrangement produces a thinner kind of work, the kind that does not earn the trust that makes anyone return.

The useful line is not “human-written” versus “AI-written,” and never was (see Written by for how this blog labels AI involvement). The useful line is whether a human mind made the decisions that determine whether the piece is worth reading: what to assert, what to omit, what experience anchors it, and whether the claim is one the author will stand behind.

What to Do Next

#

Decide what the piece is for and what claim it is making before the model writes a single sentence, because that decision is the work and the prose is downstream of it.

Anchor every piece in something the corpus does not contain. A measurement you took, a failure you caused, an opinion you hold and can defend, a reader you are specifically addressing, is the only material that keeps the writing from being echo.

Put your name behind it and mean it. The accountability is not a cost you pay for publishing; it is the source of the weight the writing carries. A reader can feel its presence or absence in the first paragraph.

The prose is now the cheapest output. The judgment behind it is the entire product.

See also

#

• Getting Noticed in the LLM Flood - the producer’s mirror of this piece: once the writing is good enough to be the floor, attention moves to trust and distribution
• The Shifting Bottleneck - the pattern of the constraint moving one level up when a lower one is automated, here from prose production to judgment
• The Acceptance Gap - the parallel problem in code: the model produces, deciding it is acceptable is the human part that stays
• Written by - this blog’s disclosure policy, which exists because the author-versus-echo distinction matters
• Keeping Up With AI Is a Losing Strategy - the reader’s side: why more fluent content is the wrong thing to optimize for

References

#

• Ted Chiang, “ChatGPT Is a Blurry JPEG of the Web” - the model as lossy compression of the corpus, which is why it can recombine but not originate
• Sturgeon’s law (Wikipedia) - “ninety percent of everything is crud,” sharpened by the fact that the crud is now fluently written
• Lossy compression (Wikipedia) - the technical basis for why generated prose is a recompression of what already exists

Generation stopped being the expensive part of working with LLMs. You describe, the model produces, and a plausible answer arrives in seconds. The expensive part is now your attention, and almost nobody has updated how they spend it.

We kept the habits from when writing the code was the hard part. We hover over the agent while it works, we read every diff it produces, we re-check by hand what a check could check for us, and we call the exhaustion that follows “using AI well.” It is not. It is attention spent on the half of the problem that is already solved, while the half that still needs a human mind gets the leftovers.

Attention engineering is the deliberate practice of treating your own attention as the scarce resource, and allocating it to the parts of an agent workflow where a mind is actually required.

Attention Is Not Time

#

The first mistake is to confuse attention with time. Time expands to fit the work; attention does not. You can run eight agent sessions in parallel in the same number of hours, but you cannot read, judge, and decide on eight outputs in parallel. The part that parallelizes is generation, which is the part that no longer needs you. The part that needs you, deciding what is good enough, is strictly serial and strictly finite.

This is why spawning more sessions often makes you slower, not faster. Each open session is a claim on working memory, and working memory is small and slow to refill after a switch. The literature on cognitive load has been clear about this for decades: heavy switching fragments attention and produces shallow processing, and the cost is paid by the task you switched into, not the one you left. Parallel agents widen the generation pipe and narrow the decision pipe at the same time, and the decision pipe is the one that matters.

Where Attention Leaks

#

Most of the fatigue people blame on AI is really misallocated attention. It leaks in four predictable places.

Watching the agent generate. The stream of tokens is mesmerizing and almost useless. You cannot usefully steer a model at token speed, and the sense of “supervising” it is a feeling of productivity, not productivity itself. You are attending to a process you cannot improve by attending to it.

Re-verifying what a check could verify. The model says the bug is fixed, and instead of trusting a test, you re-read the diff looking for the fix with your own eyes. This is the acceptance gap run backwards: you spend scarce, taste-grade attention on correctness, the one thing that can be encoded and handed off. A minute of writing the check would have saved an hour of reading, forever.

Context-switching between sessions mid-judgment. You decide on session A until a notification pulls you to session B, and back. Each switch leaves a residue of the previous task in your head, and the decision you return to is made with half your mind still elsewhere. The work feels continuous and is actually being done in shallow fragments.

Signing off without attending. The pull request opens, CI is green, the description looks right, and a feeling forms before the code is read. We have known for a long time that most review works this way, and the arrival of machines writing the diff has not made the reading more rigorous, only the ritual more exhausting. And attention collapses fastest on the work you had no investment in to begin with: it defends itself on what you care about and quietly gives up on what you do not (The Cost of Work You Did Not Choose).

The Leverage Ranking

#

Not every part of an agent workflow needs your attention equally, and the error is treating them the same. Rank them by how much they need a human mind.

Generation needs none. Stop attending to it. Hand over a finished intent and walk away.

Verification, the question of whether it did the thing, needs very little, once you encode it as a check. A failing test that must pass is attention that pays itself forever, for free, whether or not you are watching. The residual cost is exactly the set of things you have not yet bothered to encode.

Specification, the question of what you actually want, needs a great deal, and it is upstream. Attention spent writing the spec pays a higher dividend than attention spent editing the output it produced, because a good spec prevents the wrong output from existing at all.

Judgment, the question of whether the result is the thing you wanted, needs all of it, and it cannot be delegated. This is the taste decision, the “good enough, ship it” moment, and it is the last compounding thing you do.

The skill is to starve the first two and feed the last two.

Attention Engineering, In Practice

#

A few rules hold up.

Spend attention upstream, not downstream. The hour you invest in the specification is worth ten hours of fixing the generated output, because the output is downstream of the spec and inherits all of its omissions. If you keep editing what the agent produced, the problem is usually the prompt you did not write, not the model.

Encode correctness until it costs you nothing. Every check you write is attention you never have to spend again. The goal is to shrink the “verify by hand” pile to the set of things that genuinely cannot be expressed as a check, which is smaller than most people think.

Parallelize generation, serialize judgment. Let many sessions run at once, but do all your deciding in one focused pass, one session at a time, with the others closed or paused. The model is the part that benefits from parallelism. Your judgment does not, and pretending otherwise is how you ship work you never actually read.

Refuse to supervise. If you find yourself watching the agent work, you have either failed to specify the task well enough to walk away, or you have not built the check that would let you trust the result without watching. Both are fixable, and fixing them is a better use of attention than the watching.

Protect the taste decision. It is small in duration and enormous in leverage, and it is the one thing no tool will ever do for you, which is exactly why it is worth protecting from the noise of everything else.

The Implication

#

The constraint has done what it always does when a layer gets automated: it moved up the chain, from generating the work to deciding whether it is good enough (The Shifting Bottleneck). What is new is that the new constraint is not another task you can delegate. It is your own attention.

The ceiling on what you produce with agents is not the model, not the tooling, and not how many sessions you can spawn at once. It is how much focused attention you can bring to the few decisions that require a mind, and how ruthlessly you keep that attention off the many that do not.

The people who get the most out of LLMs are not the ones with the cleverest prompts. They are the ones who learned to walk away from generation, to encode everything checkable, and to save their finite attention for the specification and the taste that only they can supply.

Working with agents is not a prompting skill. It is an attention skill, and the sooner you treat your attention as the bottleneck it has become, the more of it you will have for the work that is actually yours to do.

See also

#

• The Acceptance Gap - the core insight this article builds on: generation is solved, acceptance is the bottleneck, and the taste half of acceptance is the last human loop
• The Shifting Bottleneck - the upstream pattern: automating a layer moves the constraint to the layer above it, here from generation to deciding
• Managing Many Concurrent LLM Agent Sessions - where parallel sessions make the attention bottleneck acute and turn it into human cognitive load
• You Already Review Code Without Reading It - the failure mode this article warns against: signing off on output you never actually attended to
• The Cost of Work You Did Not Choose - why attention defends itself on work you care about and collapses on work you do not

References

#

• Cognitive load - grounds why attention is finite: working memory is small, and heavy context switching fragments it into shallow processing

If you read enough of what I have written, one sentence underlies all of it: encode your judgment into artifacts that outlive your attention. The artifacts change, the principle does not.

A blog post is such an artifact. A skill file is one. The principles file I keep is one. The form runs from the trivial to the sacred, and the same instinct produces all of them: I do not trust my attention to be present when it matters, so I put the judgment somewhere it can survive without me.

This is not a philosophy of throughput, though it can look like one. I am not trying to do more. I am trying to do things that keep mattering after I stop doing them. The victory condition I keep describing, in different vocabularies, is to make myself unnecessary at the layer I currently occupy, so I am free to go find the next one. That is what I am optimizing for, and once you see it, the rest follows.

The frame: the constraint always moves

#

My master mental model is the Theory of Constraints, and I reach for it more than any other. Every system has exactly one binding constraint at a time, and improving anything other than that constraint is wasted effort. The moment you relieve the constraint, it relocates: it does not disappear, it just moves. Automate code production and verification becomes the bottleneck; solve verification and feature selection becomes the bottleneck; solve feature selection and the question of what deserves to exist at all becomes the bottleneck.

I find this frame everywhere, because it is everywhere. A team’s output is bounded by its weakest coordination path, not by how hard anyone works. A career is bounded by the skill you keep avoiding, not by the one you keep sharpening. A life is bounded by the activity you will not stop doing even though it stopped mattering years ago. The work is always the same: find the layer where the constraint currently lives, push there, and then go find it again. The people who look busy and ineffective are usually pushing somewhere the constraint is not. The people who look calm and effective have simply learned to feel where it is.

Games are one of the places I reach for when I want an analogy, because they externalize the thing I am trying to say. Factorio, StarCraft, World of Warcraft, RollerCoaster Tycoon: each is a simulation with a binding constraint, a compounding resource, and a goal that is easy to forget while you optimize a sub-goal, which is why I wrote a series mapping each onto software. The factory exists to launch the rocket, not the other way around, and every optimization that does not serve the product is a belt to nowhere. Analogies are not how I think all day; they are how I explain, and sometimes how I notice a pattern I had not named yet. A trade-off that sounds abstract in software can become obvious when you see its equivalent in a game: you spent the minerals on the wrong unit, you hit the supply cap, you optimized a belt that leads nowhere.

The axis: compounding versus depreciating

#

If the constraint frame tells me where to push, the compounding axis tells me what is worth pushing on at all. Every activity, skill, fix, and artifact is either compounding or depreciating. Compounding things leave future me more valuable for having done them: foundation knowledge, taste, specifications, encoded standards, durable mental models, relationships with people who grow. Depreciating things melt as the environment moves: boilerplate, syntax, one-off patches, anything the next model release will do for free.

My decision tool is the two-year test: if I let this continue for two more years, does the me that emerges become more or less valuable? This looks like a time-management question, but it is an ethical one in disguise. It encodes a belief that a life is something you invest in, not something you spend.

The discipline is asymmetric, and I state it as a rule: delegate depreciating activities ruthlessly, and protect compounding activities ferociously. Protecting a depreciating activity in the name of craft is not craft; it is nostalgia with a deadline. But delegating a compounding activity in the name of efficiency is not efficiency; it is capability suicide by installments. The number to watch is not how much I delegate; it is how much of my remaining time lands on compounding work.

The method: write everything down

#

I do not trust my brain to hold anything important, because I have watched it drop too many important things. So I externalize compulsively: notes, daily questions, workstacks, process documents, this blog. Anything that lives only in a head dies the moment you switch teams, or get tired, or get interrupted. Writing does not degrade as it passes through people; speech does, so I write decisions down.

Writing also does something the brain cannot: it makes what is implicit explicit, so it can be iterated on instead of left unrecorded. A principle in the head is a feeling that I roughly agree with; a principle on the page is a sentence I can sharpen, test against a counterexample, version, and improve. I treat my own notes and principles the way I treat code: something to refactor when it no longer holds, not something to revere because I wrote it once. An unrecorded thought cannot be revised; it can only be had again, slightly differently, next year.

And, finally, I write because I do not know what I think until I do. The first beneficiary of anything I write is me, because the act of writing is the act of finding out what I believe. A verbal decision is just an opinion that hasn’t been overwritten yet; a written one travels to the rooms I am not in and makes its case without me. This is why the blog exists, why the principles file exists, why the daily questions exist. They are not records of conclusions I had already reached. They are the instrument that reaches them.

Then I encode. If a rule lives only in my review comments, it runs only when I am awake, looking, and willing to argue. If it lives in a gate, a template, a paved path, it runs always. A standard runs whether or not anyone agrees with it. An opinion dies the moment you go on vacation.

Verify, do not trust

#

I am an empiricist by temperament, and I do not trust output; I trust the verification system behind it. A claim without an independent check is a hypothesis, not a result. Its confidence is not evidence. Once a system can produce faster than I can read it, review stops being a useful gate and becomes an empty ritual. The right approach is to push human attention upstream to specification, let machines verify compliance downstream, and operate on reality rather than prediction. A canary, a feature flag, a test that actually runs: these are more reliable than a tired human scanning a diff.

The same skepticism turns inward. I treat my own practices and opinions as hypotheses to test, not identities to defend. When I change my mind I try to do it structurally, not shamefully; the meta-process compounds while the specific answer does not. Consistently wrong is worse than inconsistently right, and the only way to avoid being consistently wrong is to keep asking what would change my mind.

Attention is the one resource I cannot manufacture

#

Attention is the binding constraint of my life, so I treat it as the thing the whole system is designed to protect. Keeping up is a losing strategy; the target moves faster than any consumption can match.

The move is not to consume more but to build a funnel that throws almost everything away, confidently and without guilt. Treat urgency as a sales pitch from someone with an incentive to inflate it. Prefer pull over push: knowing where to find something when I need it beats knowing it now. Re-audit the filter periodically, because filters are themselves depreciating assets.

Asymmetry favors the tighter filter. I would rather miss something than be drowned by it, and I would rather be surprised by a concept I can reuse for a decade than briefed on ten things I will forget next week.

The moral register

#

I keep this part out of most of my writing, because it does not look like the rest, but it is central. My philosophical home is Stoic. The happiness of your life depends upon the quality of your thoughts. People are frugal in guarding their property but wasteful of the one thing in which it is right to be stingy, which is time. He who spares the wicked injures the good. These are not decorative quotes to me; they are the axioms the rest has to be consistent with.

From which: tolerate bad behavior and you harm the good; never discourage anyone who continually makes progress no matter how slow; a fast, clear no is a gift, not an injury; skip the blame during the incident and save it for the post-mortem; a father who can admit in writing where he fell short gives his children permission to be imperfect too. I keep a register of my own failures, not as self-punishment, but because a rule without its wound is a slogan, and the wound is the part that is actually useful to inherit.

I am existentialist about meaning and utilitarian about consequences, and I see no contradiction. Life does not have a meaning. You define the meaning of your life. From there, the reasonable project is to reduce pain or increase capability for the largest population you can reach, accepting that capitalism will mostly reward you for producing work whose purpose is, in the grand scheme, about survival. I do not find this grim; I find it clarifying. It means the meaning is mine to assign and the assignment is allowed to be revised.

Set your own standard

#

Do not define your identity by what the people around you do. If their standards are lower than yours and they do things you do not want to see done, that is not permission to lower yours to match. Most people drift toward the average of their environment without noticing, and the excuse is always that everyone else is doing it. The fact that someone else cuts a corner does not make the corner straight.

Be your own standard setter. Be what you would want others to be, regardless of whether they are. The standard is not a comparison to the people next to you; it is a comparison to the person you decided to be, and who you were before.

In one sentence

#

Encode your judgment into artifacts that outlive your attention, from the skill file to the principles file, because that is the only move that simultaneously finds the bottleneck, compounds the foundation, protects the taste, and lets you become unnecessary at the layer you have finished building.

See also

#

• Principles - the compiled list of operating rules that this article distills into a single thesis
• The Meaning of Life - the existentialist core that the moral register section rests on
• The Shifting Bottleneck - the constraint frame as it applies to software and AI
• AI-Maxxing and Resistance Are the Same Mistake - the compounding-versus-depreciating axis and the two-year test

References

#

• Theory of Constraints - the master mental model the frame section is built on
• Marcus Aurelius, Seneca, Zeno - the three Stoic axioms quoted in the moral register