Prose forgives you. You can write a sentence that is roughly right, keep going, and fix it later — in fact that is the only way anyone finishes anything. Getting it approximately down and improving it on the second pass is the method.
Code does not work like that. A command is right or it is not, and "roughly right" is the failure mode that costs you an hour, because it looks correct and does something else.
These are two different postures. Most of us hold both in the same working day, often within the same task, and the moving between them is where the day quietly leaks.
The switch is not the two seconds it looks like
Say you are writing up a process and you need the exact command. You switch to the editor to get it.
The two seconds are not the cost. The cost is that the editor is full of other things — a file you had open, a diff you had not finished reading, an error in the terminal below it. You went in with one narrow errand and arrived somewhere with its own agenda. Twenty minutes later you are doing something legitimate and it is not what you were doing.
The other half of the cost runs the opposite way, and it is subtler. Because getting the snippet is annoying, you do not get it. You write "run the usual deploy command" and move on. The document survives; the useful part of it does not. Then the version of you who reads it in March has to reconstruct what "usual" meant.
Why the mode shows up in the typing itself
The two modes are not just a state of mind — they disagree about what should happen when you press a key.
In prose mode you want the software helping. Straight quotes becoming curly ones, a list continuing itself, a heading formatting as you type. This is invisible and correct, and you would miss it immediately if it stopped.
In code mode every one of those is sabotage. The curly quote breaks the command. The list continuation mangles the indentation. A "helpful" capital at the start of a line changes what a case-sensitive flag means. Exactness needs an editor that does nothing you did not type.
This is why the two live in different applications for most people — not because anyone chose that, but because one text box cannot do both. If you want the underlying argument for why one app can hold both anyway, that is a separate piece. What follows assumes you have somewhere for both and is about how to arrange them.
Keep the artefact next to its explanation
The single most useful arrangement is also the least clever: whatever you write about the thing should sit next to the thing itself.
A runbook is a prose note. Each command it depends on is its own code note, linked from the runbook with [[. The runbook explains and links; the code note is the exact text and nothing else. Because the link shows up from both ends, the snippet knows which document it belongs to — so when you find it in six months, it comes with its reason attached.
That solves the failure mode where the explanation and the artefact drift apart. They can still drift, but the moment you notice, they are one click from each other rather than two apps apart.
Practically, in Cyanote, that is ⌘N for the prose note and ⇧⌘N for the code note, [[ to link them, and ⌘S in a code note to save it back to a real file on disk if the text is also live configuration somewhere. ⌘K reaches any note by name and ⇧⌘F searches inside all of them at once, so the retrieval end does not depend on your having filed anything correctly.
Make the mode visible before you read a word
A small thing with a return out of proportion to the effort: set the code notes in monospace and leave the prose notes in whatever you write in. Typeface, size and line spacing are per-note settings, so this costs nothing after the first time.
The point is not aesthetics. It is that you can see which mode a note is in before you have read a word of it — and so you arrive already in the right posture instead of adjusting halfway down the page. The rest of what is worth setting is mostly about reading comfort; this one is about attention.
Batch the modes when you can
The cheapest switch is the one you do not make. Two habits do most of the work here.
Write first, verify second. Draft the whole document in prose mode, leaving a marker wherever an exact value goes. Then do one pass collecting every exact value at once. One switch instead of nine, and the writing keeps its momentum, because it was never interrupted to go and fetch a flag.
Capture snippets when you are already in code mode. The moment to save a command is the moment it finally works — not later, when you are writing the document, because by then you are in the wrong mode and you will paraphrase it instead. A working command and a sentence about what it does, saved at the moment of relief. That sentence takes eight seconds and is the entire difference between an archive and a junk drawer.
If you keep a lot of things this way, the clipboard is the other half of that story: the pinned snippet and the copy history catch things you have not decided to keep yet.
When you should absolutely switch apps
Do not take any of this as an argument for working in one window.
When you are actually building — running things, reading errors, moving between files, using git — go to a real editor and stay there. That is code mode at full depth and a notes app has no business in it. There is no debugger here, no terminal, nothing to run, and pretending otherwise would waste your afternoon.
The arrangement above is for the other thing: the writing that surrounds the work. Runbooks, decisions, how the thing is configured and why, the fragments you will need again in a context you cannot predict. That work is mostly prose with exact bits embedded in it, and it is the work that gets abandoned when the two halves live in different buildings.
The honest version
If your working day is entirely one mode, this is not a problem you have. A writer with no snippets and an engineer who never writes anything down are both well served by one good app and no thought about it at all.
The switching cost is worth attention when the two are genuinely interleaved — when the document you are writing is about a system, and half of what makes it useful is text that has to be exact.
Cyanote holds both kinds in one window, on one Mac, in one local database, for $10 once. It has no sync and no mobile app, so if the runbook needs to be readable from a phone at 3am, this is the wrong tool and you should know that before you pay rather than after.