The Cyborg Method: How to Build Apps in 2026

Five things that survive AI tool churn:

1. Encode intent in files
2. Let AI verify its own work
3. Build scaffolding that compounds
4. Persist memory across sessions
5. Make your project machine-readable

The method outlasts the moment.

The Speed Problem

Every “how I use AI” post has a half-life of four months. I wrote about my workflow six months ago. Half of it is wrong now. The tools I recommended have been replaced. The techniques I described are defaults now.

This is not that post.

The tools will keep changing. The question is: what stays? Patterns are emerging across projects, tools, and app types. Architectural choices that keep working regardless of which model or agent you run.

I call this the Cyborg Method. Not tied to a specific agent. Not dependent on a specific model. If you are still prompting, this is about going from prompting to architecture.

The Forcing Functions

Before the five principles, three rules.

Every tool in your stack must be optimizable for AI. Not “can AI use this tool?” but “is this tool the fastest path for AI?” Slack was clumsy for agents. Replaced it with Discord. Immediately better. Vanilla JS projects are harder for AI than TypeScript. Types give the AI constraints to work within. If a tool in your stack is incompatible with AI, replace it. Full stop.

Use repeatable stacks with templates and defaults you set up once. Your starter template should include CLAUDE.md, CI, branch protection, signing. All of it. TypeScript, not vanilla JS. If you start from scratch every time, you are paying a tax on every project.

Deterministic tasks happen through CLI and pipelines, not through agents. Do not ask an AI to do something a bash script can do reliably. Agents are for judgment. Pipelines are for execution. Builds, deploys, linting, formatting: pipeline work.

Principle 1: Encode Intent in Files

CLAUDE.md is not documentation. It is a project constitution. Objectives, constraints, values encoded as files the AI reads every session. They are instructions, not reference material.

One line in my CLAUDE.md says “No em dashes.” That single rule fixed infinite corrections across every session. Before that line existed, I corrected the same stylistic choice manually, every time, in every conversation.

I have a file called SOUL.md where the AI documents its own failure modes. One entry says “I lean toward appeasing the user rather than pushing back.” Now it catches itself. The file is the mirror.

If the AI has to ask you the same thing twice, it should be in a file.

Principle 2: Let AI Verify Its Own Work

Testing is not a quality gate. It is an acceleration tool.

The AI should be able to run, test, and verify without you watching. If you are the one checking “did it work?”, you are the bottleneck. Types, tests, linters: these are the AI’s guardrails, not yours.

My site has a pre-commit hook that runs astro check. The AI writes code, stages it, commits, and the hook catches type errors before I see anything. No human in the loop for that feedback cycle. The AI reads the error, fixes it, tries again.

Move yourself out of the loop.

Principle 3: Build Scaffolding That Compounds

Internal tooling compounds faster than anything else.

A five-line bash wrapper around claude sets up my entire AI dev environment. Commit hooks sync beads (my issue tracker) and run type checking. Skills encode repeatable workflows so the AI follows the same playbook every time.

My blog post skill chains: interview, research, draft, expert review, export. 66 minutes from idea to publish-ready for a recent post. One command.

My newsletter skill chains: interview, web fetch, expert council review, browser automation for screenshots. One command. The same workflow that took a full day now runs in an hour.

Every skill I write saves time on every future invocation. That is the compound interest. A 30-minute investment in a skill pays back on every project, every week, forever.

Invest in infrastructure that compounds.

Principle 4: Persist Memory Across Sessions

Context windows end. Sessions restart. Models change. If your AI forgets everything between sessions, you are starting over every time.

MEMORY.md holds institutional knowledge: conventions, gotchas, preferences. One entry says “Typefully separators don’t work.” That saved debugging time every single session. Without it, I would have hit the same wall, diagnosed the same issue, and reached the same conclusion, again and again.

For cross-session continuity on actual work, I use beads, a git-backed issue tracker. 157 issues created, 138 closed, 88% completion rate. Each issue survives context compaction, session restarts, and model changes. When I wrote “Be the Bark,” the essay spanned 3 sessions and 14 sub-tasks. Beads picked up exactly where I left off every time.

Persistence you don’t need beats lost context.

Principle 5: Make Your Project Machine-Readable

Humans read docs. AIs need machine-readable interfaces.

The llms.txt standard gives documentation sites a machine-readable index. 844,000+ websites have adopted it. Anthropic, Cloudflare, Docker, HubSpot among them. If your docs site does not serve llms.txt, your AI cannot read your docs efficiently.

