Problem statement

The issue was not only code. It was ownership around the code.

We saw a repeated problem: when the same AI actor is expected to build the application, prepare the infrastructure, deploy the result, and diagnose the running system, the repo and the operating context blur together. The issue that needed to be resolved was not just a bug in code, but a lack of clear separation between app-building work and DevOps-style deploy-and-diagnose work.

1core issue: blurred ownership between coding and operating
2distinct lanes after the fix: repo-building and deploy-and-diagnose
4stages in the resolved loop: build, lock, deploy, diagnose
Developer and local AI

Code the application inside the repo, resolve feature issues, and move the product forward through the development method.

Pubert's DevOps function

Read the repo context, preserve continuity, prepare the environment, deploy the result, and diagnose what is happening around the running system.

Ratcheting protocol

Control the handoff: lock the slice, constrain the change, verify the outcome, and keep progress forward-only and auditable.

01

The issue the AI needed to code around

ISS

Blurred ownership

The same conversation thread was carrying coding, environment setup, deployment, and diagnosis at once, which made it unclear where one responsibility stopped and the next began.

  • Repo work and infrastructure work were too easy to mix together.
  • Diagnosis could turn back into unstructured coding.
  • The operating context risked becoming invisible.
COD

The coding lane

The AI coding issue to resolve was inside the repo: features, fixes, structure, and vertical slices that make the app itself work.

  • The developer and local AI own application changes.
  • The repo remains the place where the product is built.
  • The development method keeps those changes spec-driven and verified.
OPS

The operating lane

Pubert's role is around the repo rather than inside every coding decision: deploy, diagnose, maintain continuity, and make the system legible between sessions.

  • Pubert acts like a DevOps team member.
  • It can read the repo context without owning the app build itself.
  • It keeps deployment and diagnosis from collapsing back into ad hoc work.
02

What changed after the issue was resolved

before

Mixed concern loop

  • The AI could code, deploy, and diagnose without a clear boundary.
  • Repo changes and environment changes were easy to conflate.
  • Every issue risked reopening the whole stack.
after

Segmented concern loop

  • The developer and local AI build the app in the repo.
  • Pubert handles continuity, deployment, and diagnosis around that repo.
  • The ratcheting protocol controls the handoff and verification.
03

The resolved workflow

1. Build

The developer and local AI code the issue in the repo and move the application slice forward.

2. Lock

The ratcheting protocol fixes the scope, notes, and verification path so the change is bounded.

3. Deploy

Pubert uses the prepared operating context to deploy the result without re-deciding the repo's intent.

4. Diagnose

Pubert reads what happened in the running system and feeds the next issue back into the local development loop.

Problem statement, resolved: the AI coding issue was not only to change code, but to establish a reliable boundary where local development builds the app, Pubert operates the environment, and the ratcheting protocol governs the handoff between them.
Sample pages Back to development method Open current applications What this process solves Design generation AI iteration