Keeping a judgment log

Day 28: Judgment Is the New Career Capital, So Keep a Decision Log

An agent can now produce your week's output in an afternoon. So output can't be why anyone promotes or hires you anymore. What still sets you apart is your judgment, and it only counts if someone other than you can see it and check it.

Two engineers, one review cycle

Last review cycle I had two engineers on the same team. The first one shipped fast. His commit graph was solid green, he had the most PRs on the team, and his features went out early. Three of them also got rolled back.

The second engineer's best work that quarter left no trace. She killed two agent runs that were heading for a broken data migration. She rewrote a spec so a whole category of bug couldn't happen. I only knew because I happened to be in the thread. When I sat down to write her promotion case, I had nothing to point at. On paper she just looked slower.

That was my failure as her EM, not hers. This lesson fixes it from the IC side, so your career doesn't depend on your manager happening to be in the right thread.

The broken link: skill used to show up in output

Earlier in this series we borrowed Cal Newport's idea from 'So Good They Can't Ignore You': you build career capital by getting good at rare and valuable skills. There was a quiet assumption underneath it, which was that your skill would show up in what you produced. Better engineers wrote better code, and the code was the proof.

Agents broke that. With Claude Code, Cursor or Copilot, a mid-level engineer and a senior engineer can push code that looks the same in a diff. Output is cheap now, and it all looks alike. Your commit history mostly tells people how good your tooling setup is. It says very little about you.

• Before agents, output was scarce, so output was the signal.
• Now output is everywhere, so the signal has moved to the decisions you make about the output.
• Which means your career capital is the record of your judgment. How much code you produce doesn't count for much anymore.

What is still rare in agentic software engineering

I sort the judgment that still counts into four kinds. Each one is a decision an agent won't make for you on its own.

• 1. Specifying: what you asked for, and what you left out on purpose. At PhoenixDX, an engineer wrote 'do not add retry logic in the client; the queue already retries' into a spec. That one line stopped the agent from building double-charging behaviour.
• 2. Decomposing: how you split the work between agents and humans. The schema design stayed with a human and the CRUD endpoints went to the agent, because a bad schema costs far more to undo than a bad endpoint.
• 3. Killing: the runs and PRs you stopped, and what tipped you off. One engineer stopped an agent run 20 minutes in because it kept 'fixing' a failing test by changing the assertion instead of the code.
• 4. Catching: failures you found before they shipped. A reviewer spotted that an agent-written PR passed every test but ran an N+1 query inside a loop, the kind a tenant-wide report would hammer.

Why this capital disappears unless you write it down

Good judgment mostly works by taking things away. The bug that never shipped has no ticket. The run you killed has no PR. The scope you cut never appears in a diff. When your judgment works, nothing visible happens.

So at review time, with no record, you look like the next person with a Claude subscription, and probably a bit slower. Your manager isn't watching as closely as you'd like. I have several people reporting to me and my own work on top. I see a sample of what you do. If your best calls aren't written down, I'll remember them for about two weeks.

The practice: a judgment log

A judgment log is a private, running record of the times you went against the default. The default might be the agent's plan, the obvious path, or whatever the team would have done on autopilot. Each entry is about five lines. Here's the template:

## YYYY-MM-DD · [tag: spec | decompose | kill | catch]
**Context:** one line — what task, what stakes.
**Proposed:** what the agent / plan / default would have done.
**Decided:** ship / change / kill — and what exactly.
**Why (signal):** the specific thing I noticed that made me deviate.
**Later (fill in 2–4 weeks on):** what actually happened. Was I right?

• Keep each entry under 3 minutes. If it's taking longer, you've started writing a blog post.
• Aim for roughly 3 entries a week. Far fewer and you're forgetting things. Far more and you're logging noise.
• Log only non-default calls. 'Accepted the agent's PR, it was fine' isn't an entry.
• Always come back for the 'Later' line. Without outcomes the log is a pile of opinions. With them, you have evidence of how well your calls hold up.
• Put it somewhere you'll actually open: a markdown file in your notes repo, an Obsidian vault, a pinned doc. Any tool works if you keep the habit.

Two sample entries: good vs vague

Entry 1 is a killed agent run. This is the vague version, and it's worthless at review time:

## Stopped the agent on the migration, it was doing something weird.

And this is the version that's worth keeping:

