My Personal Tech Stack: How I Combine Claude Code, n8n, and Playwright for Extreme Speed

Three months ago one of my teams shipped a pricing page update built almost entirely by an AI coding agent. The code compiled. The tests passed. Nobody opened the page in a real browser before it went live. For four hours, the "Buy Now" button sat half off-screen on mobile Safari, and the first person to tell us was a customer, not a dashboard.

That is the failure mode nobody warns you about with AI-assisted development: the model can write code that is logically correct and visually broken at the same time. I run architecture reviews across IndiaNIC's delivery teams most weeks, and even there I catch myself trusting a diff because it reads clean, not because I looked at what it renders. The pricing page incident is the reason I rebuilt my own workflow around three tools instead of one, and it is the setup I now use for nearly everything I ship personally.

Why One AI Tool Was Never Going to Be Enough

The mistake was not choosing a bad AI coding tool. Claude Code writes better implementation code than most junior engineers I have hired. The mistake was asking one tool to do three unrelated jobs: notice that work needs doing, do the work, and confirm the work is correct. Those are three different skills, and collapsing them into a single agent is how a broken button ships unnoticed. According to Anthropic's own 2025 engineering writing on agentic coding, models perform far more reliably when given a written specification up front than when left to infer intent from a short prompt, which matches exactly what I have seen change once I stopped typing one-line requests.

So I split the pipeline the way I would split a team.

Something has to watch for triggers and hand off cleanly. Something has to build against a real specification instead of a loose prompt. Something has to look at the result with something closer to human eyes than a test runner offers. That split is the whole framework, and once it is running, it is simpler than it sounds.

The Three-Layer Framework: Trigger, Build, Verify

I think of the stack as three layers stacked in a fixed order, and I have stopped letting any layer skip its turn.

• Layer one, orchestration — n8n sits at the front. It watches a webhook, a cron schedule, or a form submission, decides what kind of job just arrived, and kicks off the right workflow. It also handles every notification through Slack's incoming webhooks: a message when a build starts, another when Playwright finishes checking it, a third if something fails.
• Layer two, implementation — Claude Code takes over once n8n hands it a job. It never gets a one-line prompt. It gets a spec file with acceptance criteria, edge cases, and the exact files it is allowed to touch, the same discipline teams have used for years under the name specification by example, just handed to a model instead of a person.
• Layer three, verification — Playwright opens the changed pages in real browser engines, takes screenshots, and compares them pixel by pixel against the last approved version, the same visual-diffing idea that visual regression tools like Chromatic popularized for component libraries. It also runs the functional checks: does the form submit, does the button click, does the price actually update.

Here is the part I did not expect going in: the automation layer ends up doing almost as much for team trust as the AI layer does for speed. Nobody has to remember to run a check. The pipeline remembers for them.

What Actually Happens When I Ship a Pricing Page Update Now

A real run looks like this. A teammate edits a spec document describing a new pricing tier and pushes it to a shared folder. n8n notices the new file within a minute, pulls it, and opens a Claude Code session with that spec attached along with a rule set: use the existing design tokens, do not touch the checkout logic, write a test for every new price calculation.

Claude Code writes the change on a branch and pushes it. That push is the second trigger. n8n picks it up again, spins up a Playwright run against a preview deploy, and Playwright walks every route that touches pricing across desktop Chrome, mobile Safari, and a tablet viewport. It captures a screenshot of each, lays it against the baseline image, and flags anything that shifted by more than a small pixel threshold.

On the run that mattered most, Playwright flagged exactly what the earlier manual process had missed: a call-to-action button overlapping a discount badge on a 390-pixel-wide viewport, the same width as an iPhone 13. n8n posted the diff image straight to our Slack channel with the failing screenshot attached. Nobody had to go looking for the problem. It came to us, before a customer saw it.

I will say the unpopular part plainly: most "AI-accelerated" engineering teams I have seen are not actually faster, because they spend the time they saved on building back on manual QA they never automated in the first place. The speed only shows up once verification is as automatic as generation. Skip that step and you have just moved the bottleneck, not removed it.

How to Set This Up Starting Today

You do not need all three tools running by Friday. Build the layers in this order, because each one makes the next one safer.

1. Write one real spec. Take a task you would normally hand to an AI assistant as a loose sentence, and instead write three to five bullet points of acceptance criteria. Feed that to Claude Code and compare the output to what a vague prompt gives you.
2. Wire a single n8n trigger. Start with one: a GitHub webhook that fires on push. Have it post a Slack message. That is the entire scope of your first workflow, and it should take under an hour.
3. Add a Playwright screenshot step. Point it at your staging URL, capture two or three key screens at two viewport widths, and store the images as your baseline.
4. Connect the three. Let n8n call Claude Code on a trigger, then call Playwright once the branch updates, then post the diff back to your team. Nothing goes live until that last step passes.

The first time I ran this end to end, on a client's internal admin tool rather than my own site, the n8n workflow broke twice before Claude Code ever got a single job: once on a malformed webhook payload, once on a Slack token I had scoped too narrowly. Neither failure had anything to do with AI. That is the part nobody tells you going in — the fiddly, unglamorous plumbing is where the real setup time goes, not the model.

The whole thing took me about a weekend to get from nothing to a working pipeline on one project. That is worth knowing before you start: the orchestration layer is the fiddly one, not the impressive one.

Frequently asked questions

What does n8n actually do in an AI development pipeline?

n8n is an open-source workflow automation tool that watches for triggers, such as a code push or a form submission, and routes tasks between other tools. In this stack it starts the Claude Code build, kicks off the Playwright check, and sends status updates to Slack, without a human manually starting each step.

Can Claude Code replace manual QA and browser testing?

No. Claude Code writes and edits code against a specification, but it does not render pages in a browser or judge how something looks. It needs a separate visual verification step, which is exactly the job Playwright does in this pipeline.

Do I need Playwright if I already review pull requests by hand?

Yes, because manual review checks the code, not the rendered result across devices. Playwright automates screenshot comparison across browsers and viewport sizes, catching layout breaks a code reviewer reading a diff would never see.

So here is the question worth sitting with: which of your last five releases would this pipeline have caught before your customers did? Work out the honest answer, then bring it to your team this week and see which layer you are missing.

For additional context, see TechnologyChecker.io's lookup software.