Every migration ticket planned, cleaned up and security-reviewed with Claude Code
Approving the plan, committing and merging stay with the engineer.
The UK's leading wedding gift list group
STX Next works on the software and technical development of those platforms as a team extension. The engagement covered here is about how that team builds: Claude Code is configured as a working member of the team rather than as autocomplete, and every ticket runs through the same fixed pipeline.
Writing a feature is easy. Writing it this project's way is not
That migration is the business problem underneath the engineering one. Until it finishes, every new feature either moves it forward or adds to what has to be unpicked later. The two codebases also keep separate schema definitions for the one database they share, and drift between them is a production incident rather than a bug. Current code sits alongside an established earlier layer with its own patterns and libraries.
Writing a feature is the easy part. Writing it the way this particular project writes things, every time, on a platform still carrying its own history, takes a great deal of context to get right, and that is the part that does not scale by adding hours to the week.
STX Next: AI-native delivery, with the guardrails written down
Production status. The frontend migration stream has been delivered this way since March 2026, roughly six months. It is the standard route for tickets in that stream: every one of them goes through the workflow, one ticket to one isolated branch to one pull request, and the output ships, reviewed, merged and deployed in the project's regular releases by the same route as code written by hand. The application has been live since 2022. This is how part of it has been built for the last six months.
Very little of what makes this work comes from the model on its own. It comes from the setup built around it: the conventions written down, the corrections saved as permanent rules, the workflow reduced to one command, and a branch per ticket.
Output quality tracks setup quality. The same model with none of this scaffolding produces mediocre results, which is why the configuration is the deliverable rather than the tool.
Four layers of configuration, and one command that runs seven phases
Claude Code is set up here like a team member that already knows the project. Each layer lives in the repository rather than in someone's head.
Conventions written down
Project memory
One command, seven phases
An isolated branch per ticket
The seven phases, in order
02 Plan, then approval. Which files change, what schema changes are needed, security implications, edge cases. It asks questions rather than guessing, and nothing is written until an engineer approves the plan.
03 Implementation. Follows the written conventions, and steers new functionality into the frontend rather than extending the service being retired.
04 Fix loop. No iteration limit. It keeps working the problem instead of stopping at the first attempt and handing back something half-done.
05 Code cleanup. A separate pass for readability and consistency, rather than leaving it to whoever reviews the diff.
06 Security review. Cross-site scripting, authorization, input validation and data exposure, checked on every ticket.
07 Summary. What was built, what changed, and what is left to consider.
Committing and merging are never part of the pipeline. They happen after an engineer has read the diff.
Tech Stack
.svg){kind=icon}
Migration production tickets completed per two-week sprint rose from 6 to 10, compared to before March 2026, same team of four engineers.
Conventions enforce themselves
Nobody, person or model, has to guess whether the project uses a framework component or its own. It is written down and checked on every task, so the same review comment is never made twice.
Security review and cleanup stop being optional
Both run on every ticket rather than when someone remembers, so neither depends on good intentions at the end of a sprint.
The migration moves faster
New functionality is steered into the frontend automatically, instead of depending on whoever is writing the code staying alert to which codebase a change belongs in.
None of these is a one-off. They are properties of the pipeline rather than things a careful engineer remembered to do, so they hold for every ticket in the stream and every pull request out of it, across the six months it has been running.
Tech debt anyone can prioritise
The engineer writes what needs doing. The agent finds the repository the change concerns, adds its own read of the problem, and rewrites most of the description in plain language. Tech debt normally loses the argument for a sprint slot because nobody outside engineering can tell what is at stake. A ticket that explains itself, with a stated priority, can be weighed against everything else competing for the same time.
Median time to close a tech debt ticket fell from 3.5 days to 1 day over the same windows.
Runs on its own: reading and exploring the codebase, writing an implementation against an approved plan, and the cleanup and security review passes.
Always a person: committing and merging after reading the diff, any database command, which is blocked at the permission level, running the application and checking it in a browser, touching servers, and architectural decisions with real trade-offs.
One rule sits above the rest. A schema change goes into both codebases, every time. Two definitions of the same database drifting apart is a production incident, so it is enforced rather than remembered.
Three things this setup does not do, stated plainly because they shape how it should be used. It does not replace review: the code still has to be read, because the model can produce something syntactically correct that misses the business intent entirely. It rewards the setup work: the configuration was built up over the first few weeks and has been added to ever since, and six months of that accumulated context is why the output holds up. And the larger architectural calls still need a person, because the model executes a plan well but is weaker at choosing between trade-offs that cannot be settled from the code alone.
The same tooling turns up inside the product, not only in how the team builds it. One shipped example: image descriptions for articles are generated through the Claude API. That is descriptive writing which matters for accessibility and search, and which is the first thing to get skipped when someone is publishing in bulk.
The work around the code
Tech debt anyone can prioritise
The engineer writes what needs doing. The agent finds the repository the change concerns, adds its own read of the problem, and rewrites most of the description in plain language, so it can be weighed against everything else competing for the same sprint. Raising the ticket stays with the engineer.
.svg){kind=icon}
An impact check, when it is asked for
When a pull request has moved on, the engineer can have the agent look at whether the latest edit reaches into other parts of the application and whether anything is likely to break. It runs on request rather than on a trigger.
.svg){kind=icon}
Image descriptions, generated in the product
The same tooling turns up inside the product, not only in how the team builds it. One shipped example: image descriptions for articles are generated through the Claude API. That is descriptive writing which matters for accessibility and search, and which is the first thing to get skipped when someone is publishing in bulk.
Want this running on your codebase?
Schedule a call with our experts to discover the benefits of partnering with STX Next.
Our customers love to work with us
