Working with LLMs, as a daily craft
Most of what gets written about working with LLMs comes in two piles. One says your job is gone by next quarter. The other says it's autocomplete with a marketing budget. Neither helps much on a Tuesday when the status update is due at eleven.
We've had a model in the loop for most of the working day at Heivol for about two years now, across writing, planning, code and the Proxmox host the products run on. This article was drafted that way too. The four figures in it were written as HTML and rendered through headless Chrome, because that was quicker than opening a drawing tool, and they came out at 55 to 80 KB each, which the model did not predict and I did not ask about. The short version of two years is that it's the biggest change to how we work since version control, and like version control it rewards people who take it seriously as a tool.
What follows is the handful of patterns that survived daily use. There were more. Most didn't.
The loop
The mistake we made at the start, and the one I still see most often, is treating the model like a vending machine. Perfect prompt in, finished work out. When the work comes out wrong the conclusion is that the tool is bad, and it gets shelved for six months.
What works is a loop with five steps. The model owns one of them.
You plan. Before the model types anything you decide what the artifact is, who reads it, and what has to be true when it's done. Two minutes. Skipping it costs twenty.
The model drafts. Fast is the point. A first version exists to be reacted to.
You critique, and this part is a conversation rather than a re-prompt. "Tighten it. Numbers first. You buried the risk in paragraph four." The same things you'd say about a colleague's draft, in roughly the same tone, and the model takes it better than most colleagues.
You verify what can be verified. Then you ship it with your name on it.
The model owns the draft. Intent, judgement, standards and accountability stay with you, by design, and I don't expect next year's models to change that.
Context in, quality out
The biggest quality lever we've found has nothing to do with clever prompting. It's what you hand over before the request.
"Write a project update" with nothing attached gets you filler, because the model knows nothing about your project. The same request with your rough notes, last week's update and one line about the audience comes back close to ship-ready. Habits that pay for themselves:
- Hand over the raw notes. Your compressed memory of them is worse than the notes.
- Name the audience and tone in one line. "For the board, direct, numbers first" is the cheapest upgrade there is.
- Show one earlier example that was done well. Shape and register copy better than instructions do.
- Keep a context file per project. Ours live in Contextbox, our own knowledge base product, and every session starts by reading the project's file: what it is, the decisions so far, the vocabulary we use for it. We eat our own cooking here, which is a large part of why the product exists.
The gate
Models are at their most fluent when they're wrong. A confident tone tells you nothing about the content, so between draft and shipped there's a gate, and the gate is a person.
Facts get checked against the source. Numbers get recomputed, by hand or by a script the model didn't write. And the voice has to be ours. We keep a written style standard with a list of twenty-odd words the model isn't allowed to use (leverage, seamless, delve, that family) and a longer list of structural habits it falls into, and drafts get scanned against it before anything goes out. If a paragraph fails it goes back with a sharper instruction and the loop turns again. The first version of this article failed that scan on em dashes alone — there were twenty-six.
The rule we don't bend: nothing goes out under your name that you haven't read and would defend line by line. Read means read.
Habits
Small batches. One section, one function, one decision per exchange. Big batches are hard to critique and close to impossible to verify.
Options before answers on anything hard. Three approaches with tradeoffs, then you choose. Choosing was your job anyway.
Guard your voice. Models sand the edges off prose. Put them back in critique, or everything you write ends up sounding like everything everyone writes, and readers notice sooner than you'd think.
Some things stay out. Decisions that need taste, values or accountability. Also the parts of the work you actually enjoy; automating those is a strange way to spend a productivity gain.
Write down what works. A prompt that worked is an asset. We keep ours next to the context files. Nothing more sophisticated than that, and it gets read.
Don't change alone
Everything above is individual craft. Shifting how a whole team works is a different problem, because people move at very different speeds with this. Some colleagues already run a model all day. Some are curious and haven't started. Some have quietly decided it isn't for them, and they're not wrong to wait and see what it settles into.
The cheapest structure I've found is an interest group. Thirty minutes every other week, voluntary, one rule: only real work gets shown. Someone walks through a workflow they used that week. The prompt, what they attached, what came back, what they had to fix. No slides, no vendor demos.
What it has taught me, roughly in the order I learned it. A colleague showing this morning's work moves more people than any keynote. Watchers watch and triers try, and the sceptics ask their hard questions out loud, in the room, which is the best place for them. After a few months each member carries the practice back into their own corner, and that's how the lifting gets distributed without anybody being appointed to do it. The group is also where the prompt library, the context-file template and the "what is actually OK to paste in here" rule got settled, in that order. The paste-in rule took the longest, and it is the one I'd start with if I were doing it again.
Keep it voluntary. An attendance list would kill it inside a month. Ours has no list and no minutes, and so far that has been fine.
Where to start
Pick one recurring writing task, the weekly status or the release notes, and run the loop on it for two weeks. Plan first, attach the context, critique hard, verify before shipping. The first week is slower.
If the change you want is bigger than your own desk, find two or three colleagues who care and book the first half hour. Ours started before anyone had answers.
Nobody here types much faster than two years ago. What changed is the quality bar we can hold at that speed, and how much of the week now goes on the parts that need a person.
The figures were made the same way the text was: planned by us, drafted by a model, critiqued, verified. This way of working is also what we bring to consulting engagements. If you disagree with any of it, write to [email protected]. A person reads replies, usually within a day or two.