Your LLM doesn't have to do everything. It probably does better when it doesn't. Content designer Kelly M. joined Technical Writing Uncensored to talk about Gemini Gems — discrete, persona-driven LLM assistants she built to survive a brutal solo workload and scale her expertise to non-writers on her team. Here's what we got into: - Why "don't boil the ocean" is the cardinal rule of Gem-building - The persona → task → context → format structure Kelly uses to write Gem instructions - Why tech writers are uniquely positioned to build these tools well - The knowledge files, guardrails, and ethical considerations worth building in from the start - A live demo with Chef Antonia — a budget-conscious, empathetic culinary assistant with actual personality Have you built a custom LLM assistant for your team? Drop a comment — I'd love to hear what problem you built it to solve. ▶️ https://lnkd.in/gtpXsmeM
Technical Writing Uncensored
Writing and Editing
Beaverton, OR 561 followers
Been there, done that, got stories to tell about it.
About us
Welcome to Technical Writing Uncensored — a bold, honest space for technical writers who care about clarity, empathy, and making docs that actually help users. Hosted by Diana Payton, a veteran tech writer with 15+ years of experience leading documentation teams, this channel shares unfiltered insights, career tips, and skill-building advice for new and seasoned writers alike. Follow for real talk, fresh videos, and the occasional rant — all in the name of better documentation.
- Website
-
https://www.youtube.com/@UncensoredTechWriter
External link for Technical Writing Uncensored
- Industry
- Writing and Editing
- Company size
- 1 employee
- Headquarters
- Beaverton, OR
- Type
- Self-Employed
- Founded
- 2025
- Specialties
- Technical Writing, Editing, and Documentation Audits
Locations
-
Primary
Get directions
Beaverton, OR 97006, US
Employees at Technical Writing Uncensored
Updates
-
AI isn’t just writing documentation anymore, it’s reading it. I sat down with Ed Grzetich to talk about what happens when AI tools like Copilot, Cursor, and Claude start using documentation as their primary source of truth — and what that means for technical writers. We talked about: - Why bad documentation leads to bad AI-generated code - Why API documentation matters more than ever - How technical writers can stay relevant in an AI-driven world - The reality of layoffs and career shifts in tech - Whether “prompt engineering” is just technical writing under a new name If you're a technical writer, developer, or working in docs, then this conversation is worth your time. Watch the interview: https://lnkd.in/eHNY-CfX
AI Isn’t Replacing Tech Writers—It’s Reading Your Docs | Ed Grzetich Interview
https://www.youtube.com/
-
Everyone worried about LLMs replacing us needs to read this, print it out, and then post it somewhere to remind you that good writing needs humans. Hat tip Dachary Carey.
Coffee chat question: "My bosses want me to write with AI. Should I use it to write the first draft or should I write the draft and use AI to edit?" My answer was, "Depends on where you want to spend your time. If you have it write the first draft, then you'll spend a ton of time fact checking and editing it so that it doesn't sound like GenAI. Or you can spend time writing the first draft and use LLMs to speed up editing. Either way, good writing takes time. Trust Dachary Carey to run an experiment and give us numbers to work with. Thanks, Dachary! You are a treasure. https://lnkd.in/gPywHhuz
-
Most teams think their problem is design. It’s not. It’s structure. I sat down with Delfina Hoxha (information architecture consultant and founder of Little Language Models) to talk about why: - “Beautiful” websites still frustrate users - Content chaos quietly kills UX - And why clarity is a business advantage—not just a writing preference One of my favorite takeaways: If users can’t find what they need, it doesn’t matter how fast, secure, or polished your product is, then they leave We also get into: - What information architecture actually is (without the jargon) - How to spot when your content is the real problem - Why tech writers and content folks should care (a lot) 🎥 Watch the full interview here: https://lnkd.in/eBXFeFHS
How Information Architecture Improves UX (and Docs) | Interview with Delfina Hoxha
https://www.youtube.com/
-
Definitely worth the read, folx! Knowledge is power! RTFM!
GitBook's State of the Docs report is live! Give it a read. Lots of intelligent, insightful people contributed, plus me. If you want to know what's going on in our industry, then you want to read this! https://lnkd.in/gbcAXNJe
-
LLMs aren’t just changing how we write documentation. It’s changing how documentation gets reviewed, measured, and trusted. In this conversation with Jahdunsin Osho of TinyRocket Labs, we talk about: ✅ documentation quality metrics ✅ AI-assisted review workflows ✅ docs-as-code automation ✅ proving the business value of documentation ✅ what modern technical writers need to stay relevant We also discuss VectorLint, an open-source approach to making documentation quality measurable and consistent across teams. If you’re a technical writer thinking about the future of your role, this is a conversation worth watching. 🎥 Watch here: https://lnkd.in/gTDg2W-M
-
AI is changing technical writing. But is it going to replace technical writers? In my latest Technical Writing Uncensored interview, I talk with Fabrizio Ferri-Benedetti about what AI actually means for our profession. We discuss: • Why AI is more like a hammer than a brain • Why good documentation becomes more important in the AI era • Why writers may evolve into editors and prompt architects • How writers can maintain their own “mental gym” and creative thinking One of my favorite ideas from the conversation: "Writers should think of AI as a second language, not a replacement." It's a thoughtful conversation about the real impact of AI on technical writing — without the hype. Watch the interview here: https://lnkd.in/dcDZDiGi
-
Hey ML experts in my network! Anyone interested in coming on my channel for an interview to break machine learning down Barney-style for non-developers? DM me if you're interested in talking about ML on Technical Writing Uncensored. If I get no takes, then I'll probably do it myself. If you think you can do it better, then let's do it! It will be fun. :)
-
"AI" isn't. My thoughts on the matter.
It's not AI. Okay, this is a rant I've had for a while, so I'm spelling it out here. Just like "the cloud" isn't actually a cloud (it's a big honkin' server, or several), "AI" isn't artificial intelligence. This is because while it is artificial, it's not intelligent. Like, at all. It's a very advanced autocomplete. Basically, we stuck the internet's worth of words in a bag and are using math to decide which word gets pulled out next. This is a Large Language Model (LLM), just one type of machine learning (ML) model. LLMs aren't magic. They aren't minds. They don't understand jack shit. Doesn't mean they aren't useful tools, but keep in mind their limitations as well as their potential applications. If you do not have any idea how machine learning works or what types of models exist, then I recommend you learn. Do some hands-on tutorials. A quick search for "machine learning tutorials for beginners" will lead you to some great resources. As LLMs become more ubiquitous, and as companies shoehorn "AI features" into every conceivable product, it behooves us as users and consumers to educate ourselves about how these models work under the hood. Put in the time. Future you will thank you. And you'll understand why I hate it when people call LLMs "AI." My $0.02.
-
My musings about speed vs. deep knowledge. Enjoy!
What are we losing when we prioritize speed and productivity? I mean, it's great that we can use LLMs and other tools to make the work go zippy-fast. I'm all for efficiency, especially if it involves automating the boring, repetitive parts of a job. But one of the super powers of a writer is knowledge. Intimate knowledge. When I was managing a documentation team that handled release notes for multiple software teams a while back, I took on responsibility for handling the release notes. That meant I reviewed every feature, every breaking change, every bug fix. When a bug was reported "fixed" three releases in a row, I noticed. When a new feature was being cloned from an old feature, I had the context to go ask if they'd remembered to include the bug fix that had been added well after the original feature went live. (They hadn't.) When my list of bug fixes didn't match up with the list QA was testing, I investigated. This is part of the value we bring as technical writers: deep knowledge and context. And make no mistake, it is valuable. As we explore new tools and new workflows, make sure that you remember that speed isn't the only thing, or even the best thing, to focus on. What do you think, network? How are you balancing the demands and values of these new tools?
