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.
I tried to build it (kind of). My team is going to use it to alert us to the most critical issues so we can hop on them before waiting for triage. It's decent at figuring out criticality but it's TERRIBLE at actually doing triage and assessing whether the report is plausibly or implausibly true. Security can be really nuanced, and from my experience so far with the model I'm using it's really bad at being skeptical enough to actually figure out if something is a legit issue with impact or not. I agree though, it would be awesome if we could get AI triage that worked.
For additional context, for first I've ever seen their rfs specifically asked for startups focused on military applications and warfare "The Future of American Defense" https://www.ycombinator.com/rfs
Disappointing to see this is the future they are trying to invest in.
> 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.
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.
>We don't need to understand them to be able to verify they work correctly
I don't think that's the case and it's becoming more obvious every day. From people who cannot distinguish truth or fiction on online platforms, good code from bad, to insecure software that causes supply chain attacks, to investment vehicles or fake medicine peddled that does not work, the idiotic MBA manager who does not understand the workers they manage and so on. That is why we're living on BS metrics and crappy reviews, because to the people who manage organizations their own workplace is a Blackbox. The critique that "AI" systems are semantically blind token processors is correct, it's just not bothering anyone because it already applied to most modern companies.
When people become passive consumers rather than broadly competent users how something works cannot be evaluated so by definition all they have to go off is appearance, which is why we live in the age of influencers and marketing, because that is now the only factor that actually matters.
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.
> If I commission a part specified as 10.00 ± 0.01 mm, I can verify it with a calibrated micrometer
But there is someone that needs to design that part, specify the material needed and a few other things. The actual verification is fast because someone has compiled the list of checks. And compiling that list of checks is hard work. In other words, where '10.00 ± 0.01 mm' comes from is very important.
That's why people says typing code is not the issue. Code is merely the medium of '10.00 ± 0.01 mm' definition. The actual product is the software process. And that is already a black box as only a few developers goes on to learn computer architecture and instruction sets. Instead we deal with high level instructions like map, filter, and print. Which are the tools to say '10.00 ± 0.01 mm' instead of "this length" while demonstrating with fingers. And yes for programmers, most specs are as imprecise as the latter form.
No, the code isn't what defines it. It's the tests and specs around it.
Code should never be the only source of truth.
Another shitty analogy: baking.
Saying "code is the medium of the definition" is like saying "the cake is the medium of the recipe". So anyone wanting to make the cake or change how it's made should just dive into the cake and start analysing it.
That's why we have recipes, and even they can be modified as long as the exepectation is met: It has to be sweet, soft, covered in something white and must have strawberries inside.
Code should be the same, I should be able to toss the whole codebase in the trash and regenerate it from the tests and written specifications. If I can't there's something wrong with the process.
> That's why we have recipes, and even they can be modified as long as the exepectation is met: It has to be sweet, soft, covered in something white and must have strawberries inside
How sweet? How thick should be the covering? What’s the ratio in strawberry? Even for someone taste, which is subjective, expectations may be precisely defined.
Code is the most precise form of specs. It is not what the computer runs. The computer has no concepts of functions, objects, value types, files, buttons,… We have tools that takes code and transform into what the computer can understand.
What you say is specs is merely some doodling which always need to be properly transform into good engineering drawings. Or someone’s humming that needs to be written properly in a music sheet.
the real world doesn't consist of people sitting at home measuring square metal blocks. Judgement of just about anything sufficiently complex requires discernment, a critical eye, intuition and even taste.
A codebase and its long term health is never judged by someone going down lines of code with a ruler, but with experience that only comes from intimacy with software development. If you don't have that kind of living immediate judgement (in German we have the word Fingerspitzengefühl, lit. tip-of-the-finger-felling) you end up with people measuring your progress in commit frequency or token consumption because they in some autistic sense have nothing else left but to measure and quantify random things. We end up with so many idiotic products because the kind of people who had intuition and would immediately throw the thing out were fired, and now you have people who mistake random noise and metrics for the real thing.
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.
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.
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.
Is your autocomplete passing you disco instead of Discord and you're just going with it? Or are you implying that before the creation of disco music people had grown tired of MUDs?
I specifically outlined non-MUD role playing environments because I know MUDs lost popularity long before Discord. I am outlining that any form of tech, besides Discord, is sidelines -- MUDs and a hopeful resurgence as well.
This seems like a wild basis for a hosting policy. It doesn't ban code shown to be infringing, malicious, insecure, or unmaintained. It bans code based on how Codeberg believes it was produced or some individuals at Codeberg believe it was produced.
How would they establish that a project "mostly" consists of AI-written code? Lines, commits, tokens, or architectural importance? There is no reliable detector, and metadata only catches people who honestly disclose their tool use. In practice, this only creates an incentive to conceal AI usage.
Authorship is also a poor proxy for quality. Human-written codebases routinely contain copied patterns, unnecessary abstractions, stale comments, superficial tests, security vulnerabilities, and large subsystems nobody seems to understand. Many mature projects exhibit the exact same problems attributed to LLM-generated code with the technical debt they've built up over time. Slop isn't new or unique to generated code. It is extremely common, especially in beginner, hobby, and abandoned projects which have historically served as a critical part of the open source software community.
The copyright justification is particularly weak. Lack of copyright protection does not make code non-free. Public domain source is still free software. A particular output might reproduce protected third-party code, but that requires evidence about that output. It isn't established merely by showing that an LLM was involved. If provenance were the true concern, then allowing some undefined minority of AI-generated code doesn't solve it. A single copied component can create a real licensing problem. So, the argument immediately falls apart when they qualify it with "mostly".
I don't use Codeberg, so I have no personal stake in this, but I'm surprised its community adopted such a vague and practically unenforceable policy. The argument that Codeberg has limited resources and cannot host endless disposable projects sounds legitimate until you consider how this policy could be enforced. Either someone must investigate repositories and infer their production history from circumstantial evidence, which is expensive and unreliable, or enforcement will be selective and complaint-driven.
If resource consumption, abandonment, or low-effort projects are the actual problems, Codeberg should regulate those observable problems directly though I'd argue targeting "low-effort" projects is as problematic as this policy suffering from many of the same issues. As written, the policy seems more likely to punish honest disclosure than to actually prevent harmful or infringing code.
Maybe this is a fundamental difference in how our societies work, between Germany and the USA. Here, when we go swimming, we leave our phone, keys, and wallets at the beach and just go swimming. It's a trust system, my neighbor won't take my shit because I won't take his shit. So maybe the idea behind the system is to simply ask people who want to upload their slop to not upload their slop, and that that has enough of an impact to be worth doing already.
As for copyright, LLMs can reproduce nearly 1:1 fully copyrighted, non-foss code. I would love to see someone argue in a German court that they can copy a book, a piece of code, or a movie, by laundering it through a program that produces an average of lots of copies of the same movie or book, and burns a lot of power doing it, and that this makes the product of it entirely public domain.
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?
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.