Write a Verdict per Idea, Not a Summary
After reading a lot of one person's work, the useful output is a verdict on each idea: adopt, modify, reject, or conflicts with something I already do. A worked example from an audit of Lee Robinson's writing.
Earlier this month I ran Lee Robinson's site through my research pipeline: twenty posts, written up as six topic notes. Each note is a fair account of what he thinks about developer experience, coding agents, leadership and the rest.
Six summaries do not change how I work. A summary records what the author believes. It does not record what I am going to do about it, and without that the reading fades into a vague memory of having agreed with someone.
So the audit has a seventh note, and it is the one I would keep if I had to delete the others. It gives every idea a verdict.
The four bins
| Verdict | The test | Example from this audit |
|---|---|---|
| Adopt | It changes something concrete, as written | Verifiable outputs before letting an agent run unattended |
| Modify | The principle transfers, his circumstances do not | Spend tokens to delete complexity |
| Reject | Unfalsifiable, overstated, or impossible to verify | Anecdotes beat data; vendor cost figures |
| Conflict | It contradicts a rule I already run | Demos over memos, against my plan-first rule |
The Adopt test is the strict one. If I cannot name what changes, the idea is still a summary with a friendlier label on it.
What got adopted
Verifiable outputs came first. Robinson argues that tests, lints, benchmarks and CI are what let an agent work alone without producing slop, and two of his posts reach that point from different directions. I had already built one instance without the general rule: my yt-research skill refuses to finish until every claim's timestamp anchor verifies. The verdict turned a one-off into a question I can ask of every skill I maintain. Can the agent check this output, or can only I?
The second is a method. In 2021 he predicted that Rust would take over JavaScript tooling. He kept the original text and appended dated updates in 2023 and 2026 marking what landed and what missed, including a tool he had flagged as promising that never shipped. Few writers audit their own forecasts in place. My topic articles could carry dated predictions the same way and get a later audit pass.
The third is two-way-door triage. Before building a review process around a decision, ask whether the decision is reversible. He tells this against himself: he personally reviewed every company tweet for years and became the bottleneck.
That last story points at one of my criteria. His post on five years at Vercel earned more adoptions than his list of beliefs, because the Vercel post attaches a failure to each claim. An aphorism costs nothing to write. A claim that comes with the author's own mistake has been paid for.
What got modified
Spending tokens to delete complexity is a sound principle. The evidence for it is two projects costing $260 and $287 by his own count, done with his employer's tool. I keep the principle and set the budget from my own usage.
Modify is the bin where I separate an idea from the conditions that made it work for him.
What got rejected, and why
His belief list includes the claim that anecdotes beat data. As written it is overstated. The defensible version is that anecdotes tell me why something happened and metrics tell me what happened, and I need both. Taken literally, the original is a license to generalize from the loudest voice. I rejected the sentence and kept the smaller claim underneath it.
The line about grit beating talent went the same way for a different reason. It cannot be wrong, so it cannot guide anything. It says nothing about where the hours should go.
I also rejected every specific cost and performance number, while adopting the mechanism they illustrate. They come from a Cursor employee measuring Cursor. A summary cannot express that split. It either repeats the number or leaves out the idea.
Conflicts get a decision
This bin is the reason I use four verdicts and not three. A conflict is an idea that might be right and contradicts something I already do. If I just file it, I end up with two opposing rules in the same vault, and an agent that reads both.
His preference for demos over memos is the clearest case. Robinson says the prototype could have been built during the meeting. My standing rule is that a non-trivial feature gets questioned and written up as requirements before any code. My resolution is that they cover different moments. A prototype is for arguing a point. A requirements document is for committing to a build. I keep both and say which mode I am in.
His advice against over-optimizing workflows is the sharper one. He started a project with zero custom rules and added them only after watching specific failures. My vault was largely designed up front and then populated, and it holds dozens of skills. He is describing a fresh project and I am running a long-lived system, so the advice does not map directly. I still recorded it as evidence against my setup. Explaining it away would have been easy.
The third is his view that personal software can be imperfect. My vault runs lint skills, schema migrations, retrieval indexes and audit passes over its own notes. The resolution is to decide per component which parts are home cooking and which are infrastructure. My default has been to give everything the high bar, and that default is itself a complexity cost.
What the source cannot teach
The verdict note ends with a list of what is absent from his writing. There is nothing on systems or embedded work. His frame is web product development at well-funded startups, and he joined a company of about thirty people that grew very large, so most of the leadership lessons are conditioned on that outcome. In most posts he is also writing about the products of the company paying him.
Writing the absences down bounds the verdicts. An adopted idea from a narrow source is still adopted, but I know which of my questions he was never going to answer.
Key Takeaways
- A summary records what the author thinks. A verdict records what I will do, and it is the part worth keeping.
- Adopt only when I can name the concrete change. Otherwise it is a summary with a label.
- Reject can be partial: keep a mechanism and reject the numbers attached to it.
- Give conflicts their own bin and resolve each one in writing, so two opposing rules do not sit in the same system.
- List what the source does not cover.
Sources
- Lee Robinson, leerob.com (site audit, twenty posts)
- Lee Robinson, "5 Things I Learned From 5 Years At Vercel"
- Lee Robinson, "Things I Believe"
- Lee Robinson, "Rust Is Eating JavaScript"
- Lee Robinson, "Coding Agents & Complexity Budgets"
- Lee Robinson, "Building low-level software with only coding agents"
- Lee Robinson, "Personal Software"
The dated-predictions idea is adopted on paper. The test of this method is whether my next topic article carries a prediction with a date on it.