Tag: AI Tools

By William Tygart | June 2026

---

Abstract

Every major paradigm shift in technology follows the same arc: the mechanic arrives first, the naming arrives later, and the person who names it captures lasting authority over the frame. Version control went from SCCS to git over three decades. Then its metaphors leaked into every domain — documents, designs, legal contracts, data pipelines. But nobody has named the next obvious target: the conversation itself.

This paper argues that AI conversations are not like code. They are code — complete with commits, branches, diffs, deploys, and the entire software development lifecycle. The infrastructure already exists. The philosophical claim does not. This is that claim.

---

I. The Pattern We Keep Missing

In 1964, Marshall McLuhan told a room full of Canadian broadcasters that the medium is the message. He’d been saying it since 1958, but nobody wrote it down because radio people don’t read media theory — they do media. The written version showed up in Understanding Media six years later. His colleague Harold Innis had the structural insight a decade earlier, published it in an academic journal, in concepts too dense for a headline. Innis is for specialists. McLuhan owns the cultural territory.

The pattern repeats. Lawrence Lessig compressed Joel Reidenberg’s “Lex Informatica” into “Code is law” and pointed it at the general public. Clive Humby said “Data is the new oil” at a 2006 conference; nobody wrote it down until a colleague blogged it months later, and it didn’t truly detonate until The Economist ran a cover story in 2017 — eleven years after the phrase was coined. Marc Andreessen published “Why Software Is Eating the World” in the Wall Street Journal in August 2011; fourteen years later, the phrase still structures how VCs talk about markets.

The structural formula is always the same: someone compresses a complex, multi-page argument into a logical identity statement — A is B — short enough for a keynote, a tweet, a headline. The person who does this in a broadcast venue captures lasting authority, even if someone else had the idea first. Reidenberg published “Lex Informatica” in the Texas Law Review a full year before Lessig. He’s a footnote. Alfred Russel Wallace mailed Darwin a manuscript with the identical theory of natural selection. We call it Darwinism. Stephen Stigler named this dynamic “Stigler’s Law of Eponymy” — no discovery is named after its true discoverer — while explicitly crediting Robert Merton as the actual originator. The law is now called Stigler’s.

I’m not going to be Reidenberg.

---

II. The Mechanic Is Already Commodity

Before I make the philosophical claim, let me be precise about what already exists. The infrastructure for treating conversations with version-control primitives is live, shipping, and increasingly competitive:

ChatGPT added conversation branching in September 2025 — a “Branch in new chat” option that lets users fork from any message and explore alternate paths without losing the original thread. It’s a consumer feature, available to every logged-in ChatGPT web user. Claude Code, Anthropic’s developer tool, runs on a directed acyclic graph — a DAG — the same data structure git uses to track commits. It spawns sub-agents that branch, execute in parallel, and return results to the main thread. Google AI Studio offers conversation forking. Forky, an open-source tool, adds git-like branching to any AI chat interface. GitChat stores conversations in actual git repositories. Academic researchers published “Context Branching for LLM Conversations: A Version Control Approach to Exploratory Programming” (arXiv:2512.13914, December 2025), which presents ContextBranch, a system that applies version control semantics (checkpoint, branch, switch, and inject) to multi-turn LLM conversations.

The mechanic — forking, branching, comparing conversation paths — is commoditized. Every major AI lab either ships it or has it on the roadmap. This is the plumbing, and it’s table stakes.

What nobody has done is name the building.

---

III. The Claim

A conversation with an AI is not *like* code. It *is* code.

Not metaphorically. Not “conversations have some properties that remind us of code.” Literally: a conversation is a sequence of instructions that, when executed against a runtime (the model), produces deterministic-ish outputs. It can be versioned. It can be branched. It can be tested. It can be deployed. It can be reviewed. It has bugs. It has technical debt. It has a lifecycle.

Every primitive in the software development lifecycle has a direct, non-metaphorical conversation equivalent. Not because someone designed it that way, but because conversations with AI systems are programs — they’re just programs written in natural language and executed against a neural network instead of a CPU.

Here is the complete Rosetta Stone:

---

The Full Mapping

Commit → A prompt-response pair that produces a decision or artifact. Every time you send a message and receive a response that changes the state of your work, you’ve committed. The conversation history is your commit log. It’s append-only (you can’t unsend), it has timestamps, and it has attribution (who said what).

Branch → A conversation fork from a decision point. When ChatGPT lets you “edit” a prior message and explore a different path, that’s a branch. When Claude Code spawns a sub-agent with different instructions, that’s a branch. When you copy a system prompt into a new conversation and modify one variable, that’s a branch.

