Born Against: Contributing to Anti-LLM Dev Communities

Here’s a detail most tutorials on this topic miss: the Stack Overflow decline that everyone keeps citing isn’t just bad for humans. A PNAS Nexus study by del Rio-Chanona and colleagues found a 25% drop in Stack Overflow activity within six months of ChatGPT’s release. That same drop is quietly starving future LLMs of the exact niche knowledge they’d need to help you write an OS kernel or an emulator. The tool that killed the training data is now getting worse at the topics it killed the data for.

That’s the loop these hobby programming communities are trying to break. And on August 4, 2026, Fogus’s essay “Born Against” put a name on why they’re being so aggressive about it. The post hit Hacker News and Lobsters within hours and is still generating replies. If you want to actually contribute to these communities – not just read about them – here’s what to do.

What Fogus’s post actually says (30 seconds)

Skip this if you’ve read the piece. Fogus names seven communities where hostility toward LLM code has calcified: OSDev, LangDev, TxtDev, EmuDev, RLDev, the demoscene, and code golfers. His argument, in one line: “these communities don’t care if your code works at all, but instead care that you know why and how it works.” The output isn’t the point. The learning is.

That framing matters because it tells you what to do, not just what to avoid.

Step 1: Match the community, not the general rule

There is no single “hobby dev” policy. Each community drew a different line, and confusing them is the #1 way newcomers get banned. Here’s the current map as of August 2026:

Read the fine print. Codeberg’s wording is “largely or fully” machine-generated, not “any LLM assist.” That grey area is real – a hand-written function with an autocomplete-assisted line is a different case than a whole PR from Claude Code. When in doubt, ask before you push.

Step 2: Write your first post in the community’s dialect

Every niche forum has a tell. OSDev people write about memory layout and page tables. LangDev people write about parser combinators and grammar ambiguities. If your first post reads like a ChatGPT summary of a Wikipedia article on the topic, you’ll be spotted in seconds.

Do this instead:

1. Lurk for a week. Read the last 50 threads. Note which questions get answered warmly and which get ignored.
2. Post a specific failure, not a broad question. “My bootloader triple-faults after enabling paging on QEMU” beats “How do I start OSDev?”
3. Show what you tried. Include the code, the exact error, and the two hypotheses you already ruled out. This is the “proof of effort” these communities were built on.
4. Never paste an LLM explanation as your reasoning. If you don’t understand your own paragraph, they can tell.

Step 3: Disclose tool use – properly

The word “disclose” gets thrown around a lot. It has a specific meaning. The EFF’s policy allows LLM use with three concrete requirements: mandatory disclosure, demonstrated understanding, and human-authored documentation. That’s the template most reviewer-friendly projects are converging on.

In practice, a good disclosure looks like this at the top of a PR description:

# PR: Fix off-by-one in the ring allocator

Tool use: Used Claude to explain the existing free-list logic
in src/alloc/ring.c. All code in this PR was written by hand
after I understood the invariant. No generated code was pasted.

Why this change: [your reasoning]
How I tested: [your steps]

That opening paragraph does more work than most contributors realize. It signals you know the difference between using an LLM as a study partner and using it as a ghostwriter. Maintainers who are LLM-skeptical will still read your patch.

Common pitfalls that get first-time contributors flagged

• Perfect grammar, wrong content. LLM prose is often better than the surrounding thread. That contrast is the first flag.
• Answering questions you weren’t asked. A comment thread asks “why does this segfault?” and someone posts a bulleted list of five possible causes. That’s an AI reflex, not a human one.
• Generic variable names in a codebase with strong conventions. If everyone else uses pgd and pte and your patch introduces pageDirectory, you’re either new or generated.
• The “helpful cleanup” PR. A drive-by refactor of 400 lines from a stranger is now assumed to be AI. Don’t do this even if you wrote it by hand.

Pro tip: If you genuinely used an LLM to understand a codebase but wrote the patch yourself, mention which specific concept the LLM helped you learn. “I used Claude to explain how the existing bump allocator handles alignment” is trust-building. “I used AI for research” is trust-destroying.

What actually happens to LLM-heavy PRs

Merge rate isn’t the only cost. Byteiota’s reporting on maintainer feedback lands on something most productivity arguments skip: reviewing AI-generated code often takes more effort than writing the fix manually. A commenter on the Lobsters thread about the Fogus post was blunter: “LLM usage produces a lot of false positives that are time consuming to debunk.” So the offer implicit in an AI-heavy PR – “I saved time, please merge” – actually reads as “I saved my time by spending yours.” That’s why unpaid maintainers keep hardening their policies.

Which brings up a question worth sitting with: if the people maintaining these projects can’t distinguish a careful human patch from a mediocre AI one without a line-by-line interrogation, what does that say about the floor quality an AI generates? It’s not a rhetorical question. The detection burden itself is part of why Redox OS’s February 2026 no-LLM policy triggered a 339-comment Hacker News debate – people had real feelings on both sides, but the economics of unpaid review time are what forced the policy into existence.

When you probably shouldn’t try to contribute at all

• You can’t explain your own patch line by line without looking anything up.
• You’d need an LLM to answer basic questions in the review thread.
• Your motivation is “I want to add open-source projects to my resume,” not “I care about this specific piece of software.”
• The project is one where the process is the point – the demoscene doesn’t need your “help.” It needs you to make a demo yourself.

Is a firm no-LLM stance sustainable long-term, or is it a rearguard action? Honestly, no one knows yet. The Debian outcome – debate for weeks and decline to decide – might be the most realistic future for most large projects.

FAQ

Can I use an LLM to learn the codebase but not to write code?

Yes, and this is exactly what Fogus called a “lever” for someone with existing expertise. Just don’t paste LLM explanations into review threads as if they were your own understanding – that’s what gets caught.

How do maintainers actually detect LLM code?

Rarely through detectors – those don’t work reliably. Pattern-matching is the real mechanism: overly explanatory comments on trivial lines, defensive error handling in a codebase that doesn’t use it, variable names that don’t match local convention, and a PR description that reads like marketing copy. The giveaway is usually the disconnect between a polished patch and a contributor who can’t answer follow-up questions in review. No tool catches that. A human does, immediately.

What’s the difference between the Codeberg ban and the EFF policy?

Codeberg draws a line at the artifact – no projects that are largely machine-generated, period. The EFF draws the line at the contributor’s behavior: use whatever tools you want, but disclose it, understand what you submitted, and write your own docs. Codeberg is easier to enforce; EFF’s approach is more forgiving to newcomers who are learning honestly.

Next action: Pick one project from the table above. Read its contribution guide today. Then lurk in its issue tracker for a week before you type a single reply. That’s the whole first step.