It’s weirder than that. There is a surge of companies working on how to provide automated access to things like payments, email, signup flows, etc to *Claw.
> There is no equivalent of the network effects seen at everything from Windows to Google Search to iOS to Instagram, where market share was self-reinforcing and no amount of money and effort was enough for someone else to to break in or catch up.
The main direct network effect is that Google uses heuristic data from users to improve their search rankings. (e.g. which links they click, whether someone returns quickly to Google after clicking on a link, etc)
Other factors that favor Google at scale:
- Sites often allow only the biggest search engine crawlers and block every other bot to prevent scraping. This has been going on for more than a decade and is especially true now with AI crawlers going around.
- Google search earns more per search than competitors due to their more mature ad network that they can hire lots of engineers to work on to improve ad revenues. They can also simply serve more relevant ads since their ad network is bigger.
- Google can simply share costs (e.g. index maintenance) among many more users.
The argument is more like “humans always invent new things to want that are scarce”, and until AI literally replaces all human labour to the point of the marginal utility of a human being zero, this category will continue to exist.
Which is a fair and nuanced argument! It is also not the same as, "but historical data shows X," which is regurgitated so often without any context as to be appallingly ignorant.
We gotta take these bad actors at their word that they're creating AI meant to (eventually) wholesale replace human labor, and act accordingly. That doesn't mean burning down data centers or trying to shove AI back into Pandora's Box, so much as it means not letting them dictate societal trends or reforms necessary to ensure stability and survival through such an incredibly disruptive transformation, provided they're right.
Arguing against proactive reform with regards to AI is the same sort of ignorance I've heard about climate change for my entire life, and folks shouldn't stand for it. We have infinitely more to lose by doing nothing with a "wait and see" approach than if we proactively legislate around its definitive harms.
it’s generally a poor marketing strategy to ignore explicit requests for list removal, because users manually flag the emails as spam which is catastrophic to your domain rep and will tank deliverability. the incentives are heavily in favour of removing people who unsubscribe
The List-Unsubscribe header was pioneered by Dave Rolsky, one of the more notorious spammers of the early 2000's. His reasoning was that most people were just going to hit delete, but anyone who went out of their way to unsubscribe was a squeaky wheel that would cause more problems for him if they got angry about their request being ignored. So he really did honor unsubscribe requests ... at least until adding them to the next spam campaign on a different list.
> Especially curious about your current workflows when you receive an alert from any of these channels like Sentry (error tracking), Datadog (APM), or user feedback.
I have a github action that runs hourly. It pulls new issues from sentry, grabs as much json as it can from the API, and pipes it into claude. Claude is instructed to either make a PR, an issue, or add more logging data if it’s insufficient to diagnose.
I would say 30% of the PRs i can merge, the remainder the LLM has applied a bandaid fix without digging deep enough into the root cause.
Also the volume of sentry alerts is high, and the issues being fixed are often unimportant, so it tends to create a lot of “busy work”.
To avoid this 'busy work', we group alerts by RCA (so no duplicate PRs) and filter by severity (so no PRs for false positives or not-that-important issue). We realized early on that turning every alert into a PR just moves the problem from Sentry to GitHub, which defeats the purpose.
Is having a one-hour cron job enough to ensure the product’s health? do you receive alerts by email/slack/other for specific one or when a PR is created?
interesting. yeah the only reason it’s on cron is because the sentry-github integration didnt work for this (can’t remember why), and i didnt want to maintain another webhook.
the timing is not a huge issue though because the type of bugs being caught at this stage are rarely so critical they need to fixed in less time than that - and the bandwidth is limited by someone reviewing the PR anyway.
the other issue is crazy token wastage, which gets expensive. my gut instinct re triaging is that i want to do it myself in the prompt - but if it prevents noise before reaching claude it may be useful for some folks just for the token savings.
no, I don’t receive alerts because i’m looking at the PR/issues list all day anyway, it would just be noise.
totally get the 'token wastage' point—sending noise to an LLM is literally burning money.
but an other maybe bigger cost might be your time reviewing those 'bandaid fixes.' if you're merging only 30%, that means you're spending 70% of your review bandwidth on PRs that shouldn't exist right?
we deduplicate before the claude analysis with the alert context and after based on the rca so we ensure we have no noise in the PRs you have to review
why don't you trust an agent to triage alerts+issues?
Yeah. what I find in practice is that since the majority of these PRs require manual intervention (even if minor, like a single follow up prompt), it's not significantly better than just hammering them all out in one session myself a few times per week, and giving it my full attention for that period of time.
The exception is when a fix is a) trivial or b) affecting a real user and therefore needs to be fixed quickly, in which case the current workflow is useful. But yeah, the real step-change was having Claude hitting the Sentry APIs directly and getting the info it needs, whether async or not.
I'd also imagine that people's experiences with this vary a lot depending on the size and stage of the company - our focus is developing new features quickly rather than maintaining a 100% available critical production service, for example.
Interesting. it makes sense that it depends on the number of alerts you receive. but I’d think that if 70% of the PRs you receive are noise, an AI triager could be useful—if you give it the context it needs based on your best practices.
I’m very curious about the kinds of manual intervention you do on PRs when one is required. What does the follow-up prompt look like? Is it because the fix was bad, because the RCA itself was wrong, or because of something else?
The most common case would be defensive sentry logging that tracks unexpected LLM API call responses/parsing bugs, which are handled gracefully in the app (so not critical), but that i still want to know about to improve the prompts, response structures, cleaning code, etc.
Claude will typically resolve these in a surface level way when in practice they often require deeper changes (to prompts, routing to different model, more general cleaning code, etc) and it’s hard/impossible to have Claude do these without some input.
Other noise arises from Claude thinking related issues are unrelated and so solving them separately, and also just intermittent infrastructure type issues that are clearly transient being “solved” with some weird code change.
My primary plan is the $200 Claude max. They only operate during my working hours and there is significant downtime as they deliver results and await my review.
Probably pretty big difference in system prompt from using the apps vs hitting the api, not that that’s necessarily what’s happening here. + I think openclaw supports other models / its open source and it would be pretty easy to fork and add a new model provider.
Why wouldn't the system prompt be controlled on the server side of the API? I agree with https://news.ycombinator.com/item?id=47010577 ; I think results like this more likely come from "roleplaying" (lightweight jailbreaking).
The websites and apps probably have a system prompt that tells them to be more cautious with stuff like this, so that AIs look more credible to the general public. APIs might not.
Yea pretty confused by this statement. Though also I'm pretty sure if you construct the right fake scenario[0] you can get the regular Claude/ChatGPT interfaces to write something like this.
[0] (fiction writing, fighting for a moral cause, counter examples, etc)
I am genuinely curious - what do you see as the difference between "agent-friendly payments" and simply removing KYC/fraud checks?
Like basically what an agent needs is access to PayPal or Stripe without all the pesky anti-bot and KYC stuff. But this is there explicitly because the company has decided it's in their interests to not allow bots.
The agentic email services are similar. Isn't it just GSuite, or SES, or ... but without the anti-spam checks? Which is fine, but presumably the reason every provider converges on aggressive KYC and anti-bot measures is because there are very strong commercial and compliance incentives to do this.
If "X for agents" becomes a real industry, then the existing "X for humans" can just rip out the KYC, unlock their APIs, and suddenly the "X for agents" have no advantage.
> By collecting usage information into a single place, engineering and IT leaders can get a complete picture into both user and agent token efficiency across the organization and providers.
reply