Eight everyday jobs across development and QA, done differently with Claude Code
Everything it produces goes through the same review, staging and release process as the rest of the platform.
News and analysis for marketers, media owners and agencies
STX Next's engineering team works with Adweek on that platform: five people across web development, QA, data engineering and DevOps. This document covers that team's own workflow. Adweek's engineers are adopting AI tooling separately, on their own timeline.
A wide platform, and a lot of looking things up
The platform is wider than an editorial site. There is a paywall and metered access, payments and subscription billing, lifecycle email, and product modules for subscriptions, webinars and newsletters, all running on WordPress VIP.
Each of those is a separate system with its own settings, so the answer to a question about how something behaves is rarely in the code alone.
That is where the time went. Working out what a ticket actually asked for meant digging through the documentation for whichever service the change touched. Finding the cause of a fault meant moving between browser tools, site logs, outside services and more than one codebase, by hand.
The same was true on the QA side. Test instructions were written out by hand at the end of a job, when nobody had much appetite for it. Test cases were retyped from scratch every time. Bug reports were written up long after the problem had been reproduced.
None of that is the hard part of the work. It is the looking up and the writing out that sits either side of it.
What follows is how those jobs are done now. Everything Claude Code produces goes through the same review, staging and release process as the rest of the platform, and reaches the live site by the same route as code written by hand.
STX Next: AI-native delivery, with the guardrails written down
Claude Code runs where the work already happens. There is no separate app to open and nothing to copy and paste. It works in the terminal, reads whichever repository it is pointed at, and connects to the team's other tools so it can look something up itself instead of waiting for a person to paste in a screenshot.
That is the whole point of the setup. The tool is only as useful as the context it can reach without being handed it.
In the terminal, with the project's context already loaded
There is no separate app and nothing to copy and paste. The setup lives in the repositories and in the connections to the team's other tools.
Claude Code in the terminal
A CLAUDE.md file in each repository
Two models
Connections to the team's other tools
What changed, job by job
01 Working out what a ticket means. Claude Code reads the ticket from Jira and the team questions it before any code is written. It picks up cases nobody had thought about and fills in what the ticket left out. Before, developers worked it out by hand and went digging through the documentation for whichever service the change touched.
02 Finding out why something broke. Claude Code reproduces the problem and works out what is causing it. Point it in roughly the right direction and it finds the real cause rather than a symptom. Before, that meant moving between browser tools, site logs, outside services and more than one codebase, by hand.
03 Reviewing large changes. A new feature usually changes files in several places at once, so the change to review was often very large and someone had to read all of it. Claude Code reviews the large ones against what the ticket actually asked for, so the review stays on the feature instead of getting lost line by line.
04 Writing the technical notes. Claude Code writes the first version from the code changes themselves, and the developer edits it rather than starting from a blank page. Before, it was written out by hand in the ticket at the end of the job, when nobody had much appetite for it.
05 QA: writing the test instructions and the test cases. Claude Code reads the change and writes both, and raises things worth testing that the team would not have thought of. Before, QA had to go through the code changes with a developer to understand a ticket well enough to test it, which took time from both people, and every test case was typed into BrowserStack from scratch.
06 QA: building the automated tests. Claude Code finds the cases and writes the Playwright tests around them. The team does this about once a sprint.
07 QA: writing up bugs. Claude Code writes up the bug it has just reproduced, ready to paste into the ticket, instead of it being written out from memory later.
Every one of these still ends with a person. The developer checks the output, the change is reviewed in the usual way before it is merged, and QA tests it on staging before it goes live.
Tech Stack
.svg){kind=icon}
On its own: reading the code, the tickets and the settings of the connected tools, and drafting the first version of code, tests, technical notes and bug reports.
Always a person: checking the output, reviewing the change before it is merged, testing it on staging, and deciding how something should be built.
The division is deliberate. The tool is fast at the work that can be revised, and the steps that reach the client stay where they were. Claude Code changed how the first version gets written. It did not change who is responsible for it.
Two 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. And it rewards the setup work: the context files in each repository and the connections to the team's other tools are what make the output usable, and without them the results are ordinary.
The jobs above are the everyday work. The same setup absorbs bigger one-off pieces alongside it, without a separate process for them: one planned, one an emergency, and one piece of groundwork that made the rest possible.
Bigger pieces the same setup absorbed
Moving the automated tests from Cypress to Playwright
The Cypress tests were slow and crashed often enough that people had stopped trusting them. The QA engineer had Claude Code read the whole codebase, backend and frontend, to build up a picture of how the site fits together. It then read the old tests and wrote a plan for moving them across, and did a good deal of the move itself: converting the syntax, restructuring the tests and reworking how they are organised.
.svg){kind=icon}
The checkout stopped recording purchases
Purchases were not showing up, and the analytics stopped working along with them. This is the kind of fault that costs money for every day it goes unexplained. Claude Code read through 150 MB of Google Tag Manager logs in one session, found what was causing it and suggested a fix. Going through those logs by hand would have taken days.
.svg){kind=icon}
Getting Claude Code into the dev environment
The main technical obstacle was connecting Claude Code to the hosting platform's development environment. Once that was in place it could read the platform's own settings directly, which is what the rest of this depends on.
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
