Episode: Technical Writing in the AI Era — Skills, Guardrails, and the Craft You Can’t Outsource
Guest: Vladimir Izmalkov: https://www.linkedin.com/in/vaizmalkov/
Docuwiz: https://www.linkedin.com/showcase/docuwiz/
This episode covers the full picture: the foundational skills that still matter, how to use AI without losing your edge, and the frameworks that separate good documentation from documentation that happens to exist.
What We Cover
The skill tree, not the skill Vladimir has developed a “technical writer skill tree” to map the breadth of the profession — written communication, information architecture, instructional design, linguistics, domain expertise, tooling, and now AI. The argument: don’t master one branch in isolation. Gain working proficiency across the branches that matter for your career path, then decide how deep to go in each.
AI as a branch that touches every other branch AI isn’t a replacement for the skill tree — it’s a multiplier on it. It can patch gaps in language proficiency, speed up drafting, and scale output. But here’s Vladimir’s core warning: if you can’t tell whether the AI did a good job, you’re not using AI, you’re outsourcing your judgment. The craft has to come first, or you have no way to supervise the output.
The 30% rule Vladimir’s personal guardrail: AI should account for no more than 30% of total work. Beyond that, you risk losing the research habits, the writing instincts, and the editorial eye that make you worth hiring. Losing craft isn’t a future risk — it happens quietly, one skipped draft at a time.
Toolstack and review workflow VS Code with Copilot in agentic mode, sandboxed, with manual approval gates for anything that touches publishing or the internet. Everything AI produces gets reviewed locally first, then committed to Git so the diff is visible before it becomes a pull request. Two-stage review: author review first, then at least one peer technical writer and one engineer for anything high-stakes.
Docs-as-code and the sync problem The only reliable way to keep documentation from going stale: change the docs in the same pull request as the code. Atomic commits. Everything else — blocking releases, accepting lag, versioning separately — is a workaround for a structural problem. Vladimir covers the tradeoffs for teams where “docs in the PR” isn’t feasible.
Diátaxis in practice The framework (tutorials, how-to guides, reference, explanation) isn’t just taxonomy — it’s optimization. A how-to guide that sneaks in explanations is serving two masters and probably failing both. When a page is specialized to one type, it can actually serve the user who needs that type. Vladimir explains how he applies this when drafting new guides and when rehabilitating documentation that’s grown chaotic over time.
User-centric documentation as design thinking. The question isn’t “does this page cover the feature?” It’s “Does this page help a specific user achieve a specific goal without getting lost?” Vladimir frames documentation as a user journey, and the writer’s job as guiding someone from confusion to success — step by step, across multiple pages if needed.
Closing advice for writers starting out now: Find something you genuinely enjoy working on. Not because it sounds good, but because enjoyment is the only thing that sustains the hours required to get good. Skill compounds over time. Opportunities follow skill.
Links and references mentioned
Docs-as-code methodology
GitHub pull requests for documentation review
Docuwiz helps teams generate and maintain API documentation from OpenAPI specs. Learn more at www.docuwiz.io
