There’s a quiet shift happening in how technical teams work with AI.
A year ago, the conversation was about whether AI could write a useful first draft of a PRD, an RFC, or a bug report.
Today, that’s settled — it can.
The new question is much harder: once AI is producing more documentation than any single person can review, where does the team actually align?
Code reviews catch code drift. Standups catch scheduling drift. But there hasn’t been a clear answer for documentation drift, the gap between what an AI assistant generated, what an engineer actually intended, and what the rest of the team thinks is happening.
Without a shared layer in the middle, AI-generated docs tend to live wherever they were created: in someone’s Obsidian vault, in a Claude conversation, in a Codex session that closes when the laptop sleeps.
We’ve been talking with teams about how they’re solving this, and one conversation stood out. Mikerah Quintyne-Collins, the founder of HashCloak and Stoffel Labs — both working at the frontier of privacy-preserving infrastructure for blockchains. She walked us through her team’s workflow. It’s a clean, opinionated example of what HackMD is becoming for technical teams in 2026: not just an editor, but the governance layer between AI-generated work and team alignment.
The shift: from “where do I write?” to “where does the team agree?”
Most engineers have already settled their personal documentation tools. Mikerah uses Obsidian as her local store, it’s where she captures rough thoughts, stages prompts before sending them to Claude or Codex, and keeps the messy intermediate work that doesn’t need to be shared. Her team works alongside AI coding tools every day, and she typically drives that work from the CLI.
That part is solved. What wasn’t solved and what HackMD ended up filling is the moment a piece of work needs to leave a single person’s head and become a shared artifact the team can react to, push back on, and build from.
Here’s how she described that flow, in her own words:
"My flow for doing coding work is now:
- Write a rough PRD of the requirements I need implemented. This is done in Obsidian before I copy the prompt to Claude/Codex.
- Have Claude/Codex turn this rough PRD into an actual PRD.
- Iterate on the PRD until it actually matches what I need. At this point, this gets posted to HackMD as a note.
- From the PRD, generate RFCs. RFCs provide the implementation details needed to actually implement the PRD successfully.
- Iterate on the RFCs until they match what I need for an initial implementation. Once finalized, this gets posted to HackMD as a HackMD book that references the PRD note in the main chapter."
There’s a subtle but important pattern here. AI is doing the heavy lifting of drafting and iteration. Obsidian is the local scratchpad. But the moment something becomes real, the moment it has to be defended, reviewed, or built against, it moves into HackMD.
That movement is the governance step.
Why move into HackMD, specifically?
When we asked Mikerah why HackMD is the destination, instead of just pushing the markdown into Git, or sharing a link to an Obsidian vault, or pasting it into a doc tool, her answer kept coming back to a few practical things.
Concrete, technical detail without forcing everyone into Git. Her team needs to understand the rationale for a feature, not just the implementation. HackMD lets her share that rationale in a form engineers can read, comment on inline, and respond to without opening a pull request. As she put it: “It makes it easier to share with the team in concrete, technical details the features and rationale for a specific component. It helps them then orientate their own software decisions accordingly and they can easily push back against my thoughts as well.”
Long-term, durable knowledge. PRDs and RFCs aren’t disposable. They’re the record of why the team made the choices they made. Mikerah described this layer as “sort of like ADRs” — referencing the Architecture Decision Record pattern that Michael Nygard popularized in 2011. Used this way, HackMD notes and Books become an institutional memory that survives the AI session that produced the first draft.
Structure that scales with the work. A single PRD is a HackMD note. But once you generate the RFCs that flow from it, you have a small library and HackMD’s Book mode lets her organize those RFCs as chapters that reference the original PRD note. The team gets one canonical entry point and a coherent walkthrough of the design, instead of a folder of disconnected files.
Beyond drafting: using HackMD to interrogate the past
The most interesting part of the conversation wasn’t about generating new documentation. It was about using HackMD to make sense of work that already happened.
Mikerah described two patterns her team uses regularly:
Reverse-engineering rationale from existing code and conversations. She’ll point an AI model at a code component and ask it to articulate the design decisions encoded in it. Then bring that into HackMD for the team to review. She does the same with decisions that came out of standups or Slack threads, where the rationale never made it into a written artifact.
“It forces [us] to either double down or reconsider past decisions and integrate it into our release schedule.”
Finding the gaps. Used this way, HackMD becomes a place to surface what should exist but doesn’t — the missing rationale, the unreviewed assumption, the spec that was implied but never written down.
This is where the governance framing really lands. AI assistants are excellent at producing first drafts, including drafts of work that already happened. But a draft only becomes governance when it’s somewhere the team can see it, argue with it, and commit to it. That somewhere needs to be more durable than a chat window and more accessible than a Git repo.
What changed in practice
We asked Mikerah, point blank, what this workflow has actually improved for her team.
Her answer was concise:
“Less context getting lost and better alignment.”
That phrase deserves to be sat with. It’s not “we ship 30% faster” — that kind of metric tends to be invented after the fact anyway. It’s the more honest version: the team knows what each other is working on, why, and what was decided. The AI generates the volume; HackMD makes the volume legible.
Why this matters for any team building with AI right now
Stoffel Labs is a specific kind of team — small, technical, building infrastructure where design decisions have real cryptographic and security consequences. But the pattern Mikerah describes is increasingly universal:
- Local AI work happens fast. Engineers use Obsidian, Cursor, Claude, Codex, or some combination. Drafts are cheap.
- Team alignment doesn’t. The gap between “I have a draft” and “the team agrees on the direction” is where most projects stall.
- A shared, durable, comment-friendly layer is what closes that gap.
Not a chat thread. Not a Git repo. Something in the middle.
For Stoffel Labs, HackMD is that middle layer. Notes capture the canonical version of a PRD. Books organize the RFCs that depend on it. Comments and inline edits let the team push back. And the whole thing persists — long after the AI session that produced the first draft has been closed.
If you’re working with AI tools every day and finding that the bottleneck has moved from writing to agreeing, the workflow Mikerah described is worth using.
Try it for your own team
The fastest way to feel this is to take one document your team is currently arguing about — a spec, a bug report, an architecture proposal and move it into HackMD.
Invite the team. Let them comment inline. See what surfaces.
If you want to lean further into the AI-assisted version of this flow, the HackMD CLI and the Developer Portal make it straightforward to push markdown into HackMD from wherever your team is already working — including from agents and CLI-driven workflows.
