How to Write an Authentic Technical Blog Post Using LLMs
A deep dive for engineers, researchers, and practitioners who want their writing to actually say something.
Your ability to build, code, or engineer is only as valuable as your ability to explain what you built and why it matters.
Most technical people don’t want to hear that. Writing feels like the soft work, the thing you do after the real work is done. But that’s backwards. The writing is the work. It’s how you share what you know, build reputation, attract collaborators, and make an impact beyond your immediate team.
Here’s where it gets inconvenient. LLMs have made it easier than ever to produce text that looks like writing without doing any of the actual thinking that makes writing worth reading. This post is about how to use those tools without falling into that trap.
Why Technical Writing Matters More Than You Think
Poor communication is expensive in ways most technical organizations never measure. Research referenced in Technical Writing Essentials (Last, Neveu, and Smith) puts the cost of bad business writing in the U.S. at close to $4 billion annually and that’s just what’s visible. The invisible losses, promising projects that don’t get funded, innovations that go unrecognized, tools no one adopts because the documentation is unreadable, never show up on a balance sheet.
If you work in tech as an engineer, researcher, ML practitioner, or founder, you’re already writing constantly. Design docs, proposals, Slack threads, documentation. The blog post is a specific kind of artifact on top of all that, it’s public, it has your name on it, and it signals to anyone who reads it how you think.
That signal matters. Readers who are technically sophisticated can tell the difference between someone who’s wrestled with a problem and someone who’s generated text about it.
The Anatomy of a Strong Technical Blog Post
Before getting into where LLMs fail and where they help, it’s worth being concrete about what a good technical blog post actually looks like.
Prashanth Rao’s essay on technical writing in the age of LLMs offers a useful frame. He argues that readers interact with written content in three distinct layers.
The first layer is the outline: the structure and vision of the piece. A reader scanning the outline is asking: Why should I care? If the outline feels incoherent or generic, they don’t come back.
The second is the ideas: the concepts, themes, and arguments the author is making. A reader moving through the ideas is asking: What’s the actual point? If the ideas feel like a mashup of things they’ve already read, they move on.
The third is the text: the specific examples, data, anecdotes, and details. A reader going this deep is asking: How does this actually work? If the text is vague despite the ideas being interesting, they leave feeling like they didn’t get anything.
All three layers need to work. Most posts fail at the first two.
Technical Writing Essentials adds a useful operational framework on top of this, which is called the 7 Cs of professional writing: clear, coherent, concise, concrete, correct, complete, and courteous. These aren’t stylistic preferences. They’re structural requirements. A post can be eloquent and still be incoherent. It can be concise and still be vague. The 7 Cs are the checklist you run at revision time.
Put the three layers and the 7 Cs together, and you have a reasonably complete picture of what a great technical blog post is: a coherent outline that earns the reader’s attention, original ideas that say something non-obvious, and dense, specific text that makes the argument concrete.
Make sure to checkout our previous blog post
Where LLMs Actually Can't Help You
LLMs are useful for roughly one of those three layers. And it’s the least important one.
They fail at the outline
Forming a coherent outline requires genuine attachment to a topic, something you’ve actually struggled with, been wrong about, or arrived at through experience. Rao’s argument here is precise: getting from what you mean to what a model can act on through a prompt is inherently lossy. The nuance and grounded knowledge you have about your subject can’t be transferred cleanly via instruction. When you ask an LLM to outline your blog post, you get something that looks reasonable but reflects no particular point of view. It’s the structure of a post, not the structure of your post.
They fail at the ideas
LLMs are very good at retrieving and recombining existing ideas. What they can’t do is have an original one. Shreya Shankar, in her essay “Writing in the Age of LLMs,” identifies this as one of the core patterns of bad LLM-generated content: the ideas feel like a collage of what’s already been said, generic, shallow, and derivative. There’s nothing wrong with the words. There’s just nothing being said.
They erode the signal your readers rely on
Shankar’s follow-up essay on consuming AI-generated content raises something more systemic. When AI tools deploy the rhetorical devices of good writing indiscriminately, metaphors, bolded takeaways, emphatic constructions like “it’s not just X, it’s Y”, those devices lose their communicative power for readers. They become noise. The signal degrades.
Your readers, especially the technical ones, are increasingly calibrated to feel when something is off. They can’t always name it. But they disengage. And once that trust is gone, it’s hard to rebuild.
Where they do help
At the text layer, polishing sentences, fixing grammar, varying rhythm, completing a sentence you’re stuck on, LLMs are genuinely useful. But only if the ideas and outline are already yours.
generating text is now cheap, even for medium-to-high quality prose within a narrow scope. But deciding what to say, how to frame it, and when to go deep, that still takes judgment. And that’s the part LLMs can’t do for you yet.
BuildWithAI is Packt’s weekly AI newsletter — backed by a publisher with 8,000+ tech titles and contributions from practitioners actively building at the frontier of AI.
Published by Packt — trusted by developers and engineers for 20+ years
Every issue features insights from credible, practitioner authors — not just commentators
Covers agents, LLMs, AI engineering, tools, and emerging verticals across the AI stack
Built for the technical reader who wants to build, not just follow trends
The Guide: 7 Steps to Write an Authentic Technical Blog Post
The section above was about what not to do. This is about what to do instead, specifically, how to use LLMs in ways that help rather than hollow out your writing.
Each step below includes a task you can do right now, while you’re reading. I’d encourage you to actually do them rather than skim to the end. The whole point of a step-by-step guide is that you use it as a guide.
Step 1: Figure Out What You Actually Think
🟡 LLM role: none
Before you open a text editor or think about structure, you need to know what you’re trying to say. Not the topic. The position.
There’s a difference between “I want to write about RAG” and “I want to argue that most teams reach for RAG before they’ve validated that retrieval is actually their bottleneck.” The second one has a claim. The first is just a subject.
This is the step where LLMs fail most completely. You can’t outsource your thesis to a model because your thesis is what you actually think, built from your experience, your mistakes, your specific context. The model has none of that. It has everything written on the internet about your topic. That’s not the same thing.
📝 Your task: Write, without editing, a messy paragraph that captures your core claim. Not polished. Not structured. Just the thing you want to say. It might look like: “I think most engineers using multi-agent frameworks are over-engineering problems that could be solved with a single well-prompted call. I fell into this myself, spent six weeks building an orchestration layer that collapsed to a for loop once I actually tested it. The abstraction wasn’t adding capability; it was adding complexity I couldn’t explain.”
That paragraph is your compass, so keep it nearby!
Step 2: Define Who You're Writing For
There’s a lot more to this than I could fit into one article. If you want the complete 7-step guide, send me your email at hanaesfandiar100@gmail.com, or drop it in the comments section, and I’ll send it over.
What “Authentic” Actually Means
Authentic writing isn’t writing that avoids LLMs. It’s writing that reflects your thinking, your specific experience, your specific context, your specific position on something you’ve genuinely engaged with.
LLMs are tools. Useful for polishing sentences, checking grammar, varying rhythm, brainstorming titles, and stress-testing whether your argument is coherent. Not useful, or actively harmful, for generating ideas, building an outline, or drafting sections you haven’t actually thought through.
The framework above is about where you put your effort. Ideas and structure are human work. Once those exist, LLMs can help you express them more clearly.
But they can’t give you something to say.
That part is still yours.
If you think this article was useful, share it with your friends and spread the knowledge.
References
Technical Writing Essentials, Chapter 1.4
Technical Writing Essentials, Chapter 2.2
Prashanth Rao, “A Framework for Technical Writing in the Age of LLMs”
Shreya Shankar, “Writing in the Age of LLMs,” sh-reya.com
Shreya Shankar, “On the Consumption of AI-Generated Content at Scale,”
please send me the rest of your post it's great! mikaelabertucci@gmail.com
Hello @Hana Esfandiar , Loved your article, please share the whole guide