Why a Top Founder Dropped Claude Code for Codex

Stop being loyal to your AI tool

A founder who left Anthropic and now runs his own tool company said he has not touched one popular coding assistant in five months and runs everything through a rival agent instead. The internet turned that into a tribal headline about which tool won. I am Madhuranjan Kumar, and I want to argue that the tool switch is the least important thing he said, and that treating it as the story is exactly the mistake most business owners make. My position is blunt: your loyalty to any AI tool is a liability, and the parts of his argument that actually matter have nothing to do with brand names.

Let me stake the claim clearly. If you walk away from this thinking "I should switch from tool A to tool B," you have missed the point. The durable lessons underneath are about efficiency you can measure, a job that is turning into supervision, and context being the whole game. Those hold no matter which logo is on your agent this quarter.

The tool switch is the least interesting part of the story

Here is why the switch itself barely matters. He dropped one assistant for another because, in his experience, the rival had a tighter agentic loop and used far fewer tokens for the same task. That is a real reason, but it is a snapshot. Tools leapfrog each other constantly. The assistant he prefers today could be behind in six months, and the one he abandoned could retake the lead. If your takeaway is the brand name, your takeaway has a shelf life of about one release cycle.

The evergreen lesson hiding inside the switch is the method, not the choice. He did not switch out of loyalty or vibes. He switched because he measured token consumption on his own real tasks and one tool was cheaper for the same result. That is the transferable behavior: benchmark your actual work rather than assuming the tool you started with is still the most efficient. Loyalty to a tool is how you end up overpaying for compute out of habit. The founder's real advice is to have no loyalty at all.

Efficiency is measurable, loyalty is not

This is where the contrarian point gets practical. If one agent finishes the same job with fewer tokens, the savings compound across every single run. Over hundreds or thousands of runs, a leaner loop is not a rounding error, it is a line on your budget. And the crucial word is measurable. You can actually count tokens and time on your own tasks. You cannot count "I like this tool better." So the discipline he models is to let the measurable number decide, not the familiar interface.

Most owners do the opposite. They pick a tool because a video told them to, then stick with it because switching feels like effort. That inertia is precisely the loyalty I am arguing against. The founder's entire posture is that tools are becoming commodities, and when something is a commodity you choose it on price and performance for your job, and you switch without sentiment when a better one appears. Applied to your business, that means periodically re-testing your AI stack on real work and being willing to move. The cost of that discipline is a little time. The cost of loyalty is paying more, slowly, forever.

The uncomfortable claim: your job is becoming supervision

Now the part that actually deserves the attention the tool war stole. His bigger thesis is that agents are eating software, and the nature of work is shifting from doing the thing to supervising the thing. As models improve, the chance that you personally move a pixel or hand-write a line trends toward zero. Roles are collapsing, so a designer can act as an engineer and a project manager can ship code. The habit of visiting a website to complete a task is fading, because people increasingly run their own agent over their own files.

I will push on this one, because "you will only supervise" is easy to overstate. Supervision is not passive. It requires knowing what good output looks like, which means domain expertise becomes more valuable, not less. The owner who deeply understands their trade is a better supervisor than a generalist with a fancier tool. So I half agree: yes, the doing is being automated, but the judging is not, and the judging is where your edge moves. That reframes the anxiety. The point is not that AI replaces you. It is that your role concentrates into the highest-value part, deciding and directing, and away from the mechanical part.

Context, not cleverness, is why output looks generic

This is the claim I agree with most, and the one almost everyone ignores. He insists that AI slop is almost always a context failure, not a model failure. Give the agent your real documents, your real data, and your real constraints, and even a mid-tier model produces work that looks hand-crafted rather than generic. Withhold context and the smartest model on earth gives you bland filler. The implication is that the money and effort belong in assembling rich context, not in chasing the newest model.

That is genuinely good news for owner-operators, and it is the deepest reason the tool war is a distraction. Your hard-won knowledge, your price book, your common scenarios, your brand voice, your past jobs, becomes the context that no competitor can copy. When tools are commodities, the durable edge is brand, community, and the quality of the context you feed your systems. People follow whoever they associate with a clear point of view, then adopt that person's product. The tool is replaceable. Your expertise, turned into context, is not. That is why obsessing over which agent you use is backwards: the leverage is in what you feed it, not which one you feed.

A worked example: an HVAC back office run on supervision, not tools

