Technical writing has always been the unglamorous part of engineering work. We happily spend hours optimizing code paths or arguing about API design, but when it comes to writing down our intent, most of us hesitate. This is where large language models open up an interesting opportunity: they can reduce the friction of writing, and in doing so, change how we share ideas.
One of the main challenges in software engineering is communicating design. Whiteboards are great for quick brainstorming, but they vanish the moment someone erases the marker. Code persists, but it only captures what currently exists—not the trade-offs, the vision, or the boundaries that were meant to stay stable. Worse, business stakeholders rarely look at code at all, so the reasoning behind technical decisions often goes unnoticed. Without writing, the intent behind a system slowly erodes until nobody remembers why it was built that way.
And yet, most engineers dread writing. I don’t know many people who genuinely enjoy it, and I certainly wouldn’t count myself among the great stylists. It’s easy to dismiss documentation as busywork, but that’s a false economy. The time wasted later trying to rediscover design intent dwarfs the effort it would have taken to write a short, clear document. A five-minute read can save days of confusion months or years down the line.
Writing also sharpens ideas in a way that nothing else does. Forcing yourself to articulate a design exposes gaps in your reasoning, and it creates an artifact that others can critique. A good document is not only a record of decisions but also an invitation for others to think critically about them. Writing, in other words, is not just about communicating—it’s about thinking more clearly.
This is where LLMs become genuinely useful. They are surprisingly strong co-authors, especially when guided with the right prompts. An engineer who dislikes writing can still produce a solid draft by leaning on an LLM for structure and phrasing, then refining the output into something that reflects their intent. The result isn’t necessarily literary, but it is clear, concise, and serviceable.
Of course, good technical writing follows some simple principles. Documents should be short enough to read in one sitting—ideally five to eight minutes. They should avoid vague, qualitative statements, opting instead for facts and numbers. “This solution is 500ms faster, leading to a 10% improvement in throughput” communicates far more than “this solution is much faster.” And they should be structured in a way that rewards skimming: begin by stating what the document is about, start each paragraph with its core idea, and let the details follow naturally.
The combination of these principles with an LLM is powerful. You can sketch an outline, set a few constraints, and have the model produce a draft that already respects many of the conventions of good technical prose. What used to feel like a chore suddenly becomes a conversation—one where the model helps translate rough notes into a readable artifact.
That, to me, is the exciting part: not that LLMs replace writing, but that they lower the barrier to entry. They turn documentation from something we put off until the end into something we can do continuously, almost as part of the design process itself. And if better writing means clearer intent, fewer misunderstandings, and more resilient systems, then the value of that shift is hard to overstate.