Just cancel

I’d love to do manual labor as long as: I have a decent house, decent health insurance, can afford decent food/stuff, can afford taking sabbaticals, can afford getting sick and not losing my income, can afford decent education for kids, etc.

Unfortunately, many of us are chained to the modern way of life.

@sdevonoes What do you do for work?

ps: Unfortunately I agree with you.

I don’t think that code is that cheap either. Can we vibe code a new Notion? I doubt it. We probably can come up with a decent simulation, but I don’t think we can vibe code a Notion/Confluence/Slack that can handle millions of users in a performant way

I would prefer if it actually explodes sooner rather than later

They could also do a plan 3 where they discourage others so they can use it to, say, rapidly build many new products but competitors would have to pay a fortune for the same luxury

Just spitballing.

> They could also do a plan 3 where they discourage others so they can use it to, say, rapidly build many new products but competitors would have to pay a fortune for the same luxury

Unlikely that they all decided to do this within weeks of each other. Still, like you said, you were spit-balling, not asserting :-)

The downside of such iCloud aliases is that you cannot send emails from there (you can only reply to emails, and ofc receive emails)

True, and there has been a time or two where that has been inconvenient for me as well.

Initial account creation confirmation email, and maybe even some newsletters, were sent from noreply@ some domain. Responding to such an email address directly will likely either bounce or be silently dropped on their side, as indicated by them using noreply as the sender address.

The website might say to email support@ their domain. But because like you point out iCloud alias addresses cannot be used as sender when composing a new message, and I don’t have any past received emails from that address, I can’t email them using the same alias email address that I used to create an account.

And of course if the account belongs to jumping.carrot-1j@icloud.com and I instead send an email to them from a different sender address, then they will be sceptical about whether it really is the account owner trying to get in touch or some impostor. Assuming they don’t completely ignore the email on that grounds, you might eventually get support if you are able to either answer questions from them about past invoice amounts and dates or similar, or if they are willing to email the original account owner address from their support address. But it’s extra hassle, if they even bother to respond at all.

Fortunately most websites have a contact form or similar to get in touch with their support, but there are a few sites that have an email address as the only way to contact their support.

> Are devs really reviewing AI generated code?

Definitely. Even the current leading edge AI models (ie Claude Code Opus 4.6 (1M)) gets things (badly) wrong occasionally, makes bad decisions, and does stupid stuff.

It's a lot better than even just a few months ago, but blinding accepting its output for code that matters will catch you out.

> Nobody was reviewing protoc generated code

Are you seriously comparing LLMs with a deterministic code generator?

In general, you don’t know. Sure thing if you have a specific code base in which you already had a bunch of tests (non ai generated ) and the code you are regenerating is always touching the logic behind those tests, sure you can assess to some extent your skills/prompt changes. But in general you just don’t know. You havr a bunch of skills md files that who knows how they work if changed a little bit here a little bit there. People who claim they know are selling snake oil

Cloudflare is not the solution

What is a better solution?

You have to think hard about the problem and apply individual solutions. Cloudflare didn’t work for the author anyway. Even if they had more intrusive settings enabled it would have just added captchas, which wouldn’t likely have stopped this particular attacker (and you can do on your own easily anyway).

In this case I assume the reason the attacker used the change credit card form was because the only other way to add a credit card is when signing up, which charges your card the subscription fee (a much larger amount than $1).

So the solution is don’t show the change card option to customers who don’t already have an active (valid) card on file.

A more generic solution is site wide rate limiting for anything that allows someone to charge very small amounts to a credit card.

Or better yet don’t have any way to charge very small amounts to cards. Do a $150 hold instead of $1 when checking a new card

As far as cloudflare centralization goes though, you’re not going to solve this problem by appealing to individual developers to be smarter and do more work. It’s going to take regulation. It’s a resiliency and national security issue, we don’t want a single company to function as the internet gatekeeper. But I’ve said the same about Google for years.

None of your solutions seem useful in this case, especially a $150 hold. Site-wide rate limiting for payment processing? Too complicated, high-maintenance, and easy to mess up.

You can't block 100% of these attempts, but you can block a large class of them by checking basic info for the attempted card changes like they all have different names and zip codes. Combine that with other (useful) mitigations. Maybe getting an alert that in the past few hours or days even, 90% of card change attempts have failed for a cluster of users.

>None of your solutions seem useful in this case, especially a $150 hold.

Attackers are going after small charges. That's the reason they're going after these guys in the first place.

>Site-wide rate limiting for payment processing? Too complicated, high-maintenance, and easy to mess up.

And then you give a solution that is 10x as complicated, high maintenance, and easy to mess up.

>You can't block 100% of these attempts, but you can block a large class of them by checking basic info for the attempted card changes like they all have different names and zip codes.

This is essentially a much more complex superset of rate limiting.

A $150 hold would clearly be noticed by the victim, so the attacker wouldn't even try it.

Maybe if my bank emailed me, otherwise I doubt it. Local gas stations routinely use $200 holds and I'd have to go way out of my way to see it happen.

The point is whether every user actually notices it, it's that enough of them do that attackers are specifically looking for the ability to do small charges. If you remove that capability, they will look elsewhere.

Yeah… no it wouldn’t. I’ve watched users have their bank accounts emptied (by accident) because they kept refreshing. A measly £150 isn’t going to register until it’s too late anyway.

There's a reason attackers exploit any site that lets them do small charges, it's because enough users will notice a larger charge.

Whether every user notices it or not, attackers are looking for the ability to do small charges, and if you remove that they'll move on.

Progress is good. But why on earth should we support Anthropic/OpenAI/etc? What the planet needs is less multibillion corporations, not more

You don't have to. Just like you don't have to support Amazon for web services and file stores.

Or Oracle for databases.

Or Microsoft for operating systems.

Or DEC for computers.

There are perfectly good open source LLMs and agents out there, which are getting better by the day (especially after the recent leak!)

I want to support local models and compute over SaaS models.

I want to support RISC V over Intel.

I want other things too, and on balance, Intel+Anthropic is most compliant with my various preferences, even if they're not perfect.

Can’t we just sabotage AI? We have the means for sure (speed light communication across the globe). Like, at least for once in the history of software engineering we should get together like other professionals do. Sadly our high salaries and perks won’t make the task easy for many

- spend tons of tokens on useless stuff at work (so your boss knows it’s not worth it)

- be very picky about AI generated PRs: add tons of comments, slow down the merge, etc.

I think you should be very picky about generated PRs not as an act of sabotage but because very obviously generated ones tend to balloon complexity of the code in ways that makes it difficult for both humans and agents, and because superficial plausibility is really good at masking problems. It's a rational thing to do.

Eventually you are faced with company culture that sees review as a bottleneck stopping you from going 100x faster rather than a process of quality assurance and knowledge sharing, and I worry we'll just be mandated to stop doing them.

> be very picky about AI generated PRs: add tons of comments, slow down the merge, etc.

But that's the opposite of sabotage, you're actually helping your boss use AI effectively!

> spend tons of tokens on useless stuff at work (so your boss knows it’s not worth it)

Yes, but the "useless" stuff should be things like "carefully document how this codebase works" or "ruthlessly critique this 10k-lines AI slop pull request, and propose ways to improve it". So that you at least get something nice out of it long-term, even if it's "useless" to a clueless AI-pilled PHB.

Generate hundreds repos of plain old spaghetti code and put it on github. Easiest thing you can do.