Fifteen Years of Bullet Points
Extraction and generation look identical from the outside. Forty-six of my field notes share a publication date, and the difference between the two is the only thing worth arguing about.
My Personal LLM Policy: Extract, not generate
The thinking is mine, whether it’s years old or from this week. What a model does is get it out of my head and onto the page — writing time I’d otherwise never spend, not substance I didn’t have. I read every line, I can defend any sentence, and the errors are mine: the same bar I hold everything here to, model or no model.
TL;DR
Most people who say writing with an LLM is illegitimate mean one of two things: that the point of the writing is the writing, or that you’re shipping claims you can’t check. Both are right. Neither describes what a working engineer is usually doing, and it’s the same objection as a developer saying that coding with a model is cheating, wrong in a similar way.
Extraction and generation look identical from the outside. Same tool, same fluent prose, same confident tone. The difference is entirely whether there’s someone on the other end who can tell when it’s wrong. That distinction is the only one worth arguing about. Slop is the generation half. Extraction is what these tools are actually for.
Forty-six of my field notesField Note · currentZFN-0 — Engineering Field NotesWhat Field Notes are, why I write them, and how they work — numbered, status-tracked notes on building software well, published openly and importable as JSON and raw markdown.Open ZFN-0 → share a publication date. They’d been bullet points for years, some of them fifteen, waiting for about a hundred hours of work I was never going to prioritise.
The argument that writing with an LLM is illegitimate is the same argument as a developer insisting that writing code with one is cheating. Structurally identical: a tool produced the artifact, therefore the artifact is hollow, therefore the person who shipped it hasn’t really done the work.
Many engineers I know have already worked out where that lands for code. It depends entirely on whether you understand what came back. If you know the domain, the model is a fast, tireless implementer that lets you spend your attention on the parts that need judgement. If you don’t, it hands you something plausible and well-structured that you cannot evaluate, and you ship a defect with your name on it. Those are not the same activity, and the argument about code has largely stopped pretending they are.
Prose is in exactly the same position, and the discourse hasn’t caught up. Often the objection gets made as though it were a moral question about authenticity (a tool touched it, so it’s tainted), and that version doesn’t survive contact with the code argument.
But there’s a serious version, and I should state it properly rather than pick the weaker opponent. For a writer, the sentence is where the thinking gets tested: you find out what you actually believe by failing to phrase it, and a draft you didn’t struggle through is a conclusion you never checked. That one I owe an answer to, and I’ll come back to it.
Two things that look identical
It’s worth being precise about the word, because “slop” usually names the artifact rather than what produced it. Slop is what comes out of generation: asking a model for material you do not have and cannot evaluate, then publishing what it hands back. The fluency is the problem, because it makes unverifiable output look finished.
Extraction is the other thing entirely: you have the material, and the model puts it in order. The knowledge already existed; what you bought was the shape. That is what these tools are genuinely good for, and it is not what the objection is about. It just looks identical from the outside, because both come out fluent.
Where the objectors are right: if the point of the writing is the writing, a model won’t get you there. Nothing I publish is going to be read in fifty years for its sentences, and I’ve never pretended otherwise. And if you don’t know the subject, you’ll produce something fluent and wrong, and you won’t be able to tell. Both of those failures are real and common.
But there is an enormous amount of engineering knowledge that is not art and not speculation. It’s known, sitting in the heads of people who learned it the hard way, who have no ambition to be stylists and no economic reason to spend three days writing an essay. For that material the tool isn’t a shortcut past the work. It is the difference between the knowledge existing outside one skull and not.
Fifteen years of bullet points
Sixty-five field notes are published on this site. Forty-six of them share a single publication date.
That looks like a burst of productivity. It wasn’t. Almost every one had existed for years as a single line in a list: “queues and topics and journals are different tools”, “every lock is a lease”, “don’t hide behind anonymous people”. Each was a position I’d arrived at the hard way, argued in a design review a dozen times, and never once written down. I’d been carrying some of them for fifteen years.
The bullet points were free. What I never did was the next part: turn a line into a thousand words that explain the context, make the argument, and name the trade-off honestly. Two hours of real work per note, dozens of notes, against a week that already had too much in it.
And it isn’t as though nobody wanted them. People have told me for years that I should write a book, enough times that it stopped being a compliment. Others have said, kindly, that they learn a lot working with me on a project. That one is harder to hear, because the obvious follow-up is: only if you happen to be on the project.
That is how this knowledge has always moved. I’ve mentored dozens of people, and almost everything now sitting in those notes was originally handed over in a conversation, leaning over a screen at four in the afternoon, or on a call at some hour neither of us should have been awake, saying no, don’t do that, and here’s what happens if you do. It’s a genuinely good way to teach: specific, timely, and it carries the reasoning along with the rule.
It wasn’t only spoken, either, which is the part I had wrong about myself for years. I wrote this material down constantly: two careful pages in a Slack thread, a pull-request comment that was really an essay, a design-review note arguing the case properly. But every one had a trigger and an addressee. Somebody asked, or something was on fire.
Which turns out to be the whole mechanism: a colleague waiting for an answer is a deadline. The general version (the same argument, written once, for nobody in particular and everybody later) had nobody waiting on it, so it lost the scheduling contest for fifteen years running. I have written the same explanation more times than I’d care to count, always from scratch, and every copy is sitting in an archive nobody will ever search.
The comparison people make is the wrong one
Nobody is choosing between my field note and a beautifully crafted essay on the same subject, because the beautifully crafted essay was never going to exist. I had fifteen years to write it.
That’s the comparison the objection gets wrong. It measures the output against what a careful writer would have produced, when the real alternative was the empty page, and an empty page has no craft either.
This works because the knowledge is already in my head
Everything above rests on one precondition, and the precondition is doing all the work.
I’m not asking the model what I think. I’m asking it to structure what I already think, and then I’m checking it against everything I have been wrong about. When it produces a claim that’s subtly off in territory I know, I notice. Not because I’m careful, though I try to be, but because I’ve watched that specific thing fail in production and the wrongness has a texture I recognise.
That recognition is the whole of my contribution. What I do is closer to briefing than prompting: a messy paragraph of half-formed argument, the specifics I want in there, a strong sense of what the piece must not say. I get back a structure. Then I spend a long time taking it apart: cutting sections that argue for something I don’t believe, supplying the example that makes an abstract point land, rewriting anything that reads as more confident than I am.
That last part is most of the work, and it’s where the answer to the writer’s objection lives. I didn’t delete the thinking. I moved it from the sentence-making to the dismantling, and I’d concede that is a real change rather than a neutral one, because the two aren’t identical and I can’t prove nothing is lost in the move. What I can say is that the arguing still happens; it happens against a draft instead of against a blank page.
It is invisible in the output, and it cannot be delegated, because it isn’t a skill I could write down for you. It is thirty years of having been wrong, arranged into a set of things that feel incorrect before I can say why.
What comes back is not knowledge I didn’t have. It is the thing I was carrying, in a shape somebody else can read, which is the whole trick, and it is smaller than either side of the argument tends to make it.
The part I can’t wave away
Point the same tool at a subject where you don’t have that recognition and it can produce fluent, confident, well-structured wrongness you have no way to detect without going and checking independently, which is exactly the work you were hoping to skip. Worse, it’ll be wrong in the way that reads best: plausible, conventional, agreeable, because that is what it optimises for.
I’ve written about the version of this that shows up in engineering, people brute-forcing a solution in a domain they don’t understandOpen problem · currentZFN-28 — Capability without understanding: brute-force LLM PRsAn open problem: people brute-force PRs with LLMs in domains they don't understand, taking on more than their knowledge supports — and the struggle that used to teach them is smoothed away. How do we stop un-understood code without killing learning or banning a good tool?Open ZFN-28 →, taking on more than their knowledge supports. That note is filed as an open problem, because I don’t have a solution. The friction used to be the teacher: you’d attempt something past your depth, hit the walls, and learn. The tool smooths the walls away.
Which is where the parallel with code finally breaks, and it’s worth being exact about how. I’ve argued elsewhere that the review moves off the diff and onto the specification, and the code still gets reviewed, hard, just not by me reading it line by line. Reading it to understand what the system now does is a different act, and still worth doing.
Code exports its verification. Prose doesn’t.
That argument works because code has an external boundary. It compiles or it doesn’t. The tests pass or they don’t. It survives review, ships, and either serves traffic correctly at three in the morning or wakes somebody up. None of that depends on my say-so, which is precisely why the internals don’t need my attention: verification was delegated to something mechanical, and the reader of my service never has to evaluate my judgement. They just observe whether it works.
Prose has no such boundary. There is no compiler for an essay and nothing to run, only editors and subject-matter readers, which is slower, fallible, and mostly something I don’t have. A false sentence and a true one are the same shape, and the only check is correspondence with reality, which needs either the domain knowledge to spot the gap or the patience to verify every claim by hand.
That difference shows up directly in what I do.
I have mostly stopped reading the generated code. I read every word of this. Not as a moral position; as a question of what else is in the loop. With code the check is delegated (a compiler, a test suite, adversarial reviewers that can run both, then production traffic), so my reading it adds little that those don’t already do. With an essay there is no such loop, so I am the check by default: the claims are mine, specific to what I know, going out under my name on a subject I’m supposed to understand.
Which is a weaker guarantee than the compiler, not a stronger one. It catches the sentences that feel wrong to me. The ones that get through are the ones that don’t.
That’s the obligation I wrote down separatelyField Note · currentZFN-26 — LLM-assisted content needs no disclaimer, only a human who can back itDrafting engineering content with an LLM needs no disclaimer — inside a team or codebase that already shares the co-sign norm. The obligation is human co-signing. Writing for strangers inverts it: there, stating your policy builds trust rather than diluting a default.Open ZFN-26 → before any of this: no disclaimer needed for AI-assisted work, but you read every word or line, you agree with it, and you can defend it under questioning as though you’d typed it. The absence of a compiler is exactly why that bar has to be met by a person.
And because a person is a fallible check, the second half is making verification cheap for you as well: cite the source, name the basis, link the thing I’m standing on, state plainly what I haven’t confirmed. That’s prose’s substitute for a test suite. It doesn’t prove the piece is right. It moves the checking out of my head and into something you can run without my permission.
I believe I’m on the right side of that line for the things I write about. But notice what that sentence is worth: nothing. It is what someone on the wrong side of it would say, with the same conviction, after the same self-assessment. Confidence is the symptom here, not the evidence.
So don’t take it. And note that this essay is a weak place to test the principle anyway: almost nothing in it is externally checkable. The count of notes sharing a date, you can verify in about ten seconds. Everything else (the fifteen years, the conversations, what I did and didn’t write down) is memory, offered without corroboration, by the person it flatters.
That is the honest shape of the thing. Where a claim can be checked, I should hand you the means and I try to. Where it can’t, you’re weighing whether I’m the sort of person who counts carefully, and no amount of confident prose should settle that for you.
The cost I don’t get to ignore
There’s one more cost, and I don’t get to ignore it just because other people bear it. The same collapse in drafting cost that got sixty-five notes out of me is getting a great deal of worse material out of everybody else: knowledge became more available, and attention became scarcer at the same time. My notes now compete with an enormous volume of confident, unverified text, and from outside mine look exactly like it. That is a cost the mechanism I’m defending creates, and “but mine are good” is what everyone flooding the zone also believes.
What I’m actually claiming
Not that this is good writing. That isn’t mine to score. I’ve just spent a page arguing that a writer’s verdict on his own output is worth nothing, and it doesn’t become worth something because the verdict is modest. What I’ll claim is that it’s true, and that it exists.
Not that everyone should work this way. If you write for the love of writing, this isn’t aimed at you.
And if you’re paid for prose, I won’t pretend the exemption is clean. The engine of this whole essay is that the price of a draft collapsed, and the people who used to sell drafts are the ones who pay for that. I take the upside and the bill goes elsewhere. I don’t have an answer to it, and I’d rather say so than file it under out of scope.
What I’m claiming is narrow: a large amount of useful knowledge is trapped inside people who are never going to write it down, because the cost exceeds what they’ll spend on something with no deadline attached. It gets repeated in design reviews and Slack threads, to whoever happens to be in the room, and then it retires when they do, which is why I started writing these down in the first place.
There’s a selection pressure underneath that worth naming. Writing well takes time, and for anyone hands-on that time competes directly with the work: every hour spent getting a paragraph right is an hour not spent debugging a lock queue at midnight. And the hour keeps going to the lock queue, because the lock queue has someone waiting on it.
I’ll be careful how far I push that, because the obvious counter-example is a shelf of canonical technical books written by people unmistakably in the trenches. The claim isn’t that people who write are distant from practice. It’s narrower: a great deal of hard-won operational experience goes unpublished, because for the people holding it, writing keeps losing the scheduling contest.
And we’re not in the trenches because we failed to escape. We’re there because we like it. Given a free afternoon I’ll pick the gnarly failure over the essay about the gnarly failure, every time, and that preference is what kept most of those notes as bullet points. What changed isn’t that I decided writing was worth the afternoon. It’s that it no longer costs one.
Everyone senior I know has a version of the book they were going to write, and almost none of them have written it. If you’re one of them: the price has changed!
My own response was sixty-five notes and counting, and some of them will be useful to somebody. They’re opinions, not laws, and I’ve been wrong before at length. But a durable opinion anyone can read and argue with beats one that only ever surfaced in private conversation.
And the obligation doesn’t move. If I can’t back a sentence it doesn’t ship, and “the model wrote it” is not a defence for anything carrying my name. That’s the deal I’m offering: the ideas are mine, the judgement is mine, the errors are mine, and where you’d rather not take my word for it, the sources are there.
This piece was written the same way. I brought the argument, the fifteen-year bullet list, and the positions I’d been repeating in conversation for a decade. The structure came back from a machine. Then I took it apart, cut the parts that weren’t true, and put my name on it.