HN user

amannm

57 karma
Posts0
Comments22
View on HN
No posts found.

There's a lot of people interested in forming some sort of memory layer around vendored LLM services. I don't think they realize how much impact a single error that disappears from your immediate attention can have on downstream performance. Now think of the accrual of those errors over time and your lack of ability to discern if it was service degradation or a bad prompt or a bad AGENTS.md OR now this "long term memory" or whatever. If this sort of feature will ever be viable, the service providers will offer the best solution only behind their API, optimized for their models and their infrastructure.

Anthropic's more technical users inherently understand how LLMs work.

Yes, I too imagine these "more technical users" spamming rocketship and confetti emojis absolutely _celebrating_ the most toxic code contributions imaginable to some of the most important software out there in the world. Claude is the exact kind of engineer (by default) you don't want in your company. Whatever little reinforcement learning system/simulation they used to fine-tune their model is a mockery of what real software engineering is.

It's a half-baked, rushed out, speculative attempt to capture developer mindshare and establish an ecosystem/moat early in a (perceived) market. It's a desperate "standard" muscled in by Amazon/Claude, similar to their overwrought "Smithy" IDL that basically nobody outside the Amazon SDK team chooses to use for API/Schema management. It will end up in that same niche in the long term, most likely... AWS/Amazon/Claude specific app integrations, buried underneath some other 3rd party framework that abstracts it away and makes the "spec" irrelevant.

It might make more sense when you don't simply view it as demonstration of scientific achievement. Demonstrating dominance in the field of rapidly delivering large payloads, at the press of a button, to anywhere on the surface of the earth (even the damn moon!) likely played/still plays an outsized role in game-theoretic political/military calculations aiming to deter existential threats.

we have not succeeded in replicating that milestone

it's hard to succeed at something you aren't even trying for in the first place. the moon landing was funded during the cold war where ICBM adjacent knowledge was required in the face of an existential threat. it wasn't solely for the benefit of shared global human knowledge/progress or whatever. for the US, there's a lot more to lose than gain in terms of "face" by attempting a victory lap against the rest of the world. executing any sort of manned moon or mars mission won't be taken seriously by the US until there's real political/economic pressure to do so (in the form of maybe China laying down a roadmap to land on mars or something).

device or chip manufacturers won't spend the money to develop/support/maintain in-kernel linux drivers if they don't think it will ultimately net them enough of an ROI based on sales of the corresponding device or chip. the market for non-carrier branded, end user hackable, linux based home routers is pretty small and probably shrinking as a percent of the overall market for wifi chipped devices.

I think it's fine to assume the more likely interpretation that this company simply isn't interested in the format anymore, rather than whatever larger stretch you're describing here. "You don't want to keep dead code around." That's rich :) maybe if this was some one person hobby project or something.

The current market/use-case for "Smart Grid" technologies is in replacing the various legacy control system interfaces within Plants with a single (IP-based) one for the immediate goal of reducing opex through synergies within the Plant and to the edges of that Plant operator's owned infrastructures. The next step, obviously the hardest part, is establishing and implementing IP-based standards that facilitate the realtime brokering of inputs/outputs between different, potentially competing operators. This is the same issue as the competing/proprietary residential IoT standards that have been holding back the "Smart Home". This stuff only makes economic sense for vertically-integrated players (like Duke Energy) that benefit from the opex reduction. Any sort of "value-added" capabilities are only a bonus to that opex reduction and aren't enough of an ROI by themselves.

Agreed, I'm scared of working with programmers that aren't able to see this. There's no point of capturing the "base pizza" concept. Nobody is impressed here. My eyes have to flick around so much more. Additionally, the programmer is decreasing the ease with which the codebase can adapt to market demand due to their likely overconfidence in their understanding/visibility over the market the product is being built for.