Self-Driving Codebase: A Practical Guide

Self-driving codebases: how, what, why, practical and no BS. Based on my work with multiple companies at Scoreinforce.

What changed on the products I run this way

• Before: 3-5 devs, a QA and a PM per initiative. Now: one engineer, one PM, a fractional QA across five products.
• Five initiatives a quarter became one a week.
• On one product the PM is the second-biggest contributor: ~50 merged PRs in four months.
• Every morning 5+ PRs are waiting, half get merged, 2+ tickets close before the day starts.

Four questions to ask your CTO

1. Can we boot ten copies of our product on one machine tonight? If not, agents cannot work in parallel, and this is where the work starts.
2. Does an agent have the same tools we use to know a feature works: the browser, CI, the database, the logs?
3. Where does our knowledge live: in people’s heads, in a wiki, or in the repo where an agent can read it?
4. Can a PM change a piece of UI and get it merged without an engineer writing code?

Four yeses: you are already there, skip to the summary. Any no is normal, and it is a 90-day fix. The rest of this post is the fix: the readiness checklist is the engineer’s version of these four questions, and the six recommendations get you to yes. Send it to your CTO.

Not sure how your codebase answers these? That is what our two-week agent-readiness assessment tells you: a scorecard per repo, the walls, and the first three fixes. Book the assessment.

Why you are no longer engineering-bound

You can reach a place where you are no longer engineering-bound: you can build anything at record speed. The only limiting factors would be distribution, customer feedback, running pilots, and getting the feedback and data to tune the product.

Before: 3-5 devs, a QA and a PM per initiative. Now: one engineer, one PM, fractional QA across five products. Five initiatives a quarter becomes one a week.

This setup is possible and achievable, but it does not happen overnight. Let’s look at the levels.

The four levels of coding-agent adoption

I split this into four levels: LLM, agent, orchestrator, platform. The split is not exact, but it helps me understand the progression and see where a team actually is. Depending on where you are in your journey, some of this you already know.

Level 1: LLM

It’s very hard to master these tools without strong fundamentals and an understanding of how they work. If you don’t have time to spend two years learning linear algebra and probability theory, just watch this tutorial from Andrej Karpathy.

Category	Options
Closed models	Fable 5, GPT-6 Astra
Open-weight models	Kimi-K3, GLM-5.3
Providers	Fireworks, Together
Further reading	Agent Swarm, CS336: Language Modeling from Scratch

Open-weight is not open-source: you get the weights, not the data or the training code. One nuance that matters in practice: whoever trains the model and builds the harness has an unfair advantage, because they train them together. The same model gives you a very different experience in different CLIs.

Level 2: Coding agent

Now, why are LLMs so useful? Because you give them tools and context!

Agent = LLM + Actions + Context
A coding agent takes actions such as writing and running code.

“Agent” has become an overused word, so my definition is that simple. Running code is the action that makes coding agents so useful and why software engineering adopted them first. I live in the CLI now; the only thing I still open an editor for is markdown.

Category	Options
CLI agents	Claude Code CLI, Codex CLI, OpenCode
Further reading	The Coding Agent Is Dead, The Modern Software Dev, Sunset Roo Code

TLDR: Today, you get most of the frontier features from CLI agents.

Level 3: Fleet of agents

This is where it becomes interesting: now you want to move from one agent to managing a fleet of agents.

Once you are comfortable one-on-one with an agent per feature, you scale: multiple features with multiple agents, or one feature with several agents. What is the right slice of work per agent? There is no clear guidance; it’s still an art. What I see is that tasks get bigger and my level of detail gets smaller.

I run mine on a VM, because I travel and don’t want to keep a laptop open. I prompt them before I disconnect for the night and check the results in the morning.

Category	Options
Cloud agents	Claude on Web, Codex on Web, Cursor Agents
Management	Warp, Cmux, mngr, entire
Security	Generate temporary credentials, Agent Vault

Level 4: AI-native SDLC

