31,384 karma · joined September 24, 2008
The addons are developed by third parties that aren't Microsoft, so there's a serious risk of malware and other ways of getting the user pwned.
The added future-proofing/portability is a nice bonus, but I suspect maybe not the main motivator.
- From what I can see many products are rapidly getting past "just prompt engineering the base API". So even though a lot of these things were/are primitive, I don't think it's necessarily a good bet that they will remain so. Though agree in principle - thin API wrappers will be out-competed both by cheaper thin wrappers, or products that are more sophisticated/better than thin wrappers.
- This is, oddly enough, a scenario that is way easier to navigate than the rest of the LLM industry. We know consumer apps, we know consumer apps that do relatively basic (or at least, well understood) things. Success/failure then is way less about technical prowess and more about classical factors like distribution, marketing, integrations, etc.
A good example here is the lasting success of paid email providers. Multiple vendors (MSFT, GOOG, etc.) make huge amounts of money hosting people's email, despite it being a mature product that, at the basic level, is pretty solved, and where the core product can be replicated fairly easily.
The presence of open source/commodity commercial offerings hasn't really driven the price of the service to the floor, though the commodity offerings do provide some pricing pressure.
True, and worse, they're hungry because it's increasingly seeming like "hosting LLMs and charging by the token" is not terribly profitable.
I don't really see a path for the major players that isn't "Sherlock everything that achieves traction".
Case in point recently I was working on a mobile app where I had to check for a whole litany of user permissions and present UI to the user if any particular permission was missing, including instructions on how to rectify it.
Super annoying to do manually, but Claude Code was not only able to exhaustively enumerate all possible combos of missing permissions, but also automatically create the UIs for each edge case. I reviewed all of it for accuracy, which took some time.
I probably would've missed some of the more obscure edge cases on my own.
Overall maybe not much faster than doing it myself, but I'm pretty sure the results were substantially better.
Absolutely agreed, but I think the idea is that coding tools (or languages, or libraries, or frameworks) frees us to do the actually hard, skill-intensive bits of this, because the thing that's intellectually demanding isn't marshaling and unmarshaling JSON.
You used to have to write tons of real code to stand up something as simple as a backend endpoint. Now a lot of this stuff is literally declarative config files.
Ditto frontends. You used to have to imperative manage all kinds of weird bullshit, but over the last decade we've gradually moved to... declarative, reactive patterns that let the some underlying framework handle the busywork.
We also created... declarative config files to ensure consistent deploys every time. You know, instead of ssh'ing into production machines to install stuff.
We used to handle null pointers, too, and tore our hair out because a single missed check caused your whole process to go poof. Now... it's built into the language and it is physically impossible to pull of a null pointer dereference. Awesome!
We've been "putting ourselves out of work" for going on decades now, getting rid of more boilerplate, more repetitive and error-prone logic, etc etc. We did it with programming languages, libraries, and frameworks. All in the service of focusing on the bits we actually care about and that matter to us.
This is only the latest in a long line of things software engineers did to put themselves out of work. The method of doing it is very new, the ends are not. And like every other thing that came before it, I highly doubt this one will actually succeed in putting us out of work.
And I'll remind folks that we've been talking about the power of people owning their own servers in their homes for decades, and yet the vast vast vast vast majority of users aren't doing it.
- Battery life. One of the main reasons your phone lasts as long as it does is because it severely restricts the ability to run always-on things. A phone of course can run an email server, but the battery life will immediately tank to the point where the device becomes largely unusable for its original purpose.
- Phones make extremely poor servers because connectivity is intermittent. This is fine for software that's 100% local, but a lot of the most useful software needs to talk to the internet - or more importantly, has to allow the internet to talk to it. Imagine losing an email because you walked into the subway and your phone was unreachable the moment an SMTP server tried to connect to it.
This is harder than it looks. A “router” model often has to be quite large to maintain routing accuracy, especially if you’re trying to understand regular user requests.
Small on-device models gating more powerful models most likely just leads to mis-routes.
While the process is active the whole binary is loaded (note: may not include dynamically linked libs, which is why that's a good idea - dylibs can be configured to load on-demand).
A triply-good reason why the pattern of "giant ball of statically linked things" is an anti-pattern.
For many apps the main source of memory usage isn't stack or heap memory consumed during runtime, it's the loading of the binary itself into memory. I've seen some wild app binary sizes (200MB+ for relatively modest apps without that much functionality).
One thing that's endlessly frustrating about mobile dev is that the vast majority of devs are thoughtless about dependencies, how they are built/linked, and how that impacts memory use. Far and away the dominant mode of dependencies in mobile-land is just "statically link it and forget about it".
This is the singular biggest contributor to app size bloat, and pretty up there for runtime memory consumption as well.
A double whammy here is that modern iOS apps are actually multiple binaries (main app, watch extensions, widget extensions, etc.), and if you heavily use static linking you're carrying multiple copies of the bloat.
A few actionable things:
- Be very, very judicious about taking on new dependencies. Is a library offering enough value and marginal functionality to be worth the weight? (e.g., I don't think AFNetworking in 2025 meets the bar for the vast majority of people, but yet it's still everywhere?)
- Dynamically link, especially if you're a complex app with multiple targets.
- Deadstrip aggressively. I cannot emphasize this enough. The default compiler settings will not deadstrip unused public symbols in static libraries. Fix this.
Our industry has a bad habit of this, where we name things in such a way that make them harder to explain.
See for example one of my other pet peeves: "lambdas". Sounds fancy and difficult! Sounds like a concept you may read about in a research paper! The reality is that it's really quite simple, and we do ourselves a disservice when we name things like this.
If this is you, congratulations, this is the shortest possible line. Though, if you were Bengladeshi-born I think you may actually be in the same queue? The queues are India/China/Mexico/Phillipines/Everyone Else.
For people whose purpose is to produce reliably working systems yeah, training a model that calls out to deterministic logic to do things like math makes total sense. It will pretty much always be more reliable than training a text generation model to produce correct arithmetic.
But it feels like there's another side of the industry that's more concerned with... I dunno, metaphysical aspects of these models? Where the idea that the model is a stochastic ball that isn't conscious, isn't thinking, and does poorly at various tasks is anathema. So the effort continues to try and train and fine-tune these models until... something.
It reminds me of the great Tesla-vs-everyone-else self-driving debates that raged over the past several years. Lots of people unhappy that the best-functioning systems fused many sensor types and a mixture of heuristic and machine-learned systems in a complex architecture. These folks insisted that the "best" architecture was an end-to-end machine-learned system based entirely on visible light cameras. Because it's "most human" or some other such nonsense. As far as I can tell there was never any merit to this position beyond some abstract notion of architectural purity.
Same thing here I suppose.
+1, and IMO part of a general trend where we're just not serious about making sure this shit works. Higher scores make stonks go up, who cares if it actually leads to reliably working products.
But also more importantly it's starting to expose the fact that we haven't solved one of ML's core challenges: data collection and curation. On the training side we have obviated this somewhat (by ingesting the whole internet, for example), but on the eval side it feels like we're increasing just going "actually constructing rigorous evaluation data, especially at this scale, would be very expensive... so let's not".
I was at a local tech meetup recently where a recruiting firm was proudly showing off the LLM-based system they're using to screen candidates. They... did not evaluate the end-to-end efficacy of their system. At all. This seems like a theme within our industry - we're deploying these systems based purely on vibes without any real quantification of efficacy.
Or in this case, we're quantifying efficacy... poorly.
Adherence to context is lossy in a way reminiscent of human behavior but also different in crucial ways.
In 95% of cases, the founder isn't smashing moral barriers because the VCs and shareholders are making them, or lording the threat of legal action or any some such.
In 95% of cases, the founder is smashing through moral barriers because their interests are aligned with the VCs: because they think what they are doing will lead to stupendous mega-wealth for them personally.
Like sure, I think the idea that corporate execs must be beholden to maximizing share price is a) corrosive to our society and b) not as true as often portrayed, but I don't think that's even a real factor here.
I actually disagree with the OP in this sub-thread:
> "No, the accident is that the AI Agent wave made interoperability hype, and vendor lock-in old-fashioned."
I don't think that's happened at all. I think some interoperability will be here to say - but those are overwhelmingly the products where interoperability was already the norm. The enterprise SaaS that your company is paying for will support their MCP servers. But they also probably already support various other plugin interfaces.
And they're not doing this because of hype or new-fangledness, but because their incentives are aligned with interoperability. If their SaaS plugins into [some other thing] it increases their sales. In fact the lowering of integration effort is all upside for them.
Where this is going to run into a brick wall (and I'd argue: already has to some degree) is that closed platforms that aren't incentivized to be interoperable still won't be. I don't think we've really moved the needle on that yet. Uber Eats is not champing at the bit to build the MCP server that orders your dinner.
And there are a lot of really good reasons for this. In a previous job I worked on a popular voice assistant that integrated with numerous third-party services. There has always been vehement pushback to voice assistant integration (the ur-agent and to some degree still the holy grail) because it necessarily entails the service declaring near-total surrender about the user experience. An "Uber Eats MCP" is one that Uber has comparatively little control over the UX of, and has poor ability to constrain poor customer experiences. They are right to doubt this stuff.
I also take some minor issue with the blog: the problem with MCP as the "everything API" is that you can't really take the "AI" part out of it. MCP tools are not guaranteed to communicate in structured formats! Instead of getting an HTTP 401 you will get a natural language string like "You cannot access this content because the author hasn't shared it with you."
That's not useful without the presence of a NL-capable component in your system. It's not parseable!
Also importantly, MCP inputs and outputs are intentionally not versioned nor encouraged to be stable. Devs are encouraged to alter their input and output formats to make them more accessible to LLMs. So your MCP interface can and likely will change without notice. None of this makes for good API for systems that aren't self-adaptive to that sort of thing (i.e., LLMs).
I've done stuff very much like the above with just regular tool calls through the various LLM APIs, but there are tons of disparate frameworks for how to harness up a tool, how they execute, how they are discovered, etc. None of it is rocket science.
But the nice thing about having a standard is that it's a well-lit path, but more importantly in the corporate workflow context is that it allows tools to be composed together really easily - often without any coding at all.
An analyst who has zero coding experience can type in a prompt, click "add" on some MCP tools, and stand up a whole workflow in a minute or two.
That's pretty cool.
And yeah, none of it is impossible to implement yourself (nor even very hard!) but standardization has a value in and of itself in terms of lowering barriers to entry.
Depends on how extensive the growth is and how structurally stable the thing is in the first place. But expect major problems on the decades-timescale.
> "and in an invisible way?"
Yes. This is the main problem with allowing unconstrained plant growth near/in/under structures - the degree of structural compromise is hard to assess (especially without spending a lot of $$$), and failure can be sudden. You're not gonna get as much warning as you'd want.
In the US it's a popular look to have vines growing against brick walls. They're beautiful but often hazardous for structural safety, especially if not proactively maintained and constantly monitored (which is $$$!)
[edit] I think overall the focus on the "pleasantly ramshackle" aesthetics of the shack misses the forest for the trees. There's a lot of daylight between "permit small businesses in possibly unsafe structures" and "western status quo norms for business licensure".
I think something Japan gets done really well is making it easy and inexpensive to run businesses, especially hobby businesses. There are a ton of policies that encourage this outcome, and we can and should adopt entire rafts of them without changing existing regs about the physical structural stability of said businesses ;)
I didn't get that message at all. If anything they're saying that the complexity of PM work is entirely knowable, but the many engineers do not bother, because they do not acknowledge the existence of that complexity in the first place.
And honestly, they have a point! Our industry is rife in this attitude and it sucks.
Look at how many posts about totally disparate fields are on HN all the time where coders suddenly become experts in [virology|epidemiology|economics|etc] without so much as a passing acknowledgment that there are real experts in the field.
We even do it to ourselves - the frequent invocations of "pffft I can build that in a weekend" dismissals of other software projects, for example.
Shit is complex, that complexity is knowable to anyone willing to roll up their sleeves and put in the work, but there is definitely a toxic tendency for people in our field to be wildly dismissive of that complexity in fields that aren't ours. And yeah, that includes dismissal of complexity in our own field but not directly in the function of programming.
Pure speculation on my part but it feels like this may be a major component of the recent stories of people being driven mad by ChatGPT - they have extremely long conversations with the chatbot where the outputs start seeming more like the "spicy autocomplete" fever dream creative writing of pre-RLHF models, which feeds and reinforces the user's delusions.
Many journalists have complained that they can't seem to replicate this kind of behavior in their own attempts, but maybe they just need a sufficiently long context window?
- Depending on your product or use case, somewhere between a majority and a vast majority of your users will be using your product from a mobile device. Throughput and latency can be extremely high, but also highly variable over time. You might be able to squeeze 30Mbps and 200ms pings for one request and then face 2Mbps and 4000ms pings seconds later.
- WiFi generally sucks for most people. The fact that they have a 100Mbps/20Mbps terrestrial link doesn't mean squat if they're eking out 3Mbps with eye-watering packet loss because they're in their attic office. The vast majority of your users are using wireless links (WiFi or cell) and are not in any way hardlined to the internet.
The lack of focus I feel like comes from the fact that his audience is an amalgamation of multiple groups, much of which is the "tech is over, it's all grifters now" cadre, so a lot of this isn't really meant to be a persuasive argument of anything but rather just a dumping ground of grievances.
I alluded to finding him an unreliable narrator of this topic, and this is why. So much of this audience is so fully committed to "this is spicy autocomplete, a totally non-functional grift on par with NFTs" as a position that it compromises any of the other points he's trying to make.
FWIW I do find some things of his sympathetic - particularly around how much structural risk we're taking on every time the VCs decide to line up the hype cannon behind something. That said, I think it's also fair to say that this is my projection of his argument, because his actual arguments are often too muddied to even draw that level of specificity.
[edit] I continue to follow Ed's writing because a) I think there are glimmers or something in there and b) I treat it as a temperature read of a substantial minority of public opinion. The level of disillusionment and rising anger against our industry is concerning.
The first piece strikes me as a paean against "enshittification" - the idea that the industry has done good things, but now subsists on a combination of hot air and making existing good things worse. It further makes the specific point that LLMs belong in the "hot air" category and that it shares little with other innovations of the past.
It does touch on what he perceives as overly-friendly press coverage of the above, but I didn't read the piece as focusing on that point.
FWIW, I find Zitron to be an... unreliable commentator on this subject, to put it mildly, but I am not entirely unsympathetic to the point.
The second piece is more specifically focused on the overly-friendly press coverage, and the idea that journalists are either overly credulous, especially to fantastical claims about the tech, or openly corrupted by the parties they are meant to cover.
`isUserAGoat` ended up allowing any caller to determine if a specific app is installed on the system, which is a privacy violation and allows fingerprinting against the user's consent.
I get the desire to make the job more fun than just implementing a spec, but many of the things we work on are very important and very complex, with oodles of real-world consequences. That unfortunately means everything we do has to be well-considered and not off-the-cuff.
Anybody could run a full multi-tasking OS on a mobile device trivially. The performance sucked and you killed your battery super quickly.
The innovation was in multitasking that didn't result in a terrible user experience, and it took a lot to get there! And the answer wasn't "welp what if we just treated this thing like a desktop".
And it's still not a fully solved problem - there continues to be a lot of movement around how apps are defined so that they can be efficiently concurrent! (or at least give the appearance of concurrency)
And if you'll excuse more nerding out - a lot of work is being done still to make this even more seamless. For example, iOS now heavily encourages the use of SwiftUI to define UIs, because rendering such UIs can be done by the OS outside of the app process.
This means you can have an actual live UI while the actual app process is suspended. They literally don't have to wake the process until you tap on a button.
It used to be that your app either got a full-time 60-120Hz runloop, or you got suspended completely. Now the OS can define a much more coarse-grained idea of "alive" without losing interactivity. It's super cool stuff.
The hardware had basically ~no app ecosystem. That's not a problem that occurs over 8 weeks. The software was also incredibly under-baked, and I'm doubtful that the company pivoted from "this needs more time and should release later" to "full marketing push, press events, and big launch" in that short a time either.
I don't doubt that there was a lot of conflict over strategy with the new CEO, but the framing that all of this happened while he was on the sidelines doesn't seem very plausible.
On iOS and Android at the time, all apps were full-screen. When you switched to another app, the previous app suspended execution entirely. The OS would keep the memory footprint of the app warm in RAM if possible, but back then RAM was in short enough supply that more often than not the memory state of the process was dumped to disk instead.
There were lots of clever UX hacks to make this feel seamless - when an app was suspended it was also screenshotted, and the screenshot would be displayed to the user upon switching back, until the actual app could be restored and resume running.
But the app executable was totally suspended during this time.
Whereas on WebOS the UX was oriented around showing multiple "Cards"[1] at the same time, but each one represented a live running process that was able to interact to the user and render new UI.
This was a pretty big deal at the time.
Since then both iOS and Android gained a lot more capability and nuance around multitasking.
[1] https://www.anandtech.com/show/4508/hp-touchpad-review/2