The coding bias
AI engineering content is dominated by coding use cases. Code generation, code review, test writing, refactoring. These are the visible, legible uses — the ones that produce clear before/after comparisons.
The uses that are harder to see but often higher-value involve the writing work that surrounds the code: incident reports, architectural decision records, onboarding documentation, changelogs, handoff notes.
This work takes significant time from every engineer. Most of it is done badly because there is never enough time to do it well. AI assistance changes the calculus.
Incident reports
A well-written incident report is one of the most valuable documents an engineering team produces. It captures what happened, why, and what changes were made. Without it, teams repeat failures.
In practice, incident reports are written under time pressure by engineers who are exhausted from having just fixed something. They are terse, incomplete, and often not written at all.
The Claude workflow: immediately after an incident, spend five minutes doing a voice-memo style brain dump. Timeline, root cause hypothesis, what was tried, what fixed it, what is still uncertain. Paste this into Claude with a request to produce a structured incident report. The output requires editing but it is 80% of the way there.
The brain dump takes less time than writing the report from scratch. The model handles structure. You verify accuracy.
The prompt that works: "I will give you a raw stream-of-consciousness account of a production incident. Produce a structured incident report with: timeline, root cause, contributing factors, resolution, and follow-up actions. Do not invent details — mark any section where my account was unclear with [NEEDS DETAIL]."
Architectural decision records
ADRs are the documentation of why. Why this database, why this service boundary, why this library over the alternatives. They are invaluable six months later when someone asks why a decision was made and the original engineers are not available.
Most teams do not write ADRs, or write them so rarely that the coverage is arbitrary. The time cost of writing a thorough ADR from scratch is 30-60 minutes per decision.
With Claude, the workflow inverts: describe the decision you made conversationally — the alternatives you considered, the constraints that shaped your choice, the tradeoffs you accepted. Claude produces the ADR structure. You correct the parts it misunderstood.
The result is an ADR that would have taken an hour in twenty minutes, and that is more complete than the one you would have written under time pressure.
Onboarding documentation
Onboarding documentation is written by engineers who already understand the system, for engineers who do not. This is why most onboarding docs are bad: the author cannot see their own assumptions.
Claude cannot fix the assumption problem directly, but it can help with a technique: explain the codebase to Claude as if it has never seen it. Describe the architecture, the conventions, the non-obvious decisions. Ask Claude to identify what a new engineer would find confusing about your explanation.
The gaps it identifies are the gaps in your onboarding documentation. Often they are the same gaps that every new engineer hits in their first week.
This is a forcing function for writing docs that actually serve newcomers rather than confirming what the author already knows.
Changelogs
A good changelog communicates what changed and why it matters to the person using the software. Most changelogs are generated from commit messages, which are written for developers, not users.
The Claude workflow: paste the diff or the commit list, describe the audience for the changelog, ask for a user-facing summary of what changed and why it matters. The result is consistently better than commit-message-generated changelogs.
For semantic versioning decisions — whether a change is a patch, minor, or major — describing the changes to Claude and asking for a version classification is faster and more accurate than doing it manually, especially for large releases with many contributors.
Handoff notes
The most underwritten document in engineering. When a contract ends, when someone leaves a team, when a feature moves to a different owner — the handoff note is supposed to capture current state, open questions, and what the new owner needs to know.
In practice these are written in the last hours before a transition, are always incomplete, and often contain the one crucial detail that would have saved the new owner a week of confusion.
The discipline: write the handoff note as you go, not at the end. Use Claude to ask you questions. "I am handing off this system to a new engineer. What should they know? Ask me questions until you have enough to write a thorough handoff note."
This interview-style approach surfaces the things you would not have thought to write down. The model does not know what you know; its questions come from the perspective of someone who does not.
The compounding argument
Code is the visible artifact of engineering work. The documents surrounding the code are what make the code maintainable, teachable, and improvable over time.
Teams that invest in this documentation work slower in the short term and much faster in the long term. AI assistance removes most of the short-term cost while preserving the long-term benefit.
The ROI is not glamorous. It does not show up in throughput metrics. It shows up in the incident that was not repeated, the architectural mistake that was not made a second time, the new engineer who became productive in two weeks instead of six.
These are the outcomes that compound. The code generation use case is visible. This one is more valuable.