iepathos

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.

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.

Do the people who sign sworn affidavits already have to have proven identities? If so, then they're unable to recover from a situation where they lost everyone's identity.

The article, the teacher, and the general academic community skips the hard question when it comes to AI and that's whether these exams are testing knowledge that is still worth internalizing in the same way?

Academia has a long history of lagging behind acceptance of new cognitive tools where they claim to want to defend the students, but instead defend the assignments of the past at the expense of the students. Calculators were treated as threats to learning, even though they ultimately freed students to focus on higher-level math and provably improved their abilities across many different studies. Internet sources were dismissed as less legitimate than books, as if “published in an outdated book from the 70s” magically made it more trustworthy than the most scrutinized reference sources online.

It is not clear from the article exactly how much of this course falls into that category, but if the answers can be produced trivially with a prompt and chatgpt, then maybe memorizing that material is no longer the right educational target. Academia desperately needs to redesign itself around AI as a cognitive tool students should be trained to leverage. If a question is trivially answered by a prompt with it, then you need harder questions that actually require students to push beyond that. Simply removing AI from the equation, calling it cheating, and pretending that it isn't an ever-present asset people are expected to leverage in real life is naive and just repeats the mistakes of the past.

Sure, the tweet was about their releases since 2016 when I assume this particular dev was involved, not the original release. To be clear, I'm not saying their games aren't good or even that they didn't have some success. 20 million in sales for their entire franchise isn't bad, it isn't the 500 million in sales we see from CoD or Battlefield, but it isn't bad. I actually liked the games, but claiming they are the "BEST GAMES EVER!" and having the gall to mention Google where no Google results ever show them as the best is where I have an issue. We don't need to spread misinformation like that and if the dev actually believes this I can only assume they live in a bubble.

Wow, that tweet claiming the Doom series is the best first person action game in the entire industry is crazy. That dev has to be completely disconnected from the rest of the game industry or delusional. No stats support that claim at all. Not player count, not sales, not reviews, nothing. The first Doom was certainly industry defining, but it and its sequels have never been considered the best by anyone except apparently this dev. If they were the best, they probably wouldn't be getting laid off right now.

It's not all that surprising that people were worried and believed this. The AI companies and infrastructure companies partnering with them have spent a lot of money and time trying to convince people this is the case year after year. The critical clue people miss is that everyone claiming that has very clear financial incentives to convince people that's the case even when they know it isn't. Anyone who was actually building with LLMs and judging for themselves based on its performance knew fully well that wasn't the case year after year.

"LLMs are as good as almost any security researcher"

Oh really? If LLMs were as good as almost any security researcher then you wouldn't be getting flooded by bullshit reports from them. You'd be receiving legitimate reports instead.

Ahh good to know, thanks for clarifying.

That's right, Airbus is responsible for the faulty equipment onboard, not pilot training. Air France is responsible for its pilots' operational training and recurrent training.

Gun rights are generally not gone forever. Federal law bars people adjudicated mentally defective or formally committed to a mental institution, neither of which include a temporary mental hold for suicide watch. State laws vary, but none of them have a law where a single temporary hold means "gun rights gone forever." Some states let people go buy a gun the day they are released from suicide watch, despite how irresponsible that sounds.

You can see in their stats view they have a lot of providers/nodes connected but practically no actual demand/consumers. They just launched and I'm sure get providers was top of their agenda, but it's essentially unusable as a provider unless they perform some serious lift to get actual paying customers.

Not quite the same. Here it wasn't just the overreaction from some weak authority figure. The arresting cop had to knowingly violate established laws. The officers who pursued the charge had to have done the same. That's systematic corruption and failure in the local law enforcement who imo all need to be investigated and fired asap. It's less some weak authority overreacting and more like a whole lot of incompetent people who are supposed to uphold the law actively violating it.

Location: Mountain View, CA

Remote: Yes

Willing to relocate: No

Technologies: Python, Rust, Typescript, Go, Infrastructure, DevSecOps

Résumé/CV: https://www.linkedin.com/in/glenbbaker

Email: iepathos@gmail.com

Hi, I'm a Staff engineer with 14+ years of experience. Spent the last 8.5 years building an early stage startup and following it through acquisition. I supported the post-acquisition transition by training and mentoring offshore engineers and helping maintain continuity as the company shifted from startup execution to standardized enterprise delivery.

My background spans backend engineering, infrastructure, and security, with hands-on work in Python, Rust, and TypeScript. I maintain open source projects and contribute when I can to core Rust projects such as Clap and Cargo. I’m a good fit for teams that need pragmatic execution and someone comfortable owning hard problems across systems, platform, and DevSecOps.

