Alright, we have a fascinating one today. Daniel sent over a prompt that gets into the weeds of how we actually use AI day-to-day, or more accurately, how we should be using it but often don't because the tools are so fragmented. Here is what he wrote to us: Discuss text transformation as an underappreciated use case for LLMs. The pattern is simple: text goes in, a system prompt instructs the model to transform it, and transformed text comes out. Examples include dictation cleanup, like removing filler words and fixing grammar, tone adjustment from casual to formal, format conversion like prose to bullet points, style transfer from technical to plain English, and even summarization-as-transformation. This works incredibly well on cheap, small instruction-tuned models, like a seven-billion parameter model running locally, without needing the heavy hitters like GPT-four or Claude Opus. It is pure text-in, text-out, the most basic LLM operation. However, polished tooling for this workflow is surprisingly hard to find. Most existing tools are just prototypes or buried features. Daniel wants us to dig into what this paradigm is called, what frameworks exist like Open WebUI or TextFX, and why there is such a massive gap between how useful this is and the lack of dedicated software for it.
Herman Poppleberry here, and man, Daniel is hitting on my favorite soapbox. We spend so much time talking about these massive, agentic workflows where AI is browsing the web and booking flights, but we completely overlook the fact that these models are essentially the world's most sophisticated linguistic filters. By the way, quick shout out to our script writer today, Google Gemini three Flash. It is powering the dialogue for this episode. But back to the point, Corn, this "Text-in, Text-out" or TITO paradigm is the silent workhorse of the industry. It is the most reliable thing an LLM does because it is grounded entirely in the provided context.
It feels like we are using a chainsaw to cut butter sometimes, right? If I just want to turn my rambling voice memo into a coherent Slack message, I don't need a model that can pass the Bar Exam and explain quantum chromodynamics. I just need something that understands where the "ums" and "uhs" are and knows what a professional tone looks like. But you're right, when I look for a tool to do just that, I end up in this weird world of half-baked GitHub repos or paying twenty dollars a month for a massive subscription I don't fully use. Why is the "Photoshop for text" missing?
That is exactly the mystery. Technically, this is often called Linguistic Style Transfer or LST in formal natural language processing circles. In the newer AI literature, you will see it called Instruction-Following Text Processing or simply Text Rewriting. Google actually released a paper on something they called RewriteLM specifically for this. The reason it's so powerful is that modern small models, we are talking about the seven-billion to fourteen-billion parameter range, have been fed so many "instruction-response" pairs during fine-tuning that they are world-class at following a rubric. If you tell a model like Mistral seven-B or Llama three-point-one eight-B to "rewrite this but make it sound like a grumpy Victorian novelist," it does it instantly and locally.
And that local aspect is huge, especially for something like dictation cleanup. If I am rambling about a sensitive business idea into my phone, I don't necessarily want that transcript hitting a third-party cloud server just to remove my speech impediments. If I can run that on my laptop using Ollama, the privacy is baked in. But let's talk about that mechanism for a second. It is just a system prompt plus input text, right? There is no "thinking" involved in the sense of a multi-step chain. It is a single pass.
Precisely. It is a zero-shot transformation. You provide a system prompt that defines the "lens." For example, the lens could be "You are a professional editor. Remove all filler words, fix the syntax, but preserve the speaker's unique voice." Then you dump the raw text in. The model doesn't need to look anything up. It doesn't need a vector database. It just needs to map the input tokens to a new set of output tokens based on that linguistic transformation rule. The reason small models excel here is that they don't need the "world knowledge" of a trillion-parameter model. They just need the linguistic grammar of the transformation. It is a much "lighter" cognitive task than, say, writing a novel from scratch or solving a complex coding bug.
So if the task is lighter, why haven't we seen a dominant app for this? If I want to edit a photo, I go to a specific app. If I want to "edit" the style of my writing, I'm usually copy-pasting into a chat box, which feels like a very nineteen-ninety-eight way of doing things. It's like we've built the engine but forgot to put the steering wheel and the seats in the car.
I think it's what some people call the "Feature, Not a Product" problem. Developers at big companies like Google or Microsoft see text transformation as something that should be a button inside Google Docs or Word. They want to bury it under a "Help me write" menu. But for those of us who work across fifty different apps, Slack, Discord, Email, Terminal, we need a global utility. There is a project called TextFX that Google Labs did with Lupe Fiasco, which is actually a great example of what this could look like. It gives you ten specific tools like "Simile," "Explode," or "Unfold." You put a word or phrase in, and it performs a very specific linguistic operation. It is brilliant, but it is still a web-based experiment, not a tool that lives in my operating system.
I love the idea of "Explode" as a text operation. It sounds like something I'd do to my grocery list when I'm feeling dramatic. But more seriously, let's look at the "Dictation Cleanup" use case because that feels like the ultimate "killer app" for this. I know a lot of people who use voice-to-text, but the results are always a mess. You get these circular thoughts where you say the same thing three times because you're thinking out loud. A standard grammar checker like Grammarly might fix the commas, but it won't realize that your second and third sentences are just worse versions of your first one. An LLM transformation can actually "gist" it.
That term "gist manipulation" is actually used in human-computer interaction research. There was a paper in twenty-twenty-four about supporting writing with speech via LLM-assisted gist manipulation. The idea is that the LLM acts as a structural editor. It sees the redundancy and collapses it. The technical challenge is that to do this well, you need a high-quality system prompt that understands the difference between "cleaning up" and "rewriting so much that the meaning changes." That is where the prompt engineering comes in. For a local model like Mistral seven-B, which was really the model that proved small could be powerful back in late twenty-three, you have to be very specific. If your system prompt is too vague, the model might hallucinate and add facts that weren't in your voice note.
That's the danger, isn't it? The "grounding" issue. If I say, "I think we should meet at five," and the model decides to "clean it up" by saying, "The meeting is confirmed for six PM at the coffee shop," it has failed fundamentally. But because these transformation tasks are "Text-In, Text-Out," you can actually measure the delta. You can see exactly what was changed. This is why I think the "Pure TITO" workflow is actually safer for enterprise use than RAG. In RAG, the model is pulling from a database and might mix up two different documents. In transformation, you are giving it a closed loop. "Here is the text. Change the tone. Do not add information." It is much easier to verify.
And the speed! If you are running a quantized version of a seven-billion parameter model on a modern laptop, you are getting fifty, sixty, maybe eighty tokens per second. That is faster than you can read. You can essentially have a "live" transformation buffer. Imagine a text area where as you type, or as you speak, a "cleaned up" version is appearing in a separate pane in real-time. That is what the industry is missing. We have the models, and thanks to things like Ollama, we have the easy deployment. But the "glue" is missing.
Let's talk about the glue then. What do we actually have? You mentioned Open WebUI. I've seen they have these things called "Filters" and "Pipelines." How does that work in the context of transformation?
Open WebUI is probably the closest thing we have to a "Pro" environment for this. Their "Filters" feature allows you to write a script that intercepts a message before it is sent to the model or after it comes back. So, you could create a "Detoxify" filter or a "Professional Tone" filter. Every time you send a message, the filter runs a hidden LLM call in the background to transform the text according to your rules before it even hits the main chat. It is incredibly powerful, but again, it's tied to that specific web interface. It doesn't help me if I'm writing an email in Outlook.
So we are back to the "Copy-Paste Tax." We are all paying this tax where we have to jump between windows to get the transformation we want. It's funny because we have these massive frameworks like LangChain or LlamaIndex that are designed for these incredibly complex "agentic" workflows with twenty different steps, but using them for a simple text transformation feels like buying a semi-truck to move a single shoebox. If I just want a "Simple Chain" in LangChain that takes an input and applies a system prompt, I'm still writing twenty lines of boilerplate code.
It is the "Hello World" of LLMs, yet we've made it strangely difficult to deploy as a utility. Another way people are doing this is through Ollama's "Modelfile." You can actually create a "new" model on your machine that is just a base model plus a hard-coded system prompt. So you could run a command like ollama run clean-notes and that "model" is actually just Llama three with a system prompt that says "You are a note-cleaning assistant." It works, but it's a command-line interface. Most people are not going to open a terminal, type a command, and then paste their text just to fix a paragraph.
I'm picturing a world where my right-click menu has a "Transform" option. Highlight text, right-click, select "Make this more concise" or "Change to bullet points," and it just happens in place. That is the dream. And the crazy part is, the technology to do that has existed for over two years now. We aren't waiting for a breakthrough in AI; we are waiting for a breakthrough in boring old desktop software integration. Which, let's be honest, is where good ideas go to die sometimes.
Well, the "Custom GPTs" in OpenAI's ecosystem were a step in that direction, where you could build a "GPT" specifically for rewriting. But then you're locked into their cloud, their pricing, and their latency. The latency is the real killer for a "writing assistant" feel. If I have to wait three seconds for a transformation, the flow is broken. If it's local and takes three hundred milliseconds, it feels like magic. It feels like the text is just "settling" into its correct form.
I like that. "Settling." It's like the text is finding its own lowest energy state. But let's look at the "Small Model Advantage" again. You mentioned fourteen-billion parameter models. Why that specific jump? I've noticed that for some tasks, the seven-B models are a bit... well, they can be a bit "over-eager." They might change too much or lose the thread. Does that extra size help with the "Instruction-Following" precision?
It really does. While seven-B models like Mistral or Llama three eight-B are fantastic for simple cleanup, the fourteen-B to twenty-B range, like the Qwen two-point-five seven-B or even the larger Gemma two nine-B, they have a much better grasp of nuance. They are better at "Style Transfer." If you want to take a highly technical white paper and turn it into a blog post for a ten-year-old, the seven-B model might simplify it too much and lose the core technical meaning. The nine-B or twenty-seven-B models have enough "internal world" to understand what the technical terms actually mean, so they can find better synonyms that don't sacrifice accuracy. But even then, we are talking about models that can run on a decent consumer GPU or even a high-end mobile phone. We are not talking about a rack of H-one-hundreds.
And that brings up the "Localization" point Daniel mentioned in the prompt. Using these for translation-as-transformation is a huge deal. Usually, we think of translation as a separate thing, but really, it's just a transformation where the "tone" is "Spanish" or "Hebrew." When you combine translation with tone adjustment, like "Translate this to French but make it sound like a very polite business request," that is where the TITO paradigm smokes traditional translation tools like Google Translate.
Oh, absolutely. Traditional translation is often "word-for-word" or "phrase-for-phrase" with some neural magic, but it doesn't always understand the cultural context of a "Transformation." If you tell an LLM to "Transform this American sales pitch into something that would be well-received in a Japanese corporate environment," it won't just change the words; it will change the level of directness, the honorifics, and the structure. That is a transformation task, not just a translation task. And again, a fourteen-B model is more than capable of that.
So why is there this gap? Why is the tooling so sparse? Is it because there is no money in it? If I can run it locally for free, no one can charge me a subscription for it.
I think that's a big part of it. The "SaaS-ification" of AI has led everyone to build "platforms" and "ecosystems" because that's where the VC money is. A simple, one-time-purchase utility that sits in your system tray and cleans up your text doesn't have a "moat." Anyone could build it. But because anyone could build it, no one is building it with the level of polish required to make it a household name. We have a million Gradio prototypes on Hugging Face where some researcher shows off a "Style Transfer" model, but the UI is a mess and it takes ten seconds to load. It's a "demonstration," not a "tool."
It's the difference between a "tech demo" and "software." I think we are in the "Tech Demo" era of text transformation. Everyone knows it's cool, everyone has a script that does it, but no one has a "product." But let's get practical for a second. If someone is listening to this and they're like, "Okay, I'm sold. I want to use local LLMs to clean up my messy meeting notes," what is the "least painful" way to do that right now without being a coder?
Right now, I would say the most "user-friendly" path is to download Ollama, which is the backend, and then use a frontend like "AnythingLLM" or "LM Studio," or even better, the "Open WebUI" desktop wrappers that are starting to pop up. Once you have that, you find a good "Transformation" system prompt. There are actually community-curated lists, like the "Text-Transformation-Index" on GitHub, that give you these specific "recipes." You just paste your messy notes into the chat, but you make sure your "System Prompt" is set to "Note Cleaner."
"Note Cleaner." I need that on a t-shirt. But "System Prompt" is still a bit of a "nerdy" term, right? For most people, that's "the instructions." And this is where the prompt engineering comes in. What are the "hacks" for a good transformation prompt? I've heard that "delimiting" your input text is important.
Yes! That is a huge one. If you just dump a bunch of text in, the model might get confused about where your instructions end and your text begins. You want to use clear markers. Like, "Transform the text delimited by triple quotes." Then you put your text inside """. This prevents "prompt injection" where the model might start following an instruction that was actually inside your messy notes. Another big one is the "Output Format" instruction. If you don't tell it otherwise, an LLM might say, "Sure! Here is your cleaned-up text:" and then give you a preamble. You want to tell it: "Output only the transformed text. Do not provide an introduction or conclusion."
See, that is exactly why the tooling is missing. I don't want to have to tell my "Note Cleaner" every time to "not talk back to me." I just want the notes! A dedicated tool would have that "Output only" instruction hard-coded into the backend. It would handle the triple-quote wrapping for me. It would be a "black box" where messy text goes in and clean text comes out.
And that is why Daniel's point about this being "Underappreciated" is so spot on. We are ignoring the most robust, useful, and private application of this technology because it's not "flashy." It doesn't generate a video of a cat riding a surfboard. It just makes your writing ten percent better and saves you twenty minutes of editing. But if you multiply that twenty minutes by every office worker in the world, the productivity gain is astronomical.
It's the "Marginal Gains" theory of AI. We are all looking for the "Big Bang" that replaces our whole job, but we're ignoring the five-minute task we do twenty times a day. If I could "transform" every Slack message I write to be twenty percent more concise, I would probably save an hour a day just in reading and writing time. And my coworkers would probably like me more.
You'd be the most efficient sloth in the world, Corn. But there's another angle here: "Summarization-as-Transformation." Most people think of summarization as "Give me the bullet points." But there is a more subtle version where you "transform" a long document into a "Executive Summary" that keeps the same tone and key terminology. It's not just a "summary"; it's a "distillation." This is where the fourteen-B models really shine. They can maintain the "soul" of an argument while cutting seventy percent of the fluff.
I've actually used this for reading long, rambling academic papers. I'll tell the model: "Transform this paper into a three-paragraph explanation for a senior developer. Keep the technical terms, but explain the core mechanism clearly." It's not a "summary" in the sense of a blurb; it's a "re-contextualization." It's like having a very smart friend read the paper and then explain it to me in my own language.
And that is "Linguistic Style Transfer" in action. You are transferring the "style" from "Academic Obscurantism" to "Pragmatic Engineering." The reason this is "safer" than asking a model to "Explain this paper" is that when you frame it as a transformation, the model is forced to look at the source text more closely. It's a "constraint." AI models, especially small ones, actually perform better when they are constrained. If you give a model a blank page and say "Write a story," it might get weird. If you give it a page of text and say "Rewrite this as a poem," it has a "skeleton" to follow. It's much harder for it to fall off the rails.
That "Skeleton" concept is great. It's like the input text is the bones, and the transformation is just changing the skin and the clothes. The structure remains. So, if we have the models, and we have the "recipes" for the prompts, what is the "First Mover" advantage here for a developer? If you were going to build the "Photoshop for Text" tomorrow, what would be the first feature?
It has to be a global keyboard shortcut. Highlight text anywhere, hit Cmd+Shift+T, and a small overlay appears with your "Transformation Presets." "Professionalize," "Concise," "Bulletize," "Translate to Spanish." You click one, and the highlighted text is replaced by the transformed version. No copy-pasting, no switching windows. That is the "Product." And the beauty is, you could let users "Bring Your Own Key" for OpenAI, or just point the app to a local Ollama instance.
That sounds like something that would be a "Must-Have" utility. Why hasn't Apple or Microsoft done this at the OS level? Apple has "Apple Intelligence" coming, but it feels very "Siri-centric." It's all about "doing things" for you. It's not about "helping you refine" what you're already doing in a subtle way.
Well, Microsoft has "Copilot" in Windows, but it's a sidebar. It's another "Chat Box." This is the core issue: the industry is obsessed with "The Chat." But "The Chat" is a terrible interface for text editing. If I'm writing a document, I don't want to "talk" to my editor. I want my editor to just "edit" the paragraph I'm working on. The "Transformation" paradigm is the antithesis of the "Chat" paradigm. It's a "Tool" paradigm.
"The Chat is a terrible interface." That's the pull-quote for this episode. I think you're right. We've been forced into this conversational metaphor because it's how the models were trained, but for actual "work," I don't want a conversation. I want a "Filter." I want a "Macro." Imagine if every time you wanted to use a filter in Photoshop, you had to chat with a bot. "Hey, could you please make this photo a bit more blue and maybe blur the background?" "Sure! I can help with that. Here is a version where I've adjusted the hue..." You'd lose your mind! You just want the "Blur" slider.
We need "Linguistic Sliders." A slider for "Formality," a slider for "Conciseness," a slider for "Technical Depth." Behind the scenes, those sliders are just adjusting parameters in a system prompt. "Move the Formality slider to eighty percent" becomes "Rewrite this with a high degree of professional decorum" in the hidden prompt. This is what Google's TextFX was hinting at. Each "tool" was essentially a "preset." But we need that as a layer over our entire digital life, not just a tab in Chrome.
And the "Privacy" angle is the final piece of the puzzle. If I'm using a "Formality Slider" on a sensitive legal document, I can't have that hitting a cloud. So the "Local Model" requirement isn't just a "geek" preference; it's a functional requirement for this to be a professional tool. This is why I think the "Text Transformation" space is actually the biggest opportunity for local AI. RAG is hard to do locally because databases get big. Agents are hard to do locally because they need a lot of compute for multiple steps. But transformation? Transformation is what local models were born to do.
It is their "Natural Habit." A seven-B model running on a laptop is a "Transformation Engine." We just need to stop calling them "Chatbots" and start calling them "Linguistic Processors." Even the terminology "Large Language Model" is part of the problem. When you hear "Large," you think "Cloud." But "Small Language Models" or SLMs are the real story for twenty-six. We are seeing a "Small Model Renaissance."
"Small Model Renaissance." I like that. It sounds like a period in history where everyone suddenly realized they didn't need a giant palace when a well-built cottage would do. So, if we are looking at takeaways for our listeners, the first thing is: stop thinking of AI as just a "research assistant" or a "chatbot." Start looking at every piece of text you produce and ask, "Could this be transformed?"
And the second takeaway is: Experiment with the "System Prompt." If you are using a tool like Ollama or even just a standard chat interface, don't just say "Rewrite this." Be the "Director." Tell it exactly what to change and, more importantly, what to keep. "Keep the technical jargon, but change the tone from 'Defensive' to 'Collaborative'." You will be shocked at how well even a tiny model can follow that instruction.
I'm going to start using a "Sloth-ifier" transformation on all my emails. "Rewrite this but make it sound like it took a lot of effort to type and I might need a nap soon." It'll manage expectations perfectly.
People will just think you're being your usual self, Corn. But seriously, the practical value here is in the "Brain Dump." If you struggle with the "Blank Page," just talk. Record a five-minute voice memo of every thought you have on a topic. Don't worry about grammar, don't worry about structure. Then, use a local LLM with a "Transformation" prompt to "Extract the three core arguments and structure them as a memo." It is a superpower. It turns "Speaking" into "Writing."
It's "Asynchronous Thinking." You do the messy thinking now, and the model does the "Polishing" later. I think we're going to see a lot more of this as the "Agentic CLI" tools like Claude Code or other terminal assistants start to incorporate "Transformation" as a core command. Imagine being in your terminal and just typing transform --formalize report.txt.
That is the future. It's "Unix Philosophy" applied to AI. "Do one thing and do it well." The "one thing" is text transformation. We don't need the model to be our "friend" or our "assistant"; we just need it to be a very clever pipe that we run our text through.
A very clever pipe. I think that's a good place to wrap this one. We've gone from "Photoshop for Text" to "Linguistic Sliders" to "Clever Pipes." I hope the developers out there are listening, because there is a massive "Tooling Gap" just waiting to be filled.
And if you do build that "Right-Click Transform" tool, let us know. I'll be the first person to buy a lifetime license.
Same here. Well, this has been a great deep dive. Thanks to Daniel for the prompt—it really opened up a "hidden in plain sight" part of the AI world. And thanks as always to our producer, Hilbert Flumingtop, for keeping the gears turning behind the scenes.
Big thanks to Modal as well for providing the GPU credits that power this show. They make it possible for us to explore these technical topics without our laptops melting.
This has been My Weird Prompts. If you're enjoying the show, a quick review on your podcast app helps us reach new listeners who might also be looking for that "Photoshop for Text."
Find us at myweirdprompts dot com for the RSS feed and all the ways to subscribe. Catch you in the next one.
See ya.
