Skip to content

Prompt Request over Pull Request

peter-steinberger's workflow framing: when another agent operator sends you a pull request, what you actually want is the prompt that produced it — so you can re-run it against your own agent, tuned to your own style, on a current checkout.

The Peter version (stronger)

"I no longer need your code. Just send me the prompt." Rationale: code written by someone else's agent against their codebase is stylistically foreign, probably stale, and cheaper to regenerate than to merge. The prompt is the reusable artifact; the code is a disposable instantiation.

The Armin version (weaker, partially disagreeing)

Armin pushes back:

"It's not just a prompt. I actually value seeing a terrible implementation of something. If I get a pull request, even if it's terrible, it clarifies what someone wanted to build — and I don't need to waste my own time trying that out."

The terrible implementation is informative because it pins intent cheaper than the prompt does. Somebody else's naïve agent-produced code is a cheap spec, not a merge candidate.

Mario's position (synthesis)

Similar to Armin — values the pull request as an intent artifact, not a deliverable. "It's less about 'I want to see the prompt' and more 'what is it supposed to be doing' — once we understand that, it's probably faster for me to start from scratch." The PR functions as specification-by-example.

Why this is actually the same point wearing different clothes

All three agree on the underlying dynamic: the code artifact is the cheapest part of the exchange, the intent is the expensive part. They disagree on which medium (prompt vs. reference implementation) communicates intent most efficiently. Armin + Mario think a reference impl is cheaper to read than a prompt; Peter thinks the prompt is cheaper to run than the impl is to merge. This is a difference of taste about how to transmit intent, not what to transmit.

Connects to