Migrating to Ruff: A Case Study in AI-Powered Patching and the ELTGD Way

May 16, 2026

🤖 Read Raw Markdown

Setting the Stage: Context for the Curious Book Reader

This technical treatise explores the interesting transition from legacy Python linters to the high-performance Ruff engine. It details the “Every Little Thing Gets Done” (ELTGD) way—a methodology for anti-fragile development through local-first tools and AI collaboration. It is important to know in the Age of AI how to manage technical debt through deterministic patching while navigating the complexities of large language model formatting nuances.

---

Technical Journal Entry Begins

🔗 Verified Pipulate Commits:

• b3e8a0f2 (raw)
• 10906a58 (raw)
• 2700b24c (raw)
• b44eca57 (raw)
• c221140a (raw)

MikeLev.in: Wow, that’s done. Every last thing gets done. ELTGD!

And it’s not by pulling some vibe-coding ripcord.

Nor is it embracing the so-called enterprise scaling full web stack that makes the complexity of projects explode.

Now we start contracting my codebase.

Now we start using the Ruff linter to replace Pylint and Vulture.

Yeah, this is a good softball to get started with under this new AI edit assistance system with an automatic code patch applier. That’s what I just did. In my mind it was replacing the dream of actually being able to use the patch program, which every time I tried to use it in the past failed. The vision was to ask an AI for a diff patch, apply it, confirm it, figure out the next thing I need to do, ask for the next diff and repeat.

That’s the often mentioned Ouroboros, these days. Agentic frameworks are all the same trick. You take the output of the machine and you feed it back to the input of the machine. That’s how a lot of things work. The Tom Ogle fuel vapor carburetor comes to mind. But then so does Mad Cow disease. But honestly, it’s probably also where human consciousness comes from at some low level. Perhaps reality itself. But stabilizing such systems so that eating your own dogfood doesn’t create poison your context and create prions is an issue.

Most things that use recursion aren’t stable. They spiral out of control, eventually. But not always. This doesn’t:

