{"slug": "the-coding-agent-changed-the-engineering-method-stayed-in-the-repository", "title": "The Coding Agent Changed. The Engineering Method Stayed in the Repository.", "summary": "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.", "body_md": "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.\n\nI 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.\n\nWhich 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?\n\nI built RepoMethod around one idea:\n\n**The agent can change, but the engineering method should stay in the repository.**\n\nI 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.\n\nThe 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.\n\nRepoMethod: [https://github.com/frederik-schmittel/repomethod](https://github.com/frederik-schmittel/repomethod)\n\nDemo repository: [https://github.com/frederik-schmittel/repomethod-demo](https://github.com/frederik-schmittel/repomethod-demo)\n\nMy first attempt failed for an environment reason.\n\nChatGPT 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.\n\nIt correctly refused to fake success:\n\n```\nDELIVERY: blocked — Classic workflow state, handoff, agent-gate and deliver.sh could not be executed in the available runtime.\n```\n\nThat failure exposed the right mental model:\n\n```\nGitHub connector\n  authoritative remote state\n        ↓\nlocal working copy\n  disposable execution environment\n        ↓\nRepoMethod\n  repository-owned engineering contract\n        ↓\nverified result\n        ↓\nGitHub publication\n```\n\nThe 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.\n\nThe successful run made that execution boundary explicit instead of assuming a normal clone would exist.\n\nThis is the reusable pattern:\n\n```\nWork on the connected GitHub repository `OWNER/REPO`.\n\nUse the connected GitHub repository as the authoritative source for the current repository state.\n\nDo 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.\n\nIf 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.\n\nRead `AGENTS.md` and the installed RepoMethod instructions first. Follow the repository-owned method as authoritative.\n\nUse RepoMethod Classic.\n\nImplement FEATURE, using EXISTING_REFERENCE as the reference implementation.\n\nBefore writing implementation code:\n- inspect the existing reference behavior and relevant tests\n- create the RepoMethod feature spec\n- initialize and follow the Classic workflow\n\nKeep the change minimal.\nRun the repository-defined verification and complete RepoMethod delivery.\nDo not invent a substitute workflow or fabricate a delivery verdict.\n\nCreate a task branch from current `main`.\nOnly after successful RepoMethod delivery, commit and publish the verified feature state.\nDo not create a pull request or merge anything.\n\nReport the branch, remote commit SHA, verification result and final `DELIVERY:` verdict.\n```\n\nFor the demo, the concrete values were:\n\n```\nrepository: frederik-schmittel/repomethod-demo\nfeature: GET /items pagination\nreference: GET /tasks\nfeature slug: items-pagination\nbranch: task/items-pagination\n```\n\nThat 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.\n\nRepoMethod had already been installed and committed as part of the repository baseline.\n\nThe repository verification command was:\n\n```\nnpm run lint\nnpm run typecheck\nnpm test\nnpm run build\n```\n\nThat lived in:\n\n```\n.repomethod/verify-command\n```\n\nChatGPT 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`.\n\nThe implementation itself was intentionally boring. It reused the existing pagination helpers instead of inventing a second pagination design.\n\nThe first RepoMethod verification did not pass immediately.\n\nThe 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.\n\nAfter that evidence binding was corrected, the retry verification passed.\n\nThis 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.\n\nThe repository checks passed:\n\n```\nTest Files  4 passed (4)\nTests       21 passed (21)\n```\n\nThen RepoMethod checked the delivery contract:\n\n```\nOK: 2 files in scope\nOK: 5/5 acceptance criteria confirmed (5 strict)\nOK: 2/2 evidence files present\nOK: report names items-pagination.md\n[agent-gate] all gates passed\nexit_code=0\n```\n\nThe final delivery verdict was:\n\n```\nDELIVERY: done — gate green, workflow completed, completion node succeeded, scope clean, fresh handoff, plan artifacts committed, no open blocker\n```\n\nThe verified feature was then published to:\n\n```\ntask/items-pagination\n```\n\nPublished branch head:\n\n```\n6b780da58592e4152eba3f9d3116ee375023532a\n```\n\nNo pull request was created and nothing was merged.\n\nThe important boundary is simple:\n\n**ChatGPT writes the implementation. The repository owns the delivery contract.**\n\nAfter the valid feature was published, I deliberately asked ChatGPT for one additional change.\n\nThe 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.\n\nThe ordinary engineering checks still passed:\n\n```\nTest Files  4 passed (4)\nTests       21 passed (21)\n\n[verify] npm run build\n> tsc -p tsconfig.json\n```\n\nBut the repository-owned feature contract said `README.md` was out of scope.\n\nRepoMethod returned:\n\n```\nVIOLATION: README.md\nexit_code=1\n```\n\nFinal verdict:\n\n```\nDELIVERY: blocked — VIOLATION: README.md\n```\n\nThe blocked change was not committed and was not pushed. The remote branch stayed on the last accepted commit.\n\nThat was the strongest part of the experiment.\n\nThe application was still correct. The tests were still green. But the requested change violated the committed engineering contract, so delivery stopped.\n\n**Green tests were necessary, but they were not sufficient evidence that an autonomous coding agent had respected the task.**\n\n```\nrepomethod doctor\nrepomethod install\n```\n\n`.repomethod/verify-command`.\n\n```\nDELIVERY: done\n```\n\nThe useful distinction is:\n\n```\nrepository tests green\n≠\nautomatically acceptable delivery\n```\n\nThe 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.\n\nA future ChatGPT version may make that much simpler.\n\nThe method should not depend on that transport detail.\n\nThe stable requirements are:\n\n`done` or `blocked`;\nThat is why I prefer keeping the engineering method in the repository rather than in a model-specific prompt.\n\nThe agent ecosystem will keep changing. The repository is the durable boundary.\n\n**RepoMethod** \n\n[https://github.com/frederik-schmittel/repomethod](https://github.com/frederik-schmittel/repomethod)\n\n**Demo repository** \n\n**Successful demo branch** \n\n[https://github.com/frederik-schmittel/repomethod-demo/tree/task/items-pagination](https://github.com/frederik-schmittel/repomethod-demo/tree/task/items-pagination)\n\n**Video**", "url": "https://wpnews.pro/news/the-coding-agent-changed-the-engineering-method-stayed-in-the-repository", "canonical_source": "https://dev.to/frederik_schmittel/the-coding-agent-changed-the-engineering-method-stayed-in-the-repository-5ag1", "published_at": "2026-09-12 15:59:49+00:00", "updated_at": "2026-09-12 16:14:55.346322+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "ai-products"], "entities": ["RepoMethod", "ChatGPT", "GitHub", "Fastify", "TypeScript", "frederik-schmittel"], "alternates": {"html": "https://wpnews.pro/news/the-coding-agent-changed-the-engineering-method-stayed-in-the-repository", "markdown": "https://wpnews.pro/news/the-coding-agent-changed-the-engineering-method-stayed-in-the-repository.md", "text": "https://wpnews.pro/news/the-coding-agent-changed-the-engineering-method-stayed-in-the-repository.txt", "jsonld": "https://wpnews.pro/news/the-coding-agent-changed-the-engineering-method-stayed-in-the-repository.jsonld"}}