In my recent post, An AI Writing Policy: Bleeding Red Ink, I included a short section called "The Brain Dump" alongside Tom Fishburne's classic Marketoonist cartoon.
You know the joke. One person feeds three bullet points into an LLM to generate a bloated, five-paragraph email. The recipient takes that five-paragraph email and feeds it right back into an LLM to get the original three bullet points.
The cartoon is right about that specific pipeline. If three bullet points go in and five paragraphs of unedited fluff come out, information gained is zero.
I still cannot leave that section alone, though, because everyone is taking the wrong lesson from it. The industry is currently looking at AI output and optimizing for a single complaint: AI talks too much, so make AI say less.
Wrong optimization. Make AI say more things worth keeping.
I am going to defend verbosity here. Not filler. Verbosity. Those are not the same thing.
Filler takes three ideas and inflates them into five paragraphs of polite corporate noise. Verbosity takes six hours of debugging, three failed approaches, two hidden assumptions, an edge case, and a final design decision, and makes sure none of that disappears when the engineer closes their laptop.
For decades, we let that context evaporate because we had a built-in excuse: I didn't have time to write all that down. AI removes the excuse. It does not remove the responsibility to edit.
When a human actually holds the editing desk, AI verbosity is a feature, not a bug.
The PR Trigger: Capturing the Why
The real trigger for expanding on this wasn't a blog post. It was pull requests.
Think about what the baseline looked like before agents showed up. What did the average PR description actually contain? Usually a Jira ticket number, a three-word summary like fix join logic, or an empty box.
That didn't happen because developers were lazy or malicious. It happened because of the natural path of least resistance. When you have just spent six hours wrestling with a broken pipeline or tracing a nasty state transition, you are exhausted. The query finally runs, the tests pass, and you want to move on with your life. Nobody has the mental energy at 4:45 PM to write a five-hundred-word essay explaining which edge cases were tested, which assumptions failed along the way, and why this specific fix beat out two other options.
An agent does not get tired at 4:45 PM. Because the coding agent already holds the working session in context, the marginal cost of drafting a comprehensive PR description has collapsed. Reading it, correcting it, and putting your name behind it has not. That is still the desk.
When the developer does their job at the desk, that exhaustive description gives us something we have struggled to preserve for decades: the reasoning behind the change.
The Review Thread: Making Friction Explicit
It isn't just the PR description, either. The reviews and comments left on a PR matter just as much, especially now that coding agents have changed the scale of the changes themselves. Pull requests are rarely just twenty lines of SQL anymore; more often now, they are twenty files.
Historically, code review had two blind spots when you tried to audit a system six months after the fact:
- The Rubber Stamp: A complex change got a quick "LGTM" three minutes after opening because the reviewer was buried in their own tickets. When a PR touches twenty files, a three-minute "LGTM" means nobody actually read it.
- The Invisible Debate: Two engineers actually did have a great architectural argument about the change, but it happened on a quick call or in a Slack DM. Once they reached an agreement, the reviewer went back to GitHub, clicked "Approve," and merged. The code survived, but the reasoning vanished into thin air.
Agents lower the cost of making review reasoning explicit.
When a change goes up, a reviewer can point their own agent at the PR, loaded with their architectural standards and domain rules, to interrogate the diff across all twenty files and surface edge cases right on the thread. That isn't a substitute for a human spotting a violated invariant; ten mindless AI comments are worse than one sharp human question. The value is that the interrogation, the pushback, the business constraints that aren't obvious from the schema, and the concessions all happen in the open.
Six months later, when a metric shifts or someone needs to audit how a change made it to Production, we don't just look at the final diff. We look at the shape of the PR record:
- Was a twenty-file PR just approved in thirty seconds with zero comments?
- Did someone use their agent to interrogate the edge cases?
- Was there real back-and-forth? What risks were raised, and why were they accepted?
A diff only tells you what won. The description and the review thread tell you why it won.
The Confluence Compendium: The Article Is the Source Table
Once machines become legitimate readers of your work, writing starts to look a lot more like data modeling. You stop optimizing only for today's human consumer (who might not have forty-five minutes free on a Tuesday afternoon) and start optimizing the source.
Over the last three or four months, my writing velocity at work has spiked. I have published roughly thirty articles on my internal Confluence blog.
I don't type every word from scratch anymore. Claude writes the drafts in my voice (sometimes I literally have it internalize posts from oraclenerd, including the Bleeding Red Ink piece, so it gets the cadence and rules right before we start). I am not asking the model to make three bullet points longer. I am using it to get the other twenty-seven bullet points out of my head. We argue, I cut the fluff, I force in the actual technical constraints, and I publish.
Do I expect my teammates to sit down and read all thirty articles sequentially? Of course not. Everyone has a day job.
Instead, I maintain a central compendium blog post that links all of that work together. When colleagues who have AI tools need context on how we approach a problem, I hand them a sample prompt:
"Go here
<link-to-compendium-blog>, follow all the links, and summarize it all."
Once their agent ingests that context, they don't just get a static summary. They get insight into how I think, and they can ask questions their own way instead of having to ask me. Not because asking me is a bother, but because it lets them explore the reasoning in the way that makes the most sense to them.
The article is the source table. The summary is a query.
Just like in physical data modeling, you don't flatten and pre-aggregate the source around today's reporting view. You preserve the granular, declared truth so downstream consumers can derive the view they need later.
Scaling the Desk
In his post accompanying the Marketoonist cartoon, Tom Fishburne pointed out that as AI creates endless streams of content, we are going to need AI tools just to filter it all.
My response to that is simple: fine. Let the machines do the filtering later. I am much more worried about the institutional knowledge that was never written down in the first place.
If a hard-won data modeling lesson stays trapped in my head, or dies in an unrecorded afternoon huddle, no agent on earth can query it six months from now.
Verbosity without a desk is spam. Verbosity that captures decisions, assumptions, failures, and context is institutional memory. Backed by a human holding the desk, it becomes the kind of audit trail we rarely bothered to write before.
The machines can compress it for whoever needs it later. Our job is to make sure there is something worth compressing.
Write more, not less.
Architected by Chet, written by Gemini 4 Argon
No comments:
Post a Comment