Here's the thing about AI coding tools: they're incredible, but only if you use them correctly. And "correctly" doesn't mean picking the fanciest one and throwing everything at it. It means putting each tool in its own lane and letting it do what it's actually good at.
Here's the workflow I landed on after a lot of trial and error. Emphasis on the error.
1. Set up Google Stitch for UI design
Start with Google Stitch to generate your initial UI. It's a Google Labs tool that lets you describe what you want and get a working mockup back, which is great if, like me, you think better by seeing something rather than imagining it from a wall of text.
You could set up Claude first and have it drive the whole thing via MCP, but I'm a visual person. I wanted to iterate on the design before handing it off. This guide was super helpful for me to get started with setting that connector up. Unfortunately, it means you need to do a few more steps than just "Hey Claude, connect me to Stitch."
2. Build your backend with Claude and Copilot
Once the design is locked, it's time to write actual code, and this is where a two-AI approach pays off. I built my microcontroller code using both Copilot and Claude in VS Code, and we've used the same approach on our website with Sitefinity as the CMS.
The short version: Copilot is great at the stuff right in front of you (autocomplete, quick functions, that sort of thing). Claude is better at the big-picture integrations between different systems. Use both. They don't fight. Much.
3. Document your processes and designs in Figma
"Why not just use Stitch for this?" Because Stitch is a one-shot tool. It's great at getting you a design fast, but it's not designed for the kind of iterative tweaking where you move a button two pixels to the left and argue with yourself about it for 20 minutes. Figma handles that workflow much better, and it gives your team a source of truth they can actually use.
4. Let your git client write your commit messages
Yes, your git client probably has AI built in now. GitKraken, for example, will look at your staged changes and generate a commit message that actually explains what happened. Which is a miracle if your previous commit messages were things like "fix stuff" or "please work."
There's also a useful command in Claude Code worth knowing about: /ultrareview. Run it before checking in and it produces an audit checklist of everything you're about to commit. Worth using on anything important. Also worth having your two AIs review each other's output. Turns out they're decent at catching each other's nonsense.
Oh, and as an afterthought, you should probably check AI's work as well, then have them check your checking of their checks of your code... or something like that. AI is leveraged the most when you and it are constantly giving each other feedback. Don't just dev hands-off, but read what it's doing and contribute. At the very least, you can try to make it feel bad about making mistakes that you totally wouldn't.
Why bother?
The boring but accurate answer: more tokens, more efficiency, less setup friction.
- More output capacity. Multiple specialized tools means you're less likely to hit that soul-crushing error telling you you can't have any more fun with your AI chat friend for the day.
- More efficient token use. Each tool stays focused on what it's actually good at, so you're not wasting context on things it was never built to handle.
- Set it and forget it. Once everything is wired up, you're not reconnecting MCPs every time you want to make a change. It just works.
- Specialized tooling, fewer mistakes. Everything has its own lane. Less overlap means fewer instances of your AI confidently doing the wrong thing.
Every tool in its lane.
If your team is trying to build a multi-AI workflow that actually works, we can help you skip the trial-and-error and get to a setup your developers will keep using.
Talk to us about AI in development arrow_forwardAlbert Hovingh is a Developer at Springthrough.