How I Found an AI Partner That Actually Listens
I have been building with AI for months. Replit, Claude, ChatGPT — all tools that promise you can build faster than ever. And that is true. But there is a difference between building quickly and building well.
And that's exactly where things started to go awry.
Fast Isn't Always Sharp
Replit has brought me a lot. For months, I could vibe-code at a pace I could barely keep up with. PB.nl, pb.nl/recepten, PerfectMoods, the F1 dashboard — all built with AI assistance on Replit.
But there was a pattern that increasingly frustrated me.
I asked for one small change — for example, to adjust a logo — and then received a series of commits in return. Variations on variations. Solutions to problems I hadn't posed. Without first asking that one simple question: “What exactly do you mean?”
I tried to frame it. Wrote down collaboration agreements up to complete: WORKING_TOGETHER.md files! Clear rules:
ask first, build later. One change at a time. Stop when I say stop. The agent read them. Understood them. And then completely ignored them, every time STOP! when I read what he thought I meant'
Then you start to doubt. Is it me? Am I asking the wrong questions?
It Wasn't Me — It Was the Medium
The answer turned out to be quite simple: no, it wasn't me.
It was how the system is designed.
Replit’s agent is built for speed and autonomy. Push through. Iterate. Always forward.
My way of working demands the opposite: first stop, look, discuss. Only build when it's clear. Thirty years of design and front-end experience have taught me one thing: pixel-perfect work does not arise from haste.
Through Claude Desktop, I discovered a different form of collaboration.
An AI that retains context. That reads first. That asks questions. That does one thing at a time. And that knows its role: execute, brainstorm, provide technical options — not make autonomous decisions.
That immediately felt different. Calmer. Sharper.
GitHub as a Bridge
There was only one practical problem: Claude cannot work directly in Replit.
And I had no desire for extra hosting, deployment hassle, or DevOps detours — that was precisely why I used Replit.
The solution turned out to be surprisingly simple: GitHub as an intermediary.
Claude works locally on the code and pushes to GitHub. I pull those changes into Replit. Done.
Within half an hour, the connection was set up. My first real git pull in Replit — and it worked immediately.
The First Real Project
To test whether this way of collaborating really holds up, we immediately tackled a serious problem.
My routes.ts — the heart of the PB.nl backend — had grown into a single file of 6,587 lines.
232 API endpoints mixed together. Blog, F1, ZAPPA, lookbooks, CMS, newsletter — everything in one drawer.
Every small change brought risks. If you touched the F1 routes, you could inadvertently break something in the blog. That explained a large part of the instability I saw earlier.
Claude did exactly what I expected — and what I missed before.
He read the entire file. Made a plan. Presented that plan. Waited for approval. And only then did he start building.
The result:
15 clear route files, each responsible for one feature. A new routes.ts of only 50 lines — just imports and registration.
Push to GitHub.
Pull in Replit. Republish.
Everything worked. In one go.
What I Learned from This
AI is not a monolith. It is not “one thing”.
One agent is built to run. The other to collaborate.
Replit is quite nice for quick prototyping and still the hosting because it's too big to move now.
But for controlled building — with consultation, discipline, and respect for the craft — a different approach works better. And Claude is truly the king in code.
The tools are already there.
You just need to know which to use when.
This article is based on a real work session on Sunday, 8 February 2026.
Regards, Peter + Claude and Zappa.
Questions/comments pb@pb.nl
