Turning AI Conversations into Technical Articles
AI conversations contain questions, failures, comparisons, and decisions that can become technical articles.
The conversation log itself is not evidence for those articles, however.
Old specifications, incorrect hypotheses, unreproducible commands, and secrets can appear in the same log.
For that reason, I would not automate all the way to publication.
Automate candidate extraction, outlines, primary-source discovery, and draft generation.
Keep claim verification and publication approval with a person.
Define publishable information first
Before turning a conversation into an article, classify each piece of information.
| Class | Meaning | Article treatment |
|---|---|---|
| verified | A fact confirmed by official material or code | Cite it and include the verification date |
| reproduced | A result reproduced in your environment | State the environment and procedure |
| reported | Information from a conversation or another person’s report | Label it as a report |
| inferred | A conclusion drawn from several facts | Label it as an inference |
| opinion | An operational recommendation | State its scope and conditions |
Doing this before drafting reduces the chance that fluent prose will look like verified fact.
Prefer primary sources for specifications, prices, versions, supported operating systems, and limits.
Delete a claim supported only by conversational speculation or label it as a possibility.
Separate raw logs from publishable drafts
Do not put raw conversation history in a public repository.
Store it in a private area first, and pass only the minimum necessary summary to the article candidate.
Remove API keys, access tokens, email addresses, customer names, private URLs, local paths, unpublished code, and personal conversations.
Delete secrets from drafts and intermediate artifacts rather than merely masking them.
Before sending text to an LLM, inspect ignore rules and the actual input files.
Treat generated prose and links as untrusted until the publication diff has been reviewed.
Build a candidate backlog from conversations
Mechanically producing one article from every conversation creates short and repetitive articles.
Normalize each candidate into:
- Working title
- Problem the reader can solve
- Tentative conclusion
- Scope that can be written from direct experience
- Claims that need external verification
- Overlap with existing articles
- Publication priority
- Reason to hold
Merge several conversations when they address the same investigation.
Split one conversation when it contains several independent decisions.
At this stage, decide publication value and confidentiality before polishing prose.
Keep the investigation path in the article
A draft should preserve not only the conclusion but also how it was investigated.
Use this order as a minimum:
- State the problem raised by the conversation
- Define the hypothesis to check
- Read official documentation, source code, or release notes
- Verify what can be reproduced in your environment
- Separate facts, reports, inferences, and opinions
- Record counterevidence and unresolved points
Do not fill an unverified gap just because the conversation flows naturally.
If no primary source is available, narrow the conclusion or return the candidate to the backlog as unverified.
Make Markdown the reviewable artifact
Astro Content Collections can validate Markdown front matter with a schema and generate list and detail pages.
Use a title, description, publication date, and tags as a practical minimum.
When generating a draft, request more than the body:
- An introduction that states the conclusion
- The starting question
- Verification date and environment
- Decision criteria
- Failed attempts
- Caveats and unresolved points
- References
- A pre-publication checklist
If investigation notes and reader-facing prose share one file, separate them with headings.
Use a pull request as the publication gate
Run Markdown linting, link checks, type checks, and the site build in CI.
Putting the same checks in GitHub Actions makes the procedure consistent for every article.
Review these separately from mechanical checks:
- Does the title match the conclusion?
- Are facts and experience separated?
- Do prices and specifications have a verification date?
- Can readers who did not see the conversation understand the assumptions?
- Does the article duplicate an existing explanation?
- Are secrets or personal data still present?
- Do links actually support the claims?
A passing PR is not a substitute for technical judgment or publication approval.
Define conditions that stop publication
Return the candidate to the backlog when any of these conditions applies:
- No primary source is available
- The article states a fact that cannot be reproduced in the author’s environment
- It contradicts an existing article or official information
- A secret may be present
- A source for an LLM-added claim cannot be verified
- An automated procedure has side effects that cannot be reversed after failure
Stop conditions slow automation, but they also slow the publication of incorrect articles.
Start with a minimal setup
You do not need a large collection system first.
- Save conversations in a private area
- Append candidates to a Markdown backlog on a schedule
- Research primary sources only for selected candidates
- Generate each article as a draft
- Have a person review it in a pull request
- Publish after lint and build succeed
The goal is not unattended prose generation.
It is to attach evidence to lessons that are easy to forget and turn them into artifacts another reader can inspect.