Happy Docs - My 5 Steps to An AI-Powered Wiki

/images/nvc-wiki.png

Every developer knows the documentation paradox: you need it, but you never have time to write it. Your services are scattered — a README here, a Notion page there, half-written design docs buried in Google Drive. A new teammate joins and you send them a dozen Slack links. A sales engineer asks how the system works and you shrug, “It’s… complicated.”

Normally, this means weeks of painful writing. Or worse, just accepting the chaos.

This time, I tried something different. I leaned into what I call AI-Assisted Living Documentation and I didn’t do it alone. I brought on two AI partners:

  • ChatGPT: my document architect and prompt whisperer, handling strategy and planning.
  • Claude: my executor, running code, generating files, and doing the grunt work.

Together, we turned a mess of “random docs” into a wiki that actually lives with the codebase — always in sync, always ready.

The Problem Wasn’t a Lack of Knowledge

The information existed. That wasn’t the problem. It was scattered across tools, folders, and people’s heads. Architecture diagrams in one place, onboarding notes somewhere else, and key details tucked away with whoever last worked on them.

What I wanted was simple: a single source of truth. A spot where engineers, DevOps, even sales folks could get up to speed without a scavenger hunt.

Normally I’d spin up another doc and start the slow copy-paste marathon. This time, I went to ChatGPT and asked: “Give me a set of Claude-ready prompts to scan everything and generate a wiki.”

Step 1: The Prompt Dance

ChatGPT didn’t give me finished docs. Instead, it laid out a playbook — a recipe for Claude to follow.

  • A: Inventory everything and propose a clean table of contents.
  • B: Build maps and indexes of the existing services and how they connect.
  • C: Generate Mermaid diagrams for the system.
  • D: Run through each component to pull out key details.
  • E: Add sections for observability, security, onboarding, and sales enablement.

Think of it like a director and an actor. ChatGPT set the vision and wrote the script. Claude took that script and performed it — by generating the actual files.

Step 2: Claude Gets to Work

I ran the prompts through Claude, one by one. Pretty quickly, things started to take shape:

  • docs/backend/api.md with endpoint tables
  • docs/frontend/route-map.md with navigation flows
  • docs/ai/tools-and-prompts.md listing every LLM tool we used
  • docs/architecture/overview.md with shiny Mermaid diagrams

Were they perfect? Not at all. I had to tweak prompts and rerun a few times. But it was still miles faster than doing it all by hand. Suddenly the wiki wasn’t just a pile of notes — it was a living guide to the system.

Step 3: Making It Look Good

The docs worked. But visually? They looked like every other MkDocs site out there.

I wanted something that felt like part of our product, not an afterthought. So I showed ChatGPT a screenshot of our app’s UI — the dark purple-magenta palette, the layouts. It came back with a full plan:

  • CSS overrides for a custom theme
  • A hero section with “Quick Start” buttons
  • Card grids for navigation
  • And a Claude-ready patch script to drop straight into the repo

With a few tweaks, the wiki finally had our vibe, not just vanilla boilerplate.

Step 4: From PNG to Code

Our architecture diagram had been stuck in a dusty PNG file for months. No one wanted to update it, so it just sat there getting more out of date.

I showed it to ChatGPT. Instead of just redrawing, it laid out a plan:

  • Convert the PNG into Mermaid code so it lived inside the docs.
  • Write Claude-ready instructions to generate component diagrams directly from the code.
  • Add sequence diagrams for important flows, like “Create Howl.”
  • And create data flow diagrams for background tasks and integrations.

Now, diagrams aren’t static pictures. They’re living artifacts, version-controlled like the rest of the code. Update the system, update the diagram — simple as that.

Step 5: CI/CD the Docs

The last piece was making sure the docs never went stale. A shiny wiki is useless if it drifts out of date.

Claude, following my instructions, generated GitHub Actions to:

  • Scan and update docs on every pull request
  • Run mkdocs build –strict to catch broken links
  • Fail the build if the docs had issues

That was the game-changer. Docs stopped being optional homework and became part of the development lifecycle itself.

Why This Workflow Works

This wasn’t about having AI write documentation for me. It was about using each AI for what it does best:

  • ChatGPT: the strategist — designing the plan and the prompts.
  • Claude: the doer — scanning the implementation, running code, generating docs.
  • Me: the conductor — steering the process and making sure it felt right.

That’s what vibe coding in documentation looks like: orchestrating AIs to tackle the part of the lifecycle we all hate the most.

Steal This Flow

Want to try it yourself? Start small.

  1. Add a docs/ folder.
  2. Ask one AI (like ChatGPT) to design your table of contents and prompts.
  3. Use another AI (like Claude) to scan your implementation (repos, code, notes) and generate the first set of files.
  4. Style the docs so they feel like your brand, not boilerplate.
  5. Wire it into CI so docs update whenever your implementation changes.

And just like that, your docs stay alive without the grind.


How are you using AI for the “boring” parts of dev — docs, tests, diagrams, whatever?

#NoviceVibeCoder #VibeCoding #AIInSDLC #HappyDocs #LivingDocs

Latest Posts