FWIW, Claude Channels[1][2] are probably going to be the solution for that, eventually. While I'm not sure how the WebHook receiver example will work with, say, GitHub and a local Claude, the Chat side of things _would_. So you'd have GH send its web hook to Telegram (for example), and then the Telegram Channel MCP would inject that into Claude, and Claude would start working on the problem. Still experimental, but functional enough to play with.
This sounds... horrible? I mean, it's certainly a solution to the "wake up when this thing happens" problem, but... $SERVICE -> webhook -> $CHAT_APP -> MCP -> remote wakeup sounds both brittle and - as you said - the local code harness route is entirely unserved by something like this.
Am I having a yells-at-cloud moment where a bunch of folks are using cloud hosted LLM harnesses/environments (let's ignore the models, "of course" those are remote) and I just never saw the point?
> Ouch! Much of this verbiage was dictated by me personally; I just have a fairly distinct register some might consider inscrutable.
I do notice that the more Claude-generated stuff I read, the more it creeps into my daily usage, and I suspect I don't read nearly as much of it as an Anthropic Employee would, so I could believe that. Though "much of" isn't the same as "written with zero AI generation/rephrasing/etc."
Anyway, that aside, something I would like to see is an example of something that's possible with this system that isn't, or isn't easily, possible with existing Claude hooks. Right now it reads like "Here's a cool thing! Here's how it works! And here's this other similar system we have! Here's how that works!" But there's no summary of the differences, why I'd use this over regular hooks, and so on. Or at least not that I saw on quick skim, and I'd be looking for that to be mentioned as early as possible, so I know if the rest is worth reading.
The future for whom? The general public? Not a chance, no way, not unless it's able to run on a phone (anywhere from 20-40% of internet users, world-wide, are phone-only).
For companies? I think that's a lot more plausible, as that's mostly just a question of money - is it cheaper to run and administrate our own models, or outsource that?
For technically inclined users? I think that's unlikely unless they're able to operate on relatively cheap hardware while still being just as good as the hosted models. And by that I don't mean "a mac studio," that's far more money than I think is reasonable. A single RTX 5080, maybe, once memory prices start to drop.
Compare the games your average high-end smartphone can run to the AAA titles of the 2010's. It's not a matter of "unless it is able to" but "when it is able to".
That's going from 150w 720p gaming to ~15w 720p gaming in ~10 years. Let's say an inference cluster draws 1500w to deliver a small-ish 500b model at reasonable speeds/quantization.
Extrapolating from your gaming example, it will take smartphones only... *checks clipboard* ...100 years to achieve datacenter-level performance at the pace of 2010's improvements.
We don't need datacenter-level performance in a handheld device just like we didn't need a storage room in our backyard for a mid-sized, tape-based NAS because technology did its thing and gave us something smarter, smaller and faster.
Your argument is true if the number of parameters in an LLM is the only measurement for quality - a bit like number of bolts per aircraft or lines of code in software. I'd bet you that an 8b parameter LLM will in 5 years outperform the datacenter-level LLMs of today.
If you go far enough back in time (this dates back to at least 2011), it's arguing against things like:
For port binding, for example, it used to be that you'd deploy your app to the web application container, rather than bundling them together. e.g., deploying your WAR file to Tomcat, rather than building a self-executing JAR which included Tomcat. The wording is a bit odd, but I think they were trying to make the point very generic, and not specifically about the Enterprise Java world.
For the backing resources, it's a combination of point 3, config often living inside the codebase, applications just shelling out to /usr/sbin/sendmail or what have you, and applications living on the same host as the DB, such that bringing up a new application necessarily required bringing up a new DB as well. Which also made it hard it to scale horizontally.
The whole "12 Factor" thing was partly because Heroku had specific solutions for all of these, so going down this road made it much easier to then sell Heroku, and partly because they really were frustrating. I'd say that the port binding one is more targeted at, say, WebSphere, and all that came along with it, such as sharing a single heap across multiple apps, needing to talk to the WebSphere admins to change configuration, needing to use a "lite" version of WebSphere to test locally, if that was even possible, and so on.
They sound super-obvious these days, but at the time, for a lot of us, they were really nice to see.
Overwatch has similar issues - common advice for playing Competitive is to just completely disable text chat and voice chat. Yeah, you'll miss genuine, helpful suggestions, but they're a tiny, tiny minority of messages at the lower ranks. Not that it necessarily improves a lot at the higher ranks, as I understand it, but is less awful.
I don't play a lot of competitive Overwatch, but it's definitely a much nicer experience with chat turned off, even if I'm not the one being flamed, even if we lose because people are typing instead of shooting.
The biggest issue is, of course, (4) - how do you plan on enforcing that for sites that don't run out of your country of residence? Implicitly restrict access to only those sites in said country?
You don't enforce that, the owner (or the owner's parents, etc) of the device set that policy. MDMs can all already do this, there just needs to be a more user-friendly/consumer focused MDM to allow parents to control their kids devices. Just have it warn "Out of country sites may not follow your device policy, do you want to block them (Y/n)?"
Same way the US enforces any internet foreign policy. Make the credit card companies cut them off,make advertisers cut them off. US controls most of the ways they could make money.
Even then - I have a reasonably nice Brother Printer/Scanner/etc device, and I could never get AirPrint to reliably work until I switched over to using Ethernet instead of Wi-Fi. Something to do with it going to sleep and not broadcasting the necessary mDNS stuff, IIRC. I couldn't find any combination of settings in the printer to make it happy, and since it's now right next to a switch, it's not really worth the effort of digging any further.
The Java one can actually be quite helpful, for a couple of reasons:
1. It tells you which variable is null. While I think modern Java will include that detail in the exception, that's fairly new. So if you had `a.foo(b.getBar(), c.getBaz())`, was a, b, or c null? Who knows!
2. Putting it in the constructor meant you'd get a stack trace telling you where the null value came from, while waiting until it was used made it a lot harder to track down the source.
Not applicable to all situations, but it could be genuinely helpful, and has been to me.
In actual Java-Java (as opposed to Kotlin or something), first line of defense should be a linter that tries to prove nullability properties. In situations where that doesn't work, well, I think I'm the world's only fan of Java's assert keyword. If you can't use assert the language feature, you can at least throw AssertionError, which is a non-Exception Throwable subclass that's more likely to make your program die instantly, as it should, instead of treating the contract violation as a recoverable condition.
When spoken? Almost certainly. But I think they mostly write in Hochdeutsch, especially in formal contexts, at least that I've seen (private chats/etc are a totally different matter), so I don't foresee any major issues there.
Austrian standard german is slightly different from the German variant, even when written. The differences are pretty minor, though, so it’s very possible to have a relatively long text without being able to tell which one it actually is (especially when potatoes are not referenced in it).
Which could be summarised by a single line: "In other words, the primary cost of change increasingly becomes feedback delay, not development effort."
reply