Something wild happened last week. I built a complete system in 16 hours that would have taken me two weeks just a few years ago. Not a prototype — production code, tested and deployed.
This got me thinking: what exactly has changed in how I build software? I've been experimenting with AI tools for a while, but I'd never actually written down the full workflow. So I decided to document it — partly to share with others who keep asking, but mostly to understand it better myself.
The tools themselves aren't secret. You probably know most of them. What surprised me was how they work together as a system. Using AI to write some functions is one thing. Using it to build entire systems? That's something else entirely.
Here's the stack I use and how each piece fits together.
1. Granola
Meeting transcription tool. I run it during all discovery conversations.
The non-obvious value: it captures context you miss while taking notes. When someone mentions they've "tried three other solutions," Granola catches the exhaustion in how they say it. These nuances become valuable when you feed everything to an LLM later.
How to use it: Run it during all stakeholder conversations. Feed the transcripts to Claude as context. The emotional undertones often reveal the real problems worth solving.
2. Hex
Local speech-to-text. Toggle on with a keyboard shortcut.
I use it for everything: writing code, debugging observations, thinking out loud. Speaking maintains flow state better than typing. When you're debugging something complex, narrating what you see while keeping your eyes on the code prevents the micro-interruptions that break concentration.
How to use it: Set up a global hotkey. Use it whenever you'd normally type more than a sentence. Especially powerful during debugging sessions — speak your observations as you trace through code
3. Claude
The Swiss Army knife. I use it three ways:
Projects — Create a persistent context by uploading all your notes, requirements, and research. It's like having a team member who's been on the project from day one.
Deep Research — Add "cite academic research" to your prompts. This transforms generic advice into frameworks backed by actual studies. The model has this knowledge but needs explicit permission to access it.
System Design — Have it create detailed ERDs before writing any code. The clearer your specifications, the better the implementation.
How to use it: Start every project with a Claude Project. Upload everything. When facing design decisions, ask for research-backed approaches. Get it to write comprehensive ERDs before moving to implementation.
For context, this article came out of a Claude Project.
4. Claude Code
Terminal-based AI that writes and executes code.
The key insight: treat it like a brilliant but literal engineer. It will build exactly what you specify. If your specifications are vague, you'll get working but messy code. If they're precise, you'll get clean implementations.
How to use it: Feed it the ERDs from Claude. Always ask it to write tests first. Be explicit about error handling, logging, and code structure. Think of it as programming via specification.
5. Claude Squad
Run multiple Claude Code sessions in parallel.
I typically run 4-5 sessions simultaneously, each building a different component. It's like managing a small team where each engineer works at superhuman speed but needs clear interfaces between components.
How to use it: Break your system into independent modules. Define clear contracts between them. Spin up one session per module. Batch similar decisions across sessions to reduce context-switching.
The hard limit is about 5 sessions — beyond that, my ability to provide quality guidance degraded.
6. Cursor
AI-powered editor. Mainly for debugging and refinement.
When something breaks, paste the error and let Cursor fix it. Great for UI tweaks — paste screenshots and ask for improvements. But here's the thing: heavy Cursor use signals upstream failures. Good specifications and tests minimize debugging.
How to use it: Use it for precision work — debugging specific issues, refactoring functions, improving UI. If you're living in Cursor, revisit your specifications.
The Workflow
Here's how these tools work together:
Discovery (2-3 hours): Use Granola to capture stakeholder conversations
Research & Design (3-4 hours): Create a Claude Project, upload everything, design the system
Parallel Building (4-8 hours): Use Claude Squad to build components simultaneously
Debugging (2-3 hours): Cursor for fixing issues
Simplification (2 hours): New Claude session to identify and remove complexity
The counterintuitive part: I spend the first 3-4 hours not writing any code. Just thinking, researching, creating specifications. This feels slow. It's actually the fastest path.
Practical Tips
Test-first is non-negotiable. When moving 4x faster, bugs multiply 4x too. Always ask Claude Code to write tests before implementation. This isn't a nice-to-have — it's survival. The hours you don't spend writing tests, you'll spend 3x debugging.
Two-pass building works better. First pass: make it work. Second pass: make it simple. Despite explicit instructions, AI consistently over-engineers. Create dedicated simplification sessions. It's faster than fighting the AI's tendency toward complexity.
Your cognitive bandwidth sets the limit. I thought I could run 20 parallel sessions. Reality: beyond 5, quality degrades. You can't context-switch faster just because AI codes faster. Plan around this human constraint.
Context is exponentially valuable. The difference between giving Claude one document versus comprehensive context is staggering. Upload everything: meeting transcripts, handwritten notes, sketches, requirements, examples. More context = exponentially better output.
Academic research unlocks hidden capabilities. Simply adding "cite academic research" transforms generic advice into research-backed frameworks. The AI has deep knowledge but needs explicit permission to access it. Use this for any complex design decision.
AI amplifies everything — good and bad. Jump into coding without clear specs? You'll create a mess 4x faster. Write crystal-clear requirements? You'll build robust systems 4x faster. The multiplier is neutral. It amplifies whatever you feed it.
Visual feedback changes everything. For UI work, paste screenshots into Cursor and iterate. Some problems need visual debugging. It's faster than describing changes in text.
Document as you go. Use Claude to generate comprehensive documentation from your codebase. Ask it to create different versions for different audiences — technical docs for engineers, architectural overviews for stakeholders.
Speak, don't type. Use Hex for any input longer than a line. The 3x speed gain is nice, but the real value is maintaining flow state. The physical act of typing creates just enough friction to break deep thinking.
The Real Insight
The bottleneck has shifted from writing code to making decisions. In this new world, your ability to think clearly about systems, create good specifications, and make architectural decisions matters more than your coding speed.
These tools amplify whatever you give them. Feed them clarity, get quality. Feed them confusion, get chaos.
Start with one tool tomorrow. I'd suggest Claude — create a project for whatever you're working on and see how comprehensive context changes your interactions. Add the others as you get comfortable.
The 4x productivity gain is real and accessible today. The only question is when you'll start capturing it.