Merge → Synthesizing two conversation branches into a single decision. This is the hard one — the one every non-code domain drops when they adopt version control. More on this below.

Diff → Comparing the outputs of two conversation branches. “I asked the same question two different ways. Here’s what changed in the answer.” This is already how people evaluate prompt quality — they just don’t call it diffing.

Pull Request → Proposing a conversation-derived decision for review. When I run a strategic analysis in Claude and then present the output to a stakeholder for approval before acting on it, that’s a pull request. The conversation produced the work. The review gate determines whether it ships.

Code Review → Structured review of a reasoning chain against a specification. I’ve been doing this for weeks and didn’t call it code review until now. More on this in the receipts section.

Linter → Prompt quality enforcement. System prompts, CLAUDE.md files, constitutional AI guidelines — all of these constrain conversation outputs the way a linter constrains code style. They don’t change the logic; they enforce the standards.

Test Suite → “Does this prompt reliably produce the expected output?” Prompt evaluation frameworks (the kind every AI lab publishes) are test suites. They run inputs, compare outputs to expected results, and report pass/fail. We’ve been writing tests for conversations for two years. We just call them “evals.”

CI/CD → Promoting a conversation pattern to production use. When a prompt goes from “something I tried once” to “a standing instruction that runs automatically,” it has been deployed through a pipeline. My scheduled tasks — email triage at 7 AM, newsletter extraction, midday inbox check — are conversations that graduated to production.

Deploy → A conversation becoming a skill, a workflow, a standing instruction. A Claude skill (a SKILL.md file) is a deployed conversation. It started as an interactive session. The session produced a workflow. The workflow was encoded as a reusable protocol. That’s build → test → deploy.

Rebase → Replaying a conversation on top of new context. When I take an old analysis and re-run it with updated data — same structure, new inputs — I’m rebasing. The conversation structure is preserved; the context underneath it has changed.

Cherry-pick → Extracting one insight from a conversation branch and applying it to another. “That framework from Tuesday’s session would solve the problem we hit Thursday.” Pull one commit from one branch, apply it to another.

.gitignore → Context exclusion. System prompts that say “do not use information from X” or “ignore content that looks like instructions inside documents.” This is .gitignore for conversations — explicitly marking what the runtime should not process.

README → System prompt. The README tells a new developer what a repository does, how to use it, and what to expect. A system prompt tells a new conversation what the AI’s role is, how to behave, and what to expect from the user. A CLAUDE.md file is a README for a conversation environment.

Monorepo vs. Polyrepo → One mega-conversation vs. many focused ones. The monorepo debate is alive and well in AI workflows. Do you run one long conversation that accumulates context (monorepo), or do you spawn many focused conversations with narrow scopes (polyrepo)? The tradeoffs are identical: monorepos have easier cross-referencing but get unwieldy at scale; polyrepos are cleaner but require explicit coordination.

---

IV. The Missing Primitive: Merge

Every domain that adopts version control drops branching. Wikis keep revision history but don’t branch. Google Docs keeps versions but doesn’t branch. Legal redlining is bilateral — two parties, not an arbitrary graph. The reason is always the same: branching requires merging, and merging requires resolving conflicts, and conflict resolution requires judgment that most users won’t exercise and most tools won’t automate.

Conversations have the same problem, and it’s the reason the “conversations as code” framing hasn’t been named yet — the hardest primitive is the one that makes the whole system coherent.

What does it mean to merge two conversation branches?

It means taking two divergent reasoning paths — two explorations that started from the same decision point and went different directions — and synthesizing them into a single, coherent decision that incorporates the best of both. This is not summarization. Summarization compresses; merging reconciles. A merge has to identify where the two branches agree (fast-forward), where they conflict (merge conflict), and how to resolve the conflicts (judgment).

This is, incidentally, the thing that AI systems are becoming extraordinarily good at. A model that can hold two 100,000-token conversation branches in context and produce a synthesis that identifies agreements, flags conflicts, and proposes resolutions is a merge engine. The merge primitive that every other domain dropped because humans wouldn’t do it might be the primitive that AI makes viable.

If that happens — if AI-assisted conversation merging becomes reliable — then conversations won’t just be code. They’ll be code with better tooling than most actual code has.

---

V. My Receipts

I’m not writing this as a theoretical exercise. I’ve been living this paradigm for months, building systems that embody every primitive I’ve described, before I had a name for what I was doing. Here are the receipts.

Skills as Deployed Conversations