And this is the most interesting part: how do you integrate and scale this as a process? The full lifecycle: Plan, Build, Review, QA, Maintain.

You are not going to run a serious business on a vibe-coded product yet, but those tools show where this goes. Every company becomes a Replit: the engineering team builds a machine that runs a machine, sets the guardrails and the roads, and everyone else in the company drives.

Category	Options
Vibe-coded	Replit, Lovable
AI SDLC	Factory, custom-defined

Agent-ready codebase: the readiness checklist

This is the engineer’s version of the four questions at the top.

Where are you? At a high level, you need to answer these four questions:

1. Codebase setup and fundamentals
2. Context and harness
3. Feedback loops
4. Enabling non-engineers to contribute

1. Codebase Setup

Your codebase should be set up for an agent, not only for humans. A good test: can you spin up 10 instances of your product on one machine? The counterintuitive part is that the worse your basic engineering practices, the harder it is to work with coding agents. Feature branches and environments on demand used to be nice-to-haves that always lost the priority fight. Now they are where the value comes from.

• Locally bootable end-to-end
• Runs per worktree: claude -w feature-one
• You can spin up 10 or 100 in parallel
• Feature branches and feature flags
• Deploy from a branch without merging
• CI survives 10x more PRs tomorrow

Requires good basics.

2. Harness / Context / Wiki

The agent’s toolkit:

• Set of knowledge bases, skills, subagents, hooks, references
• Kept up to date by a background agent
• Most important: keep plans, design docs, and architecture decision records

This is the hardest and most opinionated part. Every dead end the agent hits is a lesson you compile into the harness and reuse. You can fix one bug faster than a coding agent, but you cannot fix hundreds of bugs faster than a coding agent. So instead of fixing the bug, write down why the agent couldn’t, and commit that.

Reference: Harness engineering
Example structure:

AGENTS.md
ARCHITECTURE.md
docs/
... design-docs/
... exec-plans/

3. Feedback Loops

Good context is half the answer. The other half is giving the agent your verification mechanism so it can run it on its own. Ask yourself what gives you confidence that a feature works: you click through it, you deploy it, you check the logs, you query the DB. Give the agent the same tools. Every time I copy-paste an error message into a prompt, that’s a loop I should have built.

How agents self-correct:

• Test, style, checks: your agent should run them.
• UI loop: agent drives a browser, clicks, and provides evidence.
• CI loop: agent uses gh to monitor PRs, address reviews, and restart jobs.
• DB loop: agent queries the database with read-only temporary credentials.
• Observability loop: agent connects via MCP/CLI to logs and metrics, and cross-checks services.

4. Enabling non-engineers to contribute

Bug → Backlog → Priority → Sprint. This process is gone.

• PMs can write customer-specific documentation much better
• Designers should be able to update the UI independently
• QA is the next bottleneck after coding

There is a yes part of the codebase and a no-no part. PMs and designers can change UI and flows; they cannot touch Terraform, DB schemas, or tests. It’s Lego blocks with guardrails, everything goes through a PR, and about 80% merges after a short chat with the agent. The pushback I get in regulated environments is that every change still needs an engineer to review and sign. Fair. Keep the responsibilities, change the how.

No company has everything. If you did, you would be prioritizing developers over the product.

Six practical recommendations for an AI-native SDLC

1. Context: Build context over time

This is your machine that builds the machine.

I start from an architecture guide, add data flows and the reasons behind decisions, and every time I burn a lot of tokens on something, I turn it into a skill or a reference and commit it. Pre-generating all of this with an LLM is a start, not a harness. Call me a markdown developer now!

Follow the structure from https://openai.com/index/harness-engineering/. Mine after half a year on one codebase:

CLAUDE.md               # boot, test, deploy, conventions; under 200 lines
ARCHITECTURE.md         # folder tree + data flow, one line per module
docs/
  exec-plans/           # active/, completed/, adr.md with plan -> PR -> merge date
  features/             # one page per shipped feature
  platform/             # CI, sibling repos, how to reach envs
  reference/            # logs, model benchmarks, external API quirks
