The most value I have got out of these tools is on work I was never going to do at all. The usual framing is acceleration: you’re good at something, now you do more of it per hour. That’s real, and it’s the smaller half.
The larger half is compensation. Every one of us has a list of things we know we should do, know how to do, and reliably don’t. The obstacle is friction. That category is barely discussed, probably because “I finally wrote the runbook” is a worse demo than watching a feature appear in thirty seconds.
The work that never got done
For me, and I suspect for most engineers, the list is depressingly consistent.
Documentation of anything that resists automation. Writing a process down while doing it rather than three weeks after. Keeping a decision record. Updating the runbook on the day the runbook changed. Explaining a system to someone who wasn’t there when it was built.
None of that is intellectually hard. All of it is genuinely valuable; it’s exactly the permanent category, the work that survives a pivot and outlives the person who did it. And it consistently doesn’t happen, because at the moment it needs doing the task is finished, the pressure is off, and writing it up feels like a tax on work that’s already complete. The friction is the blank page and the twenty minutes.
Why documentation is the gap that closes best
There’s a reason this specific gap closes so well, and it’s easy to miss: you’re not missing the knowledge, you’re missing the transcription.
You know how the deploy works. You know which three things go wrong at the end of the month. The distance between knowing and having-written-it-down is pure friction, and friction is the thing these tools are actually good at removing. Compare that to asking a model to tell you something you don’t know, where you have no way to check the answer; that’s the use case everyone reaches for first and it’s the one with the worst error profile.
In practice the loop that works for me:
- Talk through the process out loud while doing it, or straight after. Voice note, rambling, no structure.
- Get back a structured document.
- Correct it, which takes a fraction of the time writing it would have, because editing something wrong is far easier than producing something from nothing.
- Put it where someone will actually find it, which is the step people skip.
The result is a document that exists, and a document that exists beats a better document that doesn’t. That trade used to be unavailable, because the only two options were “write it properly” and “don’t.”
The same shape applies to everything that was always too tedious to be worth it. Extracting a runbook out of terminal history. Turning a three-hour debugging session into a written diagnosis while the details are still in your head.
The undervalued use: checking, not producing
The second use is more interesting and less obvious.
Having a documented process and following it are different problems. Everyone has a checklist they skip when they’re in a hurry. That skip is a discipline failure under time pressure, which is precisely when the checklist mattered most.
A model with your process in front of it doesn’t get impatient. Used as a check rather than a producer, it catches the step you were about to skip, because it isn’t in a hurry and you are.
The prompt shape that does this is unremarkable and I use some version of it constantly:
Here’s our deploy process. Here’s what I’m about to do. What does the process say I’m missing?
The value is that the question gets asked at all, at the moment it matters, without needing a second person to be awake.
This maps directly onto human failure modes. We skip steps when rushed, and we stop being careful at the end of a long day. Neither applies to a process check, and both apply to the person running it.
Move fast without breaking things
The two halves combine into something more useful than either.
The old trade-off assumed speed and care were in tension, because care meant slow human steps: writing it down, reviewing it, checking against the runbook. Every one of those is now much cheaper. So what changes:
- The write-up happens, which means the next person, including future you, doesn’t re-derive it from scratch.
- The checklist gets consulted rather than remembered, on the day it matters instead of the day it was written.
- The rare path gets considered, because asking “what breaks here” costs seconds instead of a meeting.
- The diagnosis gets recorded instead of living in one person’s head until they forget it or leave.
None of that is glamorous. All of it is the difference between a team that accumulates knowledge and one that keeps solving the same problem with different people. If you work remotely, it’s also the thing that decides whether your process holds at a distance, because remote teams have no ambient version of this to fall back on.
Two things this doesn’t do
It doesn’t know what’s true about your system. It’ll document the process you describe, including the parts you have wrong, and it’ll do it fluently. It’s a transcription and consistency layer, so the accuracy is still yours, and confidently wrong documentation is worse than none; it gets trusted.
And it doesn’t supply the intent. It won’t decide the process needs writing down. It won’t notice the runbook has been stale since March. That trigger is still a human noticing something and choosing to act, and no amount of model capability changes it. I think that is worth remembering generally: the deciding part is the part that stays yours whether you protect it deliberately or lose it by default.
Acceleration makes you faster; compensation makes the system around you better.
What is on your own list of things you know how to do and reliably don’t?