Colas.Nahaboo.net - ai

Bug reports: Favoring Prompt Requests over Pull Requests

2026-08-15T00:00:00+00:00

More and more often, I find a bug in some code that is not mine — often in a language or codebase I barely master. My reflex used to be to hack a fix anyway and send a pull request. But recently I spontaneously began to do the opposite: I let an AI agent fix the bug on a local copy, and instead of a pull request, I submitted the prompt I used — the one that seemed to fix the issue for me, passing the tests. An evolution of my AI without AI?

I did this twice, recently: for the Apollo Zola theme and the Openfox AI harness.

Which prompted me to wonder whether this practice already had a name. I found the CodeRabbit post on prompt requests, which was right on the spot, but nothing else. Hence this post, to draw attention to the matter.

What?🔗

The idea, in short: when you find a bug in a project, and you use an AI coding agent to fix it, do not submit the AI-generated pull request. Submit the prompt you used to fix the bug, with a comment that it seems to fix the bug on your setup, and passes the tests. Plus an overview of the useful info your AI investigation produced: the root cause analysis, the edge cases, the alternative paths tried.

The maintainers can then run the prompt themselves, in the harness and the LLM they are comfortable with — not the one you happened to have at hand — refine it, grill the AI with a grill-me style interrogation, and adjust it to their codebase. Instead of having the pain to review an unfamiliar PR.

This is not my invention, the name already exists: prompt requests. The CodeRabbit article traces the idea to a debate between Peter Steinberger, creator of the self-hosted AI agent Clawdbot, and Gergely Orosz of Pragmatic Engineer. At first I was going to call it "PS" for Prompt Suggest, but let's not reinvent the wheel.

Why?🔗

Maintainers are drowning in PR slop: AI-generated code that compiles, passes CI, and is utterly wrong for the codebase — style drift, redundant helpers, subtle architectural shortcuts. The asymmetric velocity problem: an agent generates code in seconds that takes a human hours to review.

The numbers are staggering: GitHub merged pull requests went from 25 million a month in January 2023 to 90 million a month in March 2026. A 3.6x increase, in an era where the number of human developers did not triple.

The most spectacular example was the 13,000-line AI-generated pull request on the OCaml compiler, rejected by the maintainers, who cited the lack of review resources. The author, Joel Reymont, had "carefully shepherded AI over the course of several days", and, asked why some files credited a maintainer as author, answered "Beats me. AI decided to do so and I didn't question it."

This is so bad that GitHub now lets maintainers disable pull requests entirely, or restrict them to collaborators. Open source projects are starting to close their front door rather than drown.

The root problem: code is now cheap. As Jeremiah Lowin writes in An Open-Source Maintainer's Guide to Saying No: "Historically, we could assume that since writing code is an expensive, high-effort activity, contributors would engage in discussion before doing the work. Today, LLMs have inverted this. Code is now cheap, and we see it offered in lieu of discourse."

Which prompted me to think: if the code is the cheap part, then the value of my contribution is not the diff — it is the investigation. The bug I found, the root cause my AI uncovered, the proof that a fix exists and passes the tests. And the prompt, which is the recipe to reproduce the investigation.

How?🔗

So here is what I think I will put from now on in a bug report instead of a pull request:

**Bug**: [short description, with a reproduction]
**Prompt** (tested, fixes the bug on my setup, tests pass):
  > [the exact prompt(s) I gave to the agent]
**Harness / model**: opencode / DeepSeek v4 flash (or Claude Code / ...)
**Root cause**: [what the AI found]
**Edge cases**: [what the AI's analysis surfaced]

The exact prompt is the key: like a minimal reproduction, it lets the maintainer run the fix in his environment — the harness and model he trusts, in the context of his codebase. He can refine it, ask the AI questions, interrogate it about edge cases. I have a grill-me skill in my own setup, I know it works :-)

Why do maintainers should like it?🔗

No trust question: the code is generated in the maintainer's own sandbox, by his own model, with his own system prompts. The question is no longer "do I trust this stranger's code?" but "does my setup produce a good fix for this prompt?"
Architecture control: the generated code follows the codebase conventions, because it is generated in the codebase.
The maintainer stays the author: he is not inheriting 800 lines of alien code, he is applying an insight to his own project.

And the contributor still gets the satisfaction of having found and fixed the bug — which is the valuable part anyway.

Am I reinventing the wheel?🔗

Partly. The CodeRabbit article is more cautious than me: it argues prompt requests and pull requests are not in conflict, and prompt requests work best before pull requests — review the intent before generating, then still review the code that ships. That makes sense within a team, where you will have to maintain the result, and where determinism, git blame and accountability matter.

My point is narrower, and for a different case: the drive-by contribution. When you fix a bug in a project that is not yours, and you have no intention to maintain the result — which is most bug reports — the prompt is a better unit of exchange than the diff. It is the AI without AI of bug fixing: I provide the prompt, you run it in your own wetware (or your own GPU).

There are cases where a PR is still better: the trivial one-line fix, the case where you will maintain the fix, or the project that explicitly asks for PRs. Use your judgment.

So, next time your AI agent fixes a bug in somebody else's project: resist the urge to git push. Open an issue, and give the maintainers the prompt. They will be grateful, and the code will be better for it.

Maybe a modern twist on the old saying "dont give fishes, show how to fish".

AI without AI

2026-08-08T00:00:00+00:00

Generative AI is currently morally bad, as most of it steals copyrighted works — but it would still be useful for people like me with no drawing skills. So I am increasingly using "AI without AI".

That is, I just post the prompt I would have used with a generative AI, and let the reader use his own wetware (aka "Brain") — the NI (Natural Imagination) — to visualize the picture.