.claude/skills/         # ~20 skills, 100-400 lines each, with exact commands

Rules: durable knowledge goes in the repo, not agent memory, because sessions run from many agents and machines and the repo is the only store they all see. And the harness updates itself via a background agent.

The better your context layer, the better the agent performs. Continual Harness is an interesting idea, but honestly you can just automate this update and get the same result.

2. Remove development from local machines

Your time is not scalable and your laptop is not scalable either. Remove all development from your local machine and move to a remote setup. It can be very simple: one EC2 VM, Claude Code in tmux. Just do it.

The setup:

ssh dev-vm
claude --name feature-x --worktree feature-x --tmux

Why I did it:

• Agents run for hours. A typical session runs 2 hours and burns only 80K tokens, because most of the time it waits: for CI, for a deploy, for a DB query. My laptop closes, loses Wi-Fi, goes on a plane. The VM does not.
• Overnight is where the work happens. I plan my day, set a goal, run the agent overnight and review in the morning. It’s like having an employee who works while you sleep.
• Resources. I run a full copy of the stack per worktree: every service, every DB, in Docker. That’s tons of containers. No laptop handles 5 of those side by side.
• Compliance. Customer data stays on the VM, never on my machine. Onboarding gets easier when you can say “nothing lives locally”.

Once local dev is not the bottleneck and the VM gives you durability, you can go further: dev containers in Kubernetes or a platform like mngr. For me the VM is the right balance of control, hand-holding and custom use cases, like the one where I need 20+ containers up to get proof that something works.

3. Multiple repos: Working with multiple repos from one harness

A feature rarely lives in one repo: backend, UI, data, infrastructure. The split into backend, frontend and infra teams stops making sense when one agent can change all of them. One harness, one agent, 10+ PRs in 10+ repos.

A worktree is the whole system side by side. A WorktreeCreate hook clones the sibling repos into it, and each sibling has a page in docs/platform/ with how to boot it and where its API lives. The harness repo is the control tower: a PM describes the issue there, the agent finds the repo.

Start from the initiative, not the ticket. Build it end-to-end across repos in one worktree, prove it works, then carve it into 5-7 reviewable PRs and merge in sequence.

4. Layers of verifiers

This is your main job as an engineer now: define good verification and get proof that the agent’s work works.

This is the hardest and most important part. Remember the test pyramid? Same deal for coding agents: layers of verifiers around the build, and every failed layer sends the agent back to build. The code is probably fine and the tests are probably fine, but I want proof before I spend my time reviewing.

Verifier	What the agent does with the app	Tool
QA Local	Runs the app in the worktree, clicks through, records a video, commits a Playwright script	agent-browser
CI	Opens N PRs, makes them green, addresses bot and review comments, deploys to staging	glab / gh
QA Staging	Waits until every branch is deployed, runs the Playwright scripts of every feature page, returns a verdict table	agent-browser with creds
Database	Reads the records back to confirm what the UI shows is what got written	psql / any DB MCP
Logs & Metrics	Reads traces and errors after the deploy; for LLM features, scores a sample of production runs	Datadog MCP

One night: build, open PRs, fix CI, deploy from the branch, read the logs back, commit the Playwright script. Morning: a PR with proof.

AI product? Add an Eval verifier: collect traces, label them, score every run. Evals beat background agents here, and they let you auto-tune prompts.

Once you trust the chain, read less: give every PR a risk score and let the low-risk ones merge without you.

5. Guardrails for non-engineers

PM, QA and design should be in a position to merge code. On one product the PM is the second-biggest contributor: ~50 merged PRs in four months, mostly the consumer-facing report, compliance footers, the analytics dashboard and a couple of API endpoints. No engineer wrote that code; the engineer reviewed the proof.

My model: I build the first pass rough on purpose, the PM finishes wording, flows and layout while API and infra stay fixed. Nine of ten PM PRs help; one I take over.

