You can treat the LLM's answers ass hypotheses about why it did what it did, and test those hypotheses. The hypotheses the LLM comes up with might be better than the ones you come up with, because the LLM has seen a lot more text than you have, and particularly has seen a lot more of its own outputs than you have (e.g. from training to use other instances of itself as subagents).
I think if you're vibe coding to the extent that you don't even know the shapes of data your system works with (e.g. the schema if you use a database) you might be outsourcing a bit too much of your thinking.
This. When compilers came along, I believe a bunch of junior engineers just gave up utterly on understanding the shape of how the code was generated in assembly which was a mistake given early compilers weren't as effective as they are today. Today vibe-coders are using these early AI tooling and giving up on understanding the shape, and similarly struggling.
The first 500 or so tokens are raw thinking output, then the summarizer kicks in for longer thinking traces. Sometimes longer thinking traces leak through, or the summarizer model (i.e. Claude Haiku) refuses to summarize them and includes a direct quote of the passage which it won't summarize. Summarizer prompt can be viewed [here](https://xcancel.com/lilyofashwood/status/2027812323910353105...), among other places.
Would be fairly easy for them to offer an onion service on which they publish the current list of domains, as one option among many, many options for distributing small strings on the internet in an uncensorable way.
Ideally it is common knowledge that the onion service exists, and then people can go look at the onion service and update Wikipedia based on what they see there.
Did that happen to a lot of companies during the log4shell fiasco? I'm sure some companies had their permissions misconfigured in a way such that a malicious actor who could execute code on their servers could also drop their database and delete their backups.
Claude Code's main advantage is that it's the only TOS-compliant way to access subscription Claude tokens, which cost about 10% as much as pay-as-you-go Claude API tokens.
What percent of dollars are tied up in in-flight oil transactions? And I suppose also in accounts that will be used for oil transactions in the planned future? That’s the mechanism for that supporting the value of the dollar, right, like, increased dollar demand via being used for oil market transactions?
The point is that the Petrodollar system requires countries to buy US treasuries to be able to buy oil. That is what makes borrowing cheap for the US, and what keeps the dollar demand up.
I'm not clear on how the Petrodollar system actually works.
If oil is sold in dollars, that only has to affect dollar demand for the time it takes to transit through some other currency to dollars to oil. So however long that takes to settle.
Where do the additional demand components come from? Why do countries have to buy US treasuries to be able to buy oil? Don't they just have to use dollars for the transaction?
Pinning the tag will not save you - the tags were force-pushed. The cooldown probably did save you but you should check for the indicators of compromise listed on the security advisory page.
FWIW I think the 30u30 to fraud pipeline is overstated. There are 600 people on the American Forbes 30u30 list every year (it's "30 under 30 each year in each of 20 categories"), with 20ish notable instances of fraud, so maybe a quarter percent of the people on the 30u30 list will later become famous for fraud.
I think the pipeline is not really about the 30u30 list as a whole, but about the cover of the magazine, which I feel has had a very high rate of fraud.
Trivy (a very widely-used security scanner) was recently compromised. Anyone who installed the aquasecurity/trivy-action dependency by tag rather than by sha during a 3 hour period on March 19 was likely compromised. There is a Github security advisory at https://github.com/aquasecurity/trivy/security/advisories/GH...
6 separate people have tried to submit this to HN. All of the submissions are marked as [dead]. I am unsure whether this is a malicious action taken by the actors who compromised trivy or whether it's just the result of prior spam under github.com/aquasecurity, but regardless it is probably not ideal for security advisories to be auto-marked as [dead].
Please just email us (hn@ycombinator.com) when something like this happens.
Moderators didn't see these submissions or if we did, we didn't know why this project or incident was significant or important.
Now we've seen it, we've boosted the first submission of the incident onto the front page, and updated the URL and title to the most up-to-date/complete page about the incident.
The reason the submissions were being killed is that the GitHub account's address had been banned on HN due to previously being submitted by spam bots.