QA Fixed a Bug in 5 Minutes Without a Developer: What We Designed and What We Didn't

When the AI coding tool was expanded to the whole team, sync problems broke out. Some people kept the latest rules, some kept a version from 2 weeks ago, and some kept their own locally modified way. Even the same request produced different results.

To solve this, they built a Claude Code plugin called code-forge. It was designed with a 3-layer structure: System Enforcement (Hooks) that blocks dangerous commands and automatically runs lint, a Thinking Model that makes the tool read the codebase first, and Access Control that prevents generation of sensitive files. Prompts can be ignored, but Hooks are enforced by the system.

Same Prompt, Different Results

The same campaign registration form requirements were requested on both a base project and a code-forge-configured project. The codebase already had policies implemented — "settlement rule is based on the 28th" and "minimum order amount of 50,000 won" — but these were not mentioned in the prompt.

• Base: ignored the policies, generated generic code
• code-forge: read the codebase first and complied with existing policies

In an actual PG (payment gateway) integration task, code-forge automatically derived branches by payment flow (card/bank transfer/easy payment) and scenarios (success/failure/cancellation/refund) and turned them into test cases. This even included edge cases like "repayment after cancellation."

The Bottleneck Was in Permissions and Entry Points

When operational issues like "this suddenly isn't working" came up, if the responsible developer was on vacation or working on something else, work that could be finished in 5 minutes ended up delayed by a day or two. It wasn't a matter of difficulty, but a matter of permissions.

Anvil: A Workbench That Runs on Slack

They built Anvil, which puts a Slack interface on top of code-forge. QA, planners, and designers can start tasks via Slack DM without a terminal. The workflow:

1. "Show my tickets" → list of incomplete Jira items
2. Select a ticket → automatic impact scope analysis
3. Simple fixes: direct implementation → quality gate → MR creation
4. Policy/core changes: approval from responsible developer → implementation → MR review

The final merge decision is always made by a developer. Keeping a point that must always be reviewed by a human is what allows the rest to be opened up more broadly.

A Real Production Deployment Case

In the Integrated Admin price optimization squad, a QA person started a task of adding a new field to a dashboard using Anvil. It flowed in one sequence — impact scope analysis → code modification → MR creation → deployment request — and was deployed all the way to production without a developer. This is the first case of a task started via Anvil in a squad outside the Ad Center passing all the way through to production.

Since code-forge is a plugin, the barrier to adoption is low. Running /setup automatically detects the project stack (React/Next.js, Jotai/Zustand, Emotion/Tailwind, etc.) and applies only the matching modules. It also analyzes existing codebase conventions and reflects them, so consistent code quality comes out even in new projects.

Reactions by Role

• Planners: interested in the scope they can check themselves before asking a developer
• Designers: directly experiment with interactions or tracking changes they had in mind
• QA: quickly identify which screens a specific API, copy, or button is used on

In an era where AI modifies code, the developer's job isn't shrinking — its nature is changing. Building thinking models, configuring harnesses, and embedding policies into the codebase become more important. Rather than simply opening up permissions, the role that will be required of developers going forward is to first build an environment where consistent quality comes out no matter who is doing the work.