The short of it is that cooling is likely the biggest problem, given you will need to pump the heat to the backside and radiate it away, and the amount of mass you will need to dedicate to cooling works against deployments and increases the cost per unit significantly. Not to mention, the idea of these huge deployments runs into potential space debris issues.
Whenever one of these ventures actually manages to launch a proof of concept, I think we'll be able to quickly discern if there is actually a near-future here.
I love ruby. It's certainly not sentimental; I enjoy writing it and working in it, certainly a lot more than javascript.
I do feel like these sorts of attacks on ruby are quite weird. It's totally ok not to enjoy working in any particular programming language, but I wonder what the angle is to write about it is.
Arguments regarding ruby's successes are always so weird to me. Github, Twitter, Coinbase, and Shopify are all examples of great success. Challenges with scaling are successful problems.
It's a great tool and if you read this, consider and evaluate if ruby is appropriate for your next project. :)
I need to see a video of what people are doing to hit the max limits regularly.
I find sonnet really useful for coding but I never even hit basic limits. at $20/mo. Writing specs, coming up with documentation, doing wrote tasks for which many examples exist in the database. Iterate on particular services etc.
Are these max users having it write the whole codebase w/ rewrites? Isn't it often just faster to fix small things I find incorrect than type up why I think it's wrong in English and have it do a whole big round trip?
I can tell you how I hit it: Opus and long workflows.
I have two big workflows: plan and implement. Plan follows a detailed workflow to research an idea and produce a planning document for how to implement it. This routinely takes $10-30 in API credits to run in the background. I will then review this 200-600 line document and fix up any mistakes or remove unnecessary details.
Then implement is usually cheaper, and it will take that big planning document, make all the changes, and then make a PR in GitHub for me to review. This usually costs $5-15 in API credits.
All it takes is for me to do 3-4 of these in one 5-hour block and I will hit the rate-limit of the $100 Max plan. Setting this up made me realise just how much scaffolding you can give to Opus and it handles it like a champ. It is an unbelievably reliable model at following detailed instructions.
It is rare that I would hit the rate-limits if I am just using Claude Code interactively, unless I am using it constantly for hours at a time, which is rare. Seems like vibe coders are the main people who would hit them regularly.
This is very interesting as a workflow. How “big” are the asks you’re giving Claude? Can you give an example of the type of question you’d ask it to implement where it requires a discrete planning document that long?
Whenever I use it, I typically do much smaller asks, eg “add a button here”, “make that button trigger a refresh with a filter of such state…”
The best results I get are for things like writing a new database migration and plumbing the data through to an API endpoint. That touches a lot of the codebase, but is not particularly complicated, so this process works quite well for that. Especially because it is easy for me to review.
I have also used this for creating new UI components or admin pages. One thing I have noticed is that the planning step is pretty good at searching through existing UI components to follow their patterns to maintain consistency. If I just asked Claude to make the change straight away, it often won't follow the patterns of our codebase.
But for UI components, adding new pages, or things like that, it is usually more useful just as a starting point and I will often need to go in and tweak things from there. But often it is a pretty good starting point. And if it's not, I can just discard the changes anyway.
I find this is not worth it for very small tasks though, like adding a simple button or making a small behaviour change to a UI component. It will usually overcomplicate these small tasks and add in big testing rigs or performance optimisations, or other irrelevant concerns. It is like it doesn't want to produce a very short plan. So, for things like this I will use Claude interactively, or just make the change manually. Honestly, even if it did do a good job at these small tasks, it would still seem like overkill.
Here's an example of me doing a migration from Deno -> Bun, prompting with something like "migrate this, make a plan in BUN.md" and then "do step 1 and write your progress, do step 2, etc."
Yup. I'm on a side project trying to port the 1980's computer algebra system Macaulay I coauthored from 32-bit K&R C to 64-bit C23.
K&R C is underspecified. And anyone who whines about AI code quality? Hold my beer, look at our 1980's source.
I routinely have a task manager feed eight parallel Claude Code Opus 4 sessions their next source file to study for a specific purpose, to get through all 57 faster. That will hit my $200 Max limit, reliably.
Of course I should just wait a year, and AI will read the code base all at once. People _talk_ like it does now. It doesn't. Filtering information is THE critical issue for managing AI in 2025.
The most useful tool I've written to support this effort is a tmux interface, so AI and I can debug together two terminal sessions at once: The old 32-bit code running on a Linode instance, and the new 64-bit code running locally on macOS. I wasn't happy with how the tools for this worked, that I could find online. It blows my mind to watch Opus 4 debug.
Mind sharing your detailed planning workflow and/or how you came up with it? Is it basically a detailed prompt asking it to produce a PRD?
I often find my plans for the code changing as I get into implementation. I wonder if giving the model explicit permission to change the plan would work or cause it to go off the rails for big chunks of work like this.
Creating these was basically just a workflow of writing out a workflow myself, getting Opus to refine it, then back to me, then back to Opus until it was something I was happy with. There is probably a lot more refining you could do with it, but it works pretty well as it is right now.
I then have wrapper scripts that invoke these using claude -p in a container, but those are pretty specific to my codebase.
> Isn't it often just faster to fix small things I find incorrect than type up why I think it's wrong in English and have it do a whole big round trip?
This is my experience: at some point the AI isn't converging to a final solution and it's time to finish the rest by hand.
Yesterday I tried CC the first time. I have the $20 package. I asked it to improve the code in a small kotlin based chess engine. Five minutes later I reached my limit and the engine performed poorer than before.
It just created two new classes, changed some code in others and created a couple of tests which it ran. So I hit the limit pretty quickly.
I couldn’t even get it to do simple tasks for me this week on the max plan. It’s not just max users overloading it. It feels like they’re randomly rate limiting users.
One day my very first prompt in the morning was blocked. Super strange.
Faster overall, sure. But I am interrupt driven and typing the prompt alone is faster yet, so I do that and come back after a bit (bouncing between many open tasks), so the fact that the agent took 3x longer overall doesn’t matter, because it happens in the background. my time was just spent typing out the prompt, which was only seconds.
Junior devs using AI can get a lot better at using AI and learn those existing patterns it generates, but I notice, for myself, that if I let AI write a lot of the code I remember and thereby understand it later on less well. This applies in school and when trying to learn new things but the act of writing down the solution and working out the details yourself trains our own brain. I'd say that this has been a practice for over a thousand years and I'm skeptical that this will make junior devs grow their own skills faster.
I think asking questions to the AI for your own understanding totally makes sense, but there is a benefit when you actually create the code versus asking the AI to do it.
I'm sure there is when you're just getting your sea legs in some environment, but at some point most of the code you write in a given environment is rote. Rote code is both depleting and mutagenic --- if you're fluent and also interested in programming, you'll start convincing yourself to do stupid stuff to make the code less rote ("DRY it up", "make a DSL", &c) that makes your code less readable and maintainable. It's a trap I fall into constantly.
> but at some point most of the code you write in a given environment is rote
"Most of the code one writes in a given environment is rote" is true in the same sense that most of the words one writes in any given bit of text are rote e.g. conjunctions, articles, prepositions, etc.
Some writers I know are convinced this is true, but I still don't think the comparison is completely apt, because deliberately rote code with modulated expressiveness is often (even usually) a virtue in coding, and not always so with writing. For experienced or enthusiastic coders, that is to say, the effort is often in not doing stupid stuff to make the code more clever.
Straight-line replacement-grade mid code that just does the things a prompt tells it to in the least clever most straightforward way possible is usually a good thing; that long clunky string of modifiers goes by the name "maintainability".
See, I get what you're saying, but this is my whole thing. No. Abstracting code out or building a bespoke codegen system is not always or even usually an improvement on straight-line code that just does what it says it does.
From the recent tesla acme test, where the tesla runs into a wall containing a picture of a road, they also tested rain and water blocking two mannequins. The lidar equipped vehicle managed to stop before hitting the mannequins while tesla's autopilot did not. The distance before automatic braking triggered was reduced iirc.
Sure lidar is degraded by rain, but I think the conclusion that when it rains the whole system will degrade to just cameras seems incorrect. It may reduce its effective range but it seems likely to still have some advantage in a wide range of conditions.
Polypane doesn't simulate the specific rendering engine of other browsers, it just pretends to be another browser (which is what emulation is) so you can test that the code you wrote for those browsers (for example, a polyfill) responds well. You'll still need to test in those real browsers to check against their rendering bugs or support gaps. (but something like Polypane portal[1] can make that step much easier)
I don't feel that you have a measured take on what is basically browser tooling. It's a customized browser built around web development. Is that _so_ insane?
Imagine someone came out with a browser that synced and allowed you to view/test your app in the days of ie6/7/8/9 across all those browsers. Would charging money per month for that be so weird?
This isn't for anyone to use as their normal browser.
https://www.youtube.com/watch?v=d-YcVLq98Ew
The short of it is that cooling is likely the biggest problem, given you will need to pump the heat to the backside and radiate it away, and the amount of mass you will need to dedicate to cooling works against deployments and increases the cost per unit significantly. Not to mention, the idea of these huge deployments runs into potential space debris issues.
Whenever one of these ventures actually manages to launch a proof of concept, I think we'll be able to quickly discern if there is actually a near-future here.