The Future of Documents: Editable, Portable, AI-Native
The document of the future is AI-native but human-editable, portable rather than trapped in a vendor's format, and built on the open web. HTML is quietly becoming that format.
Editing HTML documents, Claude and Codex, and AI productivity.
The document of the future is AI-native but human-editable, portable rather than trapped in a vendor's format, and built on the open web. HTML is quietly becoming that format.
A tool that does one thing well beats a bloated platform that does ten things adequately. Small single-purpose apps are easier to learn, faster to use, and harder to get wrong.
Building a Mac app with an AI coding assistant sped up the mechanical parts and let me stay in the interesting decisions, but it moved the hard work to judgement: deciding what to build and knowing when the generated code was actually right.
Pair-programming with two AIs works if you stay the driver and treat them as navigators. Keep tasks scoped, review everything before it lands, and don't let either run ahead of your understanding.
Have one AI review what the other produced, cold, without the original conversation. A fresh reviewer with no attachment to the work catches errors the author glides past. You still make the final call.
Don't pick a favourite and use it for everything. Match the assistant to the shape of the job: one for framing and judgement, the other for grinding through well-defined code. In practice you'll switch mid-task.
Editing an AI-generated document should not mean uploading it to someone else's server. Local, private tools keep your work on your machine, with no account, no upload and no tracking.
Treat Claude and Codex like two colleagues who don't share a memory. Give each a self-contained job with clear inputs and outputs, and you get more done than trying to run one giant conversation.
If capturing an idea takes more than about two seconds, you'll lose most of your ideas. Build a capture system with almost zero friction and sort things later, not in the moment.
Getting value from AI is a behaviour-change problem, not a tooling problem. Apply EAST (Easy, Attractive, Social, Timely) to your own workflow so the useful action becomes the default one.
Split the work into two modes: use the model to draft and restructure, then switch to editing the rendered document directly for everything else. Knowing when to switch is the whole skill.
Ask the AI to produce a self-contained HTML one-pager instead of a wall of chat text, then fix the last ten percent visually rather than re-prompting.
Ask for a single self-contained HTML file with clear structure and inline styles, and you get a document you can edit later instead of a tangle you have to re-prompt.
Don't review AI content by reading top to bottom like a proof-reader. Check the big things first (structure, claims, facts), fix errors directly in the document, and leave line-level polish for last.
When an AI document is nearly right, editing the specific bits that are wrong is faster and more reliable than regenerating the whole thing and hoping the good parts survive.
When an AI draft is 90 percent right, don't re-prompt to fix the last 10 percent. Edit the output directly, because re-prompting risks losing the good parts and burns your time.
Re-prompting to make small edits is slow and unpredictable. For final tweaks, edit the rendered document directly instead of asking the AI to regenerate it.
Editing the live rendered page, what you see is what you get, is faster and less error-prone than hand-editing raw HTML. For documents, it is almost always the right choice.
HTML is portable, universal, single-file and free of proprietary lock-in. For everyday documents it beats the usual word-processor and PDF defaults on almost every practical measure.
AI tools default to HTML because it is structured, universal and easy to render. That is a gift: you get a portable, editable document instead of a screenshot or a locked format.