I mean I have grabbed random non-greenfield projects and added features to them for my temporary / personal needs with Claude Code. The key thing is setting it up. The biggest thing is adopting good programming principles like breaking up godclasses. Things that help human devs consume code easier turns out it works for LLMs too.
I like Lazarus but its also stuck in time it feels like. Theres so many improvements and modernizations they could have implemented into Lazarus by now.
> One big difference is that Discord literally told people they were going to be using their data for a Theil backed experiment.
You got a source for that? Because the only communication I've seen from Discord implies no data is sent when these scans take place, its supposed to all take place locally FIRST is my understanding. The only exception is if the local scan goofs in some way.
> Key privacy protections of Discord’s age-assurance approach include:
> On-device processing: Video selfies for facial age estimation never leave a user’s device.
> Quick deletion: Identity documents submitted to our vendor partners are deleted quickly— in most cases, immediately after age confirmation.
> Straightforward age assurance: In most cases, users complete the process once and their Discord experience adapts to their verified age group. Users may be asked to use multiple methods only when more information is needed to assign an age group.
> Private status: A user’s age group status cannot be seen by other users.
> You got a source for that? Because the only communication I've seen from Discord implies no data is sent when these scans take place, its supposed to all take place locally FIRST is my understanding.
> The only exception is if the local scan goofs in some way.
Basically this, if it fails or if you wish to escalate past that, then there's a path that would hit Persona (or, would have, they've since ended their relationship with Persona. Previously, you'd open a ticket in Zendesk, which is where data was breached from before).
I don't think people are nearly as concerned about their selfie as they are for the security of their identifying documents, which Discord has already screwed up in securing once during this fiasco.
This is the part that loses me, my understanding was that this was only supposed to scan things offline, not collect any PII. Are they lying about not collecting the face scanned data?
There's two paths for verification, and the discussion on them is muddying things. There's k-id, which is the local-only age verification, and then there's a secondary process for places where k-id is indeterminate or their system flags you as possibly still being underage, and requires ID verification.
Previously, they handled this escalation path via Zendesk, which was breached revealing all of the messages with IDs.
Have we even agreed on what AGI means? I see people throw it around, and it feels like AGI is "next level AI that isn't here yet" at this point, or just a buzzword Sam Altman loves to throw around.
Find an old piece of software you care about that is broken somehow, and abandoned. Most of my friends use these types of tools to reverse engineer abandoned MMOs and remake servers for them.
> Then after a bunch of podcasts and interviews, this person gets hired by a big tech company. Would you hire someone who never read any if the code that they've developed? Well, this is what happened here.
I have a feeling that OpenAI and Anthropic both use AI to code a lot more than we think, we definitely know and hear about it at Anthropic, I havent heard it a lot at OpenAI, but it would not surprise me. I think you 100% can "vibe code" correctly. I would argue, with the hours you save coding by hand, and debugging code, etc you should 100% read the code the AI generates. It takes little effort to have the model rewrite it to be easier to read for humans. The whole "we will rewrite it later" mentality that never comes to pass is actually possible with AI, but its one prompt away.
Boris has been very open about the 100% AI code writing rate and my own experience matches. If you have a typescript or common codebase, once you set your processes up correctly (you have tests / verification, you have a CLAUDE or AGENTS.md that you always add learnings to, you add skill files as you find repeatable tasks, you have automated code review), its not hard to achieve this.
Then the human touch points become coming up with what to build, reviewing the eng plans of the AI, and increasingly light code review of the underlying code, focusing on overall architectural decisions and only occasionally intervening to clean things up (again with AI)
I didnt like how married to git hooks beads was, so I made my own thats primarily a SQLite workhorse. Been using it just the same as I have used Beads, works just as good, drastically less code. I added a concept called "gates" to stop the AI model from just closing tasks without any testing or validation (human or otherwise) because it was another pain point for me with Beads.
Works both ways, to GitHub, from GitHub. When you claim a task, its supposed to update on GitHub too (though looking at the last one I claimed, doesnt seem to be 100% foolproof yet).
Why have the issues tracked on the file system at all if it can be represented in Github issues and be accessed via tool calls? Also how are you handling sub task management, are you able to link closed checkboxes in the Github issues or?
The whole replace Discord thing is something I've been thinking about since 2019 and building my own IM platform since 2007. I hear people pitching every platform under the sun, but the one that I think has the most potential is XMPP. I've been building a modern client, nothing worth showing yet, but eventually I'll slap it on my blog and do a Show HN, for now it supports very basic XMPP primitives, adding friends, setting statuses, messaging friends, simple stuff.
Back in the late 2000s and early 2010s Google and Facebook supported XMPP, so you could login to Facebook Chat / Google Talk via Pidgin through an XMPP gateway (if if this was the default protocol or a bridge I'm not sure, its been years).
The biggest strength I see for XMPP is that because the web and even enterprise (think banking etc) uses XML too, everyone's optimized the ever living crud out of HTML so you could get some very high performance libraries to churn through all those stanzas, but also more importantly, its an extensible protocol. There's no reason it cannot have half of the things that exist on Discord, without disrupting the protocols OOTB design, because unlike IRC and other competing protocols, its extendable by design.
The best part about XMPP, or rather "protocol not service" as the OP discusses, is that you can go beyond the intended use case of it.
My favorite example - Arista network switches can be clients on an XMPP server. Control plane's have to be very slim. XMPP enables someone with a network operator to apply wide, symmetrical configurations across a network, without repetition. You can add the "core" switches to a group chat, and query them for information simultaneously.
You would never see Discord as a control plane management option, nor a Slack, Telegram or Signal option. But if all or a group supported XMPP, there would be a low resistance avenue for that (if someone really wanted it).
As it stands, we have product lock in due to each service having it's own system, with limits on interactivity. So I won't be cross-channel quoting outage causes directly from the switch in the company Slack any time soon.
> The biggest strength I see for XMPP is [...] XML
It's an advantage, sure, but to me the serialisation format is the least interesting thing. Others are similarly optimized too. I think the extensibility and approach to standards is far more interesting than the fact it uses angle brackets instead of braces.
It's a perfectly reasonable choice: flexible, well specified, well supported, reasonably performant. I think the extreme level of hype 20 years ago was overdone and (just like with anything) there's good ways to adopt it and bad ways. But as a basic technology choice, it's fine. Particularly these days when you can have a coding agent write the parser boilerplate, etc. for you.
> It's a perfectly reasonable choice: flexible, well specified, well supported, reasonably performant. I think the extreme level of hype 20 years ago was overdone and (just like with anything) there's good ways to adopt it and bad ways. But as a basic technology choice, it's fine.
Absolutely with you up to here, but...
> Particularly these days when you can have a coding agent write the parser boilerplate, etc. for you.
Absolutely not. Having seen the infinite different ways a naive implementation of XML goes wrong, arguably being one of the main causes of death for XHTML because browsers rightfully rejected bad XML, "Don't roll your own XML implementation" should be right up there with "Don't roll your own crypto".
I don't feel like it's going out on a limb to say that if someone needs to defer to a LLM to implement XML they're not qualified to determine if it's done it right and/or catch what it got enthusiastically wrong.
Oh sorry, I don't at all intend to say you should write your own parser! Totally agree: "Don't roll your own XML implementation"
What I was addressing is, interfacing with an XML parser and converting that into whatever your internal representation is, can be a chore. LLMs are great at that stuff.
IM messages aren’t really documents. They are text with some very minimal formatting that could be expressed with markdown. Any media attached isn’t embedded in the document, it’s attached externally / rendered at the bottom.
The only example I can think that messages are expressed as documents is Microsoft Teams. And it’s as much an example of what not to do as anything.
I'd disagree with that for most messaging apps. If you think about Discord or Slack for example. You have a plain text message and then media attachments externally. This could be very well expressed with JSON.
Very few messaging apps let you go beyond plain text and let you start embedding media or complex layouts inside a message.
Eh, XML is a machine-readable generic markup language. Why would you prefer using a less powerful format like markdown in a context like message representation? XML with inline tags seems the perfect fit.
Less powerful also means less complex and less exploitable. You can very easily grab a markdown renderer rather than trying to decode a .docx for messages.
Pretty much no messaging apps let you create messages more complex than markdown anyway.
I think the comparison today is more vs the Matrix protocol that is a more recent take at the same ideas, and JSON vs XML isn't the strongest argument.
XMPP was the first creep towards the bullshit of today. Unlike IRC, it makes you register, leak identifiers, centralise and transfer power over you to third parties. Exposing you to lawfare, downtime and wasted resources. Also, IRC is extendable.
reply