This is essentially 'License Laundering as a Service.' The 'Firewall' they describe is an illusion because the contamination happens at the training phase, not the inference phase. You can't claim independent creation when your 'independent developer' (the commercial LLM) already has the original implementation's patterns and edge cases baked into its weights.

In order to really do this, they would need to train LLMs from scratch that had no exposure whatsoever to open source code which they may be asked to reproduce. Those models in turn would be terrible at coding given how much of the training corpus is open source code.

If the Ars Technica editorial process requires assuming reporters don't fabricate quotes, then their process is inadequate. That's like a software company letting junior engineers release directly to production with just a spellcheck and no real process to catch errors. Major publications like The New Yorker, The Atlantic, etc. have a dedicated fact-checking department that is part of the process and needs to give the ok before any article is published. Why is their process so deficient by comparison? Why wasn't there any fact checking?

The idea that China hasn't 'attacked anyone' in 40 years is factually incorrect. In 1988, they engaged in a deadly naval skirmish with Vietnam over the Johnson South Reef. More recently, the PLA engaged in fatal border clashes with India in the Galwan Valley (2020). On top of direct skirmishes, they have engaged in constant gray-zone aggression: violently ramming Philippine and Vietnamese vessels in the South China Sea, firing water cannons at supply ships, and surrounding Taiwan with live-fire military blockades. That doesn't even touch on the internal human rights abuses against the Uyghurs in Xinjiang. Multiple international bodies and governments have recognized what they are doing to Uyghurs since 2014 as genocide. Finally, it's hard to ignore their devastating handling of COVID-19. The active suppression of information, punishment of early whistleblowers, and refusal to cooperate with international investigations resulted in unprecedented worldwide damage, amounting to an act of gross global endangerment.

Refreshing response from Google especially given the incompetence with which Anthropic has handled bans.

The old path of 'military invents it, civilians eventually get it' (like the Space Race or early ARPANET) hasn't been true for decades. Today, almost all major technological leaps like the modern internet, search engines, smartphones, commercial drones, etc. start in the commercial consumer sector first. The global consumer market dwarfs the defense market, which means the private sector has vastly more capital for R&D. Government payscale caps out ~$190k-$200k/year for specialized roles without some congressional workaround. The top AI researchers at OpenAI, Anthropic, Google etc. make ~$1m-$5m+/year for total compensation. The government couldn't afford to hire the right talent and the right talent likely would refuse based on moral, ethical, and rational principles with the current government.

"1000 PRs/week" with no breakdown of complexity or value is a vanity metric. If these are mostly migrations, boilerplate, and bug fixes on previous Minion PRs that were bug ridden, then you've just created 1000 code reviews/week to waste human time rubber-stamping. That's not productivity, that's busywork with extra steps.

It's like measuring productivity by how many people you pull into meetings each week. The CIA's Simple Sabotage Field Manual literally recommends holding as many meetings as possible with as many people as possible. The CIA should add "open as many PRs with AI as possible" to their list. Bonus sabotage points if the PRs are made from ambiguous "one-shot" attempts described in Slack with no follow up clarification.

The hole is closed with per-site pseudonyms. Your wallet generates a unique cryptographic key pair for each site so same person + same site = same pseudonym, same person + different sites = different, unlinkable pseudonyms.

"The actual correct way" is an overstatement that misses jfaganel99's point. There are always tradeoffs. EUDI is no exception. It sacrifices full anonymity to prevent credential sharing so the site can't learn your identity, but it can recognize you across visits and build a behavioral profile under your pseudonym.

If AI is good enough that juniors wielding it outproduce seniors, then the juniors are just... overhead. The company would cut them out and let AI report to a handful of senior architects who actually understand what's being built. You don't pay humans to be a slow proxy for a better tool.

If the tools get good enough to not need senior oversight, they're good enough to not need junior intermediaries either. The "juniors with jetpacks outpacing seniors" future is unrealistic and unstable—it either collapses into "AI + a few senior architects" or "AI isn't actually that reliable yet."

Apparent hypocrisy and injustice in government policy is an ugly thing in the world that should be pointed out and eliminated through public awareness and scrutiny.

Get a life that's more interesting than dish washing 4-8 hours a day.

Thought the same thing. There is no legal recourse if the bot drains the account and donates to charity. The legal system's response to that is don't give non-deterministic bots access to your bank account and 2FA. There is no further recourse. No bank or insurance company will cover this and rightfully so. If he wanted to guard himself somewhat he'd only give the bot a credit card he could cancel or stop payments on, the exact minimum he gives the human assistant.

The default output from AI is much like the default output from experienced devs prioritizing speed over architecture to meet business objectives. Just like experienced devs, LLMs accept technical debt as leverage for velocity. This isn't surprising - most code in the world carries technical debt, so that's what the models trained on and learned to optimize for.

