Earlier this month I made the case that comparing AI platforms head-to-head misses the point. The question I keep seeing — "which AI is better?" — isn't really the question that matters. What matters is which tool fits the job in front of you.
That post seemed to resonate with people, so I want to go one step further. Because knowing that you should have an AI toolbox doesn't help much if you don't actually know how to use one. Owning a toolbox and knowing your workflow are two different things.
So here's what my workflow actually looks like, tool by tool, and the thinking behind it.
The problem with picking a "favorite"
Most of the AI discourse I see online is framed as a competition. Someone posts a benchmark, someone else posts a counter-example, and the comments turn into a debate about which platform "wins." I understand the impulse — we like rankings, they're easy to argue about, and picking a favorite feels like it saves you the work of thinking further.
But the ranking impulse breaks down the moment you actually try to use these tools for real work. A tool that's excellent at one stage of a task can be mediocre at another stage of the same task. If you judge it only on the stage where it's weak, you conclude "this AI isn't very good," when really you just used a screwdriver to turn a bolt.
The fix isn't finding the one tool that's good at everything. It's noticing that your work itself has stages, and matching the tool to the stage.
The three stages of a piece of work
When I look back at how I actually get things done, three distinct modes show up over and over:
1. Shaping the problem. This is the messy, early part — before you know exactly what you're building, sometimes before you're even sure the idea is a good one. You need something to push back on you, ask the annoying follow-up question, and help you find the holes in your own thinking.
2. Doing the real work. Once the idea is solid enough to act on, the job changes completely. Now you need depth and continuity — something that can hold the whole shape of a project, a codebase, or a document, not just one clever exchange.
3. Executing in the flow. This is the moment-to-moment part — writing the actual code, making the actual edit — where you don't want a conversation at all. You want something quietly keeping pace with you.
Three different jobs. Three different tools, for me.
How I actually use each one
ChatGPT, for shaping the problem. Before I write a line of code or open a document, I want to know I'm solving the right problem in the first place. I'll bring ChatGPT a half-formed idea — a technical approach, a leadership challenge, a strategy question — and use the back-and-forth to stress-test it. It's less "give me the answer" and more "help me find out where I'm wrong." That adversarial, sparring-partner quality is what makes it useful here. I'm not looking for agreement; I'm looking for friction.
Claude, for the real work. Once an idea turns into actual work — a project, a codebase, a document that needs real structure — that's when Claude takes over for me. It holds context across a whole piece of work rather than a single exchange, and that matters enormously once you've moved past brainstorming and into building something that has to hang together. Give it a technical problem or a messy codebase and it can work through it methodically rather than needing to be re-oriented every few minutes.
GitHub Copilot, for the flow. Copilot doesn't get a dedicated "session" the way the other two do. It's just there, inline, while I'm actually writing code — finishing a line, suggesting the next one, staying out of the way otherwise. It's less a tool I deliberately reach for and more a tool that's already in my hand when I need it.
The skill isn't prompting — it's routing
Here's the pattern underneath all of this: the tool changes as the work changes. Early-stage thinking, deep project work, and in-the-moment execution are three different modes, and trying to force one AI to do all three is where people get frustrated and conclude "AI isn't that useful for X."
It's not that the AI failed. It's that it was doing a job it wasn't built for.
I think this is where a lot of the "prompt engineering" conversation misses the bigger picture. Getting better at prompting one tool only gets you so far if you're using the wrong tool for the stage of work you're in. The more valuable skill — the one that's actually going to compound over time — is routing: recognizing what stage of work you're in and knowing which tool matches it, before you even open the app.
A rough framework, if you want one
If it helps to have something concrete, here's roughly how I decide:
- Am I not sure what I'm building yet? → Start with a sparring partner. Push on the idea until it either survives or falls apart.
- Do I know what I'm building, and does it require holding a lot of context across a real project? → Move to a tool built for depth and continuity.
- Am I already doing the work, and just need help keeping pace? → Use whatever lives inline, in the flow, with the least friction.
It's not a rigid rule, and there's plenty of overlap — any of these tools can do a decent job outside its "home" stage. But defaulting to this kind of routing has made my own work noticeably less frustrating, because I'm no longer expecting one tool to be everything at once.
The real competitive advantage
The future of AI probably isn't about picking one AI platform and becoming an expert in it. It's about building a toolbox and learning, almost instinctively, which tool to reach for depending on the job in front of you.
The real competitive advantage may not be having access to AI — at this point, most people do. It may be knowing which AI to use, when to use it, and how to move between them without losing momentum.
That's the part I'm still refining. But it's already changed how I work.
#ArtificialIntelligence #ChatGPT #ClaudeAI #GitHubCopilot #Leadership #SoftwareDevelopment #Technology
Thanks,
Michael Cronin
Website: https://www.michaelcronin.info
LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/