It seems weird to get angry about a change that is happening and will continue to happen due to what the market demands from software, which I believe will be the speed/ability to solve problems, rather than its own stewardship
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.
MCP doesn't make any sense to exist at this point in time. All you need is CLIs and existing service interfaces. We don't need a new protocol for something whose purpose is to make more protocols unnecessary
> 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.
I'm not sure about his reasoning why, but I also personally have arrived at the conclusion this new Product is kind of just another new Games/Sports/Entertainment type service rather than some sort of "serious" technology
The two terms imply "engineering" varies along only one dimension. I personally don't find these terms useful or constructive for anything apart from "talking smack" about engineering decisions outside of your control, influence, or understanding.
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).
Also on the edge of my seat here, wondering what field it could be from. My ChatGPT-esque BS story is that this symbol was misplaced alongside more abstract math-y symbols and was actually briefly used in schematics to identify "lightning conductor" components shown here https://electrical-engineering-portal.com/wp-content/uploads... ... plausible, yes?
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.
