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:

> PR created: https://github.com/company/repo/pull/12758295 > QA URL: http://localhost:8400/ > Summary of root cause and fix: lorem ipsum lorem ipsum

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.

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

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.

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.

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.

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.

Oops, but probably good to know that this is not a cheap feature -- next time I'll have to figure out how to tune the workflows to use Haiku / Sonnet

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.

Maybe a better metric: Across work + personal I have 1,000+ sessions in the last 30 days, longest session was 3d 20h

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).

But I’m not necessarily oozing about it online — vocal minority and all.

I must be missing something or supremely lucky because I feel like I’ve never hit these “stupid” moments.

If I do, it’s probably because I forgot to switch off of haiku for some tiny side thing I was doing before going back to planning.

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.

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.

Personally, I've found that the paradigm of "sharp knives in the drawer" can lead to some pretty nasty output from LLMs; it's felt to me like the higher the ambiguity the higher the variance in quality.

This has shifted my approach to A&D:

* Always enforce strict contracts, i.e. the ONLY way to do X is through Y.

* Fail loudly and fail often, assumptions and fallbacks only encourage AI to make larger assumptions.

* Boring is better, the less magic you implement the easier it is for LLMs to understand and extend.

Anyone else have some nuggets of truth they'd want to share as it pertains to A&D + AI?

Comments URL: https://news.ycombinator.com/item?id=45916354

Points: 1

# Comments: 1