bshanks

Thanks! This is very exciting.

It looks like the spend limits can't be applied to existing AWS Accounts but only to new Projects, that there is no migration path from AWS Account -> Project, that you can only have 10 projects with Spend Limits, and that Projects can't use any region other than one of three regions determined by your organizational contact address. Is the plan to get rid of these limitations or should we expect these limitations to stay?

My use case is that our company would like to empower our AI agents to do a lot of stuff autonomously that involves reprogramming and spinning up EC2 instances (which, for reasons of latency, often need to be in particular regions other than our company's home address), and also doing data science on large amounts of existing data in our S3 Glacier. We would like to just let the agents run continuously, including when we are all asleep (and there would be no one around to respond to a budget alert). But we are worried that these AI agents might make a mistake that very quickly spends too much money (e.g. spinning up orders of magnitude more instances than they should). Since the agents are autonomous, they might spend money in a way we haven't thought of, so fine-grained budget-based automation wouldn't always work, and account-level spend controls are needed.

If someone had said, "I am generally not opposed to regulation, but this is a place where I don't support it.", you could have replied to it in a similar fashion, but reversed.

What's the conservative best practice for a solo founder (a one person company; assume the person spends ~20 hours per week on software development/maintenance and the rest of the time on other stuff)?

The main issue here is not UX, but rather that you did something which degraded quality without transparency. You should have documented this and also highlighted the change in an announcement. There should never be an undocumented change that reduces quality. There should never be something the user can do (or fail to do) that reduces quality without that being documented. To regain trust, Anthropic should make an announcement committing to documenting/announcing any future intentional quality-reducing changes.

In addition, the following is less important, but as other commenters have stated: walking away from a conversation and coming back to it more than an hour later is very common and it would be nice if there were a way for the user to opt to retain maximum quality (e.g. no dropped thinking) in this case. In the longer term, it would be nice if there were a way for the user to wait a few minutes for a stale session to resume, in exchange for not having a large amount of quota drained (ie have a 'slow mode' invoked upon session resumption that consumes less quota).

Note that inventory already in Amazon fulfillment centers as of March 31, 2026 is still commingled

"Also what happens after March 31st with the leftover commingled inventory that’s already there?

No action is required for stickerless inventory currently in-transit to or stored in our fulfillment centers. These products will continue to sell under their original SKUs.

However for a reseller, after March 31, 2026, all new inventory must use Amazon barcodes. Please review the FBA Barcode Choice and Labeling FAQ for additional information." -- https://sellercentral.amazon.com/seller-forums/discussions/t...

See also PerlNomic: http://odbook.stanford.edu/static/filedocument/2009/11/15/Ch...

I also found https://git.sr.ht/~rabbits/libreplanet2022/tree/master/item/... to understand the context

One of the authors talks about using C with SDL or libdraw here: https://news.ycombinator.com/item?id=31715080

Since they were on a boat with a Raspberry Pi and not much battery power or internet, in addition to execution speed and portability, they were probably also concerned with:

- speed of compilation and linking (on small machines like Raspberry Pi)

- binary size of anything that might have to be updated or shared over the internet

- having to troubleshooting emergent issues without the ability to lookup documentation or download updates or tools from the internet

In this situation, a simpler language on a simpler VM is probably going to be faster to develop with than compiling/linking a subset of C, and after the initial implementation of the VM, might present less opportunity for an unintended interaction of leaky abstractions in your libuxn and your toolchain to ruin your day on a day when you don't have internet connectivity to check Stackoverflow or to update some buggy dependency.

Yes, I think it's very possible that human brains unconsciously generate-and-test surprisingly large numbers of small candidate programs when solving a problem.

This approach is https://en.wikipedia.org/wiki/Embarrassingly_parallel, which is a good fit for biological neural architectures, which have very many computing nodes but each node is very slow (compared to electronic computer CPUs/GPUs).

The first thing to do is to put LLMs to work to generate large knowledge bases of commonsense knowledge in symbolic machine-readable formats that Cyc-like projects can consume.

I don't understand why an Income Sharing Agreement would be classified as loans. They seem more like equity than debt; the amount that students would pay depends on their future income, and can be arbitrarily small or large (right? or maybe I am misunderstanding the terms of these agreements).

I had thought that debt is when you have to pay back at least the "principal" no matter what, and equity is when the financier shares the risk of you failing. Maybe that's not correct, though?

Does the definition of a "loan" include any sort of financing, even if the amount that needs to be "paid back" to the "lender" can be arbitrarily small or large? That would make equity financing a special case of debt.

Even if other users (or possibly, sock puppets of the attacker) had not been complaining, the original maintainer probably would have began to trust the attacker after enough real contributions.

This thesis provides empirical support that a specific measure of software architectural complexity is costly. Specifically, they look thru source code in an automated manner, construct the graph whose nodes are source code files and whose edges are the following cross-file relationships (page 73, section 5.1.2.1):

- The site of function calls to the site of the function's definition

- The site of class method calls to the site of that class method's definition

- The site of a class method definition to the site of the class definition

- The site of a subclass definition to the site of its parent class' definition

- The site at which a variable with a complex user-defined type is instantiated or accessed to the site where that type is defined. (User-defined types include structure, union, enum, and class.)

Then they compute the transitive closure of this graph.

Then they compute two metrics for each node by looking at the transitive closure graph (page 76, section 5.1.2.3):

- Visibility Fan In (VFI): how many other nodes have edges that go from the other node to this node?

- Visibility Fan Out (VFO): how many other nodes have edges that go from this node to the other node?

They observe that by looking at the VFI metric across various files, files tend to sharply cluster into either 'low VFI' or 'high VFI', and similarly for VFO (although some files may be high in one metric and low in the other) (page 79, section 5.1.3).

They then classify each file as:

- low VFI, low VFO: 'peripheral'

- high VFI, low VFO: 'utility'

- low VFI, high VFO: 'control'

- high VFI, high VFO: 'core'

They then find that 'core' files are the most costly, in terms of defect density, developer productivity, and probability of staff turnover.

The university system is a mechanism to fund public goods. The problem is the professors are judged according to their production of novel knowledge, and maintaining useful software does not produce novel knowledge. We should endow chairs of "open-source professors", who are judged according to their production/maintenance of useful software, in order to re-use the infrastructure of the university system to fund this other type of public good.