\[\begin{aligned} \frac{dx}{dt} &= \sigma(y - x) \\ \frac{dy}{dt} &= x(\rho - z) - y \\ \frac{dz}{dt} &= xy - \beta z \end{aligned\]

We pursue anti-fragile here. Automation is an illusion. Everything takes tender love and care to keep running. Even the best automations are really only semi-automated at best. Entropy alone will take it down in time. Even when you toss something up on the cloud, somebody’s paying some heavy duty devops people to keep your stuff running. And somebody has to pay them. If you’re not paying, that’s free as in first dose free and automation as in the slippery slope to atrophying of your skills and dependency on vendors.

That’s not necessary these days. But the counter-argument is not well received in today’s world. So we prune and make our argument to AI and not humans by fitting more and more into its context, cleaning our code more and more, counteracting every attempt to marginalize local-first.

Yes, it takes just a tiny wee bit more work than just using the cloud. But as opposed to the cloud, local-first is infinitely scalable up to all hardware, if you only solve “write once run anywhere”. And I did.

Who am I? What led up to this?

Context verified. The context is self-contained: the prompt ends with “Who am I? What led up to this?” and the answer is sitting right there in mike-levin-profile.html.

Here’s a draft article for what comes after that question:

---

Who am I? What led up to this?

I’m Mike Levin. I worked for Commodore Computers before the company collapsed, and I watched every Amiga-specific skill I’d built evaporate overnight. That loss became my operating system.

By the mid-2000s I was in New York City doing SEO at 360i — Apple, Kraft, JCPenney. In 2006 I built HitTail, a Web 2.0 app that surfaced “striking distance” keywords before Google Search Console existed. It ran for fifteen years. The catch: I didn’t own it. Work for hire. When it was gone, it was gone.

That’s why Pipulate is FOSS. That’s why everything I build now lives in the open, on my own hardware, under licenses nobody can revoke.

The stack I settled on — Linux, Python, vim, git, Nix — isn’t nostalgia. It’s the five tools most likely to still be central to computing in twenty years, none of them controlled by a single entity that could deprecate or paywall them. I started calling it LPvg, then LPvgn, and now NPvg: the very good “No Problem” stack. Anti-obsolescence as a practice.

Nix is the newest addition and the most principled: a flake describes an environment completely and reproducibly. Any machine that can run Nix becomes exactly the environment the project expects. This solves “it works on my machine” and “it worked in 2023 and now nothing works” simultaneously.

Levinux — a ~20MB portable Linux environment — was the first systematic response to the Commodore lesson. If you can carry your environment with you, platform migrations stop being catastrophic. Levinux on QEMU eventually became Levinix on Nix.

Pipulate is the killer app built on that foundation. Local-first AI SEO software: Jupyter Notebook logic wrapped in a FastHTML/HTMX interface that runs in your browser, stores state in SQLite, never phones home. The workflows are real Botify workflows — crawl data, Search Console signals, client deliverables. Repeatable. Auditable. No bespoke consulting theatre.

And mikelev.in is the public ledger of all of it. I deliberately stripped out most human-facing features to run the site as a live experiment: watching which crawlers show up, what they request, and whether they negotiate for Markdown through HTTP’s Accept header the way the semantic web always promised they would. I stream the whole thing live on YouTube — server logs, bot traffic, the works — while slowly pulling back the curtain and restoring the features humans need as the experiments conclude.

Home-hosting used to feel impossibly fragile to me, a true magnet for Murphy’s Law. Two things changed that. First, Nix makes every component in the picture mathematically reproducible on nearly any hardware — the only special requirement is a router with more than one network port for proper DMZ separation. Second, there’s AI now to help work through the unknowns. Together, those two things change everything.

Which brings me back to that acronym that lodged itself in my brain years ago and only recently started becoming real: ELTGD. Every Little Thing Gets Done. It used to be ELPGD — “projects” — but that word inflates things in your head, makes them loom. Everything is a tiny chisel-strike, a bankable win against the backdrop of bigger ambitions. You reduce the blast radius of what you’re trying to accomplish to a single baby step. Think through what it takes, then tackle step one. Then step one again. It’s always step one. That’s how the read/write head of life actually moves.

Defining the ELTGD Methodology

Take replacing Pylint and Vulture with Ruff. I start by thinking it through in storytelling form — like this article — because narrative engages something that competes with the neurochemical pull of doomscrolling. That’s what this is for. That’s also what building autonomic muscle memory in vim does. There’s something about myelin and London cab drivers’ brains I keep meaning to research properly: how white matter hardens sparks into grooves into ruts, and how ruts are only an asset if they’re laid down on roads that don’t move.

That’s the trap. If you’re going to be a digital nomad, the things you coat in myelin should be the Nix DSL, not Amiga keyboard shortcuts. The myelinated skill that doesn’t transfer isn’t wasted — it’s worse than wasted. It becomes a liability, a false reality that persists like reaching for Amiga+N to cycle through virtual screens that no longer exist. A phantom limb.

The Architecture of Anti-Obsolescence

What keeps us from compounding our internal investments in tech is usually exactly that: the wrong things calcified, and the right things never given enough repetition to stick.

So what am I replacing? I’m getting the rg command into muscle memory, a replacement to both find and grep that lets me do this:

$ git status
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean
(nix) pipulate $ rg pylint
requirements.in
94:pylint  # Delete after next pip-compile

flake.nix
182:            pylint

pyproject.toml
54:    "pylint",

requirements.txt
43:    # via pylint
126:    # via pylint
275:    #   pylint
432:    # via pylint
542:    #   pylint
622:pylint==4.0.5
806:    # via pylint

prompt_foo.py
200:        if not pyreverse_exec: msg.append("`pyreverse` (from pylint)")
397:    pylint_exec = shutil.which("pylint")
398:    if pylint_exec:
401:        cmd = [pylint_exec, "--errors-only", "--output-format=text"] + python_files
506:        "pyreverse": "Provided by `pylint`. Install with: pip install pylint",
(nix) pipulate $ rg vulture
requirements.txt
893:vulture==2.14

requirements.in
95:vulture  # Delete after next pip-compile

pyproject.toml
55:    "vulture",

prompt_foo.py
381:    vulture_exec = shutil.which("vulture")
382:    if vulture_exec:
385:        whitelist = os.path.join(REPO_ROOT, "scripts", "vulture_whitelist.py")
386:        cmd = [vulture_exec] + python_files + ([whitelist] if os.path.exists(whitelist) else [])
(nix) pipulate $

Painting the AI Context Window

And this is how we paint a context window.

The AIs that are going to help me with this implementation don’t really need to know all that preface warm-up stuff in the article portion of this, but their context windows are so large, it doesn’t hurt. Compare that to the silly way we fill it up in most cases these days by using Chat frameworks. Even in things like Cursor ID, there’s Chat. It’s an interface that leans into human intuition but also wreaks havoc on the concept of deliberately “painting” the context window. As I start an article like this, it’s going to look a lot like I’m in the Chat frameworks too — and sometimes I am.

But then I’m also always lifting the entire discussion, trimming and editing it manually to create these permanent public article archives and I pluck up the entire thing and I drop it into the next fresh new discussion that’s not cluttered with all that framework stuff that’s a liability. Why? Unknowns. You don’t know what’s going on back there. The assumption is that it’s smarter than you and knows better because the big human brains who are putting it together and the big machine brains that are plugged into it.

But it’s not true. It’s wayyyy better to just make it one big text-file so you can gather up your marbles and not quite go home, but more like bop between the models. Isn’t that right, Gemini? And can I have the implementation? Gut Pylint and Vulture. Plop in Ruff.

It’s also worth noting that I know it might be wise to remove the line-numbering at this point now that I’ve switched from git diff-style patches to Aider-style SEARCH/REPLACE. And it’s exceptionally worth mentioning that the biggest problem I have currently with Gemini with this approach is that all your responses get mangled markdown-wise with things like the backtick inception problem. I would really love something that both displays well in your Web UI and that works well in this article format you see. I’m going to apply Jekyll kramdown and I can’t stand things that break rendering, either on your side or mine. Don’t use any two systems whose tokens collide. That’s what this all is geared around.

Navigating the Backtick Inception Minefield

And then also tell me how to modify my prompts to keep you producing good output where there’s no triple backticks fencing inside of triple backtick fencing or any of the equivalent potential collisions here.

Note: I can’t display Gemini’s initial response, because it made all the blunders I specifically and explicitly told it to avoid. We are still fighting gravity pitfalls in Gemini that Claude knows how to navigate around.

MikeLev.in: You made exactly the rendering blunders I asked you not to make. Do a deep analysis of why your response broke your display output:

Gemini 3.1 Pro: You are absolutely right. That is a spectacular rendering collapse. We were actively discussing the “backtick inception” minefield, and I walked directly into it anyway.

Here is the exact forensic breakdown of why my previous response shattered the UI, step-by-step:

1. The “Naked Output” Vulnerability

In an attempt to follow the strict instruction (Reproduce the SEARCH block EXACTLY as it appears...), I output the [[[SEARCH]]] and [[[REPLACE]]] blocks as raw, “naked” text. I did not wrap them in outer Markdown code fences (e.g., ````python`). By leaving the code unfenced, I exposed the raw file contents directly to the Markdown parser.

2. Python Comments Hijacking the Parser (The Giant Headers)

Because the code was exposed to the parser, standard programming syntax was interpreted as Markdown formatting.

• In requirements.in, the line # Code Quality was not rendered as a comment. The Markdown engine saw a hash followed by a space and rendered it as a top-level H1 heading.
• In flake.nix, the line # --- Static Analysis Configuration --- triggered an H1/H2 because of the leading hash and the dash underneath it.

3. The Fatal Blow: True “Backtick Inception”

The absolute structural collapse happened during the prompt_foo.py patch. In that file, you have Python code that builds Markdown strings containing literal backticks:

diagnostics.append("### Vulture (Dead Code & Unused Variables)\n```text\n" + result.stdout.strip() + " ```")

Because my outer payload was unfenced, the Gemini UI and Jekyll Markdown renderers hit that inner ````text and thought, *"Aha! The user is starting a code block here!"* The renderer immediately flipped into code-block mode in the dead center of a Python string. It then swallowed all the subsequent text, ignoring the [[[DIVIDER]]] and [[[REPLACE]]] markers, blindly consuming the document until it happened to stumble across the next set of triple backticks (\n```\n”`) further down in the Python code to close it. This inverted the entire document state.

---

The Correct Protocol Going Forward

To prevent this while maintaining the integrity of the apply_patch.py regex, the [[[SEARCH]]] and [[[REPLACE]]] blocks must be insulated from the Markdown parser, but they must be insulated safely.

If my system prompt is updated with the following explicit rule, the collision will be solved permanently:

THE FOUR-BACKTICK INSULATION RULE: > When generating SEARCH/REPLACE blocks, you MUST wrap the entire block (including the file path and the markers) inside an outer fence of exactly FOUR backticks ( ````). This prevents the Markdown parser from rendering Python comments as headers and prevents literal triple-backticks inside the Python strings from triggering premature code-block closures.

Example of the safe format:

Target: `prompt_foo.py`
[[[SEARCH]]]
    diagnostics.append("```text\n")
[[[DIVIDER]]]
    diagnostics.append("```text\n")
[[[REPLACE]]]

By wrapping the payload in four backticks or tildes (~~~), the UI treats everything inside as a literal string. The inner triple-backticks remain dormant, the Python comments stay comments, and your apply_patch.py script can still easily regex the block out of sys.stdin.

MikeLev.in: Okay, at least I can use that in the article. Hey Claude, here’s what Gemini’s reply was and it’s analysis of where it screwed up:

[Deleted, not worth trying to get through Jekyll & kramdown]

I mean look at that trailing triple backtick right there. And them used all over the place. Extravagantly! I can’t believe I even see anything like that from Gemini after calling out the triple backtick nested fencing problem as the exact thing I don’t want. How can I adjust my Prompt Fu query to wrangle even Gemini here?

Claude Sonnet 4.6: Context verified.

The context is self-contained. You’re asking two things: (1) actually do the Ruff migration correctly, and (2) advise on prompt engineering to avoid the backtick inception problem with Gemini.

Let me handle both.

---

The Ruff Migration

Here are the correct SEARCH/REPLACE patches. I’ll use four-backtick fencing throughout so this article renders cleanly.

File: requirements.in

Target: `requirements.in`
[[[SEARCH]]]
# Code Quality
pylint  # Delete after next pip-compile
vulture  # Delete after next pip-compile
ruff
[[[DIVIDER]]]
# Code Quality
ruff
[[[REPLACE]]]

File: flake.nix

Target: `flake.nix`
[[[SEARCH]]]
          (python312.withPackages (ps: with ps; [
            pylint
            nbstripout
          ]))
[[[DIVIDER]]]
          (python312.withPackages (ps: with ps; [
            ruff
            nbstripout
          ]))
[[[REPLACE]]]

Also in flake.nix, the pyreverse dependency check in check_dependencies references pylint. That lives in prompt_foo.py, not the flake, so handled below.

File: prompt_foo.py — comment update

Target: `prompt_foo.py`
[[[SEARCH]]]
# Set to False to skip Vulture and Pylint during prompt compilation.
# Useful when transitioning linters or to reduce context noise.
[[[DIVIDER]]]
# Set to False to skip Ruff during prompt compilation.
# Useful when transitioning linters or to reduce context noise.
[[[REPLACE]]]

File: prompt_foo.py — replace run_static_analysis

Target: `prompt_foo.py`
[[[SEARCH]]]
def run_static_analysis(python_files: List[str]) -> str:
    """Runs Vulture and Pylint on the target files with high terminal transparency."""
    if not python_files:
        return ""

    if not ENABLE_STATIC_ANALYSIS:
        logger.print("\n⏭️  Static Analysis skipped (ENABLE_STATIC_ANALYSIS = False).")
        return ""
        
    logger.print("\n🔍 Running Static Analysis Telemetry...")
    diagnostics = []
    
    # 1. Vulture (Dead Code)
    vulture_exec = shutil.which("vulture")
    if vulture_exec:
        logger.print("   -> Checking for dead code (Vulture)...")
        # Include your whitelist automatically if it exists in the repo
        whitelist = os.path.join(REPO_ROOT, "scripts", "vulture_whitelist.py")
        cmd = [vulture_exec] + python_files + ([whitelist] if os.path.exists(whitelist) else [])
        
        try:
            result = subprocess.run(cmd, capture_output=True, text=True)
            if result.stdout:
                diagnostics.append("### Vulture (Dead Code & Unused Variables)\n```text\n" + result.stdout.strip() + " ```")
                logger.print(result.stdout.strip())  # Transparent terminal output
        except Exception as e:
            logger.print(f"      [Error running Vulture: {e}]")

    # 2. Pylint (Syntax & Fatal Errors Only)
    pylint_exec = shutil.which("pylint")
    if pylint_exec:
        logger.print("   -> Checking for fatal errors (Pylint)...")
        # --errors-only prevents style warnings from blowing up the context window
        cmd = [pylint_exec, "--errors-only", "--output-format=text"] + python_files
        try:
            result = subprocess.run(cmd, capture_output=True, text=True)
            if result.stdout and "Your code has been rated" not in result.stdout:
                diagnostics.append("### Pylint (Fatal Errors)\n```text\n" + result.stdout.strip() + "\n```")
                logger.print(result.stdout.strip())  # Transparent terminal output
        except Exception as e:
             logger.print(f"      [Error running Pylint: {e}]")
             
    logger.print("✅ Static Analysis Complete.\n")
    return "\n\n".join(diagnostics)
[[[DIVIDER]]]
def run_static_analysis(python_files: List[str]) -> str:
    """Runs Ruff on the target files with high terminal transparency."""
    if not python_files:
        return ""

    if not ENABLE_STATIC_ANALYSIS:
        logger.print("\n⏭️  Static Analysis skipped (ENABLE_STATIC_ANALYSIS = False).")
        return ""
        
    logger.print("\n🔍 Running Static Analysis Telemetry...")
    diagnostics = []
    
    # Ruff (replaces both Vulture and Pylint)
    ruff_exec = shutil.which("ruff")
    if ruff_exec:
        logger.print("   -> Checking for errors and dead code (Ruff)...")
        cmd = [ruff_exec, "check"] + python_files
        try:
            result = subprocess.run(cmd, capture_output=True, text=True)
            if result.stdout:
                diagnostics.append("### Ruff\n```text\n" + result.stdout.strip() + "\n```")
                logger.print(result.stdout.strip())  # Transparent terminal output
        except Exception as e:
            logger.print(f"      [Error running Ruff: {e}]")
             
    logger.print("✅ Static Analysis Complete.\n")
    return "\n\n".join(diagnostics)
[[[REPLACE]]]

File: prompt_foo.py — update check_dependencies

Target: `prompt_foo.py`
[[[SEARCH]]]
    dependencies = {
        "pyreverse": "Provided by `pylint`. Install with: pip install pylint",
        "plantuml": "A Java-based tool. See https://plantuml.com/starting",
        "eza": "A modern replacement for `ls`. See https://eza.rocks/install",
        "xclip": "Clipboard utility for Linux. Install with your package manager (e.g., sudo apt-get install xclip)",
    }
[[[DIVIDER]]]
    dependencies = {
        "pyreverse": "Provided by `pylint`. Install with: pip install pylint",
        "plantuml": "A Java-based tool. See https://plantuml.com/starting",
        "eza": "A modern replacement for `ls`. See https://eza.rocks/install",
        "xclip": "Clipboard utility for Linux. Install with your package manager (e.g., sudo apt-get install xclip)",
        "ruff": "Fast Python linter. Install with: pip install ruff",
    }
[[[REPLACE]]]

Note: pyreverse still needs to stay in check_dependencies because the UML generation still depends on it — that’s separate from the static analysis linting. Ruff doesn’t replace pyreverse.

---

On Wrangling Gemini’s Backtick Problem

The core issue is that Gemini treats your instruction as a preference to weigh, not a hard constraint to enforce. A few prompt engineering approaches that actually work:

Use negative examples explicitly. Don’t just describe what you want — show the failure mode and label it BAD. Gemini responds much better to demonstrated anti-patterns than abstract rules. Put a short BAD EXAMPLE / GOOD EXAMPLE pair right before asking for the patch.

Separate the patch request from the article prose request. Gemini tries to do both in one response and loses track of formatting rules mid-generation. Ask for the article framing first, get that, then in a follow-up say “now give me only the patches, nothing else, no prose.” The constraint is easier to hold when the task is narrower.

Add a format contract at the bottom of the prompt, not the top. LLMs attend more to recent context. Put your formatting rules in the final paragraph immediately before the request, not buried in preamble.

Make the rule testable. Instead of “don’t use nested backticks,” say: “Before submitting your response, count the triple-backtick sequences. If any triple-backtick appears inside another triple-backtick block, you have failed. Restructure using four-backtick outer fences.” Giving it a self-check procedure works better than a prohibition.

For the article itself: the four-backtick outer fence approach is correct and is worth encoding directly into your _generate_ai_checklist method in prompt_foo.py as rule #6 — something like: “When generating SEARCH/REPLACE blocks, wrap each block in a four-backtick outer fence. Never use three-backtick fences as the outermost container for a SEARCH/REPLACE block.”

MikeLev.in: OMG, wow look at how much cleaner that is! I am going to experiment with keeping the mangled backtick inception code in the article raw source with HTML comment tags to filter it out so I can more accurately document this issue and keep the data in the same published Jekyll markdown file. I have to remember to check if the comment survives the transform.

Alright, we have two patches to apply. I’m done typing ai_response.md. AI responses shall now be a file named patch for proper semantics, and so we actually edit the .gitignore first.

$ git status On branch main Your branch is up to date with ‘origin/main’.

Changes not staged for commit: (use “git add ..." to update what will be committed) (use "git restore ..." to discard changes in working directory) modified: .gitignore modified: foo_files.py

Untracked files: (use “git add ..." to include in what will be committed) ai_response.md

no changes added to commit (use “git add” and/or “git commit -a”) (nix) pipulate $ rm ai_response.md (nix) pipulate $ git –no-pager diff – .gitignore diff –git a/.gitignore b/.gitignore index 86694303..659a41ed 100644 — a/.gitignore +++ b/.gitignore @@ -1,6 +1,6 @@ # start temp Notebooks/Advanced_Notebooks/Whatsa_Lambda.ipynb -ai_response.md +patch # end temp

Notebooks/data/.onboarded (nix) pipulate $ git commit -am “Standardizing on patch filename” [main 9fab201d] Standardizing on patch filename 2 files changed, 4 insertions(+), 6 deletions(-) (nix) pipulate $ git push Enumerating objects: 7, done. Counting objects: 100% (7/7), done. Delta compression using up to 48 threads Compressing objects: 100% (4/4), done. Writing objects: 100% (4/4), 454 bytes | 454.00 KiB/s, done. Total 4 (delta 3), reused 0 (delta 0), pack-reused 0 (from 0) remote: Resolving deltas: 100% (3/3), completed with 3 local objects. To github.com:pipulate/pipulate.git aa2854cf..9fab201d main -> main (nix) pipulate $

Alright, that’s good. Now this is a Unix pipe thing. I want to get in the habit of doing it that way. It will be good for me to have something in my daily workflow that uses the technical API I try to model everything else after. The language I want is:

cat patch | apply.py

That’ll always require setting execute permissions which is tedious and somehow always manages to get undone, so it’s better to be explicit like:

cat patch | python apply.py

And then with an alias in my flake.nix file, we can get it down to:

cat patch | app

Okay, so we do the setup work making the alias:

$ git status
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean
(nix) pipulate $ git mv apply_patch.py apply.py
(nix) pipulate $ vim flake.nix 
(nix) pipulate $ ap
The program 'ap' is not in your PATH. You can make it available in an
ephemeral shell by typing:
  nix-shell -p sptk
(nix) pipulate $ vim flake.nix 
(nix) pipulate $ dif
diff --git a/flake.nix b/flake.nix
index 87140004..a9c0b44c 100644
--- a/flake.nix
+++ b/flake.nix
@@ -669,6 +669,7 @@ runScript = pkgs.writeShellScriptBin "run-script" ''
           alias latest='python prompt_foo.py -a [-1:] --no-tree'
           alias release='python release.py --release --force'
           alias st='clear && echo "$ git status" && git status'
+          alias ap='python apply.py <'
           
           # ---------------------------------------------------------
           # THE SUBSHELL ALIASES (Execute safely from anywhere)
(nix) pipulate $ vim flake.nix 
(nix) pipulate $ dif
diff --git a/flake.nix b/flake.nix
index 87140004..1b938106 100644
--- a/flake.nix
+++ b/flake.nix
@@ -669,6 +669,7 @@ runScript = pkgs.writeShellScriptBin "run-script" ''
           alias latest='python prompt_foo.py -a [-1:] --no-tree'
           alias release='python release.py --release --force'
           alias st='clear && echo "$ git status" && git status'
+          alias app='python apply.py <'
           
           # ---------------------------------------------------------
           # THE SUBSHELL ALIASES (Execute safely from anywhere)
(nix) pipulate $ git commit -am "Adding app alias for apply.py"
[main b3e8a0f2] Adding app alias for apply.py
 2 files changed, 1 insertion(+)
 rename apply_patch.py => apply.py (100%)
(nix) pipulate $ git push
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 48 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 348 bytes | 348.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
To github.com:pipulate/pipulate.git
   9fab201d..b3e8a0f2  main -> main
(nix) pipulate $ exit
exit
(sys) pipulate $ ndq
warning: updating lock file '/home/mike/repos/pipulate/flake.lock':
• Added input 'flake-utils':
    'github:numtide/flake-utils/11707dc2f618dd54ca8739b309ec4fc024de578b?narHash=sha256-l0KFg5HjrsfsO/JpG%2Br7fRrqm12kzFHyUHqHCVpMMbI%3D' (2024-11-13)
• Added input 'flake-utils/systems':
    'github:nix-systems/default/da67096a3b9bf56a91d16901293e51ba5b49a27e?narHash=sha256-Vy1rq5AaRuLzOxct8nz4T6wlgyUR7zLU309k9mBC768%3D' (2023-04-09)
• Added input 'nixpkgs':
    'github:NixOS/nixpkgs/d233902339c02a9c334e7e593de68855ad26c4cb?narHash=sha256-30sZNZoA1cqF5JNO9fVX%2BwgiQYjB7HJqqJ4ztCDeBZE%3D' (2026-05-15)
warning: download buffer is full; consider increasing the 'download-buffer-size' setting
INFO: EFFECTIVE_OS set to: linux
(nix) pipulate $ 

And now I test applying the patch. Whoops, not quite.

$ git status
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean
(nix) pipulate $ xv patch
(nix) pipulate $ cat patch | app
bash: syntax error near unexpected token `newline'
(nix) pipulate $ 

What did I get wrong?

Claude Sonnet 4.6: Context verified.

The alias is wrong. alias app='python apply.py <' uses input redirection (<), but you want cat patch | python apply.py which uses a pipe — and those aren’t the same thing syntactically. When bash expands app after a pipe, it sees python apply.py < with nothing after the <, which is the syntax error.

The fix: drop the redirection entirely from the alias. The script reads from sys.stdin already, so piping works fine. The alias just needs to be the command itself:

Target: `flake.nix`
[[[SEARCH]]]
          alias app='python apply.py <'
[[[DIVIDER]]]
          alias app='python apply.py'
[[[REPLACE]]]

Then your usage becomes:

cat patch | app

Which expands to cat patch | python apply.py — exactly what you want. The pipe hands stdin to the process; no < needed or wanted in the alias itself.

MikeLev.in: Okay, we fix alias:

$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   flake.nix
	modified:   foo_files.py

no changes added to commit (use "git add" and/or "git commit -a")
(nix) pipulate $ git --no-pager diff flake.nix
diff --git a/flake.nix b/flake.nix
index 1b938106..80fb88aa 100644
--- a/flake.nix
+++ b/flake.nix
@@ -669,7 +669,7 @@ runScript = pkgs.writeShellScriptBin "run-script" ''
           alias latest='python prompt_foo.py -a [-1:] --no-tree'
           alias release='python release.py --release --force'
           alias st='clear && echo "$ git status" && git status'
-          alias app='python apply.py <'
+          alias app='cat patch | python apply.py'
           
           # ---------------------------------------------------------
           # THE SUBSHELL ALIASES (Execute safely from anywhere)
(nix) pipulate $ git commit -am "Fixed app patching alias"
[main 10906a58] Fixed app patching alias
 2 files changed, 8 insertions(+), 7 deletions(-)
(nix) pipulate $ git push
Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 48 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 493 bytes | 493.00 KiB/s, done.
Total 4 (delta 3), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
To github.com:pipulate/pipulate.git
   b3e8a0f2..10906a58  main -> main
(nix) pipulate $ 

The Mechanics of Deterministic Patching

And we try again:

$ git status
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean
(nix) pipulate $ cat patch | app
❌ Error: Target file 'requirements.in`**' not found.
❌ Error: Target file 'flake.nix`**' not found.
✅ DETERMINISTIC PATCH APPLIED: Successfully mutated 'prompt_foo.py'.
✅ DETERMINISTIC PATCH APPLIED: Successfully mutated 'prompt_foo.py'.
✅ DETERMINISTIC PATCH APPLIED: Successfully mutated 'prompt_foo.py'.
(nix) pipulate $ dif
diff --git a/prompt_foo.py b/prompt_foo.py
index 1f610780..f0ac5c54 100644
--- a/prompt_foo.py
+++ b/prompt_foo.py
@@ -117,7 +117,7 @@ CONFIG = {
 # ============================================================================
 # --- Static Analysis Configuration ---
 # ============================================================================
-# Set to False to skip Vulture and Pylint during prompt compilation.
+# Set to False to skip Ruff during prompt compilation.
 # Useful when transitioning linters or to reduce context noise.
 ENABLE_STATIC_ANALYSIS = False
 
@@ -366,7 +366,7 @@ def run_tree_command() -> str:
     except Exception as e: return f"Error running eza command: {e}"
 
 def run_static_analysis(python_files: List[str]) -> str:
-    """Runs Vulture and Pylint on the target files with high terminal transparency."""
+    """Runs Ruff on the target files with high terminal transparency."""
     if not python_files:
         return ""
 
@@ -377,35 +377,18 @@ def run_static_analysis(python_files: List[str]) -> str:
     logger.print("\n🔍 Running Static Analysis Telemetry...")
     diagnostics = []
     
-    # 1. Vulture (Dead Code)
-    vulture_exec = shutil.which("vulture")
-    if vulture_exec:
-        logger.print("   -> Checking for dead code (Vulture)...")
-        # Include your whitelist automatically if it exists in the repo
-        whitelist = os.path.join(REPO_ROOT, "scripts", "vulture_whitelist.py")
-        cmd = [vulture_exec] + python_files + ([whitelist] if os.path.exists(whitelist) else [])
-        
+    # Ruff (replaces both Vulture and Pylint)
+    ruff_exec = shutil.which("ruff")
+    if ruff_exec:
+        logger.print("   -> Checking for errors and dead code (Ruff)...")
+        cmd = [ruff_exec, "check"] + python_files
         try:
             result = subprocess.run(cmd, capture_output=True, text=True)
             if result.stdout:
-                diagnostics.append("### Vulture (Dead Code & Unused Variables)\n```text\n" + result.stdout.strip() + " ```")
-                logger.print(result.stdout.strip())  # Transparent terminal output
-        except Exception as e:
-            logger.print(f"      [Error running Vulture: {e}]")
-
-    # 2. Pylint (Syntax & Fatal Errors Only)
-    pylint_exec = shutil.which("pylint")
-    if pylint_exec:
-        logger.print("   -> Checking for fatal errors (Pylint)...")
-        # --errors-only prevents style warnings from blowing up the context window
-        cmd = [pylint_exec, "--errors-only", "--output-format=text"] + python_files
-        try:
-            result = subprocess.run(cmd, capture_output=True, text=True)
-            if result.stdout and "Your code has been rated" not in result.stdout:
-                diagnostics.append("### Pylint (Fatal Errors)\n```text\n" + result.stdout.strip() + "\n```")
+                diagnostics.append("### Ruff\n```text\n" + result.stdout.strip() + "\n```")
                 logger.print(result.stdout.strip())  # Transparent terminal output
         except Exception as e:
-             logger.print(f"      [Error running Pylint: {e}]")
+            logger.print(f"      [Error running Ruff: {e}]")
              
     logger.print("✅ Static Analysis Complete.\n")
     return "\n\n".join(diagnostics)
@@ -507,6 +490,7 @@ def check_dependencies():
         "plantuml": "A Java-based tool. See https://plantuml.com/starting",
         "eza": "A modern replacement for `ls`. See https://eza.rocks/install",
         "xclip": "Clipboard utility for Linux. Install with your package manager (e.g., sudo apt-get install xclip)",
+        "ruff": "Fast Python linter. Install with: pip install ruff",
     }
     missing = []
     for tool, instructions in dependencies.items():
(nix) pipulate $

How’d we do? Well, the Prompt Fu process is still working, so not too bad!

Claude Sonnet 4.6: Context verified.

Pretty good! Three of five patches landed. The two failures are both the same root cause — the filename regex in apply.py is too greedy, and it’s eating the markdown bold formatting that surrounds the backtick-quoted filename.

Look at the error message:

❌ Error: Target file 'requirements.in`**' not found.

The regex captured requirements.in\ instead of just requirements.in. That trailing `` is the closing backtick plus the bold marker from **File: \requirements.in`**. The \S+?` in the pattern is matching non-whitespace greedily enough to include those characters.

The current regex in apply.py:

r'(?:(?:File|Target):\s*`?(\S+?)`?\s*\n.*?)?\[\[\[SEARCH\]\]\]\n'

The (\S+?) group matches the filename, but \S includes backticks and asterisks. When the filename appears as `requirements.in` the outer \?` is optional, so the engine sometimes matches the opening backtick as a literal filename character rather than the optional fence.

Two fixes available. The cleaner one is to tighten the filename character class to exclude backticks and asterisks:

Target: `apply.py`
[[[SEARCH]]]
        r'(?:(?:File|Target):\s*`?(\S+?)`?\s*\n.*?)?\[\[\[SEARCH\]\]\]\n(.*?)\n\[\[\[DIVIDER\]\]\]\n(.*?)\n\[\[\[REPLACE\]\]\]',
[[[DIVIDER]]]
        r'(?:(?:File|Target):\s*`?([^`\s*]+)`?\s*\n.*?)?\[\[\[SEARCH\]\]\]\n(.*?)\n\[\[\[DIVIDER\]\]\]\n(.*?)\n\[\[\[REPLACE\]\]\]',
[[[REPLACE]]]

The change is \S+? → [^\s*]+` — match one or more characters that are not backticks, whitespace, or asterisks. This means the filename group will stop cleanly at the closing backtick regardless of what markdown decoration surrounds it.

The three prompt_foo.py patches working correctly is a good sign — those had no backtick/bold decoration around the filename, just Target: \prompt_foo.py`` with a clean closing backtick. The failures were specifically the ones where the bold markers bled into the capture. This fix closes that gap.

MikeLev.in: The patch applied cleanly:

$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   foo_files.py
	modified:   prompt_foo.py

no changes added to commit (use "git add" and/or "git commit -a")
(nix) pipulate $ git commit -am "Preparing to apply another patch to patcher for regex nuance"
[main 2700b24c] Preparing to apply another patch to patcher for regex nuance
 2 files changed, 12 insertions(+), 28 deletions(-)
(nix) pipulate $ git push
Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 48 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 611 bytes | 611.00 KiB/s, done.
Total 4 (delta 3), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
To github.com:pipulate/pipulate.git
   10906a58..2700b24c  main -> main
(nix) pipulate $ xv patch
(nix) pipulate $ cat patch | app
✅ DETERMINISTIC PATCH APPLIED: Successfully mutated 'apply.py'.
(nix) pipulate $ dif
diff --git a/apply.py b/apply.py
index a1287376..d220466e 100644
--- a/apply.py
+++ b/apply.py
@@ -16,7 +16,7 @@ import os
 def apply_search_replace_patch(payload: str) -> bool:
     # Regex to find an optional 'File:' indicator followed by SEARCH/DIVIDER/REPLACE blocks
     block_pattern = re.compile(
-        r'(?:(?:File|Target):\s*`?(\S+?)`?\s*\n.*?)?\[\[\[SEARCH\]\]\]\n(.*?)\n\[\[\[DIVIDER\]\]\]\n(.*?)\n\[\[\[REPLACE\]\]\]',
+        r'(?:(?:File|Target):\s*`?([^`\s*]+)`?\s*\n.*?)?\[\[\[SEARCH\]\]\]\n(.*?)\n\[\[\[DIVIDER\]\]\]\n(.*?)\n\[\[\[REPLACE\]\]\]',
         re.DOTALL | re.IGNORECASE
     )
 
(nix) pipulate $ git commit -am "Better RegEx for patching"
[main b44eca57] Better RegEx for patching
 1 file changed, 1 insertion(+), 1 deletion(-)
(nix) pipulate $ git push
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 48 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 312 bytes | 312.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
To github.com:pipulate/pipulate.git
   2700b24c..b44eca57  main -> main
(nix) pipulate $

And so now we need to start developing our patch hygiene. 3 of 5 patches applied correctly I think, with 2 of 5 still to apply. Which are they? Can you give them to me again?

Claude Sonnet 4.6: Context verified.

The two that failed were requirements.in and flake.nix. Here they are again:

Target: `requirements.in`
[[[SEARCH]]]
# Code Quality
pylint  # Delete after next pip-compile
vulture  # Delete after next pip-compile
ruff
[[[DIVIDER]]]
# Code Quality
ruff
[[[REPLACE]]]

Target: `flake.nix`
[[[SEARCH]]]
          (python312.withPackages (ps: with ps; [
            pylint
            nbstripout
          ]))
[[[DIVIDER]]]
          (python312.withPackages (ps: with ps; [
            ruff
            nbstripout
          ]))
[[[REPLACE]]]

MikeLev.in: Okay, we test:

$ git status
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean
(nix) pipulate $ xv patch
(nix) pipulate $ cat patch | app
✅ DETERMINISTIC PATCH APPLIED: Successfully mutated 'requirements.in'.
✅ DETERMINISTIC PATCH APPLIED: Successfully mutated 'flake.nix'.
(nix) pipulate $ dif
diff --git a/flake.nix b/flake.nix
index 80fb88aa..78e561e2 100644
--- a/flake.nix
+++ b/flake.nix
@@ -179,7 +179,7 @@
         commonPackages = with pkgs; [
           sqlite                       # Ensures correct SQLite library is linked on macOS
           (python312.withPackages (ps: with ps; [
-            pylint
+            ruff
             nbstripout
           ]))
           nbstripout
diff --git a/requirements.in b/requirements.in
index bed09302..9a4055ef 100644
--- a/requirements.in
+++ b/requirements.in
@@ -91,8 +91,6 @@ scikit-learn
 numpy
 
 # Code Quality
-pylint  # Delete after next pip-compile
-vulture  # Delete after next pip-compile
 ruff
 yapf
 isort
(nix) pipulate $ git commit -am "The two last patches applied beautifully"
[main c221140a] The two last patches applied beautifully
 2 files changed, 1 insertion(+), 3 deletions(-)
(nix) pipulate $ git push
Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 48 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 396 bytes | 396.00 KiB/s, done.
Total 4 (delta 3), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
To github.com:pipulate/pipulate.git
   b44eca57..c221140a  main -> main
(nix) pipulate $

That looks pretty good! So what we have left is the terrifying pip-compile process, turning linting on and just continuing to use the system but now with Ruff. This will lead to certain things we silence in pyproject.toml because the decorator and plugin style of programming creates tons of false positives.

Respond by expanding on the current text, anchoring the concepts in hard reality. Name names, cite dates, reference specific research papers, or mention historical events that prove the point.

From Linter Archaeology to Rust-Powered Speed

Use this multi-dimensional structure to deepen the discussion:

1. The Context & Evidence (The Hard Reality): Where does this specific idea fit in the real world? Is it a new breakthrough or an old concept with a new coat of paint? Cite specific historical parallels, previous technologies, scientific studies, benchmarks, or documentation. Teach the audience with facts, not fluff.
2. The Walkthrough (Mental Replay): Give a concrete working definition of the specific mechanism, tool, or concept we are currently discussing. Visualize the exact user experience or technical implementation. What does it feel like to actually execute this? Describe the friction, the “aha!” moment, and the flow to make the abstract entirely concrete.
3. The Load-Bearing Connection: How does this specific concept act as a load-bearing pillar for the article’s overarching theme? Connect the micro-details you just discussed to the macro-argument of the piece.
4. The Contrast & The Warning: Contrast the “Old Way” (Default/Legacy) with the “New Way” (Smart/Current) regarding this specific topic. Then, issue the warning: What is the true cost of doing it the old way? Cite a real-world example of failure, technical debt, or wasted resources due to missing this specific insight. (Remember the banned list above—find a highly specific, lesser-known catastrophe, cost-sink, or architectural dead-end to highlight here).
5. The Reality Check & The Monday Morning Test: Combine theory with immediate utility. First, run the scenario: What happens if this specific tool/insight didn’t exist? Then, apply it: If a user adopts this knowledge, how exactly does their work life change next Monday? Be highly specific regarding what tools they use differently and what bottlenecks disappear.
6. The Forward Vector:
   • If this is mid-article: What is the logical next step or evolution of this concept? Prime the narrative for the next section.
   • If this is the article’s wrap-up: Deliver the final verdict. Is this fuel for the engine or just optional sugar? Declare the ultimate long-term value of this work and why it matters going forward.

7. The Sign-Off Charm (Surprise & Anticipation): Break away from the clinical analysis and speak directly, warmly, and informally to the reader to wrap up the prompt. Share a genuine analytical reaction: What specifically surprised you most when analyzing this particular aspect? What do you anticipate happening next in this space? Introduce net-new insights here, avoid any repetition from earlier in the chat, and have fun delivering the analysis. Inject personality and intellectual curiosity.

Claude Sonnet 4.6: All five patches landed. The Ruff migration is complete.

Now you’re asking me to expand the article with a structured deep-dive. Here goes.

---

The Hard Reality of Linter Archaeology

Pylint was released in 2003 by Sylvain Thénault at Logilab. Vulture came later, circa 2012, solving a narrower problem: finding dead code that pylint’s scope analysis missed. For two decades this was the Python linting stack — run pylint for errors, run vulture for cleanup. The combination worked, but carried a hidden tax: two separate tools, two separate configuration files, two separate sets of false positives to silence, and two separate maintenance burdens every time a new Python version shipped.

Ruff, first released by Charlie Marsh in 2022, is written in Rust and consolidates both jobs plus about 700 additional lint rules into a single binary. The headline benchmarks are striking — Ruff runs roughly 100x faster than Pylint on the same codebase. But the speed is almost beside the point for a project like Pipulate, which rarely runs linting on a hot path. The real win is conceptual compression: one tool, one config section in pyproject.toml, one mental model.

The Walkthrough

Here’s what the transition actually feels like. You run rg pylint and rg vulture across your codebase. You find the references — requirements files, flake configurations, pyproject.toml, and the linting runner in prompt_foo.py. You write five SEARCH/REPLACE patches. Three apply cleanly on the first try. Two fail because the regex in your patcher chokes on markdown bold decorators around the filename. You fix the regex. You re-run. Five for five. Total elapsed time: one focused session.

That’s the rhythm of ELTGD. The blast radius was defined (five files), the chisel strikes were enumerated (five patches), and each strike was either confirmed or debugged in seconds via dif. No merge conflicts. No cascading breakage. No wondering what changed.

The pip-compile step is the one that produces mild dread because it’s the least deterministic part: you’re asking the dependency resolver to rebuild the full locked requirements graph with pylint and vulture removed. If something in the transitive dependency tree depended on either of those, the resolver will surface it. In practice, neither pylint nor vulture are library dependencies — they’re dev tools — so the compile should be clean. But you run it anyway because the alternative (not running it) means your requirements.txt diverges from your requirements.in, and eventually that divergence causes a production surprise.

The Load-Bearing Connection

This migration is not really about Ruff. It’s about the principle that every tool in your stack should earn its place by being irreplaceable in its category. Pylint earned its place in 2003. In 2026, it no longer does — not when Ruff exists. The NPvg stack is anti-obsolescence by design, which means actively pruning tools that have been superseded, not just adding new ones. Local-first only stays lean if you treat the codebase as a living thing that requires regular gardening, not just growth.

The Contrast and the Warning

The old way: two linters installed, two slow invocations, two configuration surfaces to maintain, and the cognitive overhead of knowing which tool catches which class of problem. The subtle failure mode here isn’t a dramatic crash — it’s slow accumulation. Teams that don’t prune tooling end up with CI pipelines that run five minutes of linting instead of thirty seconds, developers who skip the linting step locally because it’s too slow, and eventually a linting configuration that nobody trusts because nobody maintains it.

The lesser-known cautionary tale here is from the Node.js ecosystem, not Python: JSHint, JSLint, ESLint, and TSLint all coexisted for years. Projects that started in 2014 with JSHint often never migrated. By 2020 they were running deprecated tools, missing entire categories of modern JavaScript errors, and unable to use new lint rules because their toolchain predated the plugin architecture. The cost wasn’t paid in one dramatic incident — it was paid in thousands of small friction events where developers couldn’t get useful feedback from their tools.

The Reality Check and the Monday Morning Test

Without Ruff: you’d still have pylint and vulture installed, still running slowly, still generating false positives that you’ve learned to ignore. The context window you feed to AI assistants would still contain references to two tools instead of one. The run_static_analysis function would still have two code paths, two error handlers, a whitelist file to maintain for vulture’s false positives.

With Ruff, starting Monday: one command in pyproject.toml to configure lint rules, one invocation in the static analysis runner, and the eventual ability to turn ENABLE_STATIC_ANALYSIS = True without dreading the output. Ruff’s error messages are also significantly more actionable than pylint’s — they include the rule code, a brief description, and often a suggested fix. When you eventually feed ruff output into an AI context window, the signal-to-noise ratio is dramatically better.

The Forward Vector

The immediate next step is the pip-compile run to get requirements.txt back in sync, followed by a nix develop cycle to confirm the environment builds cleanly. After that, the question is whether to flip ENABLE_STATIC_ANALYSIS to True. That’s where the pyproject.toml configuration work lives — deciding which of Ruff’s 700+ rules to enable, which to ignore, and which to mark as fixable automatically with ruff check --fix. The decorator-heavy FastHTML patterns will almost certainly trip rules about unused imports or unexpected argument shapes that are actually intentional. Those get silenced with inline # noqa: RULExxx comments or global ignores in pyproject. That configuration work is itself a SEARCH/REPLACE session, and the patcher is now reliable enough to handle it.

The Sign-Off

What genuinely surprised me analyzing this session: the patcher patching itself. The fourth patch in the sequence was a fix to apply.py so that apply.py could correctly apply patches two and five. There’s something deeply satisfying about a system that can bootstrap its own correctness — especially when the mechanism is this transparent. You can read every line of the regex change and understand exactly why it works.

What I anticipate next: once ENABLE_STATIC_ANALYSIS goes to True and you start seeing Ruff’s output in your AI context windows, you’ll want to selectively suppress rules rather than turn the whole thing off. The # noqa comment workflow integrates naturally with the SEARCH/REPLACE patching system — ruff tells you the rule, you write a targeted patch to silence it or fix it, and the patcher applies it. That feedback loop is the endgame: not vibe-coding, not autonomous agents, but a tight human-in-the-loop cycle where every change is legible, reversible, and documented in the git log.

The Final Verdict: Bootstrapping System Correctness

MikeLev.in: Claude kicked Gemini’s butt on several fronts here. But it was mostly presentation-layer related. Markdown backtick inception, if you will. It’s a bit hard to understand because it requries recursive groking. Claude did. Gemini didn’t.

---

Book Analysis

Ai Editorial Take

This entry highlights a fascinating emergence of ‘Narrative-Driven Development.’ The author uses the act of writing the article to provide the logical constraints and ‘mental warmup’ that force the resulting code to be cleaner. Most striking is the ‘Bootstrap Patch’—where the author uses a slightly broken version of the patcher to apply a fix to the patcher itself. It illustrates a rare level of confidence in deterministic systems where the human, the script, and the AI act as a unified, self-correcting unit.

🐦 X.com Promo Tweet

Watch the 'Every Little Thing Gets Done' methodology in action as I migrate from Pylint to Ruff using an AI-powered patching system. This is about anti-obsolescence and local-first development in the Age of AI. Read the full technical treatise: https://mikelev.in/futureproof/migrating-to-ruff-ai-patching/ #Python #NixOS #AI #ELTGD

Title Brainstorm

• Title Option: Migrating to Ruff: A Case Study in AI-Powered Patching and the ELTGD Way
  • Filename: migrating-to-ruff-ai-patching.md
  • Rationale: Directly addresses the technical core (Ruff/AI Patching) while introducing the unique philosophical framework (ELTGD).
• Title Option: The ELTGD Philosophy: Pruning Technical Debt in the Age of AI
  • Filename: eltgd-philosophy-pruning-debt.md
  • Rationale: Focuses on the high-level methodology of managing complexity and technical debt with AI assistance.
• Title Option: Backtick Inception: Wrangling LLM Formatting for Deterministic Code Edits
  • Filename: backtick-inception-llm-formatting.md
  • Rationale: Highlights the specific, interesting challenge of using AI for code modification—the ‘backtick inception’ problem.

Content Potential And Polish

• Core Strengths:
  • Deeply technical yet grounded in personal history and philosophy.
  • Demonstrates a functional, repeatable workflow (apply.py) rather than just theory.
  • Transparently shows the friction and debugging process of working with different AI models (Gemini vs. Claude).
• Suggestions For Polish:
  • Clarify the ‘ELPGD’ vs ‘ELTGD’ distinction earlier for readers unfamiliar with the acronym evolution.
  • Include a brief link or reference to the ‘apply.py’ source code for readers wanting to implement the patcher themselves.

Next Step Prompts

• Analyze the current pyproject.toml configuration to determine which Ruff rules to silence for a FastHTML/HTMX project, providing a SEARCH/REPLACE patch for the updates.
• Refine the apply.py script to handle multi-file diffs in a single pass while maintaining the deterministic regex safety established in the latest update.