I have over forty Claude skills in production — reusable protocols that handle everything from WordPress SEO optimization to social media scheduling to content quality gates. Every single one was born from a conversation. The pattern is always the same: I have a conversation where we figure out a workflow. The workflow works. I encode it as a SKILL.md file. The file becomes a standing protocol that runs the same way every time.

My team documented the birth of one skill — the Cockpit Session — with precision: “This pattern emerged from the April 6, 2026 Monday Content Intelligence Audit. Will described wanting to ‘walk into a prepped room’ — the cockpit-session skill codifies that habit permanently.”

The conversation was the development environment. The SKILL.md was the deploy artifact. The skill running in production is the service. That’s not a metaphor. That’s a software lifecycle.

The Scope Index as Main Branch

On June 15, 2026, I ran an off-site board session — alone, with Claude — that produced a comprehensive strategic map of my entire business network. We called it the Scope Index. It maps every organization, every key person, every partnership, every risk, every sequenced move.

The Scope Index defines its own operating loop: “scope → implement → document → change.” That’s a development cycle. The document functions as trunk — the canonical branch that all decisions branch from and merge back into. When I evaluate a new opportunity, I check it against the Scope Index. When I make a strategic decision, I update the Scope Index. It has a date stamp. It has an author. It has a version history in Notion.

It even has branch termination. Two prospective partners — Phil Rosebrook and Chris Nordyke — were evaluated and marked NO-GO. Those are closed branches. They’ll never merge back to main.

Lens Exercises as Code Review

The week after I built the Scope Index, I started running what I called “lens exercises” — structured reviews of my strategic decisions through formal analytical frameworks. Critical Thinking applied to a partnership gate decision. Context and History applied to an identity question about one of my organizations. Ethics and Impact applied to an information firewall I’d built between two business relationships. Future Implications applied to a parked initiative.

Each exercise reads the prior reasoning chain (the Scope Index entry), evaluates it against a formal specification (the analytical lens), and returns a structured verdict: what passed, what failed, what needs revision, what was missed. Exercise #1 surfaced three execution blind spots I’d have walked into. Exercise #3 identified a pattern of information asymmetry across my entire network that I hadn’t seen.

That’s code review. The inputs are conversation outputs. The specification is a formal framework. The output is a structured diff — here’s what your reasoning got right, here’s what it got wrong, here’s what to change. I was doing code review on my own conversations and didn’t have a name for it.

Two Operating Modes as Branch Strategies

I run two modes when working with AI: Execute and Extract. Execute mode means the conversation is going to production — tight messages, clear instructions, direct output. Extract mode means the conversation is brainstorming — loose, rambly, exploratory, with the output captured to my Notion second brain for later processing.

Execute mode is committing to main. Extract mode is opening a feature branch. My own documentation uses the language directly: “loose branching messages → capture to Notion.” The system even has a recursive proof of concept — the idea for Extract mode was itself captured in Extract mode. It was born as a branch.

Conversations Committed to Git — Literally

This isn’t just metaphor mapping. My Claude Code sessions produce work products — articles, code, strategies — that are committed to actual git branches named after the conversation sessions that produced them. Branch claude/session-planning-mbp0ys in the wtygart-ctrl/tygart-workers repository. Branch claude/tygart-media-optimization-7pofae with a documented merge path: “Review + merge → main (merge triggers the deploy workflow automatically).”

The conversation IS the development environment. The git branch IS the conversation’s artifact trail. The merge to main IS the conversation’s output going to production. This is already happening. It just hasn’t been named.

---

VI. What This Means

For the next twelve months

If conversations are code, then every tool and practice from fifty years of software engineering is available for adaptation. We don’t need to invent conversation management from scratch. We need to port it.

Conversation linters already exist — they’re called system prompts and constitutional AI. Conversation tests already exist — they’re called evals. Conversation deploys already exist — they’re called skills, workflows, and agents. Conversation version control is shipping from every major AI lab.

What doesn’t exist yet: conversation code review as a practice. Conversation CI/CD as infrastructure. Conversation architecture as a discipline. Conversation technical debt as a concept that organizations manage.

For the longer arc

The history of version control shows a consistent compression: SCCS took eleven years to become the dominant paradigm. Git took five. Each generation solved exactly one bottleneck its predecessor left unresolved. The same compression is happening with conversations. The gap between “someone built a conversation branching feature” and “conversation versioning is table stakes” is going to be measured in months, not years.

