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

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