That's kind of the point. In a culture where names commonly have a lot of syllables, the length of the name is much less of an issue. That tiny discomfort of the extra effort to process more syllables disappears when it's not considered 'extra'
I’m not sure I agree. I expect that an Indian would similarly be more likely to coin the term “Krish Singh Facts” than they would “Sanjay Ghemawat Facts”, in exactly the same way we do.
I’d be interested to hear from someone from a different culture to verify whether this is true or not.
I don't know how such things are considered in India either (and would also be interested to hear from someone). The salient point is that you do value fewer syllables in a comedy context. All it takes for someone to feel that it might be racist is to recognise that fewer syllables in comedy names may not be universal across cultures, and that taking an action that elevated one person and not another may have inadvertently selected someone of one race because of that preference.
It's not an absolute claim being made here. It's just a consideration that what we intuitively feel may not be an expression of a universally held value.
When I ask Claude to do something, it independently, without me even asking or instructing it to, searches the codebase to understand what the convention is.
I’ve even found it searching node_modules to find the API of non-public libraries.
If they're using Opus then it'll be the $100/month Claude Max 5x plan (could be the more expensive 20x plan depending on how intensive their use is). It does consume a lot of tokens, but I've been using the $100/mo plan and get a lot done without hitting limits. It helps to be mindful of context (regularly amending/pruning your CLAUDE.md instructions, clearing context between tasks, sizing your tasks to stay within the Opus context window). Claude Code plans have token limits that work in 5-hour blocks (that start when you send your first token, so it's often useful to prime it as early in the morning as possible).
Claude Code will spawn sub-agents (that often use their cheap Haiki model) for exploration and planning tasks, with only the results imported into the main context.
I've found the best results from a more interactive collaboration with Claude Code. As long as you describe the problem clearly, it does a good job on small/moderate tasks. I generally set two instances of Claude Code separate tasks and run them concurrently (the interaction with Claude Code distracts me too much to do my own independent coding simultaneously like with setting a task for a colleague, but I do work on architecture / planning tasks)
The one manner of taste that I have had to compromise on is the sheer amount of code - it likes to write a lot of code. I have a better experience if I sweat the low-level code less, and just periodically have it clean up areas where I think it's written too much / too repetitive code.
As you give it more freedom it's more prone to failure (and can often get itself stuck in a fruitless spiral) - however as you use it more you get a sense of what it can do independently and what's likely to choke on. A codebase with good human-designed unit & playwright tests is very good.
Crucially, you get the best results where your tasks are complex but on the menial side of the spectrum - it can pay attention to a lot of details, but on the whole don't expect it to do great on senior-level tasks.
To give you an idea, in a little over a month "npx ccusage" shows that via my Claude Code 5x sub I've used 5M input tokens, 1.5M output, 121M Cache Create, 1.7B Cache Read. Estimated pay-as-you-go API cost equivalent is $1500 (N.B. for the tail end of December they doubled everybody's API limits, so I was using a lot more tokens on more experimental on-the-fly tool construction work)
FYI Opus is available and pretty usable in claude-code on the $20/Mo plan if you are at all judicious.
I exclusively use opus for architecture / speccing, and then mostly Sonnet and occasionally Haiku to write the code. If my usage has been light and the code isn't too straightforward, I'll have Opus write code as well.
That's helpful to know, thanks! I gave Max 5x a go and didn't look back. My suspicion is that Opus 4.5 is subsidised, so good to know there's flexibility if prices go up.
The $20 plan for CC is good enough for 10-20 minutes of opus every 5h and you’ll be out of your weekly limit after 4-5 days if you sleep during the night. I wouldn’t be surprised if Anthropic actually makes a profit here. (Yeah probably not, but they aren’t burning cash.)
I use the $200/month Claude Code plan, and in the last week I've had it generate about half a million words of documentation without hitting any session limits.
I have hit the weekly limit before, briefly, but that took running multiple sessions in parallel continuously for many days.
In my experience these models (including opus) aren’t very good at “improving” existing code. I’m not exactly sure why, because the code they produce themselves is generally excellent.
Yeah Opus 4.5 is a massive step change in my experience. I feel like I’m working with a peer, not a junior I’m having to direct. I can give it highly ambiguous and poorly specified tasks and it… just does it.
I will note that my experience varies slightly by language though. I’ve found it’s not as good at typescript.
It’s also way better than I am at finding bits of code for reuse. I tell it, “I think I wrote this thing a while back, but it may never have been merged, so you may need to search git history.” And presto, it finds it.
This is interestingly somewhere where Go really shines, in my experience. Go has no requirement to wrap (or, indeed, even handle at all) errors; yet, despite this, Go codebases I've worked in almost always perform error handling properly (wrapping at each layer of the call stack, so it's easy to identify where an error occurred).
I don't think there is anything in Go (the language) that helps achieve this - its mostly cultural. (Go creators and community being very outspoken about handling errors).
In fact, the easiest thing to do in Go is to ignore the error; the next easiest is to early-return the same error with no additional context.
It does expect you to use `wrap_err` to get the benefits, though. Which is easier to do than what Go requires you to do for good contextual errors, and even easier if you want reasonable-looking formatting from the Go version.
IMO you need both things: culture to make it happen, and technology to make it easy and reasonable looking. Rust lacks the former to some degree; Go lacks the later to some degree (see e.g. kustomize error formatting - everything ends up on a single line)
I find Claude (and specifically Opus 4.5) insanely impressive and frankly scary, but I think there is some Pareto principle that people ignore when discussing it. Specifically I find it is great at the first 80%, but I struggle getting the last 20% over the line with it. I think this colours people’s judgement, because influencers/casual/beginner users only experience that first 80%
My reading is precisely the opposite, ie that she fed it the problem without the solution and it independently came to the solution they spent months arguing over.
Unless that was a complex constraint-satisfying compromisation problem I don't think that's different though? My point is that it didn't take so long to produce the code of this solution, it took the time to agree that it was the solution. Unless you just get everyone to agree 'whatever Claude says is the solution', having Claude produce it doesn't help!
It is different. You suggested that rakyll told Claude to simply implement a solution that her team already put the legwork into designing. I'm saying that it sounds like Claude produced the solution independently based on a description of the problem. Those two are completely different and if you can't see that, I'm not sure what to say.
> having Claude produce it doesn't help!
Sure. Also, it could be a coincidence that it came to the correct solution, we can't discount that possibility.
reply