Right now this is simple: if it’s a UI change, I’m confident my verifiers catch anything that matters. The rule is the verifier chain from point 4, not a person. Good verifiers are what make a safe environment for non-engineers to contribute, so every hour spent on verification is also an hour spent widening who can ship.

6. Outsource to background agents

Build 10x faster and you own 10x more product: more bugs, more tickets, more docs going stale. Outsource support, bug fixes and maintenance to background agents, scheduled coding agents with no human in the loop that show up every morning with an PR to review.

The implementation is a skill as the spec, a thin run.sh that runs it in CI, and a pipeline schedule. One agent, one responsibility, one small PR with a ## Proof section.

Scope	Agent	What it does
Per product	Improve	ONE tiny, behavior-preserving refactor per night, under 150 lines
Per product	Architect	ONE verified architecture finding per day, shipped with the first slice of the fix
Per product	QA	Click through every feature on staging with real creds; bugs become tickets
Per product	Evaluate	Score a sample of yesterday’s production runs; push scores to observability
Per product	Feedback	Read yesterday’s production traces, ship ONE improvement with red/green proof
Per org	Harness	Keep the docs harness in sync with code and merged PRs
Per org	Triage	Triage the board against live code; advance exactly ONE task
Per org	Do one ticket	Triggered on demand with a ticket id; fixes that ticket and opens the PR

Per product means one per product in a monorepo. Not rosy at the start: 90% went to the bin, I had ~800 closed PRs before the ratio improved, and I still tune the skills daily from merged vs closed. The outcome: maintenance is very low, every morning 5+ PRs wait, half get merged and 2+ tickets get closed before I start the day.

What a CEO will worry about, and how it is contained

• Customer data. Development moves to a VM you control. Nothing lives on laptops. Compliance gets easier.
• Regulated environments. Every change still goes through a PR and a named reviewer. Keep the responsibilities, change the how.
• Quality. The verifier chain is the gate. A PR does not reach a human without proof it works.
• Lock-in. The harness is markdown, scripts and CI config in your repo. It works with Claude Code today and with the next agent tomorrow.
• Dependence on us. The harness updates itself through background agents. The engagement ends with your team owning it.
• The ramp. The first months are ugly: 90% of early background-agent PRs went to the bin, and it took ~800 closed PRs before the merge ratio was good. Plan for a ramp before the maintenance load drops.

Summary: what a self-driving codebase needs

Three things you need to be ready:

1. Codebase setup. Boots end-to-end locally, runs per worktree, 10 copies on one machine.
2. Harness. CLAUDE.md, ARCHITECTURE.md, docs, skills. Updated by a background agent, not by you.
3. Feedback loops. Every check you do by hand, the agent can run on its own.

Six practical lessons:

1. Context. Build it over time. Every burned token becomes a skill or a reference in the repo.
2. Remote dev. One VM, tmux, worktrees. Your laptop is not scalable.
3. Multiple repos. One harness, one agent, 10+ PRs in 10+ repos. Start from the initiative, not the ticket.
4. Layers of verifiers. Agent Build, QA Local, CI, QA Staging, Database, Logs & Metrics. Your job is to define verification and get proof.
5. Guardrails for non-engineers. The verifier chain is the rule, not a person. PM, QA and design merge code.
6. Background agents. Skill + run.sh + schedule. Maintenance goes to agents; you review PRs in the morning. Expect a ramp before the merge ratio is good.

Get these right and you are no longer engineering-bound.

For the business: one engineer and one PM across five products, one initiative a week, and PMs who ship. That is what “no longer engineering-bound” means.

Get your codebase assessed

If you have a product, paying customers, and features waiting on engineering, start with the assessment: two weeks, a scorecard per repo, and a plan you can hand to your CTO. Book the assessment.

Kyryl Truskovskyi runs Scoreinforce. Previously at Georgian, where he helped portfolio companies with machine learning. He now makes SaaS codebases agent-ready and builds the first background agents with the team. LinkedIn