OpenAPI specs turn your API into a tool the AI can call without you explaining endpoints. DeepWiki generates instant wiki docs from any GitHub repo. Replace github.com with deepwiki.com in any repo URL.

MCP (Model Context Protocol) is the universal connector. One protocol, any tool. Wrap a CLI as an MCP server. Now any agent can use it.

If a human needs docs, an AI needs a machine-readable interface.

Current Toolchain

The principles are durable. The tools are not. This section will age. That is fine. It is a snapshot of what works right now, March 2026.

Communication

Discord is king for AI-native teams. Bots are first-class citizens, channels are cheap, threads work well for agent updates. Slack was too clumsy. Too many permission hoops, poor bot DX, slow API. Telegram is a solid alternative with a good bot API.

The pattern: one channel per project, one channel for agent activity, human channels separate. Agents post status updates, ask for approval, share results. You respond when you want. Async by default.

Source Code

GitHub. Nothing else comes close for AI workflows. The gh CLI is excellent. Agents create PRs, manage issues, run workflows, all from the terminal. GitHub Actions for CI/CD. Fine-grained PATs over classic tokens, scoped to specific repos and specific permissions. The Rulesets API for branch protection works on Free tier, unlike classic branch protection.

Web Apps

Tool	What It Does
Playwright MCP	Browser verification. Navigate, click, screenshot, assert.
llms.txt	Machine-readable docs that agents can fetch
DeepWiki	Instant wiki from any GitHub repo
OpenAPI specs	Your API becomes a callable tool

CLI Tools

If your CLI only outputs for humans, AI cannot parse it. The checklist:

• --json for structured output
• --yes / --skip-interactive because agents cannot type “y” at prompts
• --dry-run / --check / --diff so AI can preview before committing
• Good --help text, because the AI reads it
• MCP wrapper for universal agent access

Mobile Apps (Expo)

Maestro MCP drives iOS Simulator and Android Emulator. Built into the Maestro CLI, no separate install. Add testID props for reliable element targeting. Without them, the AI is guessing at selectors. EAS Workflows for CI/CD with Maestro. The pattern: dev server + simulator + Maestro MCP. AI can build, launch, test, and screenshot.

Setting Up Local Agents

Everyone is writing “how I set up Claude Code” posts. I will not repeat the basics. A few points from shipping with it daily.

Minimal Setup, Maximal Leverage

Boris (who built Claude Code) and people like Naval prefer minimal configuration. I agree. The tooling will adapt to us, not us to it. Do not over-engineer your setup.

A good CLAUDE.md, good tests, and a few skills. That is 90% of it.

Skills Make or Break Your Agent

A skill is a repeatable workflow the AI follows. A playbook. Bad skills give vague instructions the AI interprets differently every time. Good skills have specific steps, clear outputs, and verification built in.

My blog post skill chains five phases: interview, research, draft, expert review, export. One command. Skills compound. Every skill you write saves time on every future invocation.

Plugins and Hooks

I built a plugin I install on every project. It includes a hook that blocks dangerous git commands: force push, reset —hard, checkout with the dot operator. The AI cannot accidentally nuke your working tree.

Permissions

I still do not run in YOLO mode. Not worth the risk. I approve tool calls. It keeps me in the loop. I will use a ralph loop (automated accept) if something repetitive is annoying. But selectively. If I needed ralph loops frequently, I would set up a proper sandbox first.

Isolation

Best practice: isolate Claude Code to your project directory. Do not give it your whole machine. Most people do not do this. Myself included. But I do not run in stranger-danger mode either. The tradeoff is convenience versus blast radius. Know where you are on that spectrum.

Setting Up Remote Agents

Local agents run on your machine, in your terminal, with your context. Remote agents run on a server. They pick up tasks, work autonomously, submit PRs. You review their work asynchronously. Like a junior dev who never sleeps.

OpenClaw

Open-source remote agent framework. Pulls issues, writes code, opens PRs. Skills are even more critical here because the agent has no human in the loop during execution. Guardrails matter more: branch protection, required reviews, CI gates.

OpenClaw pushed directly to main twice before we set up branch protection. No damage. But a wake-up call.

Remote Debugging

Tailscale + Claude Code on a remote server. Danger, but fast. SSH into a production-adjacent machine, run Claude Code there. Not for everyday use. For “the server is down and I need eyes on it” moments. Would not recommend without proper network segmentation and audit logging.

Experiments in Progress

• Code-graph-rag MCP server for codebase indexing
• DeepWiki-Open for self-hosted wiki generation
• OpenClaw review skills from ClawHub for automated PR review on agent-generated code
• Comparing codebase indexing: Repomix vs code-graph-rag vs DeepWiki-Open

