HN user
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?
Both very fair observations.
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.
Does Joel still disagree today?
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/<url> 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.
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
It was never about the code.
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.
Tested this out on a 5x max plan, turns out I spun up 62 Opus 4.8 1M sub-agents for my dynamic workflow and maxed out my ~5hr cap in..... 18 minutes?
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
Additionally each city often has their own fares they impose, restrictions / etc
"Make no mistakes"
Np!
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 probably use a couple thousand session hours monthly between work & personal; very pleased with the results I get.
But I’m not necessarily oozing about it online — vocal minority and all.
I put in probably thousands of Claude session hours a month, aggregated across work + personal.
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.
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.
Agreed, as a software engineer of ~8 years now Mac is actually my _preferred_ environment -- I find it an extremely productive OS for development whether I'm working on full stack or Unity game dev in my free time.
I feel like it's more often a result of suffering from success that leads to these situations, rather than a lack of foresight to begin with.
For example I work on a python codebase shared by 300+ engineers for a popular unicorn. Typing is an extremely important part of enforcing our contracts between teams within the same repository. For better or for worse, python will likely remain the primary language of the company stack.
Should the founder have chosen a better language during their pre-revenue days? Maybe, but at the same time I think the founder chose wisely -- they just needed something that was _quick_ (Django) and capable of slapping features / ecosystem packages on top of to get the job done.
For every successful company built on a shaky dynamic language, there's probably x10 more companies that failed on top of a perfect and scalable stack using static languages.
This resonates with me this so much. I feel like half the comments in this thread are missing the value typing, but maybe they've never had the misfortune of working with hundreds of other developers on a project with no defined contracts on aggregates / value objects outside of code comments and wishful thinking.
I've worked on large python codebases for large companies for the last ~6 years of my career; types have been the single biggest boon to developer productivity and error reduction on these codebases.
Just having to THINK about types eliminates so many opportunities for errors, and if your type is too complex to express it's _usually_ a code smell; most often these situations can be re-written in a more sane albeit slightly verbose fashion, rather than using the more "custom" typing features.
No one gets points for writing "magical" code in large organizations, and typing makes sure of this. There's absolutely nothing wrong with writing "boring" python.
Could we have accomplished this by simply having used a different language from the beginning? Absolutely, but often times that's not a option for a company with a mature stack.
TL;DR -- Typing in python is an exception tool to scale your engineering organization on a code-base.
The podcasts feature is primarily why I love NLM!
I try starting my morning with learning, lately having a podcast to listen to while I start my day has been awesome.
Yep 100% agreed here. I run a member management platform[1] for small clubs which generally use PP to fundraise and collect member dues.
Works perfectly well for us, we don't handle any PI or CC details and clubs can connect their PP account to our platform for their registration / event management needs.
I had a period of time at my last job where the product org was so dysfunctional engineers did in fact run out of work.
Initially I didn’t mind it because my team focused on technical debt, but it pretty quickly turned sour. Having to scrape up “work” for the team of 6 engineers each morning to appear productive to management was dreadful
I allowed Claude to debug an ingress rule issue on my cluster last week for a membership platform I run.
Not really the same since Claude didn’t deploy anything — but I WAS surprised at how well it tracked down the ingress issue to a cron job accidentally labeled as a web pod (and attempting to service http requests).
It actually prompted me to patch the cron itself but I don’t think I’m that bullish yet to let CC patch my cluster.
Attribution revenue is what I would consider the gold standard for these types of services.
It makes sense on paper, if the service helps confirm legitimate reviews for you and convinces you to purchase said product, they should receive attribution revenue for helping generate the purchase.
The reality is much much messier though, because often times the people who award attribution revenue have a conflict of interest against any service that could even potentially expose bad practices happening on their marketplace.
I once worked for a popular deal site that developed a price tracking extension, a certain marketplace threatened to completely ban us from attribution revenue and we had to kill the extension over night despite our users loving it.
For one, the trees used here are mostly the desert variety that can withstand the hash conditions of our summers and infrequent waterings [1] -- they're actually quite beautiful too!
Secondly, LV is one of the most water efficient cities in the world. We recycle nearly all of our indoor water back into Lake Mead, and despite the city growing by 800K over the last 20 years we've reduced per-capita water consumption by 55% [2]
Our water crisis is a symptom of the water rights debate between the four states, not our over-consumption of water. You could actually eliminate the state of Nevada from the water crisis debate over the Colorado river and we wouldn't even make a _dent_ in the impact, it's the irrigated deserts of AZ and water intensive farming in CA that's the unsustainable piece (coming from a proud local who grew up in LV).
[1] https://knpr.org/norms-favorite-desert-trees
[2] https://www.lvvwd.com/conservation/measures/index.html?utm_s...
Many of the trees planted here can handle the harsh climate of Las Vegas summers and infrequent watering [1], not even mentioning that we recycle nearly 40% of our water and are amongst one of (if not the most) water efficient cities in the world [2].
If you can't tell I'm a bit of a proud Las Vegas local having grown up here, so there's bias in my words.
[1] https://knpr.org/norms-favorite-desert-trees [2] https://lvgea.org/water/