Every ticket planned, browser-tested 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
The platform is a monorepo holding two codebases that share a single database: a Next.js and TypeScript frontend where new work happens, and an older service that is being retired. Each keeps its own schema definition for that shared database, and the two have to stay in step.
It has been running since 2022, so current code sits alongside an established earlier layer with its own patterns and libraries.
That is the real constraint on this kind of work. Writing a feature is easy. Writing it the way this particular project writes things takes a great deal of context to get right.
An AI tool that does not know any of this produces code that compiles, passes review at a glance, and quietly does things the wrong way. The problem to solve was not capability. It was context.
STX Next: AI-native delivery, with the guardrails written down
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 eight 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, eight phases
An isolated branch per ticket
Tech Stack
.svg){kind=icon}
Quality steps that used to be optional now happen on every ticket
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.
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.
On its own: reading and exploring the codebase, writing an implementation against an approved plan, running the application and testing it in a browser inside the pipeline, 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, touching servers and manual testing, 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: this configuration took a few weeks of incremental tuning, mostly by saving corrections as permanent rules, and without that the results are ordinary. 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 also turns up in what customers use, not only in how the team builds. When a guest buys a gift, the platform now helps them write the message that goes to the couple, which is exactly the kind of short, slightly awkward writing task people stall on. A team fluent in the tooling from daily delivery work is the team most likely to spot where it belongs in the product.
The work around the code
Branches and pull requests on command
Custom commands handle the repetitive git work of cutting a branch and raising a pull request. One instruction instead of a sequence of manual steps, several times a day.
.svg){kind=icon}
An impact check on every update
Each time a pull request changes, the agent looks at whether the latest edit reaches into other parts of the application and whether anything is likely to break.
.svg){kind=icon}
The board, handled from the terminal
Ticket status and ticket movement are updated over MCP without leaving the terminal, so the tracker reflects reality rather than being caught up at the end of the day.
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
