It was still the human writing the code. In the last several years it's become the human writing the prompt, which has led to agentic development, and the next step seems to be removing the human from managing the agents.
I'm sorry but I am just so tired of hearing this lazy logic. A C compiler is largely a 1:1, deterministic pattern matcher. I type X, I can be reasonably sure compiler will do Y.
An agent is not at all like this. The freaks who made this disingenuous machine don't even know how or why it does half the stuff it does. We're all just throwing shit at the wall and seeing what sticks. Absolute nonsense take my man, I'm sorry.
There is a huge difference between mathematical determinism and "it looks like that thing I said." Even the laziest, most superficial analysis must conclude these two things are not the same just because they have vaguely the same shaped shadow.
There's also a huge difference between formalizing your problem in a set of strict rules that take a lifetime to master and saying "make me a todo app, make no mistakes".
Linking to a straight LLM generated article where the first couple entries (the only ones I bothered to read) are about keystealers on users' computers doesn't help your case.
It's one part technical, one part a product decision. The technical part is that billing is not actually instant. As a most basic example, a VM reports its billing units every X period of time it is active. If there is some network blip but it's still running, then that billing data could be delayed.
The product level decision is that "shut down everything" is something the customers you want to target don't actually want. Are we including deleting RDS data? S3? Glacier storage? If so then the headline will just change from "Hobbyist got charged XXXXXX on AWS" to "Business literally had all their data deleted because a hacker took over their VM and mined bitcoin". The only people who really want this are hobbyists and it's not a market segment that's worth chasing. Easier to do the status quo of forgive afterwards then even open the can of worms of deleting all of a business's data and all their backups just because they had a 100k overrun.
Yeah, you can't just implement it as a pure "stop all services immediately once I hit a set amount"
It needs to be more like "don't allow spinning up additional services after you hit this amount", although that still allows you to go over the limit by a lot, since most services are billed hourly.
It really is difficult to implement a spending cap that doesn't risk shutting down important things.
It really is difficult to implement a spending cap that doesn't risk shutting down important things.
That's a checkbox decision for the customer. There needs to be the option of "This is important, never turn it off and I'll pay for any overages." versus "I want an entirely predictable bill up to $xxx, so stop my stuff as soon as possible over that."
It's not up to a cloud service to decide my website is more important than my money for me. That's my decision to make.
and they would still complain if they got it wrong - it's always the platform/company's fault.
Look at banks and fraudulent transfers that customers themselves get phished into doing. The bank in the end usually take the hit (after the customer complains long enough). That's why there's all sorts of hoops and such to prevent customers from failing - and that causes friction for people regularly.
Therefore, the cloud company's decision to default safer is more correct from this perspective.
You might be perfectly okay with having certain systems shut down, but you probably still want to pay for the archival storage of your important files.
That archival storage might be in several places, including one S3 bucket, whereas there might be another one that, contains copies of scraped Craigslist for X where you'd actually be happy that it just shut down.
This makes it far more complicated to do correctly, and as others pointed out, mostly relevant for hobbyist — this is not something you are going to make a lot of money from.
Better to spend engineering hours making an MCP for the dashboard or improving your Databricks setup.
Regarding hobbyists: some clouds, and also the bigger clouds, do target hobbyists quite a lot, presumably with the intention that some of those hobbyists will eventually grow and stick with them. So I don't think "not wanting hobbyists" is entirely true.
But yes, the amount of money they spend is less, so it makes less sense to implement features that only hobbyists want.
What surprised me about GCP was that yes, you could load all of your training data and model weights (terabytes) into a free starter account, then create a new account after 30 days and transfer the billing obligation from account A to account B.
It was such a blessing for hobbyists, back in ye olde 2019.
I think there is a middle ground between deleting data and allowing 5000 VMs to be created to mine bitcoin. Obviously there are a lot of different scenarios to consider but the explosive costs seem to be constrained mostly to a couple of features which would be fairly safe to cap.
> The only people who really want this are hobbyists and it's not a market segment that's worth chasing. Easier to do the status quo of forgive afterwards then even open the can of worms of deleting all of a business's data and all their backups
Hit the nail on the head.
Nearly all businesses would prefer a cost overrun than services going offline.
and if they're going to be a good decision maker they need to put their personal feelings from hobbyist times aside and realize stuff is different in the two scenarios.
You are correct; however, you're also putting a lot of faith in people's ability to make decisions.
Another thing (that does not really apply at AWS anymore), is that todays's enthusiasts are going to be the future CTOs, and the easiest time to recruit them to your service is when they are still an enthusiast who gets to make decisions on their own because there's exactly one decision maker you have to appeal to and that person really likes to try new stuff.
That's why you can get a free fly.io and why we all use Tailscale. And it works too — if I was in charge and needed it, I would immediately go with Tailscale for a business; I know it and I use it.
Meanwhile while in the real business world, Cloud decisions are shaped by marketing campaigns and it's the hobbyists and old grey-beards who provide the empirical push-back and reality checks.
If your peak monthly cost for AWS services as a business is $100k, do you not think setting a $200k spending limit is reasonable?
Obviously, the system should provide ample time by warning in advance of reaching it (and could even offer suggestion to keep it at N times your peak from M months ago).
If as a business you set your spending limits so tight that you frequently run into them and it's not some unusual activity, the problem is not that spending limits are available :)
It is mostly about protecting from the unknown, likely unbounded attack on your infrastructure, where your spend might grow 100x: even if you can take $100k, you might not be able to take $10M in a month.
And if you use enough services, a global per-account spending limit can't distinguish between peak usage versus one service being abused.
Imagine you spend $100k on average each month, but spend around Christmas rises to $1m because of the specifics of your industry. With a global spending limit, you can't distinguish between $200k of general spend increases due to Black Friday versus $200k in fraudulent 2FA SMS to South Sudan.
I agree but I think also, as a programmer, surely this is not an insurmountable problem. The idea that pops into my head immediately when hearing this problem is
1. of course spending limits are monthly or even weekly basis. You set a yearly limit, probably most people will do something like November to January 4 times the limits set rest of year.
2. as you near limit calls go to people on your team to tell them you are getting near your limit. Estimate is 2 hours, what do you want. Double Limit for this time period? Triple Limit for This Time Period? Remove Limit Entirely, you will get back to us with potential new limit? It's the beginning of Christmas, the next time your limit resets is the 3rd of January, remove limit entirely and you will get back to them. Why do you decide to remove limit entirely, because you have info that Amazon doesn't, specifically your assassin Nisse doll has gone viral for this Christmas season! The shit is making bank!!
3. When setting limit you say "expected low usage", "expected high usage", "limit". Limit should be significantly above expected high usage. Service informs you - you have been over your expected high usage by 20% last three time periods. Would you like to increase limit and high usage by 20%? Please Look at your settings otherwise.
4. Phone calls when there is an unexpected peaking in usage, like one hour we are 300 thousand which is very high for you, next hour it is 1.5 million.
Obviously none of this stuff helps hobbyists but even the worst run businesses I've worked at would handle this. Otherwise they deserve to be hobbyists, there's no reason to be an organization if you're not organized.
Obviously these things do not stop fraudulent attacks abusing your service, but it does make it harder for them, at the same time making it more difficult for your stuff to just get shut off without you knowing.
Of course, as a programmer I am aware that all these services are created by programmers as effective or more effective than I, and who have undoubtedly thought about it more than I, so I must also assume there are reasons why my off the cuff suggestions are ludicrously unhelpful, but I lack the knowledge as to why this should be so.
for personal/hobby accounts sure. for a business, it’s much better to negotiate around billing or adjust systems/processes post-facto than it is to have service cut off unexpectedly.
debts are easier to manage when you have an active (ideally growing) customer base. you don’t have customers anymore if your cloud account takes down your service for the rest of the month due to spending limits.
If you are actually a business, a common warning that you are near the limit should mostly resolve it. It might only be tricky because the estimated time remaining is really short if it's a huge recent spike: eg. nobody is looking forward to a notice of "you'll use up your spending limit in 4h" on the weekend.
This type of warning should give you enough time to investigate if the warning is real and adjust the spending limits.
But then again, even if you hit them and your services get paused, you'd be increasing the spending limits and restoring services after you are back at work and notice they are down, so it mostly comes down to your incident response times.
There is a middle ground here: Make this setting configurable, off by default, and with all the associated warnings of what will happen if you switch it on. Better yet, make it settable on each billable service. Keep Route 53 going, but halt and delete any VMs that exceed some limit.
> Are we including deleting RDS data? S3? Glacier storage?
If you're billing per GB of storage, then you can put hard caps on storage capacity, and then hard-reject any operation that would take the total stored size over that capacity.
A lot of billing systems are organized around event delivery. The system does what it does and reports usage. This reporting is asynchronous and can be done E.G. via cron jobs running on a 24 hour cadence in certain cases. There's an internal guarantee that billing records for a given period are delivered by a certain time. Nobody checks whether the user has enough money to do what they're trying to do, just whether they're authorized to access the system in the first place. Shutting down accounts due to non-payment is more of an abuse / fraud concern, and happens long after the bill is delivered.
Wow, I wish my my cell provider worked like that! Instead, they somehow manage to track and bill me literally in real time. How do they do it? Do the telcos have some magic pixie dust or what?
Telcos did work like that (especially in roaming scenarios).
Your MSC (roughly the thing that people in your geographic area connect to) would talk to your HLR (the place where your records are stored specifically, regardless of current location) to authenticate you and make sure you're a real subscriber, but it wouldn't necessarily do so before every single call. At the end of some billing period, the operator whose services you've used (MSC owner) would send billing records (using the TAP format) to your operator, usually via FTP or similar, and your operator would use them to send you a bill.
This worked for post-paid, when customers were assumed to be trusted, and legal sanctions could be levied against those who refused to pay their bill. However, this approach broke down when prepaid plans were introduced. This led to the invention of CAMEL, which is basically a realtime protocol which lets the MSC ask the HLR whether a given call was permitted or not.
> This worked for post-paid, when customers were assumed to be trusted, and legal sanctions could be levied against those who refused to pay their bill. However, this approach broke down when prepaid plans were introduced. This led to the invention of CAMEL, which is basically a realtime protocol which lets the MSC ask the HLR whether a given call was permitted or not.
And since the cloud providers don't have the problem in your first sentence (even if the customers pre-paid, they're still easily identifiable), they never bothered to implement the solution from your last sentence. But seriously, the problem of accurate, real-time billing is not a new one, and it's been solved before several times already (e.g. RADIUS/Diameter of dial-up ISPs).
Storage is almost never the main thing racking up bills so it should be handled in a different way. If you hit a limit you can't store any more data but everything you have stays there and readable.
This is more about compute, VMs, LLM inference and services like hosted database. These are all safe to stop if the system triggers a normal shutdown when costs hit a limit.
I dunno, the largest accidental AWS overages I’ve triaged in my career (at very different companies) were all storage. Dangling EBS, forgotten S3 accumulating data after a deletion cron broke, incompletely retention-policy’d CloudWatch buckets, Aurora snapshots…the list is pretty long.
“Large” is relative to the business of course, but the biggest storage-related overages I’ve personally triaged are in the high $100ks to low $millions per month. Colleagues have heard of orders of magnitude more costly.
That’s not storage costs, that’s activity adding to storage used. The question is whether it would be cheap enough for them to keep all your existing data frozen until you paid the bill.
For S3 a reasonable option is a data limit as the primary limit. If you set it a TB over your real needs you only waste one dollar per day after it locks. And there's no need for any other paused service to charge more than that for idle data.
You're right that nobody wants deletion. Spending limits do not imply deletion.
I think a more sensible default is S3/etc locking access to data for 30 days, maybe even as little as 7 days, while you're able to still list and DELETE said data as you wish, without being able to get or put.
No, I'm asking why ChatGPT isn't sufficient because they literally do the same thing unlike Dropbox vs rsync. In other words ChatGPT has the same UI UX but people flock to Muse for some reason.
You clearly didn’t understand what Muse is if you think it’s the same. Do you understand “always on”? Try to learn what that means, so you will understand why ChatGPT chat is not that.
You clearly don't understand ChatGPT's Dots, it is also always on. And even before that, you could emulate lots of Muse's features through ChatGPT, for example I have a daily automation to look through my emails for example. It's just that Muse is free and also captured people's attention through making it a bit more streamlined.
Google Search and Google Maps are utilities, not consumer apps that vie for leisure time, so I don't think they are really comparable. The next frontier for AI apps like Muse and Dots is competing with the social media giants.
We should look to see how Shorts vs IG Reels have adapted to the short form video landscape for product chops in this area. IMO IG has adapted far better to the new era, and I very often get people sending me Reels (they used to send TikToks). I very rarely see anyone send Shorts but it still happens. I expect this trend to continue and IG to extend their lead here. And Muse certainly has first mover advantage in personalized AI apps, who knows when Google will finally release one.
You can consider the cute & fuzzy presentation of the new consumer AI agents an admission that the doom and gloom so far has been a marketing mistep. It's good that companies are trying to rectify the image of AI.
I might stand corrected but I believe there’s a nuance even for public companies. Being awarded options directly (from the company) and not exercising would mean the company does nothing - that is, it keeps the equity. There is no options house or exchange involved hence no external settlement process.
This appears to be pretty close to the "brutalist" aesthetic mentioned in the article. Things like drop shadows on boxes are the opposite of the "fingernail" boxes and you very rarely saw them pre-AI. However I think your site looks fine and well crafted, nice work. (the article also said that this kind of design language is less grating)
Yeah brutalist is exactly right, that is basically what I prompted for. I didn't realize a bunch of other people were doing this. Actually the only inspiration I had for this was watching the movie (Brutalist) a few years back.
Even before AI, brutalist style is not that popular compared to flat, glassmorphism, skeuomorphism etc. Two popular website that use brutalist that I remember is Gumroad and Figma.
Things like Voice to Text and biometric unlocks (fingerprint scanners, face ID) have worse success rates and they're used every day by billions of people.
The fundamental issue is, that "we" somehow decided it would be a good idea to throw all the fundamental ideas of computing (determinism, context, separation between data and execution,...) away and try to solve the issues by running a probabilistic/stochastic word generator on top of deterministic circuits instead at 10 magnitude worse efficiency.
It's not a fundamental issue. Determinism and "separation between data and execution" are artificial constructs, make-believe universe in which we design classical code, and a whole lot of hardware engineering goes into allowing us to briefly forget it's all fake.
Real world is probabilistic in practical / metrological, if not fundamental sense, and separation between data and execution does not exist. Our reality does not support such separation.
> a probabilistic/stochastic word generator on top of deterministic circuits instead at 10 magnitude worse efficiency
It's 10 magnitude better efficiency end-to-end, if you factor in design time you'd have to spend to get your "deterministic circuits" (which really aren't, we just paper over it) into shape so they deterministically solve a specific problem, for each problem you want to solve - where with the "stochastic word generator", you just need to change the text prompt.
reply