Technical debt, like financial debt, is a tool. The problem isn't its existence, it's unmanaged accumulation.

A few observations from my experience:

1. One-shotting - if you're prompting once and shipping, you're getting the "fast and working" version, not the "well-architected" version. Same as asking an experienced dev for a quick prototype.

2. AI can output excellent code - but it takes iteration, explicit architectural constraints, and often specialized tooling. The models have seen clean code too; they just need steering toward it.

3. The solution isn't debt-free commits. The solution is measuring, prioritizing, and reducing only the highest risk tech debt - the equivalent of focusing on bottlenecks with performance profiling. Which code is high-risk? Where's the debt concentrated? Poorly-factored code with good test coverage is low-risk. Poorly-tested code in critical execution paths is high-risk. Your CI pipeline needs to check the debt automatically for you just like it needs to lint and check your tests pass.

I built https://github.com/iepathos/debtmap to solve this systematically for my projects. It measures technical debt density to prioritize risk, but more importantly for this discussion: it identifies the right context for an LLM to understand a problem without looking through the whole codebase. The output is designed to be used with an LLM for automated technical debt reduction. And because we're measuring debt before and after, we have a feedback loop - enabling the LLM to iterate effectively and see whether its refactoring had a positive impact or made things worse. That's the missing piece in most agentic workflows: measurement that closes the loop.

To your specific concern about shipping unreviewed code: I agree it's risky, but the review focus should shift from "is every line perfect" to "where are the structural risks, and are those paths well-tested?" If your code has low complexity everywhere, is well tested (always review tests), and passing everything, then ask yourself what you actually gain at that point from further investing your time over-engineering the lesser tech debt away? You can't eliminate all tech debt, but you can keep it from compounding in the places that matter.

The "code witness" concept falls apart under scrutiny. In practice, the agent isn't replacing ripgrep with pure Python, it's generating a Python wrapper that calls ripgrep via subprocess. So you get:

- Extra tokens to generate the wrapper

- New failure modes (encoding issues, exit code handling, stderr bugs)

- The same underlying tool call anyway

- No stronger guarantees - actually weaker ones, since you're now trusting both the tool AND the generated wrapper

The theoretical framing about "proofs as programs" and "semantic guarantees" sounds impressive, but the generated wrapper doesn't provide stronger semantics than rg alone, it actually provides strictly weaker ones. This is true for pretty much any CLI tool you're having the AI wrap python code around to do instead of calling battle tested tools directly.

For actual development work, the artifact that matters is the code you're building, which we're already tracking in source control. Nobody needs a "witness" of how the agent found the right file to edit and if they do agents have parseable logs. Direct tool calls are faster, more reliable, and the intermediate exploration steps are ephemeral scaffolding anyway.

Research on calculator use in early math education (notably the Hembree & Dessart meta-analysis of 79 studies) found that students given calculators performed better at math - including on paper-and-pencil tests without calculators. The hypothesis is that calculators handle computation, freeing cognitive bandwidth and time for problem-solving and conceptual understanding. Problem solving and higher level concepts matter far more than memorizing multiplication and division tables.

I think about this often when discussing AI adoption with people. It's also relevant to this VS Code discussion which is tangential to the broader AI assisted development discussion. This post conflates tool proficiency with understanding. You can deeply understand Git's DAG model while never typing git reflog. Conversely, you can memorize every terminal command and still design terrible systems.

The scarce resource for most developers isn't "knows terminal commands" - it's "can reason about complex systems under uncertainty." If a tool frees up bandwidth for that, that's a net win. Not to throw shade at hyper efficient terminal users, I live in the terminal and recommend it, but it isn't going to make you a better programmer just by using it instead of an IDE for writing code. It isn't reasoning and understanding about complex systems that you gain from living in a terminal. You gain efficiency, flexibility, and nerd cred - all valuable, but none of them are systems thinking.

The auto-complete point in the post is particularly ironic given how critical it is for terminal users and that most vim users also rely heavily on auto-complete. Auto-complete does not limit your effectiveness, it's provably the opposite.

Thanks for the thoughtful reply.

The objections to non-profits, OSFs, education, healthcare, and small companies all boil down to: they don't pay enough or they're inconvenient. Those are valid personal reasons, but not moral justifications. You decided you wanted the money big tech delivers and are willing to exchange ethics for that. That's fine, but own it. It's not some inevitable prostitution everyone must do. Plenty of people make the other choice.

The Google/AI distinction still doesn't hold. Anthropic and OpenAI also created products with clear utility. If Google gets "mixed bag" status because of Docs and Maps (products that exist largely just to feed their ad machine), why is AI "unquestionable cancer"? You're claiming Google's useful products excuse their harms, but AI companies' useful products don't. That's not a principled line, it's just where you've personally decided to draw it.