AI Operating System
Using AI to write code is easy. Using it to deliver production systems reliably and repeatedly, across several large codebases, is a different problem — and the answer is mostly about the process around the tool rather than the tool itself.
This page covers how I work in practice: which tools I use, how each task is prepared and assigned, what has to pass before a change ships, and where AI is not used at all.
Toolchain
What I use
The tools are the replaceable part. They are listed because “which tools” is a fair question, not because the answer is the interesting one.
Reasoning and implementation
- Claude
- Architecture review, design challenge, incident reasoning and long-form specification work.
- Claude Code
- Implementation inside a repository, under a context pack and a task card with stated acceptance criteria.
- ChatGPT
- Second-opinion reasoning and exploratory work outside a repository context.
In-editor assistance
- Cursor
- Editor-resident assistance for mechanical transformation and navigation across large codebases.
- GitHub Copilot
- Line-level completion during routine implementation.
Visual generation
- Midjourney
- Concept and variant generation for creative production, against an approved brief.
- DALL·E
- Alternative generation route where composition control matters more than style.
Internal systems
- Specialized internal agents
- Diagnostic capabilities for delivery flow, lane health, delivery evidence and bounce backoff — each registered, budgeted and mode-controlled.
- Model routing
- Task-class routing across four tiers, including a no-model tier for anything a query answers exactly.
- Knowledge retrieval
- Hybrid vector and keyword search over curated internal documentation, so assistants reason from written truth.
01
Context strategy
An assistant given a large repository infers structure from names. In these codebases that inference is actively wrong — several components share names and a substantial subtree does not run at all. So context is assembled, not discovered.
Repository operating manual
Each repository carries a document stating what the system is, which architectural claims hold today, the build and validation commands, and the definition of done. Read first, every time — by assistants and by new human contributors, who want the same document.
Context packs
The operating manual, a generated map of the relevant subtree, the specific files in scope and the task card. Exploration beyond the pack is limited and deliberate rather than open-ended.
Generated repository maps
Structural maps produced from the code rather than described by hand, so they cannot drift into being a description of what the code used to be.
Task cards
Goal, acceptance criteria, files in scope, applicable invariants and sensitivity level. Small enough to fit in context with room left to think — multi-part cards produce changes that are partly right, which are harder to review than two small correct ones.
Token budgets
Every task runs against a ceiling. A bounded task that fails to converge stops, rather than continuing until someone notices the spend.
Sensitivity levels
Classified before context is assembled, not after. Secrets and production data never enter a prompt, at any tier, for any task.
Persistent architecture truth
Invariants written down with a pointer to the code or document that proves each one. A rule without evidence rots into folklore and nobody can tell whether it is still true.
02
Model strategy
Extracting a field from a struct and designing a recovery contract are not the same problem. Routing them to the same model means overpaying on one and underpowering the other, simultaneously.
No model for deterministic facts
The most valuable rule in the policy. Counts, lookups and mechanical checks go to a query, a search or a script — faster, free, and exactly correct rather than approximately correct.
Inexpensive tier for extraction and summarization
Well-specified tasks whose output is easy to verify. Paying premium rates here buys nothing.
Strong tier for architecture and security
Where being wrong is expensive and the failure is hard to spot on review.
Premium reasoning for production incidents
The one task class where cost does not enter the decision, and the one class never downgraded when budgets are tight.
Defined fallbacks
Every tier has an alternative for provider trouble. Availability problems degrade the tier; they never relax the approval boundary.
Cost tracking and rate limits
Spend attributed per task class, which is what turned the routing policy from a set of guesses into something evidence can correct.
03
Quality strategy
Gates must be fast and give the same answer every time. A gate that is slow or variable is a gate people work around — and then it is not a gate.
Test-first bug fixes
A failing test that reproduces the defect is written before the fix. The test is the acceptance criterion, and it is what stops the defect returning.
Automated pre-commit checks
Formatting, linting, type checking, secret scanning and content-schema validation on every commit. No model, no network call, identical result every run.
AI-assisted pre-push review
Once the deterministic gates pass, the diff is reviewed against the repository's invariants. A second perspective at the point where a single reviewer has consistent blind spots.
Human approval for production mutation
No threshold, no change-size exemption. 'Low risk' is an assessment made before the incident, and the assessment that fails is the one nobody questioned.
Deployment verification
Smoke checks against a documented expected state — not against the absence of alerts, because most failures here are silent.
Rollback by default
Behavior changes ship behind flags that default to off, so reverting behavior never requires reverting code.
04
Governance strategy
The hard part of agent systems is not making them capable. It is deciding what they may do, proving that boundary holds when things fail, and building a route from observation to action that an operations team will accept.
No secrets in prompts or repositories
Enforced by sensitivity classification before context assembly, and by a secret scan that blocks a commit and cannot be overridden.
Sanitized production data
Real recipient data, client data and credentials never enter a prompt. Diagnosis works from metrics and structure, not from records.
Read-only diagnosis before mutation
Diagnostic capabilities are registered without mutation rights. An incident is exactly when an autonomous system is most likely to be wrong.
Audit trails
Every agent attempt records status, timings, budget consumption and artifacts, so history is auditable rather than reconstructed from logs.
Approval gates
Human approval on every production mutation, enforced structurally for automated agents and by process for interactive work.
Capability restrictions
Actions name a capability that must exist in a registry, and the check fails closed — an outage denies rather than permits. Deploy, migration and security-adjacent capabilities are denied from automatic action by pattern, so a capability that does not exist yet is already covered.
Explicit project statuses
Every project on this site states an honest status. The agent governance work is labeled partially operational because it is — governance and retrieval work, broad autonomous remediation does not exist.
The shortest version
Written truth, assembled context, routing by task class, deterministic gates, and human approval at the boundary. The model is replaceable; the structure is what makes the output trustworthy — and being able to say precisely where a model is not allowed to operate is what makes it defensible to anyone responsible for the system.