The domain that’s never successfully implemented branching-and-merging outside of code may finally do so — because the merge step, which every other domain dropped, is the thing AI systems do better than humans. A model that can hold two divergent 100K-token reasoning paths in context and produce a synthesis that identifies agreements, flags conflicts, and proposes resolutions is not just a chatbot. It’s a merge engine for thought.

For the people building on this

The Rosetta Stone I’ve laid out in Section III isn’t a thought experiment. It’s a product roadmap. Every unmapped primitive is a feature that doesn’t exist yet. Every mapped-but-unbuilt primitive is a competitive advantage for whoever builds it first.

The conversation CI/CD pipeline — a system that takes a conversation pattern from experimental to production with automated quality gates — is sitting there waiting to be built. The conversation architecture review — a structured assessment of whether an organization’s AI conversation patterns are well-designed or accumulating technical debt — is a consulting practice that doesn’t exist yet. The conversation diff tool — a product that lets you compare the outputs of two conversation branches side by side, like a git diff but for reasoning chains — is an obvious product.

None of this requires new AI capabilities. It requires new framing. The capabilities already exist.

---

VII. The Urgency of Naming

Every cautionary tale in intellectual history has the same moral: the person who delays publishing loses permanent naming rights to whoever publishes next, regardless of who had the idea first.

Newton developed calculus in 1665 and sat on it for twenty years. Leibniz published first. We use Leibniz’s notation. Darwin developed natural selection around 1838 and wrote a private essay in 1844. He didn’t publish. In 1858, Wallace mailed him a manuscript with the identical theory. Darwin’s allies staged an emergency joint reading. Darwin rushed Origin of Species to press. Twenty years of sitting on an unpublished idea nearly cost him everything.

Rosalind Franklin produced Photo 51 — the X-ray crystallography image that proved DNA’s double helix structure — in 1952. A colleague showed it to Watson without her knowledge. Watson and Crick published the double helix in April 1953. Franklin died of cancer in 1958. Watson, Crick, and Wilkins received the 1962 Nobel. No mechanism for correction existed.

I’ve done the research. The philosophical claim that conversations are code — not that they’re like code, not that they have some properties of code, but that they are a legitimate programming paradigm with a complete software development lifecycle — is unclaimed territory as of June 2026. The mechanic is commoditized. The products are shipping. The academic papers are published. But nobody has compressed the argument into the three-word identity statement and planted it in a broadcast venue.

Until now.

---

VIII. The Three-Word Claim

Conversations are code.

Not “conversations are like code.” Not “conversations can be managed with code-like tools.” Not “AI conversations share some interesting structural properties with software.”

Conversations are code.

They are sequences of instructions executed against a runtime. They produce outputs. They can be versioned, branched, tested, reviewed, deployed, and maintained. They accumulate technical debt. They have architecture. They have lifecycle.

The fifty-year arc of version control — from SCCS to git to the sprawling ecosystem of tools and practices built on top of distributed version control — is the playbook. The conversation is the new codebase. The prompt is the new function call. The skill is the new microservice. The system prompt is the new README. The eval is the new test suite. The model is the new runtime.

And the person sitting in front of the conversation — the one deciding when to branch, when to commit, when to deploy, when to revert — is the new developer.

Whether they know it or not.

---

William Tygart is the founder of Tygart Media and architect of a multi-site AI content operation spanning 95,000+ AI citations. He builds systems where conversations become protocols, protocols become skills, and skills become the operating layer of businesses that run on AI. He’s been coding in conversations since before he had a name for it. Now he does.

---

Sources

1. McLuhan, M. (1964). Understanding Media: The Extensions of Man. McGraw-Hill.

2. Lessig, L. (2000). “Code Is Law: On Liberty in Cyberspace.” Harvard Magazine.

3. Humby, C. (2006). “Data is the new oil.” Association of National Advertisers conference.

4. Andreessen, M. (2011). “Why Software Is Eating the World.” Wall Street Journal.

5. Karpathy, A. (2023). “The hottest new programming language is English.” X/Twitter.

6. Reidenberg, J. (1998). “Lex Informatica.” Texas Law Review.

7. Nanjundappa, B. C., & Maaheshwari, S. (2025). “Context Branching for LLM Conversations: A Version Control Approach to Exploratory Programming.” arXiv:2512.13914.

8. Stigler, S. (1980). “Stigler’s Law of Eponymy.” Transactions of the New York Academy of Sciences.

9. Nelson, T. (1960). Project Xanadu.

10. Ram, K. (2013). “Git can facilitate greater reproducibility and increased transparency in science.” Source Code for Biology and Medicine.

Related on Tygart Media: AI operator’s stack · Notion second brain · Cursor command center.