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
There are 720 hours in a month. You'd have to be running 3 sessions in parallel continuously to be doing thousands of session-hours in a month. Are individual people really doing this?!
I work with 3-5 parallel sessions most of the time. Some of the projects are related, some are not, some sessions are just managing and tuning my system configuration, whatever it means at a given time.
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).
Great, thank you for the detailed response! The biggest difference in our use is your "loops every minute", which I've not been willing to try yet (even with me at the helm, Claude might try to make a fairly straightforward bugfix in a cracked-out way and I have to steer it in the right direction).
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.
Similar usage here. But I encountered this moments, and I chalk it up to the random nature of LLMs. Back in Sonnet 3.5 days, it would happen every other day. I even build an 'you are absolutely right' tracker back then to measure it. Opus 4.6, maybe once or twice a month.
It's possible that it's simply paranoia, but moments where Opus starts acting like Haiku seem to correlate with periods of higher latency and HTTP errors. Don't like reporting this because it's so hand-wavy and conspiratorial, but it's difficult not to think they're internally using extraordinary measures of some sort to manage capacity.
But even when Opus is running healthy, it still doesn't address the underlying issue that these models can only do so much. I have had Opus build out a bunch of apps but I'm still finding my time absorbed as soon as it comes to anything genuinely exceeding "CRUD level difficulty". Ask it to fix a subtle visual alignment issue, make a small change to a completely novel algorithm, or just fix a tiny bug without having to watch for "Oh, this means I should rewrite module <X>" is something that simply isn't possible while still being able to stand over the work.
It's not to say I don't get a massive benefit from these tools, I just think it's possible to be asking too much of them, and that's maybe the real problem to solve.
Most people hate reading. Therefore they don't know how to write. Therefore they can't prompt properly. Not to mention so many "enemies of logic" cults being so strong nowadays.
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.
This just feels like the whole complicated TODO workflows and MCP servers that were the hot thing for awhile. I really don't believe this level of abstraction and detailed workflows are where things are headed.
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 don't agree with OP's sentiment that macOS is a bad dev environment, but surely I prefer Linux+KDE as an overall dev environment. I find that all the tools I need are there but that I'm fighting the UI/UX enough to make it a hassle relative to KDE.
> I don't agree with OP's sentiment that macOS is a bad dev environment, but surely I prefer Linux+KDE as an overall dev environment. I find that all the tools I need are there but that I'm fighting the UI/UX enough to make it a hassle relative to KDE.
This sounds like you think macOS is a good dev environment, but that you personally don't like the UI/UX (always safer to make UI/UX judgements subjective ["I don't like"] rather than objective ["it's bad"], since it's so difficult to evaluate objectively, e.g., compared to saying something like Docker doesn't run natively on macOS, which is just an objective fact).
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.
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.
But I’m not necessarily oozing about it online — vocal minority and all.
reply