My company, against my stringent insistence, has recently greenlit developers to use certain llm "technologies" to "assist" with writing code

Since that time, I have received a number of code review requests for code that was completely nonsensical. Like, preprocessor defines guarding empty lines. A series of adjacent logging statements, each one using a different logging methodology. Code that doesn't even compile.

Like, these are things that not even the greenest intern would do, and every one of these was from a very senior developer, at the "this code is ready to be merged into the project" phase. And even a cursory reading of the code reveals the problem.

In the golden age before large language models, I would assume some kind of version control messup. However, every time I commented on the offensive code with a polite translation of "what the fuck is this shit", the response was "oh chatgpt lol"

Kids, don't do LLMs

Dear #GitHub, when I click on a link to an English language documentation page, I don't want to be automatically redirected to a machine generated German translation.

Yes, I have both enabled in my browser. Multi-lingual people are a thing. If I want a translation, I'll explicitly ask for it.

Every site whose product owner/manager insists on automatic translation should immediately fire them.

Not being federated and E2E as an advantage

https://revolt.chat/ is a chat that ultimately tries to emulate and displace Discord as an alternative.

Revolt is not E2E encrypted and not federated. That is a big plus.

Federation and E2E encryption are features that make an implementation much, much more complicated without need. Most people do not want to organize a women's shelter or abortion support or the antifash resistance. They just want to have a public guild server for their gaming guild or chat about 3D printers.

Don't federate chat

Having a federated system for that has a number of implications that make implementations more complicated and impact quality of life for users.

In a federated systems, different servers can be on different versions of the server software. This can impact features, which may or may not work properly. If will affect security of the whole network due to lack of patches in one place. And it will create propagation delays of messages inside the federated network, that is, order or even availability of messages can differ depending on what server in the federated network you are on.

As a consequence for the individual user, there is no single history order of messages – some messages may be missing, appear out of order, and there will be spam. Lots of it.

Back when Google Hangouts was still federating XMPP (Jabber) servers, specialized Jabber server implementations existed with the sole purpose of simulating user profiles, discovering Hangouts that are joinable, and spamming users with, well, garbage.

Operating a public chat room in 2025 is already a moderation nightmare. Adding federation is a surefire way to make things fail.

Federate identity, multihome clients.

This is not to say that the client should be bound to a single server.

It can, and should, in fact, connect to different servers for each community. The server, though, should be a "single visible instance, single history for all" thing, and have proper controls for the moderation team to control admission of new users to whatever their policy is.

EDIT: And, obviously, federated identity can be quite useful.

In fact, even Mastodon and other Fediverse systems should use federated identity, and also be identity servers. This will allow me to connect my client to a chat server without making any new account.

Don't E2E encrypt chat

Use TLS (or even a REST protocol over HTTPS) to connect to the chat server. But do not E2E messages.

Keep a clear text history on the server.

This makes it trivial for a single identity ("isotopp") to have multiple devices (desktop, ipad and web client) and switch between them, yet have the same chat history on all devices.

It will allow new users to join a channel and see the full channel history, if the channel is configured to do that (and because the server is not federated, the channel backlog policy can actually be enforced).

It makes it trivial to implement search and indexed archives for a server that wants that.

It makes it easier to implement detection of spammy behavior, implement rate limits, and to autodetect inappropriate or banned content.

With E2E, the server only has binary garbage that it cannot read itself, only distribute. It may not even have metadata.

It will be complicated to scan messages for spammy behavior, detect banned content.

It will be impossible to provide backlog to newly joined users. An existing identity (Isotopp) adding a new device (his phone) can only have backlog, if the other clients (the desktop of ipad client of Isotopp) of that user support client-to-client backlog transfer.

Without E2E encryption, there is no keysplit problem ("half a channel only sees undecipherable messages"), there is no "known plaintext" problem to handle, and there is no large-scale key distribution problem.

Conclusion

That is, a project that

• uses TLS, but not E2E, and
• that uses multi-homed clients but not federation,

will be able to build a better client with better UX with less effort and be a lot more agile.

Both properties (federation, E2E) do little for the end user experience except in a few limited use-cases, but come with a huge cost in implementation complexity, review and anti-abuse measures that will ultimately bind the majority of your dev capacity for nothing in return.