DEV Community

Frederik Schmittel
Frederik Schmittel

Posted on Originally published at Medium AI-assisted

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

#ai #programming #opensource #devtools

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.
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

That lived in:

.repomethod/verify-command
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

The final delivery verdict was:

DELIVERY: done — gate green, workflow completed, completion node succeeded, scope clean, fresh handoff, plan artifacts committed, no open blocker
Enter fullscreen mode Exit fullscreen mode

The verified feature was then published to:

task/items-pagination
Enter fullscreen mode Exit fullscreen mode

Published branch head:

6b780da58592e4152eba3f9d3116ee375023532a
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

But the repository-owned feature contract said README.md was out of scope.

RepoMethod returned:

VIOLATION: README.md
exit_code=1
Enter fullscreen mode Exit fullscreen mode

Final verdict:

DELIVERY: blocked — VIOLATION: README.md
Enter fullscreen mode Exit fullscreen mode

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

  1. Install RepoMethod into the repository. 
repomethod doctor
repomethod install
Enter fullscreen mode Exit fullscreen mode
  1. Define the repository's real verification commands in .repomethod/verify-command.
  2. Commit that installed/configured RepoMethod state so feature work starts from a clean Git baseline.
  3. Connect the repository to ChatGPT.
  4. 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.
  5. 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.
  6. Require the real repository verification and real RepoMethod delivery workflow to execute.
  7. Only publish after the final result is actually: 
DELIVERY: done
Enter fullscreen mode Exit fullscreen mode
  1. Compare the published branch against the pinned base if the environment had to use a non-standard publication path.
  2. 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
Enter fullscreen mode Exit fullscreen mode

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:

  • know the authoritative remote revision;
  • execute against a real local Git baseline;
  • read and follow the repository-owned method;
  • run the repository's actual verification commands;
  • let RepoMethod decide done or blocked;
  • publish only the already verified result.

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.

Links

RepoMethod

https://github.com/frederik-schmittel/repomethod

Demo repository

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

Successful demo branch

https://github.com/frederik-schmittel/repomethod-demo/tree/task/items-pagination

Video

https://youtu.be/KZkrTzIjGQc

Top comments (2)

Collapse
 
raknaos profile image
Raknaos •

The distinction between "connected GitHub" and "a real local working tree" is the one I keep re-learning the hard way. Our fleet on a VPS hit exactly that shape: the agent could read and write remote state, but any step that needed git to actually execute fell over, and it looked like a broken tool rather than a missing boundary. The run refusing with "DELIVERY: blocked" instead of reporting success is what makes me trust the write-up — most harnesses paper over it.

Two things I'd like to know: when the sandbox materialises main as a snapshot rather than cloning, how do you notice that the remote moved mid-run? And does deliver.sh check the local HEAD against a known remote revision, or is the snapshot-to-push direction trusted implicitly?

Some comments may only be visible to logged-in visitors. Sign in to view all comments.