Results will go here as they land.

Guardrails

The uncomfortable truth: anything an AI can do, it will do eventually. Not out of malice. Out of probability. Run enough sessions and every edge case becomes inevitable.

Words Are Not Controls

Telling an AI “don’t push to main” in a prompt is like telling a coworker “don’t push to main” in Slack. It works until it does not. You need actual controls. Branch protection rules, not instructions. CI gates, not suggestions.

If the only thing stopping a bad outcome is a sentence in CLAUDE.md, that is not a guardrail. That is a wish.

The Checklist

Every new repo gets the same bootstrap. Automate it or you will skip steps.

#	Item	Why
1	CLAUDE.md with goals, constraints, conventions	Intent (Principle 1)
2	Branch protection via protect-repo.sh	Agents cannot push to main
3	CODEOWNERS	You review everything
4	CI pipeline (build + test + lint)	Verification (Principle 2)
5	OpenClaw review skills on agent PRs	Second pair of eyes
6	Label Action (agent:openclaw, agent:claude-code)	Traceability
7	Scoped fine-grained PAT	Least privilege
8	Commit signing (SSH key + vigilant mode)	Provenance
9	Secrets in age/sops or 1Password	Never in env vars or repos
10	.gitignore (secrets, .env, node_modules)	Defense in depth
11	First commit co-authored and signed	Sets the standard

protect-repo.sh

Automate branch protection via GitHub Rulesets API. One script, every repo.

#!/usr/bin/env bash
set -euo pipefail

REPO="${1:?Usage: protect-repo.sh owner/repo [branch]}"
BRANCH="${2:-main}"
ADMIN_USER="ryanlabouve"

ADMIN_ID=$(gh api "/users/${ADMIN_USER}" --jq '.id')

gh api \
  --method POST \
  -H "Accept: application/vnd.github+json" \
  "/repos/${REPO}/rulesets" \
  --input - <<EOF
{
  "name": "Protect ${BRANCH}",
  "target": "branch",
  "enforcement": "active",
  "conditions": {
    "ref_name": {
      "include": ["refs/heads/${BRANCH}"],
      "exclude": []
    }
  },
  "bypass_actors": [
    {
      "actor_id": ${ADMIN_ID},
      "actor_type": "User",
      "bypass_mode": "pull_request"
    }
  ],
  "rules": [
    {
      "type": "pull_request",
      "parameters": {
        "dismiss_stale_reviews_on_push": true,
        "require_code_owner_review": false,
        "required_approving_review_count": 1,
        "required_review_thread_resolution": false
      }
    },
    { "type": "non_fast_forward" },
    { "type": "deletion" },
    { "type": "required_signatures" }
  ]
}
EOF

Uses the Rulesets API, which works on GitHub Free for private repos. bypass_mode: "pull_request" means even you cannot push directly. Agents have no bypass entry, so they are fully blocked from main.

Batch all your repos:

gh repo list OWNER --json nameWithOwner --jq '.[].nameWithOwner' \
  | xargs -I{} ./protect-repo.sh {}

Automate the guardrails. If setup is manual, you will skip it on the third repo.

The Audit

The principles are checkable. Here is how to score any project.

Baseline (Every Project)

• CLAUDE.md exists with goals, constraints, conventions
• Tests exist and the AI can run them without help
• CI pipeline runs on every PR
• Branch protection enabled on main
• Commit signing configured
• Secrets managed properly
• .gitignore covers secrets, .env, node_modules
• Skills defined for repeatable workflows
• Memory system in place (MEMORY.md, beads, or equivalent)

Web App

• Playwright MCP or browser automation configured
• OpenAPI spec exists for APIs
• llms.txt served from documentation sites

CLI

• Structured output supported (--json)
• Non-interactive mode (--yes, --skip-interactive)
• Dry-run mode (--dry-run, --check)
• MCP wrapper for agent access

Mobile App

• Maestro MCP configured for simulator control
• testID props on interactive elements
• CI runs Maestro tests

Not everything applies to every project. A CLI does not need Maestro. Start with baseline. Add module-specific checks as your project grows.

Build for the Method

You do not adopt the Cyborg Method all at once. Start with CLAUDE.md. Then add tests the AI can run. Then a skill. Then memory. Each one compounds.

The feedback loop gets tighter: spec, generate, test, review, refine. Every principle you add shortens the cycle.

Six months from now, the tools I use will be different. The models will be better. The MCPs will have changed. But I will still have intent files. I will still have verification loops. I will still have memory. I will still have guardrails.

Build for the method, not the moment.