The intelligence is rented; the operating system is owned

The Team Talk (Alex's version)

Think about how a football club works. Star players come and go. They get sold, they get injured, a better one arrives in January. What the good clubs never sell is the academy: the training ground, the coaching methods, the scouting notes, the standards that decide what "match fit" means. Players are rented talent; the academy is the club.

AI models are our star players. A new, better one turns up roughly every month, and we swap them in without fuss. What we own is everything around them: the written rules for how work gets done, the notes that remember what we have learned, and the automatic checks that stop bad work reaching real families, whichever "player" produced it. Those checks run on all 47 of our code projects, and they do not care which AI wrote the code. Sloppy work gets stopped at the gate either way.

The surprising part is that none of this is fancy. It is plain text files and a handful of scripts, the tech equivalent of laminated coaching cards. For the kid on the far pitch, it means the app they use was built to one standard, no matter which machine, or which machine intelligence, did the building that week.

The Deep Dive

The most durable asset in our engineering setup is not a model, a framework, or a product feature. It is a git repo full of markdown files and one PowerShell script. Every strategic bet on this blog reduces to that sentence, so this post is the thesis the other nine hang off.

The reasoning is simple. Frontier models are interchangeable and improving on a weekly cadence. Whatever you build that depends on one vendor's specific behaviour depreciates at that same cadence. Whatever you build that sits around the models, conventions, quality gates, memory, playbooks, appreciates instead, because every new model arrives pre-trained to read plain files and follow written instructions better than the last one did. So we rent the intelligence and own the operating system.

What the owned layer actually is

Dev OS is a provider-agnostic operating layer for AI coding agents. The whole thing is plain markdown and PowerShell, versioned in a private git repo. There is no vendor database, no SaaS dependency, no orchestration platform. The repo holds a claude-config\ directory we call canon: the master instructions file, the rules (voice, Definition of Done, operating playbook), world context, agent definitions, skills, and memory.

Canon deploys into the home directory of each AI CLI on the machine. Claude Code is the primary runtime, Codex CLI the second; both read the same rules, the same context, the same memory. Only the engine and model tier differ. The adapter layer we use is built to target Gemini and Copilot the same way.

One script does all synchronisation, and its interface is three flags:

powershell .\deploy.ps1 -Check           # drift report, exit 1 if drifted
powershell .\deploy.ps1 -Deploy          # canon -> runtime (new machine, or after git pull)
powershell .\deploy.ps1 -Adopt -Commit   # runtime -> canon, committed and pushed

-Check hashes every file in a ~26-item sync map and reports which side is newer. -Deploy bootstraps a machine: copies canon in, merges core settings while preserving machine-local permission lists, sets the global git template so new repos inherit hooks, and registers the scheduled jobs. A nightly auto-adopt at 21:30 pushes runtime changes back to canon so drift is detected daily rather than discovered weeks later. Moving to a new laptop is git clone plus deploy.ps1 -Deploy. The operating layer follows the person, not the machine, and not the vendor.

Quality lives below the AI layer

The part we trust least is any AI's self-assessment, so the enforcement layer sits underneath all of them, at the git level. Every one of our 47 repos carries the same hooks:

• pre-commit blocks secrets and .env files outright.
• pre-push runs tsc --noEmit and lint, and, where a .gate-build marker file exists, a full production build. The marker opts in the repos that auto-deploy on push, so a broken build physically cannot reach a live site.

New repos inherit the hooks automatically via git config --global init.templateDir, set by the deploy script. The hooks skip gracefully when a toolchain is absent and they do not know or care whether the commit came from Claude, Codex, or a human. That indifference is the design. A model that hallucinates a passing test still hits a gate that actually ran the typecheck.

Memory follows the same rule: one markdown file per durable fact, indexed in a single MEMORY.md. When we brought Codex online as a second runtime, the memory store ported unchanged, because there was nothing to port. It was already just files.

The same philosophy inside the product

The SHOT Clubhouse monorepo applies the identical pattern one level down. One conventions set, many rented readers:

• .rules/: 17 topic-scoped convention files (TypeScript, Supabase migrations, RLS, state management, testing) that any agent loads by topic.
• AGENTS.md: the cross-runtime contract, from terminology canon ("Athlete", never "Player", SHOT is multisport) down to migration rules like never editing a deployed migration file.
• .clan/manifest.yaml: machine-parseable project identity. Stack, environments, board number, label prefix, in YAML an agent can read without prose parsing.

Reading that one set today: .claude/, .codex/, .gemini/, .clinerules, and Cursor via .cursorignore. Five toolchains, zero duplicated convention documents. When a sixth agent runtime appears, onboarding it is a pointer file, not a rewrite.

Scars

Three honest ones.

First, .clinerules in the monorepo is not a designed artefact; it is scar tissue. Read it and you find lines like "DO NOT QUERY: age, role, position columns from profiles table, they don't exist and will cause 400 Bad Request errors". Every entry is a production mistake an agent made once, written down so no agent makes it twice. The owned OS grows by post-mortem, not by architecture review.

Second, we over-built the machinery before we simplified it. Dev OS originally had a four-tier mode ladder (V0 to V3); we collapsed it to two modes in July 2026 because the runtimes learned to lazy-load skills natively and the intermediate tiers no longer paid for their switching friction. The predecessor sync script was also replaced wholesale: it let drift be discovered instead of detected, which is how you silently lose a week of rule edits. Owning the OS means owning its dead ends.

Third, not every file earns its keep. .rules/general-ai-rules.md is, at time of writing, empty: zero lines. It sits in the conventions directory looking authoritative and contributing nothing. Boring files are the strength of this approach and also its failure mode; nothing stops a boring file from being a hollow one except someone reading it.

You do not need forty people for this

The Silicon Valley version of this idea is a platform engineering organisation: internal developer platforms, golden paths, dedicated DevEx teams. The principle is right and the headcount is optional. Our entire platform layer is one 228-line deploy script, a git hook template, and a directory of markdown, maintained by a small core with clear lanes: architecture and data, product and platform, and the sport infrastructure thesis. The models supply the labour that platform teams used to; what they cannot supply is the judgement encoded in the conventions, because that judgement is specific to your product, your users, and your scars. That part you have to own, and owning it turns out to be cheap. It is mostly boring files, which is exactly why it works: boring files are diffable, portable, reviewable, and readable by every model that will ever be released.

The intelligence providers are rented. The operating system around them is owned. Everything else on this blog is implementation detail.

Next in The Engine Room: our secret sauce is on GitHub.