A year ago, my day looked like most engineers' and engineering managers' days: a mess of context-switching between code, docs, Slack threads, pagers, and half-finished design notes. Today, a good chunk of that friction is gone — not because the work got easier, but because I've built a small ecosystem of AI tools that each do one thing well, and I've learned when to reach for which one. That habit — routing the task, not defaulting to a tool — turned out to matter a lot more once I started applying it to how my team works, not just how I do.
Here's how that actually plays out.
Fig. 01 Routing logic - which tool gets the task, and why
Claude — the daily driver
Claude is where I spend most of my time — at home and at work. It's become less of a "tool I open when stuck" and more of a standing collaborator, the first place I go to think through a problem before I've even fully articulated it to myself.
Structuring messy thoughts into clear writing
For design documents, status updates, and interview prep, I dump half-formed ideas into Claude and iterate until they're tight. The value isn't that it writes for me — it's that the back-and-forth sharpens my thinking faster than I could alone. It acts as a partner that stress-tests my arguments and brainstorms design alternatives with me.
Kicking off idea to prototype
Often, an idea needs visual form before I can tell whether the potential investment of time is worth it. I frequently build quick, disposable prototypes — for understanding a complex domain, exploring new tech, or just tinkering on side projects — simply to visualize a concept and test its validity before committing further.
Debugging with actual reasoning
When something's broken in a non-obvious way, Claude walks through the logic step by step rather than jumping to the first plausible fix. (I do prefer a terse, no-fluff style of output — partly to save tokens, partly because I just want the answer.)
Being a sounding board for decisions
Architecture trade-offs, how to frame a hard conversation, whether an approach is over-engineered — having something that pushes back constructively, instead of just agreeing, improves the quality of my decisions.
Scheduling meetings
Coordinating group meetings for distributed, remote teams is a logistical nightmare — juggling working hours across time zones, local holidays, vacation schedules, and existing calendar conflicts used to cost me 10–15 minutes per invite. I built a custom tool in Claude that pulls in team geo-locations, vacation data, project priority, and holiday calendars to automate the coordination and generate a proposed schedule with a pre-written agenda. For a manager spending five-plus hours a day in meetings, that's hours back every week.
Net effect: A clear head outpaces a blank page.
Codex — the deliberate second opinion
This is the part of my workflow I think is underrated. I don't use Codex because it's "better" or "worse" than Claude for coding —
I use it because it's different.
Every model has a distinct stylistic signature — a set of patterns, abstractions, and instincts about what "clean" code looks like. Since both Claude and Codex are closed models, I can't point to exactly why they diverge, but when Claude's suggestions start to feel like an echo of my own assumptions, I bring in Codex to break that loop. It's not disagreement for its own sake — it's a way to route around the blind spots of any single model. The intellectual equivalent of getting a second, sharp-minded colleague's take.
Fig. 02 Cross-checking a design decision against two independent models
In practice: I ask Codex to review logic Claude helped me draft, specifically for a fresh set of eyes. I use it to sanity-check architecture decisions when I want a genuinely independent critique, not just confirmation. Comparing how each model approaches the same refactor is often more instructive than either output alone — and at work, I frequently flip this around, having Claude rigorously evaluate designs or proposals that came out of Codex.
Net effect: Two independent judgments beat one confident opinion.
Gemini — the Google Workspace glue
Outside of pure coding, most of my day still lives inside the Google ecosystem — search, Gmail, Calendar, Docs — and this is where Gemini has quietly taken over a lot of the small, repetitive work I used to do by hand.
Chrome Ecosystem
Gemini's native integration into Chrome lets me instantly summarize search results, articles, and webpages. It's changed my browsing habits entirely: instead of manually parsing a list of links, I use the sidebar to filter and synthesize. The browser stops being a search tool and becomes an active reading assistant.
Inbox triage
Smart management of my Gmail inbox, so it reflects what actually needs attention — not everything that landed.
Invite creation
Turning an email thread into a calendar invite is now effortless — no manual entry of times or attendees. Letting the AI pull and format the relevant details is worth far more than it sounds, compared to dumping raw text into a calendar field and cleaning it up after.
Docs drafting
Redrafting or bootstrapping content directly in Docs kills the blank-page problem. It's been a game changer for ADRs and RFCs, and Gemini's real-time note-taking during meetings lets me focus fully on the conversation instead of worrying about missing details.
None of this is exciting work, but it adds up. Because it's embedded directly in my workflow, I no longer bounce between windows — a tedious quarter-hour of daily inbox maintenance has become fully automated.
Net effect: The best automation is the kind no one notices.
ChatGPT — the fun stuff
Not everything needs to be optimized for rigor. I use ChatGPT for the lighter, more exploratory side of things — making images, messing around with plugins, identifying a shirt I saw in an ad, grabbing a quick vegan recipe for dinner. It's great for casual "what if" tinkering that doesn't need to be professional-grade. A good reminder that not every AI interaction has to be about productivity — sometimes it's just useful for staying curious.
Net effect: Not every tool has to earn its keep — curiosity earns its own.
What this changes about how I lead
The habit doesn't stay personal for long. Once "route the task, not just reach for a tool" becomes second nature, it reshapes how you run a team — especially a lean one.
I expect the same support rotation from my reports
Claude for the first pass on code, Codex for the PR review, Gemini for anything document-heavy — polishing writeups, drafting, or searching a long corpus of internal docs with NotebookLM when the answer's buried three RFCs deep. It's less a mandate than it's become the default way work gets done on the team.
It's kept us shipping despite losing a lot of institutional knowledge
Recent layoffs took real subject-matter expertise with them. These tools have partly filled that gap — engineers with no ownership history on a codebase can go on pager rotation and hold their own, because the LLM does the first pass on runbooks and outage history and hands them a starting diagnosis instead of a blank page. That's made it possible to put people on 24x7 on-call without months of ramp-up, and to push through migrations that would otherwise have needed a specialist we no longer have — moving off a homegrown, Netflix-Genie-style orchestrator onto Airflow, converting Avro schemas to JSON in Glue, migrating MWAA Airflow 1 pipelines to Astronomer.
It's given people room to stretch
Backend engineers picking up frontend work, people touching parts of the stack they'd normally avoid — the tools lower the cost of being a beginner at something, so people take that risk more often.
My own job changed too
I use the same rotation for the manager-specific grind: full oversight of what my team's actually working on, rolled into leadership updates without a week of chasing status; scheduling across a half-dozen calendars of stakeholders who are all impossible to pin down. The tasks that used to eat my week are the same tasks I'd hand to a person if I had the headcount — now I hand them to whichever tool fits.
I weigh worth-per-token, not just capability
Gemini is already paid for through our Workspace license, so there's no case for spending a premium model's budget on document drafting it already handles well. Claude earns its keep on code, where the quality difference actually changes outcomes — and because Claude is the one writing or touching that code, having Codex look at it through an independent lens is worth the extra spend, not redundant to it. The question isn't "which tool is best," it's "which tool is worth it for this specific job."
Net effect: A lean team isn't understaffed if it knows how to route its work.
The bigger shift: role-switching, not tool-switching
The real change in my daily routine isn't "I use AI now." It's that I've started treating different AI tools the way I'd treat colleagues with different strengths — one for deep collaborative thinking, one for an intentionally outside perspective, one for the Workspace admin grind, one for low-stakes exploration. That mental model matters more than any individual tool.
Match the tool to the kind of help you need, not just the task. "I need code written" and "I need my code challenged" are different jobs, even if they look the same on the surface.
Don't ask for a second opinion from the same source. If Claude and Codex converge independently, that's a far stronger signal than either one agreeing with itself twice.
Protect the exploratory, low-stakes time. Not every interaction needs to be about shipping something, or you'll burn out on the productivity framing.
Use AI to sharpen your own reasoning, not replace it. The best sessions end with a clearer opinion of your own — not just an answer you copied.
Weigh cost against leverage, not just capability. The question isn't whether a tool can technically do the task — it's whether the one you're already paying for is good enough, and where the task's leverage justifies reaching for something sharper (and pricier) instead.
Route the task, not the tool, and most debates resolve themselves. That's where the real leverage is.