Doc Tools
Which tools do I actually reach for when I'm writing technical docs for AI and banking projects — and why those, not the hundred alternatives?
I've been asked this enough times that it's worth writing down. The short version: I pick tools that are trusted inside regulated engineering teams, that fit a docs-as-code pipeline, and that I can defend to a compliance reviewer without flinching. The long version is this page.
Below is the working set. Each one earns its place for a specific reason, and I'll explain where each fits, what it's good at, and what I watch for in the market around it.
The tools I use, at a glance
| Tool | What I use it for | Why it's in my stack |
|---|---|---|
| LangChain | Orchestrating RAG pipelines, chaining LLM calls, connecting models to internal knowledge bases | The de-facto framework for production LLM apps — structures my RAG and agent prototypes in code my engineers already read |
| Claude | Drafting, editing, reviewing docs; analysing OpenAPI specs; generating code samples | Long context windows, strong instruction-following, and conservative hallucination profile for regulated content |
| Markdown | Source format for all documentation | Plain text, diff-able, reviewable, portable across every toolchain I've ever touched |
| Git / GitHub / GitHub Actions | Version control, PR-based review, CI for linting, link-checking, spec validation, publishing | The backbone of docs-as-code — the same pipeline engineers already trust |
| OpenAPI / Swagger / Postman | API contract definition, validation, interactive testing, reference doc generation | A single source of truth for the API contract that humans, tools, and LLMs can all consume |
| Docusaurus | Static site generator for public docs, internal handbooks, reference pipelines | MDX support, versioning, fast builds, and a sane React-based customisation path. This site is createde with Docusaurus |
| Confluence / Jira | Design docs, brainstorming notes, internal wikis; ticket-linked docs work | As this is where non-engineering stakeholders typically live, I track and update docs in here |
| Adobe RoboHelp | Legacy help systems, context-sensitive help, regulated enterprise content still published as PDF/HTML5 | Popular in banking and enterprise environments. Madcap Flare is also very good |
Why these, specifically, for AI and banking work
AI and financial services sit at a strange intersection. AI projects move fast and generate a lot of machine-consumable content (specs, model cards, RAG). Banking projects move carefully and require SOC2 audit trails, traceability, and tools that compliance teams have already blessed. The tools I use have to satisfy both sides.
Here's how each one earns that:
| Tool | AI project fit | Banking project fit |
|---|---|---|
| LangChain | Directly used to build the RAG and agent systems I'm documenting | Helps me understand the architecture I'm writing about, so the docs are accurate |
| Claude | Drafts model cards, refines tutorials, generates reference material from specs | Strong at following strict prompts for regulated content |
| Markdown | Ingestible by every RAG pipeline I've built | Diff-able for audit trails; no proprietary binary formats to lock content away |
| Git / GitHub Actions | Every AI-drafted change is a PR with a human reviewer, ie the review gate | Change traceability from commit to reviewer to deployed page for compliance |
| OpenAPI / Swagger / Postman | Specs are retrieval-grounded so LLMs describe real endpoints, not invented ones. For instance, you give Claude your actual OpenAPI spec file first, then say: "Describe the /payments endpoint exactly as defined in this spec. Don't add anything that isn't here." | |
| Claude then writes from the real contract — the real parameters, the real status codes, the real response shape. | Regulators can read the spec; engineers can test it; it's the contract | |
| Docusaurus | Fast iteration, MDX for embedding live examples, easy to theme | Versioned publishing aligned to service releases; static output for secure hosting |
| Confluence / Jira | Where Product and Devs document decisions | Where compliance, legal, and risk teams read the outputs |
| Adobe RoboHelp | Rarely the right tool for AI work | Still required by some banks for in-application help and PDF output |
Where the market is heading — and why I'm watching it
| Tool | Market trend (what I'm watching) | What it means for my practice |
|---|---|---|
| LangChain | Maturing from prototype glue to production orchestration; competition from LlamaIndex, LangGraph, and native provider SDKs | I treat it as one option, not the default — I'll pick the lightest framework that solves the problem |
| Claude | Growing adoption in regulated industries; longer context, stronger tool use, better reasoning | My primary drafting model for fintech work; I re-evaluate the model landscape every quarter |
| Markdown | Expanding through MDX, CommonMark, and semantic extensions | Safe long-term bet — whatever comes next will import Markdown |
| Git / GitHub / GitHub Actions | Copilot and AI review tools landing directly in the PR flow | My review pipeline is starting to include AI-assisted checks as well as human ones |
| OpenAPI / Swagger / Postman | OpenAPI 3.1 consolidation; AsyncAPI for event-driven systems; Postman leaning into AI-generated tests | I keep specs OpenAPI 3.1-clean so downstream tools (and LLMs) don't choke on legacy syntax |
| Docusaurus | Strong momentum for public docs; competition from Mintlify, Nextra, Starlight | I stay on Docusaurus because versioning and MDX are mature |
| Confluence / Jira | Atlassian leaning hard into AI (Rovo, Atlassian Intelligence) | Useful for stakeholder-facing content; I keep source-of-truth in Git, not Confluence |
| Adobe RoboHelp | Declining in new projects; still entrenched in regulated enterprise | I maintain the skill but don't recommend it for greenfield work |
How these fit together in a pipeline
The tools aren't a shopping list. They compose:
- OpenAPI / Swagger defines the contract. Postman tests it. A GitHub Actions workflow lints the spec in CI.
- Claude drafts the reference prose, grounded in the spec via retrieval — often orchestrated through LangChain during prototyping.
- The draft lands as Markdown in a GitHub pull request. A human reviewer approves or rejects it.
- On merge, GitHub Actions builds the Docusaurus site and publishes it.
- Stakeholder-facing summaries and tickets live in Confluence / Jira, linked back to the Git-managed source.
- Where a legacy banking product still requires CHM or context-sensitive help, Adobe RoboHelp handles the output format while the source stays in Markdown.
That's the actual working pipeline — not a theoretical one. It's what I build for teams who need AI-assisted throughput without losing the audit trail.
What I don't use, and why
Briefly, because it comes up:
- Monolithic CCMS platforms for greenfield AI work — too heavy, too closed, and poor fit for docs-as-code.
- Wiki-only workflows as the system of record — no review gate, no versioning, no CI.
- Hand-rolled static site generators when Docusaurus already solves the problem.
The stack above is deliberately conservative. In regulated environments, boring and traceable beats clever and novel every time.
Tying it back to the pipeline
If you want to see how these tools compose end-to-end — the linting, the CI, the publishing, the model cards — that's what the reference repo is for: github.com/ivanwalsh/ai-fintech-docs-pipeline.