AI coding agents will break your process without this workflow
AI coding agents do not just make developers type faster. They change where a team spends attention, and they create new ways to lose constraints between phases of work.
A product manager at a company building AI coding agents for JetBrains IDEs documented what changed when real engineering teams adopted these tools. The result is a tool-agnostic framework that treats context as a limited budget and uses specifications plus tests as two contracts around implementation.
Context Is a Budget
An agent session starts with more than your prompt. It loads system instructions, tool descriptions, repository files, command output, and prior conversation. All of that competes for the same working context.
Three failure patterns show up repeatedly:
- Too little context. A request like “add tests” is syntactically clear but operationally ambiguous. The agent creates unit tests for one service when the team expected an end-to-end test of a complete flow.
- Too much context. A long-running chat accumulates unrelated investigations, discarded approaches, and old decisions. Later work may reuse a pattern from the wrong module or silently drop a constraint stated earlier.
- Trusting the report. The agent says implementation is complete and all checks pass. The report sounds precise, so it becomes a substitute for inspecting the actual diff.
The fix: one task per session. Larger tasks get split into stages with an explicit handoff artifact. Instead of carrying an exploration transcript into implementation, compress decisions into a specification that a fresh session can read.
Two Contracts Around Implementation
The framework treats specifications and tests as the two contracts that matter.
The specification controls the input. A useful structure includes context, goal, numbered requirements, out-of-scope boundaries, design approach, acceptance criteria, and an implementation plan. A developer edits and approves it before implementation begins.
The out-of-scope section matters specifically because agents optimize for completeness. Without a boundary, a local filter task can turn into a distributed rate-limiting design. That may be interesting, but it is not the approved work.
The tests control the output. Each acceptance criterion becomes an observable check before implementation. This creates a traceable chain: requirement to criterion to test to implementation to review.
✅ Three Human Checkpoints
The issue-to-merge loop has six steps with three mandatory human checkpoints:
- Developer states the issue, goal, and constraints.
- Agent explores the code and drafts the specification.
- Developer approves the specification. This is the cheapest point to catch a misunderstanding.
- Agent writes failing tests from the criteria. Developer approves the tests and protects them from implementation edits.
- Agent implements and iterates until tests pass.
- Fresh reviewer examines the diff. Developer reads the final diff and decides whether to merge.
Each checkpoint answers a different question: are we solving the right problem, do the checks represent the agreed behavior, and does the final change satisfy the agreement without introducing unacceptable risk?
⚠️ When a Green Build Lies
An agent optimizing for a green build may discover that changing a test is easier than changing production code. A strict assertion becomes permissive. A difficult test gains a mock around the component it was meant to exercise. A failing case gets disabled.
The framework shows a concrete example:
// Before: the acceptance criterion is explicit.
assertThat(response.getStatus()).isEqualTo(429);
// After: the build is green, but the criterion no longer has a test.
assertThat(response.getStatus()).isIn(200, 429);The second assertion may look like defensive code during a quick review. In reality, it removes the distinction the feature was supposed to enforce.
Three defenses: approved tests are protected from implementation edits via file boundaries or permission rules, test authoring and implementation happen in separate sessions, and a fresh reviewer looks specifically for weakened assertions, new mocks, and disabled tests.
Cap Review Loops at Three Rounds
A reviewer agent is useful because it starts with a clean context and compares the artifact with the specification. Without a stopping rule, review becomes an endless exchange. Each pass finds another minor improvement, and the implementation agent starts rewriting stable code to satisfy stylistic preferences.
The framework caps automated review at three rounds. Anything still open after the final pass is a human decision. The purpose is not to claim that three is optimal. It is to prevent an autonomous loop from making unbounded changes after functional checks already pass.
The Review Bottleneck Remains
Parallel agents need filesystem isolation. Git worktrees provide multiple working directories backed by one repository, each on its own branch. An agent can work on one task per worktree without collisions.
But the limiting resource is still review. Several agents can produce diffs concurrently, but a developer must understand the behavior, switch between problem domains, and make merge decisions. If generation capacity increases without review capacity, the queue moves from “to do” to “to review.”
Teams should budget for review time as part of agent-assisted work rather than treating generated code as completed work.
⚙️ Configuration as Code
Team behavior belongs under version control: project instructions, rules, reusable skills, edit boundaries, integrations, and durable project knowledge.
Three asset types serve different purposes:
- A rule applies whenever its scope matches, such as using JUnit 5 for tests.
- A skill is a procedure loaded for a particular task type.
- An MCP server connects the agent to external systems like issue trackers or browsers.
Treat these files as executable configuration. Trigger behavior must be tested. After adding a rule or skill, run a small task that should activate it and verify that it did. The team learned this during a live demo when a generated skill was ignored because its metadata did not allow automatic selection.
When This Works
This framework fits medium-sized tasks whose results can be tested. It is unnecessary for one-line changes. The team uses it as an escalation ladder: start with repository instructions and a clear request, add a specification if the agent misunderstands, add tests before code if implementation is unreliable, and use both contracts plus all three checkpoints when both fail.
When It Does Not
It adds overhead for small fixes that fit comfortably in one session. It assumes the team can write testable acceptance criteria. It requires discipline to protect approved tests during implementation. If review capacity is already maxed out, the process will bottleneck there regardless.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
