The rest of the job
Writing code was never most of engineering. Now that it is cheap, the other parts are most of it explicitly.
Estimates of how much of an engineer's time goes into writing new code vary, but every honest accounting puts it well below half. The rest is reading, deciding, writing prose, reviewing, meeting, planning and explaining.
All of those are text work, and all of them can be done with an agent. Some are improved by it and some are made considerably worse, and the distinction is not obvious.
Where it helps
| Task | Why it helps |
|---|---|
| Structuring a document you know the content of | You supply the substance; it supplies the shape |
| Turning notes into prose | The thinking is done; this is transcription with grammar |
| Adapting one message for three audiences | Mechanical, tedious, and you can check it |
| Finding what is missing from an argument | Structural critique, its strongest mode |
| Writing the runbook from what you just did | You have the knowledge and no energy |
| Summarising a long thread into decisions | Mechanical extraction with a checkable result |
Where it actively hurts
| Task | Why it hurts |
|---|---|
| Deciding what to build | Requires context about people that exists nowhere in text |
| Estimating | Estimates come from experience of your team, not from priors |
| Writing something whose value is that you wrote it | A performance review, an apology, a difficult message |
| Thinking through a hard problem | Fluent output substitutes for thought and you do not notice |
| Anything where the writing IS the thinking | Outsourcing it means the thinking did not happen |
The last row is the important one and it applies to more of the job than people expect. A design document is not a record of a decision; writing it is how the decision gets made. Generating one produces a plausible document and no decision.
The test
Before delegating any piece of non-code work, ask: am I producing an artefact, or am I thinking?
If the thinking is done and what remains is shape, grammar and structure — delegate freely, it is transcription. If the artefact is where the thinking happens — write it yourself, and use an agent afterwards to find what you missed.
The pattern that works for almost everything here
1. write it yourself, badly, in whatever form comes out 2. ask what is missing, unclear, or unsupported 3. revise it yourself 4. ask for the three strongest objections a sceptical reader would have 5. address them, or say why you are not The agent never writes the draft. It reads it.
This gets you the benefit — structural critique is genuinely good — without the cost, which is that a fluent draft you did not write feels finished and is not.
The honest risk in this module
Everything here is easier to get wrong than code, because there is no check. A wrong design document compiles fine. A bad estimate passes every test. The verification layer that makes delegation safe in code does not exist for prose, which means judgement is the only control, and judgement is exactly what does not survive being outsourced.
Exercise
List the non-code work you did last week — documents, decisions, messages, planning. Sort each into "producing an artefact" or "thinking".
Then check your habits against the sort. Most people find they delegate at least one thinking task and hand-write at least one pure transcription task.
Worked solution
One week of non-code work, sorted honestly.
THINKING (should write myself) - the design doc for the export scheduler - an estimate for the Q3 roadmap - a reply to a colleague disagreeing with an architecture decision - deciding whether to take on the reconciliation service ARTEFACT (should delegate) - the runbook for the new worker - release notes from the commit log - a summary of a 90-message thread into decisions - adapting the incident write-up for the support team - the weekly update to my manager
delegated, should not have: the design doc. I had asked for a draft and then edited it. The result read well and I could not have defended two of its decisions under questioning, because I had not made them - I had approved them. Rewrote it by hand. Took 50 minutes rather than 15. Two of the original decisions changed, one substantially: the draft had proposed storing next_run_at, which goes stale on a timezone change. I would never have written that myself, and I had approved it. hand-wrote, should not have: the runbook and the release notes. Both pure transcription. The runbook took 40 minutes by hand and 12 minutes from my notes with an agent, and the agent version was better because it was more complete - it included the steps I considered too obvious to write down.
The design-doc case is the one to generalise. Editing a fluent draft feels like authorship and is not: you end up defending decisions you never made, and the failure surfaces the first time someone asks why.
Net effect of correcting both: about the same total time, materially better outputs in both directions.
Takeaways
- Ask whether you are producing an artefact or thinking; delegate the first, write the second.
- A design document is where the decision gets made, not a record of it.
- Write the draft yourself and use the agent to find what is missing — never the reverse.
- There is no check for prose, so judgement is the only control — and it is what outsourcing removes.
Check yourself
Why is editing a generated design document worse than writing one yourself?
A fluent draft presents decisions as settled, and reviewing them is a much weaker cognitive act than making them. The gap surfaces the first time someone asks why — and in the meantime the document carries decisions nobody actually made.
A course by Pieter Zandbergen