I think Forgejo is great. But we need to remember the fact that many enterprises pick GitHub or GitLab because they provide paid support and SLA. Also Forgejo Actions are still in beta, while GitLab and GitHub are pretty established solutions for CI/CD

Sourcehut is basically a really barebones web interface for git server, so I don't think it's really comparable to GitHub

For hosting your own projects that's sometimes not a viable solution either. Limiting your open source project to platform other than GitHub hurts it's discoverability, because usually GitHub is what most devs and non devs associate with open source. I heard a lot of "It's not open source if it's not on GitHub". You can mirror your project to GH of course

"Just migrate to X because it's faster" doesn't work that well in the real world

I'm surprised this article is not taken down. OSM wiki states that what3words the company have a good history of taking down code (and maybe articles) like this one, because algorithm (any algorithm that converts any number of words to coordinates) is patented to them in multiple countries

https://wiki.openstreetmap.org/wiki/What3words

The author, if I remember correctly from twitter, was a thorn in the side of the people who developed this system for quite some time. Given his profession I expect he made sure he was on the right side of the law before publishing this.

I think that the example in the article is not a good usecase for this technology. It would be better, cheaper and less error prone to have prebuilt forms that LLM can call like tools, at least for things like changing shipping address

Shipping forms usually need verification of addresses, sometimes they even include a map

Especially if on the other end data that would be inputted in this form, would be stored in the traditional DB

Much better usecase would be use it in something, that is dynamic by nature. For example, advanced prompt generator for image generation models (sliders for size of objects in a scene; dropdown menus with variants of backgrounds or style, instead of usual lists)

You make a good point! There are many common input configurations that will come up again and again, as forms and other types on input (like maps as you mentioned). How can we solve for that?

Maybe a solution would look like the server expression a more general intent -- "shipping address", and leaving it to the client to determine the best UI component for capturing that information. Then the server will need to do its own validation of the user's input, perhaps asking for confirmation that it understood correctly.