Human-Native vs Agent-Native
AI lock-in isn't at the model layer. It's in the formats and storage your work lives in — which is why git is becoming a skill everyone needs.
Last week I wrote about keeping one notes repo that every AI I use reads from. Halfway through writing it, I kept coming back to why the whole setup works at all: the notes are plain markdown. Make them Word docs and it quietly falls apart.
None of this is surprising once you know where AI tools came from. GitHub Copilot shipped in 2021. Code completion. Refactoring. Reading and writing files in a git repo. That was the first job. AI was built by engineers, for engineers, and engineers had already spent decades solving exactly the problem AI now generalizes: many people working across many files in one shared system, without it falling apart.
The formats engineers use are not physically constrained. A markdown file doesn’t have to fit on a printed page. HTML can be a one-pager, a slide, a dashboard, or a report depending on how you render it. JSON can hold any shape of data. These formats compose into whatever you need. A slide deck is fundamentally a printable page. A spreadsheet is fundamentally a grid. They were made for a person projecting them on a screen or handing them to a printer, and that physical bound is baked in. AI tools aren’t struggling with Office formats because they missed something. The formats weren’t made to be read by programs.
Most of what people call “working effectively with AI” is just moving work onto the substrate AI tools already expect. That’s what this post is about: the two layers of that substrate, format and storage, and what changes when you’re on them.
The Format
A doc (.docx), a spreadsheet (.xlsx), a deck (.pptx) were designed for human eyes and hands. They embed presentation, fonts, layout, revision state, and a pile of binary scaffolding. That made sense. For thirty years the reader was a person.
Hand an agent a Word doc and it has to either run a vision model over a rendered page or fight a brittle parser to dig content out of zipped XML. It can’t reliably diff two versions or cleanly compose a new one. The format fights it the whole way.
Hand that same agent markdown or HTML and it reads, writes, uses git for diffs and version controls, at zero friction. No vision model. No parser. The format isn’t in the way; the format is the interface.
Between those two, markdown and HTML aren’t doing the same job. Markdown is the working layer: notes, drafts, the source of truth for anything you’re still editing. HTML is what you ship. It can carry tables with styling, SVG diagrams, embedded scripts, interactive controls: things markdown either can’t do or requires so many workarounds that the file becomes unreadable past a hundred lines. Anthropic’s Thariq Shihipar made the case for this in May: for anything you’re handing off or publishing, HTML is the right deliverable. The implication for agents is practical. An agent doesn’t need to produce a slide deck or a PDF anymore. It writes one HTML file, and that file becomes the report, the spec, the dashboard, or the design exploration, depending on what you asked for.
That’s the split that matters. Not open versus closed, not cloud versus local. Human-native versus agent-native.
The Storage
Start with where most people are. Word docs live on one machine, or in OneDrive if you remembered to save there. Track Changes is something you turn on when you remember to, not a default. Sharing a doc usually means emailing a copy, which immediately means two versions exist, and within a few rounds you have FINAL_v2_USE_THIS_ONE.docx and nobody’s sure which one has last week’s edits. One editor at a time is the practical limit. And even if you solve the format problem by converting to markdown, you still have a storage problem if the file lives on one machine.
Google Docs and Notion feel like they solve this. They’re cloud-synced, anyone can be in the doc at once, and the version history is automatic. But auto-save is undirected: every keystroke is a save, so finding “what did this doc say on Tuesday before the rewrite” means scrolling through hundreds of micro-versions with no labels and no obvious anchor points. You can’t branch a Google Doc. If you want to try an experimental rewrite without touching the live version, you make a copy and now you’re back to managing two files manually. “Suggesting” mode and comments exist, but they’re shallow. The person reviewing can see your suggestions, but there’s no formal diff, no sign-off workflow, and conflict resolution when two people edit the same sentence at once is basically last-write-wins. If you’re lucky, you notice.
Git works on a different assumption. It’s version control: it tracks every change you make to a file and lets you roll back to any earlier version. But where Docs saves everything automatically, saving in git is intentional. Instead of auto-saving constantly, you decide when to save and you write a one-line note about what changed. Each of those intentional saves is a commit. GitHub is where those commits live remotely. Your phone can read the files, your team can pull from them, and AI tools connect to it directly.
When you want to try a change without touching the main file, you create a branch. The mental model is “Save As.” Except git knows it’s the same file’s experimental copy, not a separate document you’ll forget to reconcile. The original stays clean. If the experiment doesn’t pan out, delete the branch and nothing changed. If it does, you fold it back in.
Before you fold it back in, you usually open a pull request. That sounds technical but it’s just: “here’s what I changed, take a look.” The reviewer sees the diff: a line-by-line view of exactly what moved, what was added, what was removed. They can approve, leave a comment, or push back. Nothing merges until someone says it’s good. For solo work, that someone can be an AI. Paste the diff into Claude and ask it to check for anything you missed.
Once the change is approved, you merge. Git handles the combination automatically. If two people changed the same line in different ways, it flags the conflict instead of silently picking one.
Add a second person or a second agent and this is what the model buys you: main is always the version that counts. Everything else is a proposal until someone approves it. The reviewer can be another human or an AI. The contributor can be a human or an agent that drafted the change and opened the PR itself. The workflow doesn’t care which combination you’re running. The owner reviews, approves or pushes back, and nothing lands until they say so. Word docs and Google Docs can’t do this. Five collaborators, human and AI in whatever mix, all proposing changes to the same file, with one owner who controls what makes it in. That’s what the branch-PR-merge model actually solves.
That’s the operating model. A different assumption about how work gets saved, reviewed, and combined. Markdown checklists, sales playbooks, ops runbooks: they all behave better in a repo than in a doc. And any AI you bring in later reads from the same place, because that’s what repos are for.
I need a GitHub too! Is it like that or nah?
— Meek Mill (@MeekMill) March 23, 2026
Two million views and counting. When a rapper in his late thirties is publicly trying to figure out pull requests, the assumption that git is a developer-only skill has expired.
What to Watch For
The fastest way to get ahead of this is to start using the substrate yourself. Get a GitHub account. Put one thing you actually use into a repo: a recurring report, an ops checklist, a doc you keep rewriting in Notion. See what changes when the AI you’re already using can read it directly instead of you feeding it manually every session.
You don’t need a course. Paste this into Claude, ChatGPT, or whatever you’re already using and let it walk you through it: