You need to write a clearer prompt.

Yes, you can give the Big Brain Thing a vague task and expect results, some times it'll do it right

But if you want repeatability, give it tools to determine what is a "disruption".

I have this exact system running on a WhateverClaw with a few simple tools: weather, train time tables (I commute via train) and a read-only version of my "will I be at the office or remote today" -calendar via a tool. Oh and a tool to notify me via Telegram.

It gets this information using the given tools and determines if it's worth notifying me.

TBH this doesn't need a "claw", I could just run the tools in cron, construct a prompt with that data and run any LLM on it.

You'll define exactly what good looks like.

You misspelt ">95% discount relative to API pricing" ;)

Please. I'm sure you're referring to their locking down of subscription keys, which of course they are going to have restrictions on. It's a subsidized subscription model.

You've always been able to create a platform account and use API keys with usage-based billing, and that will never go away. Charging enough to make a profit on inference isn't exactly rent-seeking or whatever language you want to use to villainize a company trying to make enough revenue to survive.

I'm not sure it's a rug pull when their stats show 7% and 2% subscription-level impacts. We're back in the ISP days, and they never said unlimited.

Its baffling to see these comments on hacknernews though. I guess you have to prove that you are not a luddite by making "ai forward" predictions and show that you "get it"

(1) https://en.wikipedia.org/wiki/Bullshit_Jobs

"Generate the following JSON formatted object array representing the interruptions in my daily traffic. If no results, emit []. Send this at 8am every morning. {some schema}. Then run jsonreporter.py"

Then just let jsonreporter.py discriminate however it likes. Keep the LLMs doing what they are good at, and keep hard code doing what it's good at.

Maybe for a non-dev it would be nice to submit a ticket and have it auto-fixed by an agent. But in the devs case, it feels like it would be faster to just do it manually.

(And on Android, AFAIK there's exactly nothing at all. There's not even common support for any kind of basic automation; only recent exception is Samsung. From third-party apps, there's always been Tasker - very powerful, but the UX almost makes you want to learn to write Android apps instead.)

Computing isn't, and has never been, demand-driven. It's all supply-driven. People choose from what's made available by vendors, and nobody bothers listening to user feedback.

They solved that with subscriptions. For end-users (and developers using AI for coding), it makes no sense to go for pay-as-you-go API use, as anything interesting will burn more than the monthly subscription worth of $$$ in API costs in few hours to days.

In fact, I re-read the article before submitting this comment just to make sure I wasn’t missing something. What on earth is so polarizing about a prompt being run recurrently? It’s a long-awaited feature that I’ve personally needed.

If you want to win your war, you’ll need better propaganda to recruit people. Start with me. My mind is open. Why should I join?

Please tie your claims concretely to this new feature. I’m interested in how adding this could erode open source software. To me they seem completely independent, and it’s a welcome change.

It's a bit like asking if "an API" was a critical link in some cybersec incident. Yes, it probably was, and?

But this is just not true, otherwise companies that can already afford such high prices would have already outpaced their competitors.

- IFTTT was great when it started; at some point, it became... weird, in a "I don't even know what's going on on my screen, is this a poster or an app" kind of way.

- Zapier is an unpenetrable mess, evidently targets marketers and other business users; discovery is hard, and even though it seems like it has everything, it - like all tools in this space - is always missing the one feature you actually need.

- Yahoo Pipes, I heard they were great, but I only learned about them after they shut down.

- Apple Shortcuts - not sure what you can do with those, but over the years of reading about them in HN comments, I think they may be the exception here, in being both targeting regular users and actually useful.

- Samsung Modes and Routines - only recently becoming remotely useful, so that's nice, even if vendor-restricted.

- Tasker - an Android tool that actually manages to offer useful automation, despite the entire platform/OS and app ecosystem trying its best to prevent it. Which is great, if your main computer is a phone. It sucks in a world of cloud/SaaS, because it creates a silly situation where e.g. I could nicely automate some things involving e-mail and calendars from Tasker + FairEmail, but... well my mailboxes and calendars lives in the cloud so some of that would conflict with use of vendor (Fastmail) webapp or any other tool.

Or, in short: we need Tasker but for web (and without some of the legacy baggage around UI and variable handling).

The sorry state of automation is not entirely, or even mostly, the fault of the automation platforms. I may have issues with some UI and business choices some of these platforms made, but really, the main issue is that integrations are business deals and the integrated sides quickly learned to provide only a limited set of features - never enough to allow users to actually automate use of some product. There's always some features missing. You can read data but not write it. You can read files and create new files but not edit or delete them. You can add new tasks but can't get a list of existing ones. Etc.

It's another reason LLMs are such a great thing to happen - they make it easy (for now) to force interoperability between parties that desperately want to prevent it. After all, worst case, I can have the LLM operate the vendor site through a browser, pretending to be a human. Not very reliable, but much better than nothing at all.

Expectations - the functionality of "do X on a timer" needs to be offered to users as a proper end-user feature[0], not treated as a sysadmin feature (Windows, Linux) or not provided at all (Android). People start seeing it on their own devices, they'll start using it, then expecting it, and the web will adjust too[1].

UI - somehow this escapes every existing solution, from `cron` through Windows timers to any web "on timer" event trigger in any platform ever. There already exists a very powerful UI paradigm for managing recurring tasks, that most normies know how to use, because they're already using it daily at work and privately: a calendar. Yes, that thing where we can set and manage recurring events, and see them at a glance, in context of everything else that's going on in our lives.

--

<rant>

I know those are hard problems, but are hard mostly because everybody wants to be the fucking one platform owning users and the universe. This self-inflicted sickness in computing is precisely why people will jump at AI solutions for this. Why I too will jump on this: because it's easier than dealing with all the systems and platforms that don't want to cooperate.

After all, at this point, the easiest solution to the problems I listed above, and several others in this space, would be to get an AI agent that I can:

1) Run on a cron every 30 minutes or so (events are too complicated);

2) Give it read (at minimum) access to my calendar and todo lists (the ones I use, but I'm willing to compromise here);

3) Give it access to other useful tools

Which I guess brings us to the actual root problem here. "Run tasks on a cron" and "run tasks on trigger" are basically just another way of saying unattended/non-interactive usage. That is what is constantly being denied end users.

This is also the key to enabling most value of AI tools, too, and people understand it very well (see the popularity of that Open Claw thing as the most recent example), but the industry also lives in denial, believing that "lethal trifecta" is a thing that can be solved.

</rant>

--

[0] - This extends to event triggers ("if X happens, then") automation, and end-user automation in all of every-day life. I mean, it's beyond ridiculous that the only things normal people are allowed to run automatically are dishwasher, and a laundry machine (and in the previous era, VCRs).

[1] - As a side effect, it would quickly debullshitify "smart home" / "internet of things" spaces a lot. The whole consumer side of the market revolves around selling people basic automation capabilities - except vendor-locked, and without the most useful parts.

Fair enough but then that means that MCP is not "a bit like asking if "an API" was a critical link in some cybersec incident"

Because I can secure an API but I can't secure the the "(LLM/human) general nature."

I think this shows the value.

> Which granted is probably real for a lot of software firms

Here's the rub though; for many many people it's a huge improvement over what they have right now.

All Chinese labs have to do to tank the US economy is to release open-weight models that can run on relatively cheap hardware before AI companies see returns.

Maybe that's why AI companies are looking to IPO so soon, gotta cash out and leave retail investors and retirement funds holding the bag.

Of course it's in the areas where it doesn't matter as much, like experiments, internal tooling, etc, but the CTOs will get greedy.

“There are 4 Rs in the word “burberrorrly.” Here they are highlighted: burberrorrly (positions 3, 6, 7, 9)”

Obviously not a real word, but perhaps the fundamental concept remains

Of course it's still valuable. A real app has plenty of mundane code despite our field's best efforts.

The number of devs will reduce but there will still be large activities that can't be farmed out without an overall strategy

You're missing the point though. "1 + 1" vs "one.add(1)" might both be "passable" and correct, but it's missing the forest for the trees, how do you know which one is "long-term the right choice, given what we know?", which is the engineering part of building software, and less about "coding" which tends to be the easy part.

How do you evaluate, score and/or benchmark something like that? Currently, I don't think we have any methodologies for this, probably because it's pretty subjective in the end. That's where the "creative" parts of software engineering becomes more important, and it's also way harder to verify.

Benchmarks ==> it's absolutely not a given that humans can't be involved in the loop of performance measurement. Why would that be the case?

I think using agents to prototype code and design will be a big thing. Have the agent write out what you want, come back with what works and what doesn't, write a new spec, toss out the old code and and have a fresh agent start again. Spec-driven development is the new hotness, but we know that the best spec is code, have the agent write the spec in code, rewrite the spec in natural language, then iterate.

Ah ok so you didn't really read my comment, what is your counter argument? Models are just fundamentally incapable of understanding business context? They are demonstrably already capable of this to a large extent.

> Every investment has a date where there should be a return on that investment. If there’s no date, it’s a donation of resources (or a waste depending on perspective).

what are you implying here? This convo now turns into the "AI is not profitable and this is a house of cards" theme? That's ok, we can ignore every other business model like say Uber running at a loss to capture what is ultimately an absolutely insane TAM. Little ol' Uber accumuluated ~33B in losses over 14 years, and you're right they tanked and collapsed like a dying star...oh wait...hmm interesting I just looked at their market cap and it's 141 Billion.

> You may be OK with continuing to try to make things work. But others aren’t and have decided to invest their finite resources somewhere else.

I truly love that. If you want to code as a hobby that is fantastic, and we can go ahead and see in 2 years how your comment ages.

"There is no sense in which they are mathematically destined to eventually program well"

- Yes there is and this belies and ignorance of the literature and how things work

- Again: RL has been around forever. Scaling laws have held empirically up to the largest scales we've tested. There are known RL scaling laws for both training and test time. It's ludicrous to state there is "no sense" in this, on the contrary, the burden of proof of this is squarely on yourself because this has already been studied and indeed is the primary reason why we're able to secure the eye-popping funding: contrary to popular HN belief, a trillion dollars of CapEx spend is based on rational evidence-based decision making.

> "How good are these types of algorithms at generalization"

There is a tremendously large literature and history of this. ULMFiT, BERT ==> NLP task generalization; https://arxiv.org/abs/2206.07682 ==> emergent capabilities, https://transformer-circuits.pub/2022/in-context-learning-an... ==> demonstrated circuits for in context learning as a mechanism for generalization, https://arxiv.org/abs/2408.10914 + https://arxiv.org/html/2409.04556v1 ==> code training produces downstream performance improvements on other tasks

> Verifiable domains are interesting. It is unquestionably why agents have come first for coding. But if you've played with claude you may have experienced it short-circuiting failing tests, cheating tests with code that does not generalize, writing meaningless tests, and at long last if you turn it away from all of these it may say something like "honest answer - this feature is really difficult and we should consider a compromise."

You say this and ignore my entire argument: you are right about all of your observations, yet

- Opus 4.6 compared to Sonnet 3.x is clearly more generalizable and less prone to these mistakes

- Verifiable domain performance SCALES, we have no reason to expect that this scaling will stop and our recursive improvement loop will die off. Verifiable domains mean that we are in alphago land, we're learning by doing and not by mimicking human data or memorizing a training set.

Unless the AI is inserted into every conversation it won't discover this, or how it changes.

Even if it had access to all this documented it wouldn't then be able to account for politics, where Barry who runs analytics is secretly trying to sabotage the project so it ends up run by his team, etc.

It does learn in context. And lack of continuous learning is temporary, that is a quirk of the current stack, expect this to change rather quickly. Also still not relevant, consider that agentic systems can be hierarchical and that they have no trouble being able to grok codebases or do internal searches effectively and this will only improve.

> It doesn't have better reasoning beyond very localized decisions.

Do you have any basis for this claim? It contradicts a large amount of direct evidence and measurement and theory.

> This is just a bunch of words stringed together, isn't it?

Maybe to yourself? Chinchilla scaling laws and RL scaling laws are measured very accurately based on next token test loss (Chinchilla). This scales very predictably. It is related to downstream performance, but that relationship is noisy but clearly monotonic

We have all the data now.

I don’t see where the huge gap should come from, as one person before they said they still make basic errors.

Models got better for a bunch of soft tuning. Language and abstractness is not really the same thing there are a lot of very good speakers that are terrible in logic and abstractness.

Thinking abstract sometimes makes it necessary to leave language and draw or som people even code in another coding language to get it.

We’ve seen it with the compiler project it’s nice looking but if you would want to make a competitive compiler you would be as far as starting fresh

> “AlphaZero excels at learning through association,” Zhou and Riis argue, “but fails when a problem requires a form of symbolic reasoning that cannot be implicitly learned from the correlation between game states and outcomes.”

Seems relevant.

I love it when people include links to papers that refute their words.

So, Antropic (which is heavily reliant on hype and making models appear more than they are) authors a paper which clearly states: "tokens later in context are easier to predict and there's less loss of tokens. For no reason at all we decided to give this a new name, in-context learning".

> agents like Claude have access to older sessions, they can grok impressive amounts of data via tool use

That is they rebuild the world from scratch for every new session, and can't build on what was learned or built in the last one.

Hence continuous repeating failure modes.

10 years ago I worked in a team implementing royalties for a streaming service. I can still give you a bunch of details, including references to multiple national laws, about that. Agents would exhaust their context window just re-"learning" it from scratch, every time. And they would miss a huge amount of important context and business implications.

> Have you read the literature on scaling laws?

You keep referencing this literature as it was Holy Bible. Meanwhile the one you keep referring to, Chinchilla, clearly shows the very hard limits of those laws.

> Do you argue things have not improved in the last year with reasoning systems?

I don't.

Frankly, I find your aggressiveness quite tiring