Technical Writing

Documentation is not a cost center or an add-on, but is the fundamental mechanism that makes a product usable and valuable to customers. Therefore, eliminating technical writers is a strategic miscalculation that directly damages the product.

AI can draft prose fluently, but someone still has to decide what's true, useful, and trustworthy — and increasingly that means writers doing ontology, epistemology, and phenomenology work that pure language models can't.

For technical teams, the Docs-as-Code approach has definitively won by treating documentation like source code to prevent it from becoming outdated. This method is the clear choice when developers are the primary contributors, even if it's not suitable for non-technical teams.

Documentation is no longer created solely for human consumption; it must now also serve as a structured, machine-readable "contract surface" for AI agents and other tools. This requires creating outputs like `llms.txt` files alongside traditional human-readable formats.

AI is systematically automating every stage of the documentation lifecycle, creating an industrialized process that bypasses and threatens to replace human technical writers. This shift is happening quietly within engineering teams who are building their own "docs-orchestrators" to sideline the traditional writing process.

The true value of Docs-as-Code lies in its principles of rigor and collaboration, not in the rigid imposition of a specific developer toolchain like Git, which is often a misapplication of the methodology. This narrow focus creates unnecessary complexity and can be a "broken promise" for writing teams.

To keep pace with continuous deployment, documentation must evolve beyond Docs-as-Code to a "Docs-as-Tests" model that actively verifies content against the product. This approach is the next logical step to ensure documentation does not become stale or inaccurate as the product changes.