Ok long time Claude Code user here; lately I've started to realize there's other great models out there I should be trying, but I'm hesitant to leave Claude Code behind for something new.
What's the consensus today on codex vs claude code, does it really matter anymore?
> Whether this mode of working is going to be long-term viable is going to depend on how important it is for you to be aware of what has happened for the system in question
This is the million dollar we'll see answered in our lifetime. Software engineering exists to automate work, are we arrogant to think we are not destined to the same fate? Is this truly a job befitting of a human over an agent?
Ever since I discovered my dad's C++ book in highschool I've absolutely loved coding, but i'm not convinced I have a long stable career ahead of me in SWE -- I'm 30 now and have already seen so much change in the industry during my professional career.
> how viable the economics are for the LLM usage at this level of assurance and how much ownership you exert over the LLM used or another similarly powered one
This piece scares me the most, a world where the next generation models are capped behind capital infeasible for the common person to access, further separating the ultra wealthy from what little remains of the middle class.
My hope is that open source models will fill the moat all of these AI companies so desperately want to dig, aready models like Qwen and Kimi are unfathomably better than what we had just a year or two ago.
Worth noting that this article is 25 years old. The world was very very different back then, especially when it comes to software engineering.
Context switching is a problem when the cost of switching contexts is non-negligible -- but in the age of agentic development is that still really true? Surely yes for some problems, but for many others I would argue it no longer is.
A personal anecdote for you:
At my company we have a local development CLI our devX team built, it allows for agents to interact with standing up, tearing down and managing local stacks for our software suite. When I receive customer feedback about a broken button, or a poor UX experience, I simply start up a prompt:
/metal user X reported an issue on the trial balance page, they encountered a blank page when using the inception to date filter. We need to investigate the root cause, spin up a new stack, and resolve the bug.
Then off to the next task, maybe some few hours later I'll check back in on the session and I'll see:
After a quick QA session I validate the fix, confirm that our claude reviewer has approved the PR and merge the PR to deploy. The mental burden of switching to this task is quite low, orders of magnitude lower than it would be 25 years ago.
I used the chrome MCP to profile a slow react page at my company, set a /goal and had it iterate until it achieved under 100ms responsiveness to actions.
Claude was able to identify the slowness and use various react tricks to fix the specific issues, all without my input.
I don’t think the playwright MCP can do this, unless I’m mistaken
6.x feels much more efficient with respect to token usage to be fair.
I picked up superpowers back when it first started gaining traction; the first iteration felt like an “oh shit” moment for me, then the sheen quickly wore off. Higher spend, slower throughput and mediocre results made me eventually drop it and go back to plan mode, which had improved significantly during that time.
Coming back, 6.x does feel different and I’m back on the superpowers train. I’m finding it great at taking discrete tasks from beginning to end with very little hand holding.
I run every session with a /goal as well: “Spec + Plan is written and you have implemented the plan without my involvement. You have validated that the implementation is complete and ready to merge”
It’s also great in situations where you may need to complete a plan over multiple sessions, because you get a whole ton of state with superpowers that new sessions can pickup on.
We switched our very large Django monolith codebase over to ty — the trick for us was generating stubs for Django models and having tooling keep those stubs in sync with the actual models.
Went from type checking taking ~10 minutes in CI to now taking ~15 seconds and runs on pre-commit.
Absolute game changer, I think we spent $10k in claude credits and did the entire mypy -> ty refactor in about 3 weeks.
I imagine Kernel development is quite difficult, as might be designing infrastructure that can handle 10K+ RPS. I don't quite understand why you're being so passive aggressive, this isn't reddit; I'm not interested in being correct/incorrect -- you're welcome to share your opinion with me and I'm more than willing to hear your side.
Like anything in life, "it depends" -- but I do have the opinion that the vast majority of software engineering jobs are orders of magnitudes simpler in requirements than the two examples you've given. On the grand scheme, many engineers need to be experts in their domain to succeed; it doesn't matter if you can support 1k RPS if you only have a few hundred clients and don't understand their needs well enough.
Most startups don't fail because they don't have the right tech, but because they don't capture the right market or understand their customers well enough. There have been many startups with absolutely brilliant tech, but if your company (and your engineers) aren't experts in your product the tech won't matter _until_ you hit a scale in which you require that sort of expertise.
Lol truly. A short list of just a few things that haunt my dreams: Distributions, American/European waterfalls, Carried interest, Management fees, and basically every single detail about Master feeder fund economics
After spending the last 5 years building software for venture capital and private equity, this blog post really resonates with me. Writing code is by and far the _easiest_ part of my job; understanding the financial engineering and nuance behind what my company's customers need from us the tough part.
We always joke that we'd rather hire a senior fund accountants and teach them to program if we could, only problem is there just aren't any of these folks around. Teaching an engineer to understand the minutia of fund accounting well enough to build software for these firms is tough.
I also love using `/loop` at work on combination with a PR maintenance skill, helps me push up changes initially and have a session automatically monitor + fixup a branch to get it passing before I review it myself and then later send off for a human review.
Self-edit: a couple thousand session hours is probably hyperbolic; it's likely closer to a thousand after discussing usage with another user in a separate thread.
Maybe a better metric: Across work + personal I have 1,000+ sessions in the last 30 days, longest session was 3d 20h
In my OP I mention this is aggregated across both work + personal, so the comparison of just 8 hour workdays 5 days a week isn't accurate.
Running some `/stats` on my work computer shows for the last 30 days:
* Sessions: 341
* Active days: 21/30
* Longest session: 3d 20h 33m (Some large scale refactoring of types)
So I'm running a little over 10 sessions a day, each session varies from something like 1-2 hours to sometimes multiple days if it's a larger project. Running `/clear` actually doesn't start a new session fwiw, it will maintain the session but clear context, which explains why I can have a 3 day long session but I'm not actually using a single context window.
On the personal side I have activity in 30/30 of the last days (:yay); I've been learning game dev recently and use Claude a lot for helping digest documentation and learn about certain concepts as I try to build them in Unity. One of my more interesting use-cases is I have three skills I use during play tests:
* QA-Feedback: Takes random thoughts / feedback from me and writes to feedback markdown files
* Spec-Feedback: Loops every minute to grab a feedback item and spec out the intention / open questions
* Impl-Feedback: Loops every minute to grab a spec, clarify open questions with the user (me) first, then create an implementation plan
So I might have a friend play my game and I'll generate 20-30 items of feedback as I watch them play the game, things like minor bugs or mechanics in general. Over the course of the day my Claude will spec and plan out the feedback for me. I have remote sessions always on so I can use my phone to check in on the implementor job and answer open ended questions as they come up.
By the following day I'll usually have a bunch of plans ready for Claude to work on. I'll send agents off to do the simple ones throughout the day (bugs) and work with Claude on the bigger items.
Sorry for the long winded explanation but trying to convey the level of usage I have w/ Claude code. I do admit "thousands" is hyperbolic, as I'm probably only nearing 2k session hours in the most extreme months but I would say I on average use Claude every day to some capacity, often times both during work and after work (for my hobbies).
I’ve been a full stack developer for 10+ years now and I completely disagree.
Modern models like Opus / Gemini 3 are great coding companions; they are perfectly capable of building clean code given the right context and prompt.
At the end of the day it’s the same rule of garbage in -> garbage out, if you don’t have the right context / skills / guidance you can easily end up with bad code as you could with good code.
Not to mention their language server + type checker `ty` is incredible. We moved our extremely large python codebase over from MyPy and it's an absolute game changer.
It's so fast in fact that we just added `ty check` to our pre-commit hooks where MyPy previously had runtimes of 150+ seconds _and_ a mess of bugs around their caching.
Anecdotally I'm using the superpowers[1] skills and am absolutely blown away by the quality increase. Working on a large python codebase shared by ~200 engineers for context, and have never been more stoked on claude code ouput.
What's the consensus today on codex vs claude code, does it really matter anymore?