Abstract software delivery architecture converging into an independent amber release chamber
|

If Your Coding Agent Owns the Repo, Rehearse the Exit

ByLukas Hertig

The code is portable. The delivery system around it often is not.

That distinction matters more now that coding agents are moving beyond autocomplete. They can open issues, create branches, write tests, review pull requests, trigger CI, remember repository-specific instructions and propose releases. The repository host is no longer just where Git objects live. It is becoming the control plane for software production.

For IT services firms, MSPs, hosting companies and development shops, that creates a familiar infrastructure risk in a new form: the team can still clone the repository, but it may no longer be able to reproduce the service.

I have spent more than 20 years in hosting and Linux infrastructure. The rule has not changed: a backup is a promise; a successful restore is evidence. When we scaled software from €600,000 to €240 million ARR, operational ownership never came from a contract or an export button. It came from knowing which state mattered, who owned it and whether the system could be rebuilt under pressure.

Here’s what works: run a Repository Exit Drill before an integrated coding-agent platform becomes critical. Not a procurement questionnaire. Not a PDF continuity plan. A real release from a clean destination, completed within a measured recovery window.

Git portability is only the first layer

Git gives you an unusually strong portable core. Its object database stores content as blobs, directories as trees and history through commit objects; refs make that history usable.[1] A mirror clone can preserve the Git object graph and refs. That is valuable, but it is not the same as preserving the operating system around delivery.

GitHub’s own backup guidance separates the repository from other assets. It documents the Git CLI for repository backups, a separate process for Git Large File Storage, a separate wiki repository, APIs and migration archives for selected metadata, and third-party tools.[2] The structure of the documentation is the evidence: “the repo” is already several recovery surfaces before an agent writes its first line of code.

Now add the surrounding state:

  • issues, pull requests, reviews, comments and release records;
  • branch protections, rulesets, environments and approval policies;
  • user identities, teams, permissions and service accounts;
  • CI workflows, runners, caches, packages and build artifacts;
  • webhooks, installed apps and external deployment integrations;
  • secrets, signing keys, tokens and workload identities;
  • agent instructions, memory, plans, tool permissions and evaluation history;
  • audit records showing who or what changed production.

A normal clone does not prove that these surfaces can move. An API export does not prove they can be imported. A successful import does not prove the next release will work.

GitHub Enterprise Importer is a good example of the right operating posture. GitHub says customers can run migrations repeatedly before production and allows some migrations to continue with non-critical errors, such as a pull-request comment that did not move; operators then review a migration log.[3] That is not a criticism of the tool. It is a reminder that migration is a reconciliation exercise, not a binary export-success event.

The Repository Exit Drill

The Repository Exit Drill is a five-layer recovery test. Its output is not “we downloaded everything.” Its output is: we shipped a verified release from a clean control plane, within our target recovery time, with known and accepted gaps.

Repository Exit Drill: five recovery layers from Git core to a clean-room release

Layer 1: Preserve the canonical Git core

Start with the part that should be portable: every required repository, branch, tag, submodule and large-file object. Record the source commit IDs, generate the destination refs and compare them.

Do not settle for “clone completed.” Run integrity checks. Confirm protected release tags. Build from the destination. If a repository depends on private submodules, generated code or a package that only exists in the old platform, the Git layer is not independent yet.

Proof artifact: a signed manifest of repositories, refs, object checks and LFS coverage, plus a clean build tied to a specific commit.

Layer 2: Reconstruct collaboration history

The team needs more than source code. Open work, review decisions and release context carry operational knowledge. Export issues, pull requests, comments, labels, milestones, attachments and links between them. Then sample the result from the perspective of a developer arriving during an incident.

Can they see why a security-sensitive change was approved? Can they find the open release blocker? Do references between issues and commits still resolve? Measure record counts, missing relationships, attachment failures and identity-mapping exceptions.

Do not demand perfect historical fidelity if it adds no operating value. Define the minimum viable history by consequence. An old emoji reaction is not equal to a missing approval on a production change.

Proof artifact: a reconciliation report that grades missing records by operational consequence, not just volume.

Layer 3: Rebuild the execution path

This is where many “portable” repositories stop being portable. Recreate workflows, runners, deployment targets, package registries, artifact retention, environment gates and rollback paths. Replace platform-specific actions where necessary. Pin dependencies you cannot trust to remain available.

Then replay one real release. Use the destination repository as the canonical source. Build the artifact, run the test suite, pass approval gates, deploy to a non-production target and execute the rollback procedure.

Track the time spent rebuilding each dependency. That becomes your real switching-cost ledger. If 70% of the drill is consumed by one proprietary build service or an undocumented webhook, you have found the risk worth removing.

Proof artifact: a release record from the clean-room host, including build provenance, test results, deployment evidence and rollback evidence.

Layer 4: Re-establish identity and control

Credentials should not be copied blindly. Recreate identities, permissions, secrets and signing flows from authoritative systems. Map human users, teams, bots and workload identities. Confirm least-privilege access and revoke the drill credentials when the test ends.

