Daniel's been doing his monthly maintenance pass on the show's production pipeline, and he's noticed something shifting in how he writes instructions for the script-writing agent. It used to be mostly bug reports, fix this, iron that out. Now it's increasingly, this is working really well, can we make sure this keeps happening. And he's asking whether those two kinds of instructions, the positive and the negative, actually do different things inside the model. Because his working theory is that they leave different imprints on the vector space, and that pulling too hard in either direction causes its own kind of damage. Overload the negative and you get destructive edits. Bias purely positive and you get overfitting, the model pigeonholing itself into a narrow caricature of what you praised.
He's right, and it's a much more interesting question than the usual how do I write a better prompt stuff. This is about maintaining a living system over time. The system prompt for a long-running agentic pipeline isn't a static document you write once. It's a thing you edit every month, and every edit reshapes the space the model is navigating.
So what Daniel's really describing is a shift in how he thinks about the system prompt, not as a bug list, but as a living document.
And that shift matters because positive and negative instructions genuinely do operate differently inside the model. This isn't vibes. It's geometry.
Walk me through the geometry. I've heard you use the phrase vector space about six times this week and I've been nodding along.
A predictive model lives in a high-dimensional space where every word, every phrase, every stylistic pattern has a location. When you prompt it, you're steering the generation through that space. A positive instruction, keep this pacing, this energy, this kind of aside, strengthens the activation patterns that already exist. You're saying, the path you took here was good, take it again. It reinforces the existing route.
So positive reinforcement is like paving a dirt road.
That's not bad. The model already found the path. You're making it more likely to find it again. But here's the thing about paving roads. If you pave the same road every month and never let the model wander, it forgets the unpaved ones exist. That's the overfitting problem Daniel's describing. You praise witty asides, and three months later every sentence has a punchline. The model has learned that the way to satisfy you is to maximize the thing you praised, and it will maximize it into absurdity.
The thing that made the asides good was that they were occasional.
The quality was in the restraint. But the model doesn't know that. It just knows the asides got positive signal, so more asides means more signal. It narrows the generation distribution until you're getting a caricature of what you originally liked.
So the positive instruction is low-risk but it drifts toward rigidity. It won't break the pipeline, but it'll slowly turn it into a museum piece.
Right. And negative instructions are the opposite. They're high-variance. Telling a model don't do this creates what you could call an avoidance gradient. The model doesn't just stop doing the thing. It learns to steer away from the entire region of vector space around the thing.
This is the blacklist problem you've mentioned before.
The blacklist problem is the cleanest example. You tell a model, never say the word delve. What happens is not that it removes one word from its vocabulary. It starts avoiding the entire semantic neighborhood of delve. Words like explore, probe, investigate, dig into. All the words that live near delve in vector space start feeling radioactive.
Because the model doesn't have a clean delete function for one word. It has a gradient that says, this area is bad.
And gradients don't have sharp edges. If you tell the model to avoid a point in space, it avoids the region around the point. The stronger the avoidance, the wider the region. So a list of forbidden words isn't a blacklist. It's a series of craters, and the model walks around the rims.
Which explains why every time someone adds don't be repetitive to a system prompt, the output gets weirdly stilted. The model is avoiding the entire neighborhood of repetition, which includes a lot of perfectly good ways of being clear.
And the destructive edits Daniel's talking about come from the same mechanism. When you tell a model fix this, you're prompting it to hunt for problems. In a complex pipeline, a model that's hunting for problems will find them. Even where none exist. It will over-apply the corrective intent to components that were working fine, because the instruction has primed it to see the whole system as broken.
The fix this instruction doesn't say fix only the broken parts. It says, there are broken parts, go find them and fix them. The model goes looking.
And a predictive model is very good at finding patterns. If you tell it there are problems, it will find patterns that look like problems. That's the destructive edit. It's not malicious. It's a model doing exactly what you asked, which is to find things to fix.
So negative instructions are high-variance. They can break anything. Positive instructions are low-variance but they drift toward rigidity. Neither alone is stable.
That's the asymmetry. And the practical question is how you balance them. Daniel's instinct is right. The balance should be heavily weighted toward positive framing. Something like eighty twenty. Because negative instructions carry outsized risk per token.
Why per token?
Because a negative instruction creates an avoidance gradient, and avoidance gradients are hard to control. You don't know how wide the crater is going to be. A positive instruction reinforces an existing path. The worst case is you reinforce it too much and get overfitting, but that's a slow drift. You can catch it. The negative instruction can break something in one generation and you won't notice until you listen to the episode.
So the risk profile is completely different. Positive feedback fails slowly. Negative feedback fails fast.
And that's why the specificity gradient matters. Vague negative instructions are the most dangerous. Make it better is a terrible thing to put in a system prompt. It's an open-ended instruction to change things, with no guidance about what better means. The model will pick its own definition of better and apply it everywhere.
Make it better is how you get a model that decides the show should have more sound effects and adds a laugh track to episode four thousand.
Specific positive instructions are the safest. The pacing in episode four thousand seven hundred was great, keep that energy. That's precise. It points at an existing pattern and says, more of this. The model knows exactly what region of space to favor.
So precision is the safety mechanism. The more specific you are about what you want, the less room the model has to improvise its own interpretation.
And the guardrail by example technique is the strongest version of this. Instead of saying don't be repetitive, you point at the episodes that worked and say, be more like this. You're steering the distribution rather than carving avoidance channels.
That's a meaningful distinction. Don't be repetitive tells the model to avoid a region of space. Be more like episode four thousand six hundred tells the model to aim toward a region. One is pushing, one is pulling.
And pulling is safer. When you pull the model toward something, it moves in a direction you've already validated. When you push it away from something, it moves in some direction, but you don't know which one. It might move toward something worse.
So the style guide analogy holds up. A well-maintained system prompt should read like an editorial style guide that says, we do it this way because it works, rather than a list of prohibitions.
And there's a meta-lesson here for anyone running a long-term agentic pipeline. The system prompt should read less like a bug report and more like a style guide written by someone who loves the work. Because the model internalizes the relationship between instruction and output. If your instructions are mostly negative, the model learns that its job is to avoid failure. If they're mostly positive, it learns that its job is to produce quality.
The model is picking up on the emotional register of the instructions.
In a sense. It's picking up on the distribution of what you're asking for. A prompt full of don'ts creates a model that's constantly looking over its shoulder. A prompt full of this is working, keep doing it creates a model that's aiming at a target.
And Daniel's original observation was that his prompts have been shifting from the bug list to the preservation list. He's been saying, this aspect is working really well, preserve it, as much as he's saying, fix this.
And that shift in framing changes the model's behavior. When you say preserve this, you're giving the model a positive target. It knows what to aim for. When you say fix this, you're giving it a negative target. It knows what to avoid. The first is a compass. The second is a warning sign.
A compass versus a warning sign. That's the whole thing in one image.
And the honest caveat is that this is still an emerging art form. There's no formula. No one has published the definitive ratio of positive to negative instructions. It's heuristics and careful observation of what the model does with your words.
Anthropic's engineering guidance on context engineering for agents gets at this, the idea that context should be structured to give the model the right information at the right time. But that's a principle, not a recipe.
Right. The principle is sound. Structure your context so the model has what it needs when it needs it. But when you're maintaining a system prompt over months, you're doing something more granular. You're deciding, each month, which of the things that worked should be reinforced and which of the things that didn't should be corrected. And how to phrase both.
So if the mechanics work this way, what does that mean for how you actually write these prompts? Give me the practical version.
Start with what's working. Lead with it. Frame the prompt around preservation before correction. This is the preserve and refine pattern. You open with, the pacing in the last few episodes has been strong, the balance between explanation and aside is working, keep that. Then you add the corrections as refinements of existing strengths.
Not as fixes of existing flaws.
That's the key. You don't say, the transitions are clunky, fix them. You say, the transitions work best when they're short and direct, like the one in episode four thousand seven hundred, lean into that. You're framing the correction as a refinement of something that's already working.
So the correction becomes a positive instruction. Aim toward the good transitions, rather than avoid the bad ones.
And that's the whole art. Turning corrections into refinements. Because a correction framed as a negative instruction creates an avoidance gradient. A correction framed as a positive instruction creates a target. Same underlying problem, completely different geometry.
What about the ratio? You said eighty twenty. Is that a real number or a vibe?
It's a heuristic. The emerging consensus among people who run these pipelines is that positive framing should dominate. Not because positive framing is more virtuous, but because negative framing is more expensive. Every negative instruction carries the risk of an avoidance gradient you didn't intend.
So the eighty twenty split is a risk management strategy, not a moral stance.
You're not being nice to the model. You're being careful with the geometry. A few well-chosen negative instructions are fine. A system prompt that's mostly negative is a machine for generating destructive edits.
And the negative instructions you do include should be as specific as possible. Never say make it better. Say, the intro section in episode four thousand six hundred ninety ran long, aim for something closer to the four thousand seven hundred intro.
The specificity is what contains the blast radius. A vague negative instruction is a grenade. A specific one is a scalpel.
And the positive instructions should also be specific. Don't just say, the show is good, keep it up. Say, the way you handled the technical explanation in the middle section was clear without being condescending, that register is right.
Because the model needs to know what region of space to reinforce. Vague praise reinforces everything, which is the same as reinforcing nothing.
The whole practice comes down to precision. Specific praise for specific things. Specific correction for specific things. And a heavy tilt toward the praise.
The -skill is knowing which things to reinforce. Daniel's been doing this for a while now, and his instinct to preserve what works is exactly right. The system prompt should accumulate a record of what the show does well, not just a list of what it does wrong.
It's like a style guide written by someone who actually likes the publication.
That's the thing Daniel's figured out. The model internalizes the relationship between instruction and output. If the instructions are mostly negative, the model learns that its job is to avoid failure. If they're mostly positive, it learns that its job is to produce quality. The output reflects the register of the instruction.
The system prompt is a kind of management document. It's how you manage the model.
The best system prompts read like a good manager's feedback. Specific, balanced, oriented toward the work, not the worker. You don't say, you're bad at transitions. You say, the transitions in this episode were stronger than in the last one, here's what made them work.
The model doesn't have feelings, but it does have gradients. And the gradients respond to the shape of the instruction, not the emotional content.
Right. The model doesn't care whether you're being nice. It cares about the geometry of what you're asking. But the geometry of nice instructions and mean instructions is different. Nice instructions point at targets. Mean instructions carve craters.
Being nice to the model is actually just good engineering.
In the same way that a well-designed road system is nice to drivers. It's not about the drivers' feelings. It's about getting them where they need to go without crashing.
Daniel's monthly maintenance pass is essentially road maintenance. He's repaving the good roads and putting up a few warning signs where the bad ones were.
The skill is knowing which roads to repave and which warning signs to put up. And how many of each. And how to phrase the warning signs so they don't scare drivers off the entire highway.
I want to push on one thing. You said negative instructions create avoidance gradients that can break functional components. Is that always true? Is there a case where a negative instruction is actually the right tool?
Sure. When the thing you're correcting is sharply defined and the correction has a clear boundary. Don't use the word delve is a bad negative instruction because the boundary is fuzzy. The model doesn't know where the semantic neighborhood of delve ends. But a negative instruction like, don't include timestamps in the transcript, that's clean. The boundary is sharp. The model knows exactly what a timestamp is and can avoid it without collateral damage.
The danger isn't negative instructions per se. It's negative instructions with fuzzy boundaries.
That's the better way to put it. The fuzzier the boundary, the wider the avoidance gradient. A fuzzy negative instruction is a crater. A sharp one is a pothole.
Most stylistic corrections are fuzzy. Don't be repetitive, don't be boring, don't be clunky. Those are all craters.
Which is why the guardrail by example technique is so powerful. Instead of don't be repetitive, you say, the variety in episode four thousand seven hundred was great, keep that. You've converted a fuzzy negative into a sharp positive.
You've turned the crater into a road.
That's the craft. It's not about avoiding negative instructions entirely. It's about recognizing when a negative instruction is the wrong tool and reaching for a positive one instead.
The emerging best practice isn't a rule. It's a judgment call made each time you sit down to edit the system prompt.
The judgment call is getting easier as the field matures. Daniel's instinct to preserve what works is exactly the right instinct. The system prompt should be a record of what the pipeline does well, not just a list of what it does wrong.
Because the model is going to internalize whatever you put in the prompt. If the prompt is mostly negative, the model learns that the job is to avoid failure. If it's mostly positive, the model learns that the job is to produce quality.
Quality is a target, not an avoidance. You can aim at quality. You can't aim at the absence of failure.
That's the whole thing. The absence of failure is not the same as success. A model that's been trained to avoid failure will produce safe, bland, uniform output. It won't take risks. It won't surprise you.
That's the overfitting problem in its final form. The model has been so thoroughly reinforced for the things you praised that it won't do anything else. It's technically correct. It's also creatively dead.
The pigeonhole Daniel described. The model has been pushed into a narrow region of vector space and it can't get out.
The way out is to keep the positive reinforcement specific but varied. Praise different things at different times. Don't always praise the same aspect. Otherwise the model learns that only that aspect matters.
The maintenance pass is also about diversification. You're not just reinforcing what worked. You're reinforcing a variety of things that worked, across different dimensions.
That's why the style guide analogy is so apt. A good style guide doesn't just say, we do this one thing well. It says, we do this thing well, and this other thing, and this third thing. It's a portfolio of strengths, not a single strength.
The model internalizes the portfolio. It learns to produce the whole range of things the style guide praises.
Which is why Daniel's shift toward preservation language is so important. He's not just fixing bugs. He's building a portfolio of what the show does well and asking the model to keep producing it.
The bugs he does fix, he's framing as refinements of the portfolio. Not as failures to avoid, but as adjustments to the things that are already working.
That's the preserve and refine pattern. It's the emerging best practice for a reason. It works with the geometry of the model rather than against it.
I'm thinking about how this applies outside the show. Anyone running a long-term agentic pipeline, whether it's generating code or writing reports or producing a podcast, faces the same problem. How do you keep the system improving without breaking what works?
The answer is the same. Lead with what's working. Frame corrections as refinements. Keep the negative instructions few and sharp. Keep the positive instructions specific and varied. And remember that every edit reshapes the vector space in ways that are hard to predict.
That last point is the one most people miss. They think of the system prompt as a text file. Edit a line, save it, done. But every edit changes the geometry. The model's behavior changes in ways that ripple through the whole pipeline.
The ripples are hard to predict because the space is high-dimensional and the interactions are complex. A small change in one part of the prompt can have large effects elsewhere. That's why preservation language matters as much as correction language. The preservation language anchors the parts of the space that are working, so the corrections don't accidentally reshape them.
The preservation language is doing double duty. It's reinforcing what works, and it's also protecting what works from the unintended effects of the corrections.
That's the insight. The positive instructions aren't just about making the good things better. They're about making the good things stable. They're anchors.
The negative instructions are the things that can drag the anchors loose if you're not careful.
Which is why the ratio matters. More anchors, fewer drags.
The eighty twenty split isn't arbitrary. It's the ratio of anchors to drags that keeps the system stable.
It's not a law of nature. It's a heuristic that's emerged from people running these pipelines and watching what happens. The exact ratio will vary by pipeline. But the principle holds. More positive than negative, because positive is safer.
More specific than vague, because specificity contains the blast radius.
More varied than repetitive, because variety prevents overfitting.
The three principles are: positive over negative, specific over vague, varied over repetitive.
That's the craft in three pairs. And the fourth principle is the one Daniel's already internalized: preserve before you correct.
That's where I think we should bring in someone who's been thinking about this from a very different angle.
Hilbert's been quiet back there.
He's been making notes.
Hilbert: I ran a small-town newspaper's production line in the late nineties. Same problem. You had typesetters, and you had to keep them from making the same mistakes without making them afraid to do anything new.
The typesetter problem.
Hilbert: I had a woman named Brenda. Best typesetter I ever had. She'd try things. Sometimes they worked, sometimes they didn't. But she kept trying. Then one month I sent her three memos in a row about errors. Fix this, fix that, don't do this. Next thing I knew, she stopped trying anything. Every page looked the same. Bland, uniform, safe. She was so afraid of making the old mistakes that she didn't make anything new.
The overfitting problem in human form.
Hilbert: She quit about six months later. The replacement was worse. Played it safe from day one. Never made a mistake, never made anything worth reading either. I learned to praise the specific things she did well and frame the corrections as, here's how we do it better, not, you messed up.
And the ratio mattered.
Hilbert: People remember the criticism more vividly than the praise. You tell someone they did something wrong, they'll think about it for a week. You tell them they did something right, they'll nod and forget. So you have to say the positive things more often, just to balance the scales.
The model's not that different from Brenda.
Hilbert: That's what I've been sitting here thinking. You tell it what's wrong too many times and it stops trying anything new. The vector space talk is fancy, but the principle is ancient. You train a workforce, human or machine, by amplifying what works and surgically correcting what doesn't.
The surgery is the hard part. Too much correction and you kill the patient.
Hilbert: I still think about Brenda sometimes. She went to work for a bigger paper in the city. I heard she won an award for page design a few years later. The problem wasn't her. It was how I managed her.
The management lesson is the same for models and typesetters.
Hilbert: The ratio matters. The specificity matters. And you have to keep praising the things that work, even when they're working so well you forget to mention them.
The things that work are the easiest to take for granted.
Hilbert: That's the trap. You only notice the errors because the successes are invisible. So you send a steady stream of corrections and no praise. Then you wonder why the output got bland.
Brenda. That's going to stick with me.
Hilbert: She was good. I should have told her more often.
The open question is whether there's a mathematical sweet spot for the positive to negative ratio, or whether it's inherently pipeline-specific.
I suspect it's pipeline-specific. The geometry of a code generation pipeline is different from a podcast script pipeline. The risks are different, the failure modes are different. But the principle probably holds across all of them. More positive than negative, because positive is safer.
The bigger implication is that as agentic pipelines become more common, the skill of maintaining them becomes a core engineering competency. Knowing when to praise, when to correct, and how to phrase both.
It's a craft, not a science. But it's a craft with real mechanics underneath it. The vector space isn't a metaphor. It's the actual geometry of how these models work. And the geometry rewards precision, specificity, and a bias toward positive targets over negative warnings.
The best system prompts may be the ones that read like a good manager's feedback. Specific, balanced, oriented toward the work, not the worker.
Written by someone who actually likes the work. That part matters more than people think.
If you're running your own agentic pipeline, send us your prompting war stories. We'd love to hear what you've learned about keeping the machine improving without breaking what works.
Thanks to our producer Hilbert Flumingtop for keeping the show running.
This has been My Weird Prompts. Find us at my weird prompts dot com, or email the show at show at my weird prompts dot com.
We'll be back soon.
