What we need is deep thinking on the implications and make the default way forward one where we want to go. In other words, we build a channel for the flood waters, not a wall. Creating a role for "somebody to deal with AI issues" is one of those hand-wavvy upper management moves that looks defensible but simply passes the buck to someone who structurally lacks the agency to actual move the needle.

All of the use cases and integrations for AI seem to be leading toward a future exactly like this. It was interesting to see how reliant he became on his AI (couldn't use a computer, didn't know his own password) - it is barely scifi at this point, and terrifying to see how close that future is, how useful it would be, and how dangerous.

The Internet has globalized/flattened elements of culture very quickly, and AI will only accelerate that. And knowing how vulnerable humans are to suggestion/advertisement/propaganda, it seems like a perfect recipe for disaster. From an evolutionary standpoint, monoculture provides certain short-term advantages but centralizes weaknesses. If nothing else, I think we are in for a bumpy ride, whether or not we continue to boil the ocean.

LLMs do GREAT utilizing well-defined tools to accomplish tasks. Look at Datadog's MCP, instead of figuring out a multitude of filter and navigation options your LLM can immediately navigate to what you want and extract the precise data you need. Tool instructions with defined I/O structures let LLMs fly.

But for a nightly cron job pulling down stats or something like that? Why the hell do you want to route through a protocol built for in-person consumption? This is such a pointless overreach for the protocol. What would have been better is blessing a standardized pattern for exporting any MCP tool definition into a well-structured API endpoint. Then everything related to API endpoints like doc generation, comes along for free.

Instead we get this kitchen sink protocol that is going headlong toward polyfill hell, since no two IDEs support the same protocol features like structured content, local state, elicitations, etc., even from the same provider - Claude Code/Desktop/web all handle MCP connections differently. It's a shitshow.

Almost every major MCP service uses the same baseline default features (plain context) rather than build around partially-supported features. Why add more and more specs on the pile when adoption is so far behind?

Of course, you have to intuit a reasonable line length, but Claude cries if you happen to clip its wings too aggressively.

It would be less weird than you think. There is the Japanese custom of saying "Itadakimasu" before eating - not thanking the chef, but thanking the food itself.

Mr. Rogers said that that "graceful receiving is the best gift you can give someone" It is counterintuitive idea, but deeply empathetic. Training yourself to "gracefully receive," even by thanking your car for starting, sound like a habit that could lead you to a richer, calmer life.

I've taken to screenshotting the initial shipping date, but it doesn't make much difference. I don't know what "Prime" even means anymore.

And I live in SF so it's not like there is some logistics problem with my location, either.

My money is on the more efficient solution. Even if Anthropic can win some benchmarks by using 3x tokens over 3x time, it is a terrible base to build toward the future. Users are no longer willing to wait exponentially long for linear improvements. And as we see from some of the Chinese models, they can quickly distill frontier models with the tax of being slower and more token-guzzling, while retaining most of the quality. The real differentiators are becoming speed and efficiency, which translate to cost and user velocity more than incremental capability improvements.

It's great that frontier models can solve complex math equations, but bread and butter LLM usage (where the money is made) has already shifted from "I need the best always" to "what solves my day-to-day problems quickly and consistently". Fable usage as a percentage is flat-lining. We are already at the point where output quality is negligible. What wins going forward is cost, speed, consistency and the compounding effects of "softer" improvements to the harness.

Comments URL: https://news.ycombinator.com/item?id=49325551

Points: 2

# Comments: 0

Code review can go much deeper now if you use AI to aggressively attack a PR combined with your human insight. Same for planning a feature:

Can I consolidate this logic to a shared function? Does the error surface to the user and are there any gaps? What preexisting functionality is affected by this PR? Can this query be made more efficient?

LLMs are great with focused questions, up and down abstraction layers and across all kinds of concerns. Stack up these focused concerns into a rich understanding of what you are doing or writing.

Understanding is the real output, code is the byproduct.

With small kids, these sort of lazy tasks bring out focus, physical awareness and exploration. Living in the city, these are valuable respites from chaos and noise.

That's basically it. It is surprising hard to find people that can do both, but engineers are becoming much, much better at the first gate while flaming out on the second.