On that general note, I think the comparison point to look at for 'state of the art' in the subject would be India's just plain excellent UPI system (https://en.wikipedia.org/wiki/Unified_Payments_Interface) and all its supporting infrastructure. It's seriously great in a way that's hard to understand for people whose only context is being familiar with Western credit card or bank transfer systems. Nigh instant payment reconciliation, free and extremely convenient for individuals, operational costs small enough that it's practical for everyday micro-transactions for the poor (I'm talking on the territory of 5¢ in USD terms) which makes cashless payments extremely practical for even ordinary street merchants.
Yeah, there's a lot of people who have either forgotten or never knew that the context React came into was a world full of JQuery and AngularJS two-way bindings. I started my internet touching career having to work on that stuff, and boy, so much of it was a nightmare that just got endless workarounds heaped on top for basic performance issues, let alone other complications.
I think step one well before getting to the hard problem of sapience would be showing he had consistent desires and consistent understanding of the world, which would be easy for Data and very hard for even the fanciest current LLMs.
It's absolutely the moral thing. Even on HN there are an endless number of people who treat the use of GLP-1s as a failure that must be publicly shamed.
For those who like Frog and Toad, I definitely have to recommend Frog and Toad are Doing Their Best, which puts a spin on the concept with a more adult, but still lovingly universal, take: https://bookshop.org/p/books/frog-and-toad-are-doing-their-b...
One reason: it's really easy to have a lightning-fast dev loop when the entire running process can hot-swap almost every piece of code, when then also extends to all extensions written against the core functionality.
Having built out MCP functionality for actual use cases for a small company, the big gotchas for us that can't be handled with "just an API" (putting aside the auth flow thing) have so far been (a) fully custom UI pieces in GUI clients (for example, media embeds with custom rendering) and (b) having the ability to put a user-facing hard stop in the loop for some interactions.
Part (a) in particular is pretty prominent for us since our uses cases are all about video, and having "just" an iframe URL to supply, with no other interaction with the model/turns, would give a pretty janky and unpleasant experience if Claude/ChatGPT even allowed it to embed.
That feels like it should be the obvious use case for something like a `?q` query param, formalized or not, but it seems like nobody working on the spec and libraries ever considered query params as a use case, since they're still broken in the Typescript library.
"Just use OpenAPI" doesn't handle the question of having a single well-defined OAuth flow that will work with desktop clients across the board, as well as various gotchas like rendering embedded widgets that will use that OAuth flow, elicitations for user decision points outside of the model control, and other such things outside of the API round trip process itself.
Be careful about this one if you want to have any level of control over basic stuff like comment style and accuracy. Claude will happily spend 20 review cycles in a row rewriting the same 10 comments for a small bugfix over and over because it can recognize "Claude-ese" in the review cycle but then just immediately and compulsively spew out more of it and drift even further from your style rules in the next "fix".
I'm seriously not joking about the 20 tries, I left it running in the background for what should have been a minor code change and it took 18 out of 20 review cycles to stop writing in more comments that all either broke my ASE-STD100ish style rules or included false statements about the code.
That "only advantage" is doing a lot to dismiss the actual use case of, say, everyone keeping appointments on their calendar when the legislature passes laws around time zone changes.
Public signage with words was basically nonexistent in the pre-modern era. Why bother? The overhead of getting literate people was reserved for the stuff that couldn't be communicated in symbols, like keeping records for the taxman or contracts to prevent future land disputes.
Most cities in the US aren't even near 'a little bit efficient', let alone 'most efficient'. You're worrying about what happens if the waddling baby at the ten-yard line on the football field runs out past the end zone and keeps going onto the highway.
There's only so hypothetical you can go before losing the point of the whole system. We could, after all, make the whole planet like Coruscant if we really wanted, but taxing for that hypothetical would do nothing useful.
The effect on taxes depends on the specific rules. But, with the easiest answer of basing it on market rate of land sales, industry in rural areas only increases taxes if that industry's paying significantly above existing market rate for some reason.
And if they are doing that, the taxes should go up, since there's some previously unrecognized value to the land that's driving industry to need to build there specifically and not somewhere else they can buy at preexisting market rate.
Of course, the same also applies in the other direction: if an active mine shuts down and sells for pennies, taxes for the surrounding land should go down based on that.
The point of Georgism is to get rid of the 'unused' part. You're just taxed on land, full stop, based on the most valuable things that could probably be done with it right now.
Land in a city center? Hefty taxes, identical for a parking lot and a skyscraper, because the parking lot could be a skyscraper instead.
Land in a low population rural area? Low taxes, because the likely uses are homes or businesses that could be built in any other rural area.
SF has laws that make it a multi-year process just to get the permits to refurbish a building, before any construction even starts. The end result is that most of the city is frozen in the 70s.
According to the influencer, the weight is 100 g. I have 25 g (+lenses) glasses I wear often, and even that is right on the upper edge of what's comfortable and needs almost-uncomfortable tight arms to stay steady when my head moves. And, that's all as somebody who's worn glasses all my waking hours since like age 10, complete with nose-indent calluses. Either those Meta glasses are clamping uncomfortably hard on the sides of your head all the time or they'll fall off the first time you lean forward.
> the current approach isn't delivering the desired engineering requirements. Maybe we need to rethink
I'm reminded of the times I've tried to let Claude fix some well-documented bug in the background, and it ends up burning 4 million tokens and 20 self-review cycles re-writing the same set of code a dozen times with ever more complex unit test mocks / overcomplicated regexes / giant comments restating the same thing the code does, when the actual fix turned out to be "change three to ten lines to do something in a slightly different way that avoids the problem entirely".
Even Next.js, for all that people are unhappy about its quirks, complexity, and random undocumented behavior and bugs (God help you if you ever want to try and actually use parallel routes as documented), can do all of this SPA stuff out of the box. Use `<Suspense>` appropriately on data loading, and everything static (including e.g. purely input-output components like editors) will load once and be re-used forever, and your Suspense-wrapped items will show a loading placeholder and only re-load when you intentionally re-trigger the data loading (which you can push down all the way to the level of individual buttons if you want).
Almost every time I've seen it in action, it felt like an Onion-grade parody, the same grade of stuff as the white people complaining about tribes in Canada building malls and housing towers and not living like historical stereotypes instead (https://www.cbc.ca/newsinteractives/features/land-back-podca...).
The one exception was a traveling theater show with Native peformers and no actual control over the theater, and even then there was some careful rhetoric involved to keep it from sounding like an accusation aimed at the audience.
It's a register that would be great for some tabletop games or pop science writing, but in this context it could really use a technical editor to aggressively remove phrasing like "keeping the fold neatly uniform" and "affordance surface", as well as change things like "hooks live in a hooks.json file, today of four extant types" into plain technical language ("there are four types of hook that can be defined in hooks.json").
The tl;dr of the tl;dr is treating the model setup like an autonomous robot with its own machine to use and just telling it what to do via chat rather than directly supervising it, which is bonkers in some ways (all the open internet/service access/permissions stuff you would imagine), and smart in others (a fully isolated machine means it can fuck up something locally or run high-load tests without taking down your important systems).