Take an HVAC company that wants to stop drowning in office work without hiring it all out. Following the real lessons instead of the tool war, the owner does not start by picking a trendy agent. They start with context. They gather the company's actual price book, its common repair scenarios, its warranty terms, and its brand voice into one place the agent can read. That context is what stops the output from sounding like a generic template, and it is the asset a competitor cannot lift.

Then the owner maps the tasks the office repeats every day and turns the top few into one-word shortcuts: a word that drafts a quote from a service description, one that writes a seasonal maintenance reminder, one that turns a finished job into a review request and a social post. They plan high and implement low, using a strong model once to design each workflow, then running the day-to-day on a cheaper, faster model to keep costs down, and re-checking that split periodically rather than staying loyal to one model. The owner no longer writes every quote. They review a draft, approve it, and the agent sends it, which is supervision, not typing.

The payoff, framed as illustrative, is a back office that runs on a fraction of the old admin time. The quotes and follow-ups the agent drafts flow into the CRM and website stack where automation handles the next several touches, the review requests and job posts feed SEO and organic search and social proof, and the freed-up hours and budget shift toward Google Ads and lead generation at the top of the funnel. Token usage per task drops meaningfully over the first few months as the shortcuts and the model split get tuned, but the real win is not the token count, it is that the owner is now supervising a system built on their own expertise instead of grinding through admin by hand.

The objection worth taking seriously

The honest thing to do with a contrarian argument is to steelman the strongest objection to it, so here it is. Someone could reasonably say: if tools are commodities and I should switch without loyalty, am I not just condemning myself to constantly re-testing and re-learning agents forever, burning time chasing marginal efficiency gains? That is a fair worry, and it deserves a real answer rather than a dismissal, because taken too far, "no loyalty" becomes an excuse to thrash between tools and never build depth in any of them.

The answer is that the switching discipline applies to the tool layer, not to the habits and assets that sit on top of it. You do not re-learn everything when you switch agents, because the durable parts, your context files, your one-word shortcuts mapped to long prompts, your plan-high-implement-low workflow, are portable. They describe what you want done and how, independent of which agent executes it. So a switch is mostly a matter of pointing the same workflow at a different engine, not rebuilding from scratch. The re-testing is periodic and lightweight, a check on your real tasks a few times a year, not a constant scramble. Framed that way, the objection actually reinforces the point: invest in the portable layer, stay loose about the swappable one.

There is a second, subtler objection: does not deep familiarity with one tool make you faster than someone who keeps switching? Sometimes, yes, and this is where I part company slightly with the pure "no loyalty" stance. Fluency has real value, and thrashing has real cost. The resolution is that you should switch when the measurable gap is meaningful, not when it is marginal. If a rival agent is a little faster, stay put and keep your fluency. If it is dramatically leaner on tokens for the same result, the way the founder described, then the gap is worth the switch and the brief relearning. Loyalty is the failure mode, but so is restlessness. The mature position is to let a meaningful, measured difference decide, and to ignore small ones.

Hold those two refinements and the core argument survives intact and gets stronger. Measure efficiency on your real work and switch when the gap is real. Expect your role to concentrate into supervision and judgment, which raises the value of your domain expertise rather than erasing it. And pour your effort into context, because that is the asset no tool can commoditize and the reason your output stops looking generic. The specific agent is a detail. The founder's real message was never a product recommendation, it was a warning against the comfortable inertia of loyalty, and a redirection toward the things that actually compound: your judgment, your context, and the brand and community that grow from having a clear point of view.

The position, restated

The story everyone repeated was "he dropped one tool for another." The story that matters is three-part and tool-agnostic: measure efficiency on your real work and switch without loyalty, expect your job to concentrate into supervision and judgment, and invest in context because that is where quality and durability actually come from. Believe those three and the specific agent you use becomes a detail you update, not an identity you defend.

You can set this up yourself with patience, and the shortcut system plus a solid context file is the right first step. If you would rather have the context, the agent workflow, and the automations wired up correctly from the start, that is exactly the kind of setup worth doing deliberately. But whatever you do, stop rooting for a tool. The founder's real message was never "use this one." It was "stop being loyal, and start owning the context and the judgment that no tool can replace."

That is why the loudest version of this story, the one about which coding tool won, ages so badly and the quiet version ages so well. Tools will keep trading the lead, and if your identity is tied to one of them, you will keep defending a choice that no longer serves you. Tie your effort instead to the portable layer, your context, your workflows, and your judgment, and every tool switch becomes a cheap upgrade rather than a crisis. The founder stopped touching a familiar tool the moment a better one appeared. The lesson is not his destination, it is his willingness to move.