Field notes — the blog

Notes from inside the system.

Specific write-ups on decisions that moved the needle: architecture trade-offs, delivery pipelines, and leading engineers who are better than you at their part of it.

              {{ totalPosts }} notes
              {{ totalMinutes }} min total
              Monthly
            

/

                Latest
                {{ featured.date }}
                {{ featured.cat }}
                {{ featured.read }}
              

{{ featured.title }}

{{ featured.excerpt }}

Read the note →

// before → after
{{ row.text }}

{{ listHeading }}

{{ resultCount }}

                {{ post.cat }}
                {{ post.date }}
              

{{ post.title }}

{{ post.excerpt }}

{{ post.read }}

Nothing matches that.

Try a different term, or clear the filters.

The architect's dispatch

One note a month. Nothing else.

A single deep write-up on a system I worked on: the trade-off, the numbers, what I'd do differently.

            {{ article.cat }}
            {{ article.date }}
            {{ article.read }}
          

{{ article.title }}

{{ article.excerpt }}

{{ part.text }}{{ part.text }}{{ part.text }}

{{ b.alt }} — {{ b.caption }}

{{ b.label }}

{{ h.text }}

{{ cell.text }}

{{ b.label }}

{{ link.label }} {{ link.note }} {{ link.host }}

{{ b.caption }}

{{ b.text }}

{{ b.text }}

{{ b.label }}

{{ line.text }}

{{ item.no }}

{{ part.text }}

{{ part.text }}

{{ part.text }}

Takeaways

▖ {{ t }}

Tags

{{ tag }}

← Newer

{{ prevPost.title }}

Older →

{{ nextPost.title }}

Related notes

{{ post.cat }}

{{ post.title }}

{{ post.read }}

Rubber-ducking with something that argues back

AI · Aug 2026 · 6 min read

I run design decisions past a model before I run them past a person. Not because it is smart — because it is available at 11pm and has no stake in the outcome.

I have started putting design decisions through a model before they reach a colleague, for reasons that have very little to do with the model being clever. It is available at 11pm, it has no stake in the outcome, and it will not soften its third objection because I looked irritated by the second.

The framing is the whole thing

Asking what it thinks of a design gets agreement, because agreement is the safe answer to a vague question. The version that works is adversarial: state the design as a decision already made, then ask for the strongest available case that it is wrong.

// gets you a mirror
"what do you think of splitting billing into its own service?"

// gets you a review
"we are splitting billing into its own service. give me the
  three strongest arguments that this is a mistake, ranked by
  how likely they are to bite us in the first six months."

-> "invoice creation and ledger write become a distributed
    transaction. you have not said how you settle a partial."

Ask for an opinion and you get a mirror. Ask for a rebuttal and you get a review.

That specific objection cost me a fortnight of pleasant assumption. I knew both writes existed. I had not put them in the same sentence, and putting them in the same sentence is the entire job.

Where it helps, and where it cannot

Good: enumerating failure modes you have not thought of, and naming the pattern you are quietly reinventing.
Good: surfacing the assumption you left unstated, because it has to be stated before it can be attacked.
Not good: judging whether the trade-off is right for your team. It does not know your on-call rotation is one person.
Not good: knowing which objection matters. It ranks by plausibility; you rank by what you can survive.

So the output is not the value. The value is that writing a design down in enough detail to be attacked is most of the thinking, and having something that will reliably attack it removes the excuse not to. This is the same mechanism that made architecture decision records work, with the latency dropped from a week to a minute.

One caution learned the slow way: it will argue against a good decision just as fluently as a bad one. The rebuttal is an input, not a verdict. If you cannot articulate why an objection does not apply to you, that is a signal — but it is a signal to go and find out, not to reverse course.

Takeaways

Ask for the strongest case against your decision, ranked by likelihood — never for an opinion.
The forcing function is writing the design down precisely enough to be attacked.
It ranks objections by plausibility; only you can rank them by what your team can survive.

All notes · Shehzad Aslam