As an example, in a reply to John Scalzi's post on Bluesky I described the book cover instead of generating it via AI:

And for some AI-without-AI, here is the prompt to generate the cover in your own wetware (aka "Brain"): «A book cover for the next Sci-Fi humoristic novel of the fictional author John Barefoot titled 'The Brother Laser Printer Aficionados'»

The nice thing about running prompts on your wetware is that the model is local, free, and the output stays in your head. No credits, no seed, no style references, infinite resolution, perfect privacy. It renders instantly — the only downside being that nobody else gets to see the result.

Also, it is something that has bothered me for a long time. As a boy, I was struck that during his famous 65-day survival drift across the Atlantic Ocean in 1952, narrated in his book Naufragé Volontaire, French physician and adventurer Alain Bombard — aboard his boat l'Hérétique — took only a few personal items, including a pocket score of Beethoven's string quartets (specifically the 15th String Quartet in A minor, Op. 132) alongside Bach's Passions. He recounted that studying and mentally playing this complex music helped keep him sane and motivated during extreme isolation and hardship.

I loved listening to Beethoven, but I could not fathom somebody actually "listening" by merely reading the score. It turns out he was doing AI-without-AI, ... decades before AI.

Migration of this site to the new Zola Tera2

2026-08-06T00:00:00+00:00

I migrated this site to Zola 0.23, released yesterday with the new Tera 2 template engine (Well, 0.23.1 from today actually). When I chose Zola last March, I praised its creator for not chasing the latest fad. I stand by it: 0.23 breaks my templates, but it does it in a cleaner way.

Tera 2 removes the old macros and imports, and Zola 0.23 removes the shortcodes. Everything is now a namespaced component. A macro that I used to import and call like this:

{% import "macros.html" as utils %}
{% macro show_link(url) %}<a href="{{ url }}">{{ url }}</a>{% endmacro %}
...
{{ utils::show_link(url=link) }}

is now a global component with no import at all:

{% component site.show_link(url) %}<a href="{{ url }}">{{ url }}</a>{% endcomponent %}
...
{{<site.show_link url={link} />}}

The big philosophical change: components are global and no longer inherit the caller context. Every variable — page, section, config, current_path — must be passed explicitly as an argument. More verbose, but it makes dependencies visible. I like that more and more: one way to do it, and it is visible.

Tera 2 is also strict: a missing variable is now a hard error. My templates use optional chaining (?.) for anything optional, which catches typos at build time instead of silently rendering broken pages.

What concretely changed:

concat and slice filters are gone → array spread and slicing
get_env is gone → config.mode == "serve" for local editor links
include ... ignore missing is invalid → empty hook templates
get_page with fatal=false → canonical path with lang and allow_missing=true
get_taxonomy_url with name → term

The migration guide was my best map through all of this.

I use the Apollo theme as a git submodule, and as it does not support Zola 0.23 yet, I keep a small local template-only patch of it until upstream migrates. The design, CSS, and JavaScript are untouched: this was a syntax migration, not a redesign, and I did not rewrite my post contents either.

Use of AI🔗

I chose to have AI help me migrate my site. It worked flawlessly, so I encourage you to do the same. AI work especially well with Zola, as it is opinionated, and that means that there are clear ways of doing things so that AI agents do not get lost in rabbit holes trying to pursue all the possibilities of more flexible systems like Hugo.

For reference here is the first prompt I gave it to prepare the plan for the migration:

I want you to only create a document for agents ai/agents/tera2.md to summarize
how tera2 of Zola 0.23 differs from tera1 of Zola 0.22, and the plan to migrate
my site from Zola 0.23 to 0.22.

Examine the differences between Zola 0.22 and 0.23, not just tera.

Docs:
Tera2 https://keats.github.io/tera/
Migration guide Tera1 → Tera2 https://github.com/Keats/tera/blob/master/MIGRATION.md
Zola 0.23 docs https://www.getzola.org/documentation/getting-started/overview/

Take your time, be thourough, but do not modify yet any file of my site except
the ones in ai/agents/ and AGENTS.md

Then, plan the migration of this site to zola 0.23
1. not modifying the contents of the posts unless necessary for tera2 changes
2. not changing the look and feel, the UI of the site
3. adapting the various templates
4. changing my local copy of the Apollo theme I use if needed.
   These changes are a stopgap measure until upstream apollo is migrated to Zola 0.23

I use Deepseek v4 flash normally, but chose to use GPT-5.6 Luna for this migration as it is currently quite cheap and I trust it more to not go change unecessary files. And Deepseek as no vision, so it cannot check the actual visual results of changes. It helped me greatly for this migration, without any problems.

Summary of AI actions:🔗

Replaced Tera 1 macros, imports, self:: calls, and macro namespaces with namespaced Tera 2 components in the root templates and Apollo templates.
Converted the local language-listing, page, navigation, debug, file inclusion, and section-name helpers to components.
Converted the site shortcode implementations to components in templates/macros/shortcodes.html.
Converted active post calls from the removed Zola shortcode syntax to Tera 2 component syntax. This includes YouTube, snapshots, attachments, Mermaid, static-file inclusion, legacy overlays, obsolete notices, and SVG icons.
Passed explicit base_path values to components that used to receive page.path implicitly from Zola shortcodes.
Updated get_page calls to use the canonical path with lang="fr" and allow_missing=true.
Updated get_taxonomy_url calls from name to term.
Replaced the removed get_env call with config.mode == "serve" for the local editor links.
Replaced the removed concat and slice filters with Tera 2 array spread and slicing, and changed the object test to map.
Added empty Apollo hook templates because Tera 2 no longer accepts include ... ignore missing.
Updated dev/bin/site-check to recognize the new legacy component syntax.
Updated static/ZOLA to zola 0.23.0.