## 2026-10-08 · kill
**Context:** Moving tenant settings from a JSON column to a normalized table. Prod data, ~all tenants affected.
**Proposed:** Agent planned an in-place migration using a `jsonb_to_recordset` path and a 'rollback script' it said was tested.
**Decided:** Killed the run. Rewrote as expand → backfill → dual-read → contract, and did the backfill design myself.
**Why (signal):** The rollback script referenced a column that doesn't exist in our schema. The agent hallucinated the migration path, and if the rollback is fiction, the whole plan is unverified.
**Later:** Backfill surfaced 14 tenants with malformed JSON. In-place version would have failed mid-migration with no real rollback.

Entry 2 is a spec edit that wiped out a whole class of bugs:

## 2026-09-24 · spec
**Context:** Agent-built webhook handler for payment events.
**Proposed:** Spec said 'handle payment events and update order status.'
**Decided:** Added to spec: 'Handler must be idempotent on event_id. Store processed IDs. Out-of-order events must not move status backwards.'
**Why (signal):** Our provider documents at-least-once delivery. Without this line, every agent run would produce a handler that double-processes retries — not a bug, a bug class.
**Later:** Two weeks in, provider had a retry storm. Zero duplicate status changes. Same week, another team's handler double-shipped orders.

Look at why the good versions work. Each one names a specific signal (a column that doesn't exist, a documented delivery guarantee) and an outcome you can check. A senior engineer reading it can decide for themselves whether your reasoning was sound. That's what I mean by 'judgment someone else can check'.

Turning the log into capital

• Every month, check your calibration. Tag your entries and count where you were right and where you were wrong. Maybe your kills are usually right but your spec cuts keep turning out to be over-engineering. That pattern is the real asset. Nobody is right all the time, so what you want to know is where you tend to go wrong.
• Every quarter, feed your review. Pull your 3 strongest entries into the self-review or promo packet. 'Prevented a bug class in payments, here's the spec line, here's what happened to the team without it' beats 'shipped 40 PRs' every time.
• When you're job hunting, you've already got your stories. These entries are interview answers a portfolio can't fake. 'Tell me about a time you disagreed with a technical plan' now comes with a date, a signal and an outcome.
• On the way to EM, use it to spot judgment in other people. The same template is how you start asking your reports 'what did you kill this week, and why?' That's how I find the quiet engineer before review season now, instead of during it.

The uncomfortable part: the fast coder

The fast coder wasn't a bad engineer. He was being rewarded for the wrong signal, and I was the one rewarding it. Commit volume was easy to see, so without either of us saying it, that's what we both optimized for.

After that cycle I asked him to keep the log for a month. His first week was nearly empty. He did have judgment. He'd just stopped using it, because accepting the agent's output was faster and nothing punished him for it. By week three his entries were mostly 'catch' entries on his own PRs: an unbounded query, a missing auth check on an internal endpoint, a test that only covered the happy path. The log slowed him down at exactly the points where slowing down mattered. He still ships fast. The rollbacks stopped.

A few traps to watch for. Logging everything turns it into noise. Writing entries to impress instead of to be accurate is another, and your wrong calls are the most useful entries you'll have. Skipping the 'Later' line wrecks the whole thing. And don't let the log stand in for the work. It records your judgment, and you still have to exercise it.

Day 28 assignment

• Create the log file today, using the template above.
• Back-fill 3 entries from the past two weeks: one run or PR you stopped or changed, one spec or scope decision, and one failure you caught. If you can't find three, that tells you something too.
• Add a recurring 15-minute slot on the last Friday of each month called 'judgment log: tag + fill Later'.
• Tomorrow, on Day 29, this log becomes raw material for telling your career story and making your work visible without self-promotion theater.

Extend your knowledge

• Re-read Cal Newport's 'So Good They Can't Ignore You'. As you go, ask which of his 'rare and valuable skills' still show up in output and which have moved into judgment.
• Read Annie Duke's 'Thinking in Bets' on separating decision quality from outcome quality. It's the theory behind the 'Later' line.
• Look at Architecture Decision Records, starting with Michael Nygard's original ADR format. Your judgment log is a personal, lightweight ADR for the calls you make on agent work.
• Read Julia Evans' post 'Get your work recognized: write a brag document', then compare. A brag doc lists wins. A judgment log records decisions, including the ones you got wrong.