31,384 karma · joined September 24, 2008
This is kind of a non-answer, no? What baggage does it get rid of? What kind of performance optimization does it bring that cannot be fulfilled with an existing OS/kernel?
- Companies have generally tightened belts on discretionary spending, which means fewer people are being paid to go to conferences and events. Many workplaces offered a relatively free hand when it came to company-sponsored conference trips, but now you're not only looking at paying your own way but taking PTO to do it!
- As someone who still makes an effort with in-person meetups: space is so hard to get unless you're well-funded. There used to be a plethora of startups around here that were happy to let you use their office after hours, but the end of ZIRP and the ensuing belt-tightening has taken a lot of these places off the list.
- AI has sucked so much air out of the room. AI-related meetups around here are still pretty common, lots of VC-funded AI startups lending their space to AI-related meetups. Heck, many even have a food and drinks budget. But if you're in any space that isn't AI this kind of support is basically completely non-existent.
Also, I think a major factor that can't be discounted are incentives for speakers. For the same reason most companies have switched to recorded announcements vs. live stage announcements, speakers are incentivized towards remote/recorded events vs. in-person since the content has much wider reach. It may be less useful for the in-person participants but you're optimizing for the long tail of people viewing remotely/viewing later.
Yes. Having been in the room for some of these demos and pitches, this is absolutely where it's coming from. More accurately though, it's wealthy people (i.e., tech workers) coming up with use cases that get mega-wealthy people (i.e., tech execs) excited about it.
So you have the myopia that's already present in being a wealthy person in the SFBA (which is an even narrower myopia than being a wealthy American generally), and matmul that with the myopia of being a mega-wealthy individual living in the SFBA.
It reminds me of the classic Twitter post: https://x.com/Merman_Melville/status/1088527693757349888?lan...
I honestly see this as a major problem with our industry. Sure, this has always been true to some extent - but the level of wealth in the Bay Area has gotten so out-of-hand that on a basic level the mission of "can we produce products that the world at large needs and wants" is compromised, and increasingly severely so.
[1] https://www.politico.com/news/2025/03/21/trump-boeing-stealt...
[2] https://www.usnews.com/news/national-news/articles/2025-03-2...
The exact transcript is here:
[3] https://rollcall.com/factbase/trump/transcript/donald-trump-...
All of these are in the top-10 first results when you search for this.
The nominal regulations on automotive behavior is pretty sufficient throughout the US, the main problem is that in most parts of the country traffic law may as well be a dead letter.
New requirements come up all the time in technology. The existence of a new requirement isn't in and of itself justification for skepticism - is there a particular reason to believe that Waymo is not capable of solving for the new requirement?
The answer may be yes, but simply "ahah! It would need to do [new thing]!" is insufficient. "[new thing] is likely intractable because [reason]" would be more justification for skepticism.
> "It's my understanding that self-driving cars don't really account their acceleration and braking for roads that could sometimes be very slippery due to snow and ice."
Sure, but like above - is there a reason this is an intractable problem?
I'll throw this out there: your human-driven car already accounts for acceleration and braking on slippery roads, without the need for the human. Traction control systems and electronic stability control systems exist! They're in fact incredibly common on modern cars.
You do this as a process engineer also. You don't have to have a human operator inserting the stator into the motor housing, you could have a robot do it (it would cost a lot more) and be a lot more deterministic.
After the stator is in the housing you don't need to have a human operator close it using a hand tool. You could do it robotically in which case the odds of failure are much lower. That also costs a lot.
You choose to insert probabilistic components into the system because you've evaluated the tradeoffs around it and decided it's worth it.
Likewise you could do sentiment analysis of a restaurant review in a non-probabilistic manner - there are many options! But you choose a probabilistic ML model because it does a better job overall and you've evaluated the failure modes.
These things really aren't that different.
I agree, and I think that's the root of the years-long argument of whether programmers are "real" engineers, where "real engineering" implies a level of rigor about the existence of and adherence to specifications.
My take on this is though that this unseriousness really has little to with AI and entirely to do with the longstanding culture of software generally. In fact I'd go as far as to say that pre-LLM ML was better about this than the rest of the industry at-large.
I've had the good fortune to be working in this realm since before LLMs became the buzzword - most ML teams had well-quantified model behaviors! They knew their precision and recall! You kind of had to, because it was very hard to get models to do what you wanted, plus companies involved in this space generally cared about outcomes.
Then we got LLMs, when you can superficially produce really impressive results easily, and the dominance of vibes over results. I can't stand it either, and mostly am just waiting for most of these things to go bust so we can go back to probabilistic systems where we give a shit about quantification.
Woah hang on, I think this betrays a severe misunderstanding of what engineers do.
FWIW I was trained as a classical engineer (mechanical), but pretty much just write code these days. But I did have a past life as a not-SWE.
Most classical engineering fields deal with probabilistic system components all of the time. In fact I'd go as far as to say that inability to deal with probabilistic components is disqualifying from many engineering endeavors.
Process engineers for example have to account for human error rates. On a given production line with humans in a loop, the operators will sometimes screw up. Designing systems to detect these errors (which are highly probabilistic!), mitigate them, and reduce the occurrence rates of such errors is a huge part of the job.
Likewise even for regular mechanical engineers, there are probabilistic variances in manufacturing tolerances. Your specs are always given with confidence intervals (this metal sheet is 1mm thick +- 0.05mm) because of this. All of the designs you work on specifically account for this (hence safety margins!). The ways in which these probabilities combine and interact is a serious field of study.
Software engineering is unlike traditional engineering disciplines in that for most of its lifetime it's had the luxury of purely deterministic expectations. This is not true in nearly every other type of engineering.
If anything the advent of ML has introduced this element to software, and the ability to actually work with probabilistic outcomes is what separates those who are serious about this stuff vs. demoware hot air blowers.
I mean, this is basically how all R&D works, everywhere, minus the strawman bit about "single fiscal year", which isn't functionally true.
And this is a serious career tip: you need to get good at this. Being able to break down extremely ambitious, many-year projects into discrete chunks that prove progress and value is a fundamental skill to being able to do big things.
If a group of very smart people said "give us ${BILLIONS} and don't bother us for 15 years while we cook up the next world-shaking thing", the correct response to that is "no thanks". Not because we hate innovation, but because there's no way to tell the geniuses apart from the cranks, and there's not even a way to tell the geniuses-pursuing-dead-ends from the geniuses-pursuing-real-progress.
If you do want to have billions and 15 years to invent the next big thing, you need to be able to break the project up to milestones where each one represents convincing evidence that you're on the right track. It doesn't have to be on an annual basis, but it needs to be on some cadence.
If you have the latest betas installed you can call those APIs right now.
They also support fine-tuning on the model that ships with ~every device:
https://developer.apple.com/apple-intelligence/foundation-mo...
"Pull out credit card, sign up for some thing and pay a bit of money" is a non-trivial bit of friction! Extremely non-trivial!
Especially in a corporate context - you have to get the expense approved. It's not clear if you can put company data onto the machine. Whereas generally running local things on corporate laptops is far less controversial.
"Download this tool and run it." is still an extremely powerful pitch. Pretty much the only thing that beats it is "go to this website which you can use without any signup or payment".
I'm generally pretty hostile to companies being acquired and breaking their past customers' products. Shutting down various required cloud services, making software undownloadable, etc.
But I don't think that happened? The roadmap simply ended, but every watch that was out there kept working as-advertised for a good long while?
They were totally fine products, I enjoyed using them. I am no longer using them, but such is the nature of consumer gadgetry.
I don't recall getting rogered at any point in that process?
I heavily suspect this is down to the RLHF step. The conversations the model is trained on provide the "voice" of the model, and I suspect the sycophancy is (mostly, the base model is always there) comes in through that vector.
As for why the RLHF data is sycophantic, I suspect that a lot of it is because the data is human-rated, and humans like sycophancy (or at least, the humans that did the rating did). On the aggregate human raters ranked sycophantic responses higher than non-sycophantic responses. Given a large enough set of this data you'll cover pretty much every kind of sycophancy.
The systems are (rarely) instructed to be sycophantic, intentionally or otherwise, but like all things ML human biases are baked in by the data.
A significant part of this is the intersection of the cult with money and status - this stuff really took off once prominent SV personalities became associated with it, and got turbocharged when it started intersecting with the angel/incubator/VC scene, when there was implicit money involved.
It's unusually successful because -- for a time at least -- there was status (and maybe money) in carrying water for it.
One of the perks of just-a-text-file-with-a-bunch-of-addons is that it enables progressive disclosure - it takes no learning curve to just get in and use the tool on a basic level, but additional complexity (and power) can be introduced over time.
The problem with a purpose-built app is that there's a minimum level of new concepts to learn before the tool is even minimally useful, and that's a barrier to adoption.
A good example of this in action is something like Markdown. It's just text and will show up fine without you learning anything, but as you pick up more syntax it builds on top - and if you learn some markup syntax but not others, it doesn't prevent you from using the subset you know. There is a clear path to adding new knowledge and ability.
Sure, datacenters will get rid of the hardware - but only because it's no longer commercially profitable run them, presumably because compute demands have eclipsed their abilities.
It's kind of like buying a used GeForce 980Ti in 2025. Would anyone buy them and run them besides out of nostalgia or curiosity? Just the power draw makes them uneconomical to run.
Much more likely every single H100 that exists today becomes e-waste in a few years. If you have need for H100-level compute you'd be able to buy it in the form of new hardware for way less money and consuming way less power.
For example if you actually wanted 980Ti-level compute in a desktop today you can just buy a RTX5050, which is ~50% faster, consumes half the power, and can be had for $250 brand new. Oh, and is well-supported by modern software stacks.
The trick with any layering like this is that your end-to-end reliability is subagent_reliability * routing_agent_reliabilitty. Neither are 100% (or anywhere close to it, let's be honest), so the multiplying probabilities are still going to trash your performance.
If you get routed to the correct subagent, then subsequent performance is likely to be solid - but that's because you've taken the `routing_agent_reliability` term out of the equation.
Routing agent reliability hinges pretty heavily on the subagents themselves and how semantically or linguistically similar they are. If you have subagents that are in wildly disparate domains it may work well, but if your subagents start overlapping (or just look like they overlap) then routing accuracy is likely going straight into the dumpster. And a mis-route is catastrophic in that setup.
For very specific agents (well-established workflows that cross multiple, well-defined, non-overlapping domains) the architecture may be suitable, but in terms of the holy grail of the omni-agent (i.e., a desktop app agent suitable for general use) I suspect we'll continue running into a brick wall.
The new training rewards that suppress hallucinations and tool-skipping hopefully push us in the right direction.
I'm not sure if you ever got a good rundown, but the tl;dr is that the 3 products ("Desktop", Code, and API) all expose the same underlying models, but are given different prompts, tools, and context management techniques that make them behave fairly differently and affect how you interact with them.
- The API is the bare model itself. It has some coding ability because that's inherent to the model - you can ask it to generate code and copy and paste it for example. You normally wouldn't use this except that if you're using some Copilot-type IDE integration where the IDE is doing the work of talking to the model for you and integrating it into your developer experience. In that case you provide API key and the IDE does the heavy lifting.
- The desktop app is actually a half-decent coder. It's capable of producing specific artifacts, distinguishing between multiple "files" it's writing for you, and revisiting previously-written code. "Oh, actually rewrite this in Go." is for example a thing it can totally do. I find it useful for diagnosing issues interactively.
- "Claude Code" is a CLI-only wrapper around the model. Think of it like Anthropic's first-party IDE integration, except there's not an IDE, just the CLI. In this case the integration gives the tool broad powers to actually navigate your filesystem, read specific files, write to specific files, run shell commands like builds and tests, etc. These are all functions that an IDE integration would also give you, but this is done in a Claude-y way.
My personal take is: try Claude Code, since as long as you're halfway comfortable with a CLI it's pretty usable. If you really want a direct IDE integration you can go with the IDE+API key route, though keep in mind that you might end up paying more (Claude Code is all-you-can-eat-with-rate-limits, where API keys will... just keep going).
But not too general, because then it can get lost in the sauce and do something profoundly wrong.
IMO it's worth the effort to know these tools, because once you have a more intuitive sense for the right level of abstraction it really does help.
So not "make this very basic data structure for me based on my specs", and more like "rewrite this sequential logic into parallel batches", which might take some actual effort but also doesn't require the model to make too many decisions by itself.
It's also pretty good at tests, which tends to be very boilerplate-y, and by default that means you skip some cases, do a lot of brain-melting typing, or copy-and-paste liberally (and suffer the consequences when you missed that one search and replace). The model doesn't tire, and it's a simple enough task that the reliability is high. "Generate test cases for this object, making sure to cover edges cases A, B, and C" is a pretty good ROI in terms of your-time-spent vs. results.
I do know the answer to OP's question but that's because I pickle my brain in this stuff. It is legitimately confusing.
The analogy to different SKUs strikes me also inaccurate. This isn't the difference between shoes, shirts, and shorts - it's more as if a company sells three t-shirts but you can't really tell what's different about them.
It's Claude, Claude, and Claude. Which ones code for you? Well, actually, all of them (Code, web/desktop Claude, and the API can all do this)
Which ones do you ask about daily sundry queries? Well, two of them (web/desktop Claude, but also the API, but not Code). Well, except if your sundry query is about a programming topic, in which case Code can also do that!
Ok, if I do want to use this to write code, which one should I use? Honestly, any of them, and the company does a poor job of explaining why you would use each option.
"Which of these very similar-seeming t-shirts should I get?" "You knob. How are posts like this even being posted." is just an extremely poor way to approach other people, IMO.
For the purposes of the exercise, let's conservatively say, maybe ~2000 tools covering ~100 major verticals of use cases. Even that may be too narrow for a true general purpose assistant, but it's at least a good start. You can slice the sub-agents however you'd like.
If you can get recall, for real user utterances (not contrived eval utterances authored by your devs and MLEs), over 70% across all the verticals/use cases/tool uses, I'd be extremely impressed. Heck, my thoughts on this won't matter - if you can get the recall for such a system over the bar you'd have cracked something nobody else has and should actively try to sell it to Google for nine figures.
- If you are wearing an Apple Watch a ML model is constantly analyzing your heart rhythm and will alert you to (some types of) irregularities. It's so computationally efficient it can literally do this in the background all day long.
- When you take any picture on any iPhone a whole array of ML models immediately run to improve the image. More models are used when manually editing images.
- After you save the photo ML models run to analyze and index the photo so it's easily searchable later. That's why you can search for "golden retriever" and get actual results.
- When you speak at your device (for example, to dictate a text message) there's a ML model that transcribes that into text. Likewise, when you're hands-free and want to hear an incoming text message, an ML model converts it to audio. All on-device and available offline at that.
Or are we playing that stupid game where "AI === LLM"?
This is actually one of the hardest frontier problems. The "general purpose" assistant is one of the singular hardest technical problems with LLMs (or any kind of NLP).
I think people are easily snowed by LLMs' apparent linguistic fluency that they impute that to capability. This cannot be further from the truth.
In reality a LLM presented with a vast array of tools has extremely poor reliability, so if you want a thing that can order delivery and remember your shopping list and remind you of your flight and play music you're radically exceeding the capabilities of current models. There's a reason successful (anything that isn't demoware/vaporware) uses of agentic LLMs tend to narrow-domain use cases.
There's a reason Google hasn't done it either, and indeed nor has anyone else: neither Anthropic nor OpenAI have a general purpose assistant (defined as being able to execute an indefinite number of arbitrary tools to do things for you, as opposed to merely converse with you).
- At the high end, everyone's got a gimmick. You can't just be personable and charming, you have to be so memorable as to feel like some fictional character. Your clientele are expecting more than mere representation, but something/someone who makes their life actively more interesting.
- Part of this may have been the market (NYC), but I got the distinct feeling that a lot of this was that buyers wanted a NYC fairy tale. If you're wealthy enough, it's not enough to have an agent, your agent has to spring forth and become a side character in the adventure story of their life.
- There's a lot of spilled ink about the mega-wealthy buyers (Middle Eastern oil barons, Russian oligarchs, Chinese billionaires, etc.) but they are a vanishingly small portion of the population of very wealthy people. In general I think most people have a poor appreciation of how little of the ultra-high-end consists of foreigners and high-profile business people that they've heard of.
- Related, there are way more wealthy Americans than most people appreciate, and the sources of their wealth are way more mundane than most people suspect. There are more 8-figure luxury condos being sold to families that own car dealerships and trucking companies than tech wunderkinds or petro-oligarchs. By multiple orders of magnitude.
Except this isn't the main market for Ferrari, McLaren, Lambo, et al. There are maybe a few dozen people on this planet who fit into that kind of stratospheric wealth.
The bulk of their sales are to the "merely multi-millionaire" rich - your business executive, late-career law partner, guy who owns a chain of dental practices, etc. These are people who are not exactly scrimping and saving for their Ferrari, but certainly don't have the infinite money cheat code.
If you think Ferrari's sales ledger is consisted mainly of oil barons and other billionaires, I dunno what to tell you.
Respectfully disagreed. The sales people for veblen goods work extremely hard because competition is intense even within that space. The Bugatti salesman is competing with Ferrari, McLaren, Lamborghini, etc.
The margins per-sale are great, but because of your low volumes you experience a lot more volatility. Minor fluctuations in sales have disproportionate impact on your bottom line.
I once worked for a luxury real estate brokerage and had opportunity to talk to real estate brokers who dealt in ultra-high-end real estate (the kind of properties that people make YouTube videos about). One conversation stood out to me that's relevant here:
I asked him about a listing for a Manhattan penthouse that had been making the news (mid-8-figure buy-in), and his response was that it was an incredibly risky property to represent, because the list of potential buyers is perhaps a dozen people long. If none of them move on the deal then you're holding an absolutely immense albatross.
Ultra-high-end goods are generally susceptible to this. Your market is small enough that it doesn't take a lot to existentially threaten you, and there is no shortage of people who want to eat your lunch (just like with any other market).