Born Against the Bot: Why Hobby Coders Are Pushing Back on LLMs

If you spend any time in the corners of the internet where people write code for fun — small forums, IRC channels that somehow still exist, subreddits for niche languages, the comment threads under Advent of Code puzzles — you'll notice something odd. In an industry that has embraced GitHub Copilot, ChatGPT and Claude with the enthusiasm of a startup pitch deck, whole swathes of the hobbyist world have quietly, and sometimes loudly, said no thanks.

Post an LLM-generated solution to a Rust learning forum and you'll be told to delete it. Ask a Copilot-derived question in a Common Lisp channel and you'll get a polite request to try again after actually reading the manual. Some code golf and demoscene communities have written explicit bans. Advent of Code's creator has repeatedly asked people not to feed puzzles to AI or race for leaderboard positions with them.

To an outsider, this can look reactionary — a bunch of Luddites shaking their keyboards at progress. It isn't. It's a coherent position about what programming is for, and it's worth understanding, especially as the same debate creeps into every other creative discipline.

Hobby code is not small professional code

The first thing to understand is that hobbyist programming and professional programming are not the same activity performed at different scales. They have different goals.

Professional software development is, mostly, about producing an artefact: a working system that solves someone's problem, on time, at acceptable quality. If a tool helps you get to the artefact faster, the tool is good. That's the frame in which LLMs make obvious sense — they're a productivity multiplier for people whose job is measured in shipped features.

Hobby programming, by contrast, is often about the process. The point of building a toy compiler, writing a Game Boy emulator, or golfing a solution down to 42 characters of APL is not to have a compiler, an emulator, or a short program. Working versions of all of those things already exist and can be downloaded in seconds. The point is the person who did it — what they learned, the moment the register allocator finally worked, the elegance they wrestled out of the problem.

Under that framing, asking an LLM to write your emulator is roughly equivalent to buying a jigsaw puzzle and paying someone else to complete it before you open the box. The output is identical. The activity has been destroyed.

The pollution problem

There's also a purely practical reason communities are pulling up the drawbridge: signal-to-noise.

Anyone who has moderated a technical forum in the last two years can describe the pattern. A user posts a question that reads slightly too smoothly. The code sample compiles but references a function that doesn't exist in the library. When challenged, the user posts a follow-up that contradicts the first message in confident, uniformly formatted prose. You are now debugging a hallucination on behalf of someone who is not really there.

Stack Overflow banned AI-generated answers in late 2022 for exactly this reason: plausible-looking but wrong content is more expensive to clean up than obviously bad content, because it demands expert time to refute. Volunteer-run hobby communities have even less capacity to absorb that cost. A single popular forum can be effectively drowned by one determined poster with an API key.

Bans, in that context, are not a philosophical statement — they're infrastructure. They're the equivalent of a pub deciding it will no longer host stag dos. The venue is still there; it just wants to remain the kind of place its regulars turned up for.

Craft, apprenticeship and the joy of struggle

Beyond the practical, there is a genuinely philosophical strand running through the resistance, and it echoes older arguments in woodworking, photography and music.

Programming, for many of its practitioners, is a craft. Crafts have apprenticeships. You do the boring exercises not because the exercises matter in themselves but because they build the intuition that lets you do the interesting work later. A carpenter who has never joined two pieces of pine badly cannot really understand why the good joint is good. A programmer who has never lost a Sunday to an off-by-one error does not truly know what an off-by-one error is.

LLMs are extraordinarily good at removing exactly this kind of productive struggle. They collapse the loop between not-understanding and understanding into a copy-paste. For someone whose goal is to ship, that's a feature. For someone whose goal is to become the sort of person who understands memory allocation, it's a bypass around the only road that leads there.

You hear this expressed, in hobbyist spaces, as suspicion of anything that looks like a shortcut around thinking. It's the same instinct that made older programmers suspicious of visual IDEs, drag-and-drop web builders and, going back far enough, high-level languages themselves. The difference is that most of those tools still required you to know what you were doing. An LLM will happily generate a plausible answer for someone who does not.

What Australian devs might take from it

Australia has a healthy hobbyist scene — Linux user groups, retrocomputing meetups in Melbourne and Brisbane, active representation in Advent of Code and the international demoscene, a growing local presence in languages like Zig and Elixir. Most of the people in those rooms also have day jobs where they use Copilot without a second thought.

That split is instructive. The interesting question is not should we use LLMs, because for professional work the answer is obviously yes if they help. The interesting question is: what parts of your practice are you willing to automate, and which parts are you protecting because they are how you stay good?

Musicians ask this about drum machines. Photographers ask it about generative fill. Writers, increasingly, ask it about first drafts. In every case the healthy answer turns out to be some version of: use the tool for the parts that are not the point, and defend the parts that are.

Hobby programming communities have simply been forced to articulate that boundary earlier and more sharply than everyone else, because their entire existence sits on the automatable side of the line. If the artefact is all that matters, they have no reason to exist — someone can just ask a model. So they are naming, out loud, the thing that actually keeps them together: it was never the artefact. It was the people making it, and the fact that they made it themselves.

Not anti-AI, pro-something-else

The framing of these communities as "anti-AI" is, in the end, a bit lazy. Most of the people writing the bans are perfectly capable of using the tools; many of them do, professionally. What they are doing in their off-hours is protecting a space where the point of the activity is the activity.

That's not reactionary. It's the same impulse that keeps people running marathons in an age of cars, brewing beer in an age of Dan Murphy's, and hand-rolling pasta in an age of the supermarket fresh aisle. Automation makes the output cheap. The doing is what gets more valuable, not less.

The hobbyists worked this out first. The rest of us will probably catch up.

Related on Bleen

Sources