I have found including this in my AGENTS.md to be quite transformative in this regard:
> Always use an aggressive red/green TDD-approach. It is critical to remember that in the red phase, things like module/exports import failures due to trying to import file paths that don't yet exist, exports that don't yet exist, etc. is not valid TDD. For valid TDD, the test cases must actually run. For this, you must create stubs of the expected modules and exports in the red phase, so that the test cases actually run and fail on the test case assertions themselves. In some cases, when using this approach, once in a while some of the red phase test cases might "incidentally" pass, and this is ok. Before running red phase tests you should always make predictions about the number of test cases you expect to fail/pass -- this count is not the number of test files or test suites, but rather the number of test cases. By performing these red phase expected counts of passing/failing test cases, it will help you catch errors in your prior reasoning quickly and efficiently.
> Always use a proof-driven, scientific method-based approach to validate hypotheses, assumptions, and conclusions: define the smallest falsifiable hypothesis, create or identify a reproducible failing case, gather direct evidence, make the smallest targeted change, and then re-run the same proof to confirm the issue is fixed. Avoid speculative fixes, broad rewrites, or changing multiple variables at once. When possible, preserve the reproduction as a regression test before implementing the fix. Consider that when gathering evidence, additional logging and durable files can be very helpful.
> The strict TDD and proof-driven approaches described above could be described as "proof-driven development". Try to internalize and generalize these concepts, as they are broadly applicable.
Lots and lots of automation, along with long-running multi-instance headless tasks. My usage, which I was on the verge of increasing via a second Max plan, would cost 3 figures per day, rather than per month. I already know this because my initial tooling was prototyped against direct API usage, and that was the cost of my usage patterns.
That is not sustainable for me. I understand that Anthropic can't subsidize all of us forever, but this will force me away from claude which is unfortunate. A number of the people I work with are similarly affected.
It's a bit disheartening that this is generating so little discussion (this thread seems to be the one with the most comments, currently at 8).
99% of my max plan usage is non-interactive, and this post-June 15 pricing will far, far exceed what I can afford. I assume this applies to a great deal of us.
Last week (Sunday to Sunday) I had a repo running a lot of cron workflows 24/7. After like 4 or 5 days I exceeded the free limits (Pro plan) and so set up self hosted runners.
After like day 2 my workflows would take 10-15 minutes past their trigger time to show up and be queued. And switching to the self hosted runners didn't change that. Happens every time with every workflow, whether the workflow takes 10 seconds or 10 minutes.
Odd that you would omit the part of the text you quoted that contradicts the impression your partial quote creates.
> The images were initially believed to have been obtained via a breach of Apple's cloud services suite iCloud, or a security issue in the iCloud API which allowed them to make unlimited attempts at guessing victims' passwords. Apple claimed in a press release that access was gained via spear phishing attacks.
I also found it notable that the source for the above unlimited password guessing password guessing is an Apple press release that states no such thing.
Also interesting was that all sources in that article suggesting anything about unlimited attempts describe to an app or script (unclear which) called iDar, which the only source to actual name iDar claims that it reports success 100% of the time, regardless of its actual success in guessing the password.
I've no love for Apple. Maybe it's true. But the evidence presented in this wiki article is weak.
I have found including this in my AGENTS.md to be quite transformative in this regard:
> Always use an aggressive red/green TDD-approach. It is critical to remember that in the red phase, things like module/exports import failures due to trying to import file paths that don't yet exist, exports that don't yet exist, etc. is not valid TDD. For valid TDD, the test cases must actually run. For this, you must create stubs of the expected modules and exports in the red phase, so that the test cases actually run and fail on the test case assertions themselves. In some cases, when using this approach, once in a while some of the red phase test cases might "incidentally" pass, and this is ok. Before running red phase tests you should always make predictions about the number of test cases you expect to fail/pass -- this count is not the number of test files or test suites, but rather the number of test cases. By performing these red phase expected counts of passing/failing test cases, it will help you catch errors in your prior reasoning quickly and efficiently.
> Always use a proof-driven, scientific method-based approach to validate hypotheses, assumptions, and conclusions: define the smallest falsifiable hypothesis, create or identify a reproducible failing case, gather direct evidence, make the smallest targeted change, and then re-run the same proof to confirm the issue is fixed. Avoid speculative fixes, broad rewrites, or changing multiple variables at once. When possible, preserve the reproduction as a regression test before implementing the fix. Consider that when gathering evidence, additional logging and durable files can be very helpful.
> The strict TDD and proof-driven approaches described above could be described as "proof-driven development". Try to internalize and generalize these concepts, as they are broadly applicable.