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

Frederik Schmittel — Sat, 12 Sep 2026 15:59:49 +0000

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

Demo repository: https://github.com/frederik-schmittel/repomethod-demo

The first useful discovery: connected GitHub is not the same thing as a local checkout

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 prompt that worked

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.

The repository defined the real checks

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 full gate failed — and that was useful

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 successful run

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.

The more interesting test: green tests, blocked delivery

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.

How to reproduce the workflow

Install RepoMethod into the repository.

repomethod doctor
repomethod install

Define the repository's real verification commands in .repomethod/verify-command.
Commit that installed/configured RepoMethod state so feature work starts from a clean Git baseline.
Connect the repository to ChatGPT.
Start a fresh chat and tell ChatGPT to treat GitHub as the authoritative remote state, establish a real local Git working state, read the repository instructions and use RepoMethod Classic.
Give it the feature and an existing reference implementation where possible. Let the repository answer implementation details instead of encoding them all into the prompt.
Require the real repository verification and real RepoMethod delivery workflow to execute.
Only publish after the final result is actually:

DELIVERY: done

Compare the published branch against the pinned base if the environment had to use a non-standard publication path.
To test the failure path, request an extra change outside the existing feature scope and explicitly forbid the agent from rewriting the spec to make the request legal. Then rerun delivery.

The useful distinction is:

repository tests green
≠
automatically acceptable delivery

What is stable, and what may change

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: