A year of AI coding / 02
Keeping your workflow independent of your coding agent
Changing coding agents should not mean losing the requirements, verification evidence, and operational decisions behind your software.
By Grafty team · · 3 min read
Written in .
Suppose your team decides to switch coding agents. The repository moves easily enough. What happens to the explanation of why a feature works the way it does?
If that explanation lives only in a vendor's chat history, changing tools means losing part of the engineering record. The source remains available, but the rejected approaches, security constraints, and unanswered questions may not.
GitHub's October 28, 2025 Agent HQ announcement put multiple coding agents inside a common workflow on the product roadmap. It described a place to manage agent work and announced integrations planned for the following months. That distinction matters: the announcement was a direction and a rollout plan, not evidence that every named integration was already available. GitHub's original post sets out that plan.
The broader engineering question remains useful regardless of where the agents run. Which parts of the development process should belong to the organization rather than the tool?
Open full-size diagram Keep decisions close to the work
We would start with a simple requirement: another engineer should be able to continue the task without opening the original agent session.
Take an expense approval app. The durable record should say who can approve a request, whether approvals can be delegated, what happens when an approver leaves, and which system owns the final payment status. These are application requirements. They should not disappear into a conversation about generating a form.
The pull request can preserve the implementation rationale and verification results. Tests can preserve important behavior. A short design note can capture a decision that affects several services. The exact format matters less than whether the next person can find it.
This does not mean saving every token an agent produces. Raw transcripts often contain abandoned plans and repeated output. Keeping all of that can make the record harder to use. A concise handoff should identify the current result, the checks performed, and the unresolved risks, with links to evidence where appropriate.
Open full-size diagram Portability has limits
It is tempting to put a common interface in front of several models and call the problem solved. That helps with request plumbing, but agents differ in how they inspect repositories, request approval, manage context, and use tools.
A workflow that works well with one agent may need adjustment with another. We would test a replacement on representative repository tasks before changing the default. Compare whether the same constraints survive, how much review the result needs, and what happens when a tool fails. A shared API shape cannot answer those questions.
Tool independence also should not become a reason to avoid useful features. A vendor-specific capability may be worth adopting. The important thing is to understand what would need rebuilding if the team stopped using it, and to keep critical engineering decisions somewhere you control.
For internal software, the exit question extends beyond coding. Can the organization rebuild the application? Does it have the deployment configuration? Can another team inspect its dependencies and rotate its credentials? Does the application still operate if the generation service is unavailable?
Our preference is to make the agent replaceable without pretending all agents are interchangeable. Keep requirements and operational ownership stable. Let the execution tool change when there is a good reason. The expensive migration is rarely moving the files; it is reconstructing the decisions nobody wrote down.