iepathos

I see a lot of parallels with how people were worried for decades that kids who learned with calculators wouldn't be able to do math. Instead, studies show the opposite that kids who learned with calculators do better in math even when the calculators are later removed. The reason is our learning bandwidth is limited and if you're learning multiplication and division tables you aren't learning the far more important higher level concepts.

There is something similar happening with AI and most people don't understand it and we don't have enough long term studies for data to make conclusions on this yet. Engineers sounding an alarm here but they also don't have the data to support their worry. Certainly some of the lower level understanding of coding languages aren't being acquired and maintained as much as before. Whether that underlying knowledge actually needs to take up the learning bandwidth that it was taking is the real question. My hunch is that it doesn't and that dropping it makes room for higher level concepts and understanding that are actually more important given modern tooling, the same way we don't actually need to know binary and assembly to be effective engineers, but time will tell.

An LLM finds a dubious bug, an LLM turns it into a convincing report, and now the proposed solution is to have an LLM triage it? There are a lot of turtles holding up this approach and the circular logic seems hard to miss.

Automated triage can filter obvious spam, which was already fast and easy for humans to do. The hard part is independently reproducing a plausible finding and assessing its actual impact. If LLMs could already do that reliably, then the slop report problem wouldn't exist in the first place.

Nice marketing Google, now tell us how many of the bugs that were fixed were actually introduced by AI usage to begin with?

> The motion also states that Tunick asked four times to speak with a lawyer and was denied each time.

This is the kind of thing that loses cases, even if they were legitimate at first. Seems like the prosecutor is desperate charging for the phone wipe cause they didn't have any evidence of terrorism, child-pornography, etc. The problem they have now is given he was in custody and agents pressured him to provide the passcode that they then incompetently put into the phone, the fact that they denied him a lawyer multiple times means there is a very strong argument that his rights were violated. Typically, courts suppress any evidence when there is a violation like this with someone in custody. So the compelled passcode, the phone's reaction when that passcode was entered, and the agents' testimony describing the supposed wipe would be thrown out by most judges. What's left for the prosecution after this is jack and shit, but jack left town.

If I commission a part specified as 10.00 ± 0.01 mm, I can verify it with a calibrated micrometer without understanding the CNC machine, its software, or how to manufacture the part. Likewise, a function with a finite input space can be exhaustively tested against its specification without understanding its implementation. In these cases, I need to understand the requirement and the test, not the production details, which can actually be a black box.

Your examples show that verification is sometimes inadequate, not that it requires full productive competence. The conclusion doesn't generalize.

This post ignores that verifying something works doesn't require you to fully understand it. This is easily observable in products we use everyday. We don't need to understand them to be able to verify they work correctly. The cost of verification is often cheaper than the cost of production.

It present delegation as absence of power/agency. While I think there is some kernel of truth in here, the claim "it's not empowering to hand off the details" quickly falls apart when we consider real examples. If it were true, it would mean any leader who coordinates an organization isn't empowered through delegation. We know that's false. The general claim doesn't hold at all. Somewhere in there is an argument for engineers losing something in the hand off, but it isn't clearly articulated.

There is no war in Ba Sing Se

Perhaps, but it's important to keep in mind not even a majority of Codeberg users voted for this. A majority of their privileged voters did, which is a small minority of the actual users, and it wasn't unanimous amongst the voters. Over 30% of their voters did not agree with this choice. I'm not building crypto or vibecoded projects and this still makes me seriously question if I could trust Codeberg's current majority voters to not simply target other minority software categories without real justification just because they didn't personally approve of it.

Prohibiting fraud or infrastructure abuse is one thing, but declaring entire categories of lawful software harmful to Codeberg’s reputation is another. They've ironically tanked Codeberg's reputation far more from these policy changes than any projects in that category could have possibly. After these changes, it is difficult for any business, or any project seeking stable infrastructure, to trust that its codebase won’t become unacceptable after the next member vote.

Haha, ty for this. That's just a personal habit. I tend to call Discord disco for short amongst my friends.

Your two points seem logically at odds. If simply asking people not to upload prohibited material worked without enforcement, then Codeberg's existing copyright policy (and international laws) would already be sufficient. If people don't reliably follow that policy, then adding a vague AI-specific policy with the same enforcement problem changes nothing. What logical connection between AI involvement and copyright infringement does this new rule address that the existing copyright policy does not?

MUDs never disappeared. People stopped finding them engaging enough to use. Blaming Discord reverses the causality. MUDs lost engagement long before disco was created. People congregate on disco because it offers a more compelling social interface, even if it lacks the depth of a persistent game world. The opportunity I'd draw from this isn’t to convince people to return to older and less engaging interfaces. It’s to build persistent roleplaying systems around the interaction modes that have proven to be more engaging already. Potentially combine voice, speech recognition, text, tts, and synthesized characters with a proper world simulation underneath. If roleplaying communities already gather in disco, then deliver the experience where they already are. The interface was always irrelevant to what made MUDs fun anyway. Imagination and connecting with other people was always the thing.