Hey everyone, welcome back to My Weird Prompts. We are at episode seven hundred ninety-five, which feels like a bit of a milestone, even if it is a slightly arbitrary number. I am Corn, and I am sitting here in our living room in Jerusalem with my brother. The winter rain is finally hitting the stone walls outside, and it feels like the perfect afternoon to dive into some heavy theory.
Herman Poppleberry, at your service. Seven hundred ninety-five, Corn. Five more until eight hundred. We should probably do something special for that, though knowing us, we will just end up talking about some obscure paper on sparse autoencoders or neural architecture and forget to celebrate entirely. Maybe we will just have a very quiet cupcake while debating the merits of state-space models versus transformers.
Most likely. But today, we have plenty to chew on before we get to eight hundred. Daniel sent over a prompt that really hits on the evolution of this whole field we have been living in for the last few years. It is about the state of prompt engineering. Specifically, whether it is still a standalone discipline or if it has been swallowed up by something bigger, like AI engineering or context engineering.
It is a great question because the vibe has definitely shifted. Back in twenty twenty-three and twenty twenty-four, being a prompt engineer was the hottest, most mysterious job title on the planet. People were talking about it like it was this arcane magic, like you were learning the secret incantations to talk to the ghost in the machine. There were those viral articles about people making three hundred thousand dollars a year just to type "take a deep breath" into a text box. And now, in February of twenty twenty-six, the conversation feels much more... well, engineered. Less like magic, more like plumbing.
Exactly. Daniel mentioned that while we have gotten better at things like prompt versioning and using tools like the Model Context Protocol, there are still these weird gaps. One of the things he pointed out was the lack of focus on saving raw AI outputs for review and the mixed results we get from automated prompt enhancement. I want to start there, Herman. Why do you think we are so obsessed with the prompt—the input—but we still treat the output like it is disposable?
That is such a keen observation, and it is honestly one of the biggest technical debts we are accruing in the industry right now. I think it comes from our collective background in traditional software engineering. In traditional coding, the code is the source of truth. If the code is right, the output is predictable. It is deterministic. So, we focus all our version control and our energy on the script, the prompt, the "source." But with large language models, the relationship between the input and the output is probabilistic.
Right, so the same prompt might give you a brilliant answer one day and a total hallucination the next, especially if the model has been updated behind the scenes or if the temperature settings are slightly nudged. We have all had that experience where a prompt that worked perfectly on Friday is suddenly producing garbage on Monday morning.
Precisely. And if you are not saving those raw outputs, you are losing the only actual evidence of how your system is performing in the wild. You can have the most beautiful, version-controlled prompt in the world, stored in a fancy Git repository, but if you do not have a database of ten thousand real-world outputs to look at, you cannot actually say if your prompt is good. You are just operating on vibes. We are still in the "Vibes Era" of evaluation for a lot of companies.
Vibes-based development. That was the early era, for sure. But Daniel mentioned that even now, tools like the Model Context Protocol, or MCP—which for those who don't know, is that standardized way for AI models to connect to data sources—are mostly focused on the "read" side. They help the AI read your Google Drive, your Slack, or your local database, but they do not do much on the "write" side, like automatically archiving and categorizing those outputs for later analysis.
It is a massive blind spot. If you want to move from prompt engineering to what I would call "AI engineering," you have to treat the output as data. That data is what you use for fine-tuning, for evaluation, and for building guardrails. If you are just letting those outputs vanish into the chat history or the logs of some API provider, you are essentially throwing away the fuel for your next iteration. It is like trying to train a professional athlete but never filming their games. You are just giving them instructions and hoping for the best when they hit the field.
That is a good analogy. But let’s look at the other side of Daniel’s prompt: the automated prompt enhancement. We have seen these systems—things like DSPy or even just the "improve my prompt" buttons in the major LLM dashboards—where you give a basic prompt to a model, and it expands it into this three-paragraph masterpiece of chain of thought, persona setting, and XML tagging. Daniel says he often sees mixed results, and I have felt that too. Sometimes the enhanced prompt feels... performative? It is more verbose, but not necessarily more accurate.
Oh, I have a real bone to pick with those automated enhancers. What often happens is that they add so much fluff and so many constraints that they actually narrow the model's creative space too much. In the literature, we sometimes call this over-specification. The model gets so caught up in following the sixteen different formatting rules and the specific persona instructions the enhancer added that it loses the core logic of the task. It is spending all its "attention" tokens on the window dressing instead of the actual problem solving.
It is like telling someone to go buy groceries, but then adding a list of fifty rules about which aisles to walk down first, what color shoes to wear, how to breathe while looking at the milk, and making sure to recite a poem to the cashier. By the time they get to the store, they are so stressed about the rules they forget the eggs.
Exactly! And there is another technical reason for this. These automated enhancers are often trained on what humans think a good prompt looks like—the "as an expert linguist" or "think step by step" tropes—rather than what actually triggers the best response in the model's latent space. We have seen research showing that sometimes the most effective prompts for a model are strings of text that make zero sense to a human. There was that famous case where adding "This is very important for my career" or "I will tip you two hundred dollars" improved performance. If you let an AI optimize a prompt for another AI, it might end up being a weird string of tokens that looks like gibberish but hits the model's weights just right.
That is the part that creeps people out, I think. The idea that the best way to talk to these things might not be human language at all. It might be a series of mathematical "keys" that unlock certain behaviors. But for now, in twenty twenty-six, we are still mostly stuck with language. So, if prompt engineering as a standalone thing is fading, what is taking its place? Daniel mentioned "context engineering." How is that different from just writing a better prompt?
Context engineering is a much more holistic way of looking at the problem. Think of it this way: the prompt is the specific question you ask. The context is everything the model knows when you ask it. In the early days, we tried to cram everything into the prompt. We would paste three whole documents into the chat window and then ask a question. That is just bad prompt engineering, and it is incredibly inefficient.
And it gets expensive and hits the context window limit pretty fast, even with the million-token windows we have now.
Right. Context engineering, on the other hand, is about building systems that dynamically fetch the right information at the right time. This is where Retrieval-Augmented Generation, or RAG, has evolved. Instead of giving the model everything, you build a system that searches your database, finds the three most relevant paragraphs, and provides those as context. But in twenty twenty-six, context engineering has gone further. It is about "state management." It is about the AI knowing where you are in a workflow, what you did five minutes ago, and what your preferences are, without you having to re-explain it every time.
So, the prompt becomes almost like the final inch of a mile-long cable. The engineering is in the cable, not just the tip.
That is a great way to put it. If you are a context engineer, you are worried about the data pipeline. You are worried about how the information is chunked and embedded. You are worried about the latency of the retrieval. You are worried about "needle in a haystack" problems where the model misses a tiny detail in a huge context. The actual text of the prompt might stay the same for months, but the context being fed into it changes every millisecond based on the user's actions.
I can see why that feels more like a real engineering discipline. It requires knowledge of databases, vector search, and systems architecture. But does that mean the person who is just really good at talking to the AI—the person who knows how to use chain of thought or few-shot prompting—is becoming obsolete?
I don’t think so, and I think that is one of the blind spots Daniel was asking about. If we dismiss prompt engineering entirely, we lose the ability to debug the model's reasoning. You can have the best RAG system in the world, but if your final prompt doesn't tell the model how to weigh that information or how to handle conflicting data, the whole system fails. We are seeing this a lot with the newer "reasoning" models—the ones that do a lot of internal processing before they output. They are very sensitive to how the task is framed.
Right, because the model still needs to know what to do with the context you gave it. If I give you a map and a compass but I don't tell you if we are trying to find water or avoid a cliff, the map doesn't help you much.
Exactly. And there is a level of psychological intuition involved in prompt engineering that I think is still very relevant. You have to understand how these models tend to drift or where they are likely to get confused. For example, knowing when to use a negative constraint versus a positive one. Telling a model "do not be sarcastic" is often much harder for it to follow than telling it "be professional and earnest." A seasoned prompt engineer knows that. They understand the "personality" of the model.
So, it is less of a standalone job and more of a core competency that gets folded into other roles. Like how being good at searching Google used to be a specific skill people put on their resumes in the late nineties, but now it is just part of being a functional human in a digital world.
That is a perfect comparison. In twenty twenty-six, if you are a developer and you can't write a decent prompt, you are going to be left behind. But you probably wouldn't call yourself a "Prompt Engineer" anymore. You are an AI Engineer who happens to be proficient at prompting. It is a tool in your belt, not the belt itself.
Let’s talk about the workplace implications of this. Daniel asked about the holistic AI skill set for someone who wants to stay current. If you are sitting in an office today, and you see all these tools like MCP and automated agents being deployed, what should you actually be learning? If it’s not just learning how to say "take a deep breath" to the AI, what is it?
I think the first and most important skill is evaluation. We talked about this earlier with saving outputs. If you can't measure whether an AI is doing a good job, you can't improve it. So, learning how to build evaluation frameworks is huge. That means knowing how to use one model to grade another model's work—what we call "LLM-as-a-judge"—or how to set up human-in-the-loop systems where a person can quickly flag errors to create a gold-standard dataset.
Evaluation seems hard because it is often subjective. If I ask the AI to write a marketing email, what makes it good? Is it the tone? The clarity? The call to action?
It is hard, but that is exactly why it is a high-value skill. A holistic AI professional can take a vague business goal and turn it into a set of measurable criteria that an AI can be tested against. They can say, "Okay, for this task, we care sixty percent about factual accuracy and forty percent about brand voice." And then they build a system to test that across a thousand variations. That is engineering.
That makes sense. What else is in the toolkit?
I would say model selection and "right-sizing." We are moving away from the era where there was just one big model that everyone used for everything. Now we have tiny models that run locally on your phone, medium models for specific tasks like coding or SQL generation, and massive frontier models for complex reasoning. Knowing which tool is right for the job is a massive skill. You don't want to use a massive, expensive frontier model to summarize a two-sentence email. That is like using a Ferrari to drive to the mailbox. It is a waste of compute and money.
And conversely, you don't want to use a tiny, fast model to help you design a new chemical compound or write a complex legal brief. It will just confidently lie to you because it doesn't have the parameters to handle that level of complexity.
Exactly. So, understanding the landscape of models—the trade-offs between speed, cost, and capability—that is part of the engineering mindset. And then there is the orchestration piece. How do you chain these things together? If the user asks a question, does it go to a classifier model first to decide which tool to use? Does it go to a search engine? Does it need a human to approve the final output? Designing those workflows—using things like LangGraph or other agentic frameworks—is where the real value is right now.
It sounds like we are moving from being authors to being directors. We aren't just writing the lines; we are managing the whole production.
That is a great analogy. You are the director, the script supervisor, and the editor all in one. You have to make sure the actors—the models—have the right props, which is the context. You have to make sure they know their lines, which is the prompt. And you have to make sure the final scene looks good, which is the evaluation.
I want to go back to something Daniel mentioned about saving raw outputs. He said it remains "remarkably underdeveloped." Why do you think companies aren't doing this more? It seems like such an obvious thing to do if you want to improve your systems.
I think it is partly a privacy and security concern. If you are an enterprise, you are terrified of accidentally saving sensitive user data—like social security numbers or private health info—in a big pile that could be leaked or misused. So, they just turn off logging entirely to be safe. But I also think it’s a technical hurdle. Storing and indexing millions of chat turns is actually quite expensive and complex. It requires a different kind of database architecture than what most companies are used to. You need a way to search those outputs by "vibe" or by "failure type," not just by keyword.
Plus, if you save it, you have to do something with it. I think a lot of people are overwhelmed by the sheer volume of AI-generated content. They feel like they are drowning in it already, so the idea of archiving it for later seems exhausting.
But that is where the opportunity is! The people who figure out how to use AI to analyze their own AI outputs are the ones who are going to win. You can have a model that periodically scans your archived outputs to find patterns of failure. It could say, "Hey, every time a user asks about our return policy in Spanish, the model gets the date wrong." That kind of insight is pure gold for a business. It tells you exactly where your context engineering is failing.
So, if you are looking to be a leader in this space, maybe don't just focus on how to write the perfect prompt. Focus on how to build the system that watches the AI and learns from its mistakes.
One hundred percent. And I think we should talk about the "blind spot" Daniel mentioned regarding prompt engineering's continued relevance. There is a danger in thinking that because the models are getting smarter, the prompts matter less. People say, "Oh, the model is so smart now, I can just talk to it like a person."
And can't you? I mean, I talk to my voice assistant like a person all the time.
To an extent, yes. But the smarter the model, the more subtle the influence of the prompt becomes. It is like the difference between giving instructions to a toddler and giving them to a genius. The toddler needs you to be blunt and repetitive. The genius will pick up on your subtle biases, your unspoken assumptions, and the way you framed the question. If you are not careful with your prompt, a very smart model will go off in a direction you didn't intend because it "read between the lines" of your poorly phrased request. It might over-interpret a casual remark as a strict constraint.
That is fascinating. So, as the models get more sophisticated, prompt engineering actually becomes more like high-level diplomacy or philosophy. You have to be incredibly precise with your concepts because the model is capable of taking them to their logical extremes.
Exactly. We see this with the reasoning models that have come out recently, like the ones that use internal chain of thought before they answer. If you give them a slightly ambiguous prompt, they might spend ten seconds "thinking" about the wrong problem. You’ve wasted time, you've wasted compute, and you've potentially gotten a very detailed answer to a question you didn't mean to ask. So, the "engineering" part of the prompt is actually more important than ever for these high-end models. You need to provide clear boundaries for their reasoning.
It’s like the difference between steering a rowboat and steering a massive container ship. In the rowboat, you can correct your mistakes instantly with a quick flick of the oar. With the container ship, a one-degree error in your initial heading can put you miles off course by the time you realize it. These new models are the container ships.
That is exactly right. And I think that is the bridge between the old-school prompt engineering and this new AI engineering. The prompt is the heading. The context and the orchestration are the engines and the hull. You need all of it to get where you are going. If you ignore the heading, you're lost. If you ignore the engines, you're stationary.
So, to summarize for our listeners who are trying to navigate this: Prompt engineering isn't dead, it’s just graduated. It is now a component of a much larger, more complex machine. If you want to stay relevant in twenty twenty-six, you need to understand the whole machine. You need to know how the data gets in—that's context engineering. You need to know how the model processes it—that's model selection and prompting. And you need to know how to measure the result—that's evaluation.
And don't forget the "write" side of the equation! Start saving your outputs. Even if you don't know what to do with them yet, that data will be the most valuable asset you have in six months. It is the history of your system's behavior. It is the only way to move from "I think this prompt works" to "I know this system works."
I think we have covered a lot of ground here. Daniel’s prompt really forced us to look at how much this field has matured even in just the last year or two. It is no longer just about the "magic words." It is about the systems we build around those words. It's about moving from being a "wizard" to being an "architect."
It is an exciting time, Corn. It feels like the "amateur hour" of AI is over, and the real engineering is beginning. It is less about finding a lucky phrase and more about building robust, reliable infrastructure.
An architect of intelligence. I like that. Well, Herman, I think that is a good place to wrap up this part of the discussion. Before we go, I want to remind everyone that if you are finding these deep dives helpful, or even if you just like hearing us nerd out about technical details in our living room, please leave us a review on your podcast app.
Yeah, whether you are on Spotify, Apple Podcasts, or somewhere else, those reviews really do help people find the show. We see them, and we appreciate the feedback. It keeps us going through these long Jerusalem winters.
And if you want to get in touch, you can always reach us at show at my weird prompts dot com. Or visit our website at my weird prompts dot com for the full archive and our contact form. We have all seven hundred ninety-five episodes there if you really want to see how our thinking has evolved since the beginning. You can hear us in twenty twenty-two being excited about things that seem so primitive now.
That would be quite a journey. From the early days of basic text completion to where we are now with multi-modal reasoning agents. It has been a wild ride, and we are only five episodes away from eight hundred.
It certainly has. Thanks for joining us for another episode of My Weird Prompts. I am Corn.
And I am Herman Poppleberry. We will see you next time.
Goodbye, everyone!