This layer needs negative tests. Can an unapproved agent bypass a protected branch? Can a former service account still trigger deployment? Does the destination preserve required separation between author, reviewer and deployer? Can the kill switch stop automated writes without taking read access away from responders?

NIST’s contingency-planning guidance asks organizations to evaluate systems and operations so they can determine recovery requirements and priorities.[4] Apply that logic here: define the maximum tolerable outage, the acceptable data gap and the control set that must exist before delivery resumes.

Proof artifact: an identity-and-policy diff, failed-bypass test results and an approved list of temporary exceptions.

Layer 5: Recover the agent operating context

Agent state is the newest and least standardized layer. Inventory repository instructions, system prompts, planning files, codebase indexes, tool configurations, policy rules, evaluation cases, accepted-risk decisions and durable memory. Separate what is stored in the repository from what exists only in a vendor account.

Do not migrate opaque memory just because it can be exported. Rebuild the minimum context required for safe performance, then test it. Give the agent a representative task on the destination platform and compare:

  • files changed and tests selected;
  • policy violations and denied tool calls;
  • review defects and human correction time;
  • token and compute cost;
  • ability to explain the change and cite repository evidence.

The objective is not identical output. It is acceptable delivery under the same engineering controls.

Proof artifact: a destination-side agent acceptance report against a fixed task set.

Measure an exit, do not merely document it

Every drill should produce six numbers:

  1. Recovery time: elapsed time from “source unavailable” to verified release.
  2. Recovery point: the newest source, metadata and artifact state recovered.
  3. Reconciliation exceptions: missing or transformed records, graded by consequence.
  4. Manual rebuild hours: skilled effort needed to restore execution and controls.
  5. Release acceptance rate: required checks passed on the destination.
  6. Residual dependency count: old-platform services still required after the release.

Use median time for repeated technical steps, but report the worst dependency and the longest manual queue separately. A comfortable average can hide the one signing key, runner image or approval mapping that blocks the release.

Set the decision before the drill:

  • Scale the platform if the release succeeds inside the target window and residual dependencies are owned.
  • Redesign if the release works but depends on undocumented state, heroic access or excessive manual rebuilds.
  • Stop expansion if the team cannot produce a release, cannot reconstruct authorization or cannot explain what agent context was lost.

This is not an argument against integrated platforms. Integration can remove enormous friction. The operating mistake is consuming that speed without pricing the exit cost.

A 30-day proof path

You do not need a six-month resilience programme. Pick one representative repository and prove the route in 30 days.

Days 1–5: Map the delivery dependency graph

Choose a repository that is important enough to expose reality but not so critical that the drill becomes political. Inventory the five layers. Name an owner for each dependency. Define the recovery-time target, acceptable data gap and minimum release acceptance criteria.

Days 6–10: Export and reconcile

Create the Git mirror, LFS copy and metadata exports. Capture current policies, identities, workflows, packages, artifacts and agent context. Store the recovery package outside the source platform. Reconcile counts and relationships; do not wait for migration day to discover unsupported objects.

Days 11–18: Build the clean destination

Provision a clean host with new credentials. Restore Git and minimum viable metadata. Recreate runners, registries, policies and deployment connections from code or controlled configuration wherever possible. Log every manual step and every old-platform dependency.

Days 19–24: Replay a release

Run the build, tests, approvals, deployment and rollback from the destination. Execute one agent task against a fixed acceptance set. Record defects, exceptions, correction time and elapsed recovery time.

Days 25–30: Remove the largest lock-in point

Fix the single dependency with the highest combination of outage impact and rebuild effort. Convert a manual runner setup into code. Move agent instructions into version control. Export release evidence to owned storage. Replace an opaque webhook with documented automation. Then rerun the failed portion.

At day 30, leadership gets a one-page evidence pack: tested recovery time, known data loss, manual hours, control exceptions, residual dependencies and a scale/redesign/stop decision.

Ownership is a tested capability

After 15-plus acquisitions and two exits at a €1.5 billion valuation, I have seen the same pattern in diligence and operations: confidence disappears when the answer to a hard systems question depends on one person saying, “I think we can recover it.”

The hidden door is to make portability a quarterly release exercise rather than an emergency migration project. Rotate one repository each quarter. Keep the destination disposable. Track recovery time and residual dependencies like any other engineering reliability metric. The drill becomes cheaper, while your negotiating leverage improves.

Coding agents will keep absorbing more of the delivery system. That is useful. But if the agent, repository, CI, policy and memory converge into one control plane, ownership has to be demonstrated outside it.

Thirty days to proof. One clean destination. One verified release.

Book a 30-minute strategy call

Sources

[1] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects — Git Objects
[2] https://docs.github.com/en/repositories/archiving-a-github-repository/backing-up-a-repository — Backing up a repository
[3] https://docs.github.com/en/migrations/using-github-enterprise-importer/understanding-github-enterprise-importer/about-github-enterprise-importer — About GitHub Enterprise Importer
[4] https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final — NIST SP 800-34 Rev. 1

Similar Posts