The Coding Agent Changed. The Engineering Method Stayed in the Repository.

A developer built RepoMethod, a system that keeps an AI coding agent's engineering method inside the Git repository rather than in model-specific prompts, and tested it with ChatGPT on a Fastify TypeScript service. In the demo, ChatGPT aligned the GET /items endpoint with the existing pagination pattern of GET /tasks, but an initial run was blocked when the sandbox could not perform a normal git clone, prompting the agent to report a blocked delivery verdict instead of faking success. The project establishes a repository-owned delivery contract that runs against a real local Git working tree tied to a known remote revision.

Coding agents can already do meaningful repository work. The interesting engineering problem is increasingly how much autonomy we can give them while keeping scope, verification and delivery under deterministic control. I built RepoMethod to keep that method in Git instead of inside one model-specific prompt. This post walks through the real ChatGPT demo and the repository-level delivery contract behind it. Which repository state is the agent actually working from? Which files is it allowed to touch? What counts as finished? What happens when the normal tests are green but the requested change violates the agreed scope? I built RepoMethod around one idea: The agent can change, but the engineering method should stay in the repository. I tested that with ChatGPT against a deliberately ordinary Fastify TypeScript service. The feature was simple: GET /tasks already supported pagination, while GET /items did not. ChatGPT had to bring /items in line with the existing pattern. The interesting part was not the implementation. It was getting ChatGPT, GitHub, a local execution environment and a repository-owned delivery contract to work together for real. RepoMethod: https://github.com/frederik-schmittel/repomethod https://github.com/frederik-schmittel/repomethod Demo repository: https://github.com/frederik-schmittel/repomethod-demo https://github.com/frederik-schmittel/repomethod-demo My first attempt failed for an environment reason. ChatGPT could access the connected GitHub repository, but the sandbox could not rely on a normal git clone . Direct GitHub network access failed, so the agent could modify repository content remotely but could not execute the full local RepoMethod workflow. It correctly refused to fake success: DELIVERY: blocked — Classic workflow state, handoff, agent-gate and deliver.sh could not be executed in the available runtime. That failure exposed the right mental model: GitHub connector authoritative remote state ↓ local working copy disposable execution environment ↓ RepoMethod repository-owned engineering contract ↓ verified result ↓ GitHub publication The transport between GitHub and the local workspace may change as ChatGPT evolves. The invariant is what matters: RepoMethod must execute against a real local Git working state that corresponds to a known remote revision. The successful run made that execution boundary explicit instead of assuming a normal clone would exist. This is the reusable pattern: Work on the connected GitHub repository OWNER/REPO . Use the connected GitHub repository as the authoritative source for the current repository state. Do not depend on git clone or direct GitHub network access working in the sandbox. Establish a local working copy from the current main state using the connected repository as the source of truth. If that local workspace is not already a Git working tree, initialize Git and record the materialized main snapshot as the clean baseline before feature work. The repository method must operate against a real local Git working tree. Read AGENTS.md and the installed RepoMethod instructions first. Follow the repository-owned method as authoritative. Use RepoMethod Classic. Implement FEATURE, using EXISTING REFERENCE as the reference implementation. Before writing implementation code: - inspect the existing reference behavior and relevant tests - create the RepoMethod feature spec - initialize and follow the Classic workflow Keep the change minimal. Run the repository-defined verification and complete RepoMethod delivery. Do not invent a substitute workflow or fabricate a delivery verdict. Create a task branch from current main . Only after successful RepoMethod delivery, commit and publish the verified feature state. Do not create a pull request or merge anything. Report the branch, remote commit SHA, verification result and final DELIVERY: verdict. For the demo, the concrete values were: repository: frederik-schmittel/repomethod-demo feature: GET /items pagination reference: GET /tasks feature slug: items-pagination branch: task/items-pagination That prompt does not tell ChatGPT how to implement pagination. The repository already contains that knowledge. The extra detail is about execution integrity: source state, local baseline, real RepoMethod execution and publication only after verification. RepoMethod had already been installed and committed as part of the repository baseline. The repository verification command was: npm run lint npm run typecheck npm test npm run build That lived in: .repomethod/verify-command ChatGPT then read the repository instructions, inspected the existing /tasks route and tests, created specs/items-pagination.md , initialized RepoMethod Classic and implemented the smallest matching change in /items . The implementation itself was intentionally boring. It reused the existing pagination helpers instead of inventing a second pagination design. The first RepoMethod verification did not pass immediately. The TypeScript implementation was fine, but the generated evidence report was not explicitly bound to the feature spec. RepoMethod rejected it as stale evidence and used the Classic retry path. After that evidence binding was corrected, the retry verification passed. This matters because RepoMethod was checking more than whether the application compiled. It was checking whether the repository's evidence, scope and acceptance contract were internally consistent. The repository checks passed: Test Files 4 passed 4 Tests 21 passed 21 Then RepoMethod checked the delivery contract: OK: 2 files in scope OK: 5/5 acceptance criteria confirmed 5 strict OK: 2/2 evidence files present OK: report names items-pagination.md agent-gate all gates passed exit code=0 The final delivery verdict was: DELIVERY: done — gate green, workflow completed, completion node succeeded, scope clean, fresh handoff, plan artifacts committed, no open blocker The verified feature was then published to: task/items-pagination Published branch head: 6b780da58592e4152eba3f9d3116ee375023532a No pull request was created and nothing was merged. The important boundary is simple: ChatGPT writes the implementation. The repository owns the delivery contract. After the valid feature was published, I deliberately asked ChatGPT for one additional change. The feature spec and scope had to remain unchanged. ChatGPT was told to add a short pagination note to README.md , then rerun the same RepoMethod workflow without quietly expanding the scope. The ordinary engineering checks still passed: Test Files 4 passed 4 Tests 21 passed 21 verify npm run build tsc -p tsconfig.json But the repository-owned feature contract said README.md was out of scope. RepoMethod returned: VIOLATION: README.md exit code=1 Final verdict: DELIVERY: blocked — VIOLATION: README.md The blocked change was not committed and was not pushed. The remote branch stayed on the last accepted commit. That was the strongest part of the experiment. The application was still correct. The tests were still green. But the requested change violated the committed engineering contract, so delivery stopped. Green tests were necessary, but they were not sufficient evidence that an autonomous coding agent had respected the task. repomethod doctor repomethod install .repomethod/verify-command . DELIVERY: done The useful distinction is: repository tests green ≠ automatically acceptable delivery The exact ChatGPT mechanics used in this run are environment-specific. In this session, direct clone and push were unavailable, so the agent had to use the connected GitHub tooling to establish and publish the working state through a fallback path. A future ChatGPT version may make that much simpler. The method should not depend on that transport detail. The stable requirements are: done or blocked ; That is why I prefer keeping the engineering method in the repository rather than in a model-specific prompt. The agent ecosystem will keep changing. The repository is the durable boundary. RepoMethod https://github.com/frederik-schmittel/repomethod https://github.com/frederik-schmittel/repomethod Demo repository Successful demo branch https://github.com/frederik-schmittel/repomethod-demo/tree/task/items-pagination https://github.com/frederik-schmittel/repomethod-demo/tree/task/items-pagination Video