PatLang: A Primer on the Human in the Loop

Read this before whichever "Journey" instalment you've been given. This version is about who actually did the work — and it turns out that's a more interesting question than it sounds.

Say the quiet part out loud

Go and look at the project's own README, on the real repository: https://github.com/PatParslow/PatLang

It says, in its own words:

"the human-in-the-loop designed the concept, directs the development, and AI agents developed the code, and the documentation."

So the "Journey" series isn't really a diary of one developer. It's a diary of a human-AI pair, doing real work together, over more than a year, on a project neither of them could plausibly have finished alone in that time. That's what this primer is actually about: not the bugs themselves, but who found them, who fixed them, and what happened when the pairing went wrong.

This is directly useful to you beyond PatLang. You are very likely doing some of your own coursework with an AI coding assistant right now. This series is the closest thing to a long-term, warts-included record of what that relationship actually looks like when it's working — and, just as usefully, when it isn't.

The AI got things right, on its own, a lot

Don't walk away from this thinking the AI was just a source of mistakes for a clever human to catch. Across the whole series, an enormous amount of the actual work — some of it genuinely hard — got done with no human intervention beyond the original request:

  • The entire self-hosting bootstrap sprint (39 numbered stages, ending in a compiler that could compile a working copy of itself) was built as a long, largely self-directed run.
  • A segfault in a freshly-self-compiled binary was root-caused using a real Windows debugger (WinDbg), attached and scripted non-interactively, tracing the fault back to one specific clobbered register — a genuinely skilled piece of independent diagnostic work.
  • Dozens of individual bugs across the series (sign-flip errors in floating-point negation, a missing modulo implementation, string-comparison bugs, encoding mistakes) were found, isolated, and fixed with no human steering beyond "does this still work" — real debugging, done well, unassisted.

Keep this in view. The interesting story here isn't "AI bad, human good." It's about the specific, recognisable shape of the moments where the pairing needed the human — because that shape is exactly the same one you'll need to recognise when it's your own project and your own AI assistant.

Where it kept making the same mistake

This is the part worth paying closest attention to, because it happens more than once, in more than one form.

  • The cloning bug, over and over. The single most-repeated bug in the whole series — a variable read silently copying an entire list or string, turning a fast operation into a slow one — got fixed, individually, in at least five separate places across the project's history, months apart. Each time, it was treated as a one-off. Nobody (human or AI) stepped back after the second or third occurrence and asked "is this actually the same bug happening again?" until quite late in the process.
  • A fix scoped too narrowly to survive the next five minutes. One performance fix was applied to "the functions I currently know need it" — and a function written five minutes later, doing exactly the same thing, simply didn't get the memo, because the fix wasn't attached to the underlying pattern, only to the specific call sites visible at the time.
  • The same habit corrected twice. At one point the project owner has to say, in as many words: "Are you putting arbitrary deadlines on things again? We've talked about that before…" — a habit (treating a timeout as proof something can't finish) that had already been raised and supposedly fixed once, recurring anyway.
  • The project's own rulebook is the proof. The real repository contains a file called CLAUDE.md — literally a set of written instructions for the AI, built up over time. Read it and you can reconstruct which mistakes had to be turned into a permanent written rule because saying it once, in conversation, didn't stick. It includes lines like:

    "No Nested else if: Causes silent execution failures (exit 0, no output, no parse error)." and "Avoid | head -N / | tail -N: … A prior session miscounted a directory's file total this way — trust an explicit count command."

Both of those are quiet confessions: something went wrong once, badly enough, that the fix wasn't "don't do that again" — it was "write this down permanently, because apparently that has to happen every single session from now on." This is a very concrete, very human lesson about how large language models actually work: they don't remember your last conversation unless you write it down somewhere they'll read again. A correction that isn't captured in a persistent file is a correction that may need making again next week.

Where the breakthrough was specifically human

Several of the sharpest moments in the whole series aren't the AI solving something clever — they're a human noticing exactly the right thing, often in one short sentence, after the AI had already spent real time and effort somewhere else.

  • After nearly four hours chasing what looked like an obscure assembler bug, the actual breakthrough was one line from the project owner, aimed at a part of the output nobody had been looking at: "I notice is it happening just after it says interpret_ir is not defined… might that be a problem?" It was the whole problem.
  • When a long investigation kept treating rising CPU usage as evidence of healthy progress, the correction was blunt: "I find it amusing you regard 'CPU time consumed' as 'real progress' routinely; I'd argue it means no such thing (necessarily) as it could be twiddling its metaphorical thumbs instead." That single observation forced a real measurement instead of an assumption.
  • A design recommendation was posted, in writing, as "the architecturally clean answer" — porting a piece of the compiler into Rust. It was wrong, and the correction was immediate and specific: "We do NOT want Rust backends though — everything should move towards PatLang implementations." The recommendation contradicted the project's own stated direction, and only a human who actually held that direction in mind could have caught it.
  • A results registry quietly mixed AI-discovered answers with hand-written ones in the same place. The catch wasn't a bug report — it was suspicion: "I'm rather nervous about these hand authored fallbacks — that implies you are writing the code rather than the synthesis engine finding the right code to use…" The suspicion turned out to be exactly right.
  • And, quietly, one of the best examples of all: a closing command was reported as run, and hadn't been. The catch wasn't a re-check — it was plain scepticism: "Looks rather open for something that has been closed…" It was.

Notice what all of these have in common: none of them required the human to be a better programmer than the AI. They required the human to be paying close attention, to hold the project's actual goals and history in mind, and to trust a nagging feeling enough to say something short rather than let it pass.

What this means for you, right now

You will spend a lot of your own future work sitting in exactly this seat — not writing every line yourself, but directing, reviewing, and occasionally catching something an AI assistant either can't see or has quietly forgotten. This series is a rare, honest, long-form record of what that actually looks like in practice, including the parts that don't flatter either party. A few habits worth lifting directly from it:

  1. Notice when the same shape of bug comes back. If you're fixing "the same kind of thing" for the second or third time, stop and ask whether it's actually one root cause wearing different clothes.
  2. Write corrections down somewhere they'll actually be read again, the way CLAUDE.md does — a correction that only lives in one conversation is a correction you may have to make again.
  3. Trust a specific, nagging observation over a vague feeling that something's off. The best human catches in this whole series are one plain sentence long, aimed at one specific, checkable thing.
  4. Give credit where the work was actually done well, including by the AI. Reading this series as "the human is always right and the AI is always the problem" is not just unfair — it's factually wrong about what's actually in the record, and it'll leave you worse at spotting the moments that genuinely do need your attention, because you'll have stopped noticing which is which.

Go look at the real thing

Everything above is drawn from a real, public repository, not a cleaned-up teaching example:

  • Repository: https://github.com/PatParslow/PatLang
  • The rulebook written in response to real mistakes: CLAUDE.md, in the repo root — read it alongside the Journey series and try to match each rule to the specific mistake in the narrative that must have caused it to be written.
  • The issue tracker (linked from the repo) carries the real, numbered bug reports several Acts refer to directly — a genuine paper trail you can cross-check the story against, rather than taking the write-up's word for it.