gedankenexperiment / philipp warmer
sign in contact

Gedankenexperiment Snippets

Prompt and pray

Text is the new code and skills are the new programs. Code got an IDE to read it. Skills are still edited in a plain text editor.See loopsie →

Snippet · August 2026

Read one prompt and you understand all of it at once: a few lines of text, saying plainly what they want, legible on a single screen. A skill is a folder of them. It holds an instruction file, a settings file the instruction points to by name, and a script that checks the result. Every file still reads clearly on its own, and the thing they add up to does not.

Text is the new code, and a skill is the new program. The parts stay legible one at a time. The behaviour lives in how they call each other. Prose runs in one dimension, so every relation that is not adjacency has to travel as a cross-reference. The loop and the branch are both in the folder, and neither one is drawn. So you author it, install it, trigger it, and read the output to find out what it actually did. That is prompt and pray.

If text is the new code and skills are the new programs, what is the new IDE? Code went through this already, so start there.

Code is text too, it stayed text, and what it evolved on top of the text was a view. That view is the IDE, and reading a composition is the job it does. A codebase with many files, functions, classes and dependencies is hard for reasons that have nothing to do with any one function, and a skill folder is hard the same way. The answer was a set of instruments: go to definition, find references, call hierarchy, a debugger that halts mid-execution and shows the stack. Every one of them makes the composition visible while leaving the code exactly as complex as it was.

TODAY · SKILL AS PROSE CODE · WHAT THE IDE ALREADY GIVES YOU NEXT · SKILLS IN AN EDITOR SEE LOOPSIE → critique/SKILL.md When a claim comes in, argue for it first, using the strongest version of the case rather than the one the reader gave, then argue against it the same way. If either side comes out thinner than the other, argue that side again, up to three rounds, unless the thin side is thin because the claim is weak, in which case let it stand. Contrast the two structurally, claim against claim, except where one side rests on a fact the other disputes, and settle that fact first. Then synthesise a position, which is neither a summary of both sides nor a midpoint between them, and raise nothing neither side raised. knobs.md Three rounds. A side counts as thin when it carries fewer distinct claims than the other, though claims that restate each other count once. Balance is judged as in SKILL.md. gate.sh Renders both arguments and prints one balance score. Exits non-zero when either side comes back empty. Three files. Flat prose, exceptions everywhere. You find the mistake by running it. 2 references 123 456 789 10 def critique(claim): -> Position pro = con = None for i in range(ROUNDS): pro = argue(claim, FOR) con = argue(claim, AGAINST) if contrast(pro, con).balanced: break return synthesise(pro, con) syn synthesise(pro, con) contrast(pro, con) → bool knobs.ROUNDS → 3 Folding, scope guides, diagnostics, definitions, completion. You find the mistake before running it. used in 3 skills 123 456 steelman · pattern -> Position CLAIM ARGUE FOR ∥ ARGUE AGAINST CONTRAST retry ×3 SYNTHESIS add step cite-check · gate map-over-claims · pattern human-review · gate Folding, parallel steps, diagnostics, usage counts, completion. You compose from parts the tool can name.
One rule, three views. Code got the middle one.

The problem is the same one. Highlight the composition while it is being written. Show the steps and the order they feed each other in. Show the two that run independently, and the file nothing reaches. Put the prose on the left and the structure on the right, and the gap between what you meant and what you wrote becomes something you can point at.

The analogy stops in one place. A function executes the same way every time, while a skill routes on the input, so a drawing made before the run can only show what could happen. How much that leaves out is the part I am least sure of.

Every file in a skill can be read in a minute. The composition of those files is what needs an instrument.

Editors came first, then debuggers, then profilers, each arriving when composition outgrew what one person could hold in their head. Skills are at that point now, with tooling about where code was when people started drawing call graphs. Text became the new code before anything was built to read it that way, and closing that gap is the whole of the work.

Gedankenexperiment · Zurich