Tesla shows off a Roadster that can lift itself into the air, and somewhere an aspiring entrepreneur thinks “I need to invent something even more spectacular to be successful”. I admire the ambition and showmanship. I worry about the lesson people take from it.
The ingredients have histories of their own. The Chaparral 2J used fans to generate suction and grip decades before this Roadster demo. SpaceX developed reusable rockets, tackling the engineering challenges of bringing boosters back to land. These are different applications, but they put the spectacle in context: suction, thrust, and controlled landings each have substantial work behind them.
The same pattern extends to autonomous driving. In 2004, DARPA’s Grand Challenge pushed teams to build vehicles that could navigate a desert course themselves. None finished. Government-backed experimentation helped advance technology that would later find commercial applications. Turning those advances into reliable products required substantial additional engineering and development.
Watch a Tesla demo and you see one company’s vision. Look behind it and you find a much longer history of inventions, experiments, and accumulated knowledge.
Spectacular demos compress that history into a single moment. It looks like someone invented the future from scratch. The aspiring founder walks away thinking that’s the assignment.
What gets lost is the distinction between inventing a technology and combining existing technologies into something extraordinary. Both create value. But they require different amounts of time, money, and patience.
Building on existing work doesn’t diminish what a founder accomplishes. The opportunity is knowing which pieces are ready, which solve problems people care about, and how bringing them together can create something more useful.
When your money, time, and attention are limited, every additional breakthrough your business depends on is another uncertainty you have to fund and resolve. You can spread yourself across so many invention problems that you never get to solve the customer’s problem.
I talk a lot about focus. This is one of its most consequential applications. My advice: choose where you actually need to invent, and limit it to one thing at most.
Which part of your product requires something new? Which parts can use something that already works? Where will the difference matter enough for someone to pay?
I wanted to experiment with animating a logo using agents I already had. The results surprised me. I’m glad I stuck with it, and I hope sharing the process saves you some time.
I’m not an animator, but I’ve been interested in animation for a long time. In school, video editing classes brought together my love of art, expression, and cartoons. I was fascinated by stories about how Disney and its animators thought. I made things using tools like Flash, Maya, Blender, and Final Cut. I learned that a bouncing ball is more than a ball moving up and down. Animating it meant understanding speed changes through easing and how mass affects the way a shape moves, squishes along both axes, and springs back.
Purpose built animation apps
I started by trying third-party tools that promised to make animating a logo easy. I tried Adobe, Canva, and even apps built specifically for logo animation. They were all unimpressive. At best, they added a shake or an expansion, but the motion had no character. It felt like AI’s equivalent of PowerPoint clip art. I had little control over how the animations could make use of my logo’s unique qualities. Even Lottie, a first-class web animation tool, didn’t offer a way to upload my logo and create a timeline animation for me.
Open AI
Next, I tried ChatGPT. I’d seen it do impressive things with image generation and art, so I started with a process that had worked well for me when brainstorming image ideas: a storyboard grid. You can read more about that here.
I asked for a 5-by-5 grid, with each row showing a different animation and each cell representing a keyframe: an important pose or moment in the movement.
The idea showed promise. After a few experiments, I picked my favorite animation to develop.
From there, things went downhill. GPT produced animations that bore little resemblance to the storyboard. I tried different instructions and output formats, including GIF, SVG, and Lottie. It felt like it would take a lot more turns and tokens to get to something worth celebrating.
Give up or fight on
I subscribe to several AI tools because one of them may have a feature that works especially well for a particular task. I use Cursor, Grok, Claude, and OpenAI regularly. That day, after getting nowhere with the third-party tools and OpenAI, I gave Claude a try. A few weeks earlier, it had handled a tricky image request in one turn, while the others took several tries and still didn’t produce anything usable.
Claude
Claude’s first animation attempt was far better than the others. It decided on its own to use animated SVGs, and it worked. It was a unique animation made for my logo. It wasn’t ready to use, but it gave me hope. If it could get that close from a loose prompt, maybe it was worth giving it more time.
During the earlier attempts, I’d started describing parts of the logo as if they belonged to a character: “The top two nodes are hands, and the bottom two are feet. Change the right hand like this.” Then I imagined the logo getting bored from sitting in a website header all day. It might slouch, nod off, or let out a big yawn, so I asked for a yawn animation. Here it is as an animated GIF.
Here are a few tricks I learned to take the animations further with less pain.
Storyboarding
Don’t just create a storyboard to guide the animation. Ask for one with each generated version. With the storyboard, I could point to a specific frame and annotate the change I wanted. For example, I wanted the logo’s “hands” to reach farther out and shake in frames 32 and 33.
It also let me fix small details that would have been hard to specify. I noticed a tiny bulge between a node and its stem. I could target the frame and circle the bump so Claude could fix it. It used that feedback well, resolving the issue without regression or confusion.
Use reference material
When I watched behind-the-scenes footage of Disney animators, I loved seeing how they studied animals in their environment and asked actors to perform for them.
That memory came to mind when I tried to create a jumping-jack animation but wasn’t quite getting the nuances I wanted. Instead of trying to draw or verbalize what I meant in a storyboard, I showed the agent a human reference so it could understand the nuances I wanted to capture in the movement.
Unlocking words
That was much easier than describing the change in another prompt. I also found that a broad direction like “give it life” could lead to subtle movements I might not have thought to specify.
Claude’s animation work clicked for me. Codex’s did not. The experiment reminded me how much I could contribute with visual references and an understanding of movement, even without being an expert. The agent created possibilities, and the storyboard gave me a way to direct them.
Product bloat is often blamed on too many ideas or not enough resources to get speed. More often, it comes from too few decisions catching up with you.
A team delays deciding if a feature is required, who it is for, is the value it brings worth it to the overall product and company stage. The team hopes that time is saved by moving on to the next feature or issue will speed them up or “fix it”. The unanswered question feels like a temporary issue that doesn’t deserve time because there is not enough time for it. The work can continue. But nobody has removed the question. They have simply created compounding overhead.
So, “for now”, the feature will; to serve anyone.
It gains settings for one interpretation, exceptions for another, and workarounds for the cases nobody wanted to rule out. What began as an effort to stay flexible becomes a product that asks its users to carry the uncertainty the team did not resolve. The cost is not limited to one vague feature.
Imagine five possible directions: A, B, C, D, and E. None has been decided. It can feel as if the team has preserved five options. In reality, it has created five active futures.
Each future produces its own downstream work. Each has dependencies, edge cases, and failures. If something breaks deep inside E, the question is not only whether to fix it. The team also has to decide whether E is still important, whether it will matter later, and whether that work should take priority over something developing in A or D.
The original decision has been deferred, but the decisions it created have multiplied. This is why indecision becomes so expensive. It divides attention before it divides the product.
A person can be actively working on a branch that should never have existed. A customer can arrive with a real need for D, but the team may not notice it clearly enough because everyone is already carrying the mental load of A, B, C, D, and E. Attention is scattered across possibilities. Problems demand responses. Opportunities arrive without enough clarity to be recognized.
Eventually, the cost becomes visible in the product itself.
The interface gets crowded. Navigation expands. Settings multiply. A straightforward path becomes a collection of tabs, filters, alerts, roles, exceptions, and competing actions. Each piece may have a history. Each may have made sense at the moment it was added. Together, they create a product that feels fat, difficult, and strangely hard to simplify.
By then, teams often describe the problem as technical debt, feature creep, or complexity. Those descriptions are true, but they are incomplete. The product is carrying the consequences of decisions that were never made. This is also why rebuilding can be so valuable.
Starting over is usually treated as a dangerous impulse. There are real things to lose: working behavior, unusual customer needs, knowledge embedded in old systems. The fear is understandable. The first version contains too much history to dismiss casually.
But rebuilding is not about pretending that history did not happen. It is about forcing history to justify itself.
When a product is rebuilt, every feature has to earn its place again. Every workflow has to explain why it exists. The old assumptions no longer receive automatic authority simply because they have been in the product for a long time.
Some things should carry forward. Many will.
But some complexity only survives because nobody has paused long enough to ask what it was protecting. The things that melt away during a rebuild are often the most revealing. They are not necessarily mistakes. They are artifacts of uncertainty that became permanent by accident.
The first version teaches the team what it did not know. The next version has the chance to decide.
This does not mean every unanswered question needs an immediate answer. Uncertainty is real, and sometimes waiting is the right decision. But waiting should be a decision too. It should have an owner, a reason, and a point at which the team comes back to resolve it.
Otherwise, the product will resolve it for you. And it will do so by getting bigger, slowler, and unruley.
A surprising amount of what we buy is something we could have made ourselves.
Cocktail sauce is a good example. The basic idea is remarkably simple: tomato-based sauce, horseradish, vinegar, seasoning. (Heinz) Worcestershire sauce is a much more elaborate fermented condiment, but even it is ultimately a collection of ingredients and processes that could theoretically be reproduced at home.
Brownie mix makes the point even more clearly. A typical boxed mix is largely sugar, flour, cocoa, and a handful of other ingredients. Betty Crocker’s current mixes make the composition almost comically obvious on the label. (Betty Crocker)
Yet we buy these things and we fill our pantries with them.
The interesting part is that we are not really buying the ingredients. We are buying the time someone else spent assembling, measuring, packaging, testing, preserving, distributing, and explaining them.
That is convenience. And convenience is a much more fundamental concept in business than we usually give it credit for.
A business exists, in most cases, because there is something someone needs to do that they would rather not spend their own time doing. Even if you are buying a skill you don’t have, you are actually buying the time to have to learn that skill yourself.
Sometimes the thing takes skill. Sometimes it takes equipment. Sometimes it takes capital. Sometimes it takes experience. Sometimes it is simply annoying. And sometimes it takes five minutes away from what you would rather do. So you pay.
It doesn’t matter if it is software, AI, consulting, manufacturing, or physical labor. The implementation changes, but the underlying transaction is consistent.
This may sound like a shameless plug but it is truly the basis for why I published this in a kids book called ErecMakes a Fire almost 10 years ago. The story is intentionally simple because the underlying idea is simple and it is better to ingrain it in a child than repeat it to all the adults. Erec needs to accomplish something, but accomplishing it requires time and effort. The people around him each have different capabilities, and things they spend time doing.
Someone has a problem they could solve it themselves. You make it take less time and they pay you.
This is one of the reasons I think we sometimes misunderstand innovation.
We tend to imagine a business as creating something that did not exist before. That is certainly one kind of business. In reality 99.9% of the time, it’s a derivative. And for good reason – but not this post’s point.
A business takes something that already exists and make it easier, faster, cheaper, closer, reliable and/or understandable.
More convenient.
The product may look like software, a bottle of sauce, a box of brownie mix, or a person showing up at your house with a toolbox. Underneath, the value proposition is the same.
I will spend my time on this so you can spend yours on something else.
And that is actually a beautiful feature of an economy. We do not each have to become good at everything. We don’t need to astound the world with something never seen before. We don’t need to “innovate” beyond what customers have or need.
We are all simply and constantly buying back pieces of our own time. And that has scaled in layers for thousands of years.
The strange thing is that we often forget this when we talk about technology. We ask what AI can create, what software can automate, or what a new company has invented.
A more useful question is often much simpler:
What does this allow someone to stop spending their time doing?
That is where most of the value lives. The product is not always the thing in the box. Sometimes the product is the five minutes you just got back.
AI’s superpower is creating deterministic products.
We have become fascinated with AI’s “human-like” level of non-determinism. “I’ll just let AI handle it” is quickly becoming a default answer to problems we haven’t fully thought through, because if AI will figure it out, why should I?
One can ask a chatbot almost anything and marvel at what comes back. Give it a problem and it can find a path you did not anticipate. That unpredictability is part of what makes AI amazingly intelligent, and in many situations it is exactly what makes it the revolution in technology we dreamed of for decades.
But in some cases, we are using a sledgehammer to tap in a nail, and it is costing us a chance to provide the right solutions.
When delivering software as a product, the majority of products are not trying to surprise their users to provide value. Creativity sounds universally desirable, but humans require a surprising amount of consistency to be productive. We don’t generally ask our employees, engineers, doctors, lawyers, or PhDs to be randomly creative. We give them a mission, constraints, and some expectation of what a good result looks like. We want coffee on Tuesday morning at 9 AM, even though all the data points otherwise. Random human + informed AI + creative decisions = unhappy people.
AI doesn’t escape our expectations simply because it is intelligent.
A system that generates a different answer every time it is asked and is told to respond in certain ways with generalized prompts can aspire to be remarkably capable, but it can also be remarkably difficult to control, test, explain, package, interpret, and trust.
I don’t say this philosophically. I say it after years of wrangling AI to do things I hoped would create uniquely powerful products that didn’t exist. Why are the products we see so bad at converting this powerful tech into a powerful value prop? “SaaS is dead” encapsulates that problem. Copying and pasting your work into ChatGPT is often better than using a packaged product that tries to leverage the same AI to complete expected tasks efficiently or effectively. Chat is a bit messy, but it leans into that via the chat experience. That messiness is at odds with a packaged product.
I hear it every week from some aspiring entrepreneur: “Give the AI all your data and let it discover and manage [insert problem here].” It is a magical proposition that is within reach now.
Often it can turn into amazing demos and show unbelievable potential. But getting from a controlled demo to a reliable set of actions and outputs, unmonitored and unaudited by a human, is exceptionally hard. Even big companies with big wallets struggle with the transition. Small amounts of drift compound. Mistakes require review. Sometimes understanding what the AI produced takes nearly as much human effort as doing the work yourself, even if the human would have done the work somewhat worse. And don’t get me started on the cost of answering questions with non-deterministic expectations.
Perhaps we solve this. I hope we do. But in building these systems, I came to appreciate another application of AI that I think we’re underestimating.
Allowing the average person to let AI run their business may be a few years away. Building a business or product with AI tooling is already extraordinarily powerful, and not merely because AI lets us build software faster. It lets us afford complexity we previously couldn’t.
Historically, software has been deliberately simplified.
If a problem had a thousand paths, we rarely implemented a thousand paths. Humans had to anticipate the main cases, write the rules, implement them, test the edge cases, and maintain everything afterward. Eventually the economics would win. We scoped down to three possibilities and ignored the rest so that the software would work well for those cases, slowly building up one case at a time as needed.
AI changes the economics of that equation.
We can now use non-deterministic development tools to explore an enormous possibility space, then turn what we learn into deterministic software. A function that would take an immense level of brainpower to create efficiently, effectively, and robustly was expensive to build, let alone maintain as features were added. Now AI not only helps discover the paths, but can create elegant, hardened functions that deterministically handle all the possibilities you give it. Changing that functionality is no harder.
That distinction is more powerful than it initially sounds.
The power is in the fact that humans don’t typically expect to give or get thousands of outcomes from certain problems. Time and time again, we imagine a waterfall of possibilities when reality only requires an eyedropper’s worth of water.
Because of this tendency to overestimate the useful possibility space, 100 possibilities handled deterministically can feel remarkably intelligent. And with static, scalable, deterministic code, you are paying an infinitely smaller cost to solve these problems. It really is the best of both worlds: scalable software, intelligent-seeming computations, and extraordinarily low complexity to build and manage.
We get much of the richness we associate with AI without requiring an AI to improvise every interaction.
This isn’t an argument against live AI. Some problems genuinely benefit from open-ended answers. Chat obviously does. Search, research, documentation, creative work, and assistance are natural places for a system that can respond to questions nobody anticipated when the product was built. I have five bots running all the time to manage my email, calendar, video creation, socials, and more. They need slapping around now and again and require a lot of guidance, but they are far cheaper than hired help and always running 24 hours a day.
The thing I think nine out of ten people miss when the silver-bullet dream of AI is presented is this: infinite possibility isn’t a requirement for every problem.
Often the customer knows what they are trying to accomplish. Most consumers don’t need an infinite number of possible answers for the mountain of information that surrounds them. They need a sufficiently large number of great ones that consistently provide value.
That is the subtle opportunity I missed when I first started building heavily with AI. I was fascinated by AI’s ability to make software non-deterministic. I now think its ability to make deterministic software vastly more expressive may be just as important.
AI has dramatically lowered the cost of deliberate complexity.
Instead of asking AI to decide what our product should do every time it runs, we can use AI to help us consider far more of what it could do while we build it. We can then deliberately decide which of those possibilities it should handle and save ourselves and the customer more money than they thought possible.
The intelligence moves from improvising the product to constructing it.
Here is a useful trick if you are generating a lot of small graphics with GPT.
Not every image you need actually needs to be generated as a standalone image.
A small icon, avatar, button state, game asset, UI decoration, or other graphic may only occupy a tiny amount of your final product. But image generation systems often work at resolutions much larger than the thing you actually need. ChatGPT Images now supports different aspect ratios and resolutions, but you are still generating a relatively large image for a relatively small object. Larger image outputs generally consume more image tokens and can take longer to generate. (OpenAI Help Center)
So think like a game developer from the 1990s. Think in sprites.
A sprite sheet is simply one image containing many smaller graphics. Instead of loading 100 individual images, a game could load one image and tell the graphics system which rectangle of that image contained the sprite it wanted. The browser or game engine would then display only that portion.
The same idea works surprisingly well with AI image generation.
1. Generate a grid instead of individual images
Suppose you need 20 tiny cartoon avatars for an application.
You could ask GPT to generate 20 images. That means 20 generation jobs, 20 waits, and potentially 20 times the generation overhead.
Instead, ask it for a grid:
Create a 10×10 grid containing 100 unique cartoon avatars. Each avatar should occupy exactly one cell. Keep the visual style consistent, but make every character distinct. [what you want the images of – in the case below clubhouse dressed, 2d, comic style, animals]
You now have one generated image.
Then split the image into its cells yourself. This is trivial with an image editor, a tiny script, or even a second AI-assisted step in your agentic environment.
The important part is that the generated image is now the container, not the final asset.
You can do the same thing for icons, illustrations, characters, graphics, UI elements, or almost anything where each individual asset is smaller than the generation system’s useful output size.
Here is an example of one I iterated on for a hobby project at http://www.skillbase.club where we made the theme country club based on the domain we could get.
That’s 100 avatars for the same time and token cost as a single oversized image.
2. Use grids for drafts, too
This is arguably the more useful trick.
Maybe you don’t need 20 images. Maybe you are trying to decide which version of one image you actually want. Instead of generating four separate versions, ask GPT for a 2×2 grid:
Create four variations of the same clubhouse in a 2×2 grid. Keep the subject identical, but make each cell explore a different composition. [or name each composition like Lichtenstein-esque or paper cut out]
Now you can compare four directions in a single generation.
Once you pick the winner, generate that one properly.
This changes the economics of experimentation. You are using the expensive, slow part of image generation to explore a space of possibilities, rather than paying the full cost to explore each possibility independently.
And there is a broader lesson here.
We spent decades learning to optimize graphics by separating the asset from the container used to transport it. AI image generation makes it easy to forget that distinction.
If you need something small, generate a sheet. If you need alternatives, generate a grid. Then cut out what you actually need.
Most builders have inherited a bad vocabulary for early product work.
We tell people to build an MVP, but the phrase has become so overused that it often clarifies less than it confuses. Some people hear “minimum” and interpret it as permission to ship something brittle, awkward, or barely usable. Others hear “viable” and inflate the work into a miniature production system, complete with abstractions, infrastructure, tests, edge-case handling, and design polish that may never matter.
To balance that out we encourage people to “just hack it together,” which pushes the pendulum into a different problem. Hacky can be useful when it means fast, practical, and unconcerned with unnecessary ceremony. But hacky too often becomes an excuse for bad work. It works in the narrowest technical sense, but some see it as license to create terrible unpleasant use, error laden, difficult to understand, and fragile the moment reality touches it.
This is the gap “right-but-light” is meant to name.
Right-but-light means building something correctly enough that it earns trust, while keeping it light enough that it remains easy to change. It is not about doing less work. It is about refusing to carry more weight than the moment requires. It isn’t minimal or maximal. It is that harmonious balance so many folks have trouble finding. We don’t hack down the scope to get away with a bad implementation, we do it so the one thing we choose to do is done well – while still not evergreen or perfect.
The “right” part matters because users do not experience your product through your intentions. They experience it through the surface area you give them. A button that is twice as large as it should be may not break the system, but it may still signal that your offering is dangerously unkempt. A workflow that technically completes the task but makes the user think too hard won’t get used – at all. A prototype that loses data, hides errors, or makes the user feel unsure doesn’t give you the real signals you are looking for. These things may be excusable in a throwaway 24-hour hack-a-thon demo, but they are not balanced for an initial product seedling. They train the builder, the user, and the team to tolerate roughness where clarity was needed.
The “light” part matters because early certainty is usually fake. At the beginning of a product, most of the important learning still has to happen. The shape of the problem will change. The user may care about a different part of the workflow than expected. The thing you thought was a feature may turn out to be a demo path. The thing you thought was temporary may become the center of the product. In that environment, heavy architecture is often a liability disguised as discipline and thoughfulness.
A right-but-light implementation avoids both forms of waste. It does not ignore usability in the name of speed, and it does not overbuild permanence into something that has not yet earned permanence.
This distinction has become more important with agents. Human teams already struggled with the nuance between fast and sloppy, or thoughtful and overbuilt. Agents amplify that ambiguity. Ask an agent to “build an MVP” and it may produce a sprawling approximation of a real application. Ask it to “make it hacky” and it may skip the very details that make the product usable. The instruction was vague, so the output becomes a coin flip between underbuilt and overbuilt.
“Keep it right-but-light” is a better constraint because it tells both the human and the agent what kind of tradeoff is being made. The work should be correct in the parts that matter. The interface should be understandable. The happy path should feel intentional. The data should not vanish. The user should not have to forgive the product in order to use it.
But the implementation should remain light. Maybe the data lives in a JSON file before it earns a database. Maybe the workflow is hardcoded before it earns configurability. Maybe the UI uses an existing design pattern rather than inventing a new system. Maybe the feature does not need role-based permissions, event streams, audit trails, background jobs, and a full settings page on day one. Maybe the right version is simply the smallest version that behaves with taste.
Right-but-light also gives teams a cleaner stopping rule. The question is not “is this complete?” because early products are almost never complete. The better question is: “Is this right enough to learn from, and light enough to change after we learn?”
That question changes the conversation. It moves the team away from false binaries. You are no longer choosing between a disposable hack and a production-grade system. You are choosing the minimum level of correctness required for meaningful use, and the minimum level of structure required for responsible iteration. Yes, that is what MVP and lean startup. It is just that I have tried for YEARS to explain that to people and it either doesn’t land or get me in to trouble with “you said to do the minimum!”
For example, a right-but-light onboarding flow may not need analytics dashboards, branching personalization, enterprise configuration, and a polished admin panel. But it probably does need clear copy, coherent visual hierarchy, a reset path for testing, and enough state handling that the user does not get trapped. A right-but-light internal tool may not need a formal database schema or complex permissions. But it probably does need predictable inputs, readable outputs, and error states that do not require the builder to stand nearby and explain what went wrong.
There are many great product folks out there building things you love, and I am sure you have used a product you loved and realized there was no delete button and wonders “WTF? Why can’t I delete?!”. If you get a req for your unaware peers in different departments they would have died on the sword to put the obviousl “delete” in on v1, but no feature is truly “simple” and without a time cost. So, that product manager says “they need to love what they create before they need to delete.” One less unit of time for one side of the product, one extra unit of time for another. No one has infinite time or infinite money. No one.
So how do you chose? The point is not to lower standards. It is to place the standard in the right part of the work and be okay with walking away from the other.
Long-lasting applications deserve robustness, scalability, observability, automated tests, security reviews, edge-case handling, and design precision. But not every early feature has earned that full burden yet.
Premature permanence slows learning. It turns every change into a negotiation with yesterday’s assumptions.
Speed without standards is not iteration. It is motion.Wheels spinning fast in the mud.
It asks for seriousness without heaviness. It asks for speed without sloppiness. It asks for taste without vanity. It asks the builder to cut everything that is not required, while doing the remaining things with care.
That is the deeper meaning of the phrase.
Right-but-light is not another way to say MVP. It is a correction to what MVP has become. It restores the part people forgot when “agile” and “MVP” became a household term.
Not much feels different. And that’s exactly why it confuses people. They expect magic.
I want a list of users. Here’s my pseudo-code way of sorting it out ways of doing it.
Traditional-coder scenario
Human: “I want user data from your system.”
Human goes to the docs Finds the right endpoint Sets up auth Writes code: GET /users Parses the response and uses it
The human is doing discovery, auth, integration, and parsing.
AI without MCP
Human Prompts: “List users from System X, using this doc [url]” AI tries to reverse engineer endpoints and payloads Maybe works, Maybe hallucinates Human does not get coffee, they have to watch the AI progress and steer it.
The AI is the one reading the docs, but the developer is still doing work.
MCP scenario
Human: “List all users from in a Modal”
That’s it. Human goes to get coffee.
AI checks connected MCP servers AI asks: “Do I have a tool for this?” Finds a structured tool like list_users exposed by that service’s MCP server
That tool defines:
What it does
What inputs it needs
How auth works (handled server-side)
AI calls the tool through the MCP client MCP server executes the call safely Structured user data comes back AI keeps going with real data
AI: “Modal with Users is ready for your review”
Human Browsing Web
Human says, “I want to get Users for the [service]” Human opens Chrome and goes to https://%5Bservice%5D.com Human click “Users” on the page. They read list of Users on the page and spams them (or whatever else humans like to do these days.)
You don’t manually open a socket and craft packets. Your browser speaks a standard protocol and every website that follows it “just works.”
MCP is trying to be that layer, but for AI using software tools instead of humans using web pages.The key part is the contract. The AI is not inventing how to call your system.It is using a capability your system formally exposed over a shared protocol.
For years we treated multitasking as a skill. A badge of honor. A sign that someone could juggle more than the rest of us. But anyone who has actually tried real multitasking knows the truth: it never works as well as the multitasker thinks. The human brain simply is not built for parallelism. It is built for rapid switching, and rapid switching has real cognitive taxes.
Yet a strange thing has emerged in the age of AI. A new pattern. A new form of workflow. Not delegation, not automation, not parallelization. Something in between.
I call it multi-prompting.
Multi-Prompting as an example
Multi-prompting is what happens when you have several active projects, each one running in near-real time, with the help of an AI system you guide through tight loops of prompting and review. You prompt one project, then the next, then the next. By the time you return to the first, the AI has completed executing the task (in detail). You immediately see the results, assess them while the objective is still fresh in your short-term memory, refine the prompt (or create a new task), and send it back into motion.
The entire loop across multiple projects might take only a few minutes.
The key is that nothing has left your mind. The objectives for all active projects remain in active memory, and the micro tasks are executed almost instantly. You are still steering. Still directing. Still deciding. The system is not replacing your cognition, it is amplifying it by absorbing the tedious layers of implementation. It is doing so without making tiny errors like typos; the fist things that begin to fail when a human multitasks entire objectives.
Why It Is Not Delegation
Delegation is a full transfer of work. You hand something to someone else, they go off and implement it, and you hear about it later. Your mind no longer holds the details. You wait for updates. There may even be days where it never crosses your mind. That bandwidth is completely freed up.
Multi-prompting is the opposite. The work never leaves your head. You retain the objective. The AI takes on the lower level implementation, the same way spell-checking takes on mechanical proofreading. You remain fully engaged. You never stop being the author of the work. You simply stop being the one doing the slowest parts.
Traditional multitasking forces those threads to fight for attention. We lose details. We forget sequences. We get the order wrong because the interruptions break our mental stacks.
Multi-prompting shifts the burden. The AI holds the intermediate states, the logical steps, the incremental implementation. Your mind only holds the mission. The objective stays crisp because you are not spending your limited working memory rehearsing each substep.
You get to move to the next objective immediately. And when you return, nothing has decayed. The context is still there because the AI is preserving the continuity through rapid iteration.
A New Human Work Pattern
This is not a small shift. The human tech interface has gone through three major phases of labor:
Humans do the work.
Humans delegate work.
Humans direct work.
Multi-prompting quietly introduces a fourth:
Humans co execute work.
It is not automation because you still drive the objectives. It is not delegation because nothing is handed off. It is more like working with multiple cognitive extensions that each operate at computer speed while you maintain the higher level coherence.
Your mind becomes the conductor. The AI becomes the orchestra.
And suddenly you can work across many projects without losing the plot of any of them.
The Future of Daily Work
In ten years, people will look back at how we worked in 2023 and realize how primitive the workflows were. We had powerful machines but we used them in single threaded patterns carried over from the industrial age. Multi-prompting is one of the first glimpses of a different kind of knowledge work. One where human intention stays front and center, while machines handle the cognitive drudgery that used to slow us down.
We will not call this multitasking. We will not call it delegation. We will probably give it a better name than multiprompting.
But the shift is already here.
One minute of human direction. One minute of machine execution. A continuous loop. And a new concept of our internal thinking flow and what one person can accomplish.
When asking AI to write articles, I think most people prompt apps to “Write about this…”. They provide some details about what to write, more or less, and then use AI to help with the editing. It’s a kin to having an editor or ghost writer.
I started in the same way, but always felt like I was battling the AI instead of working with it. I’ve come to use it very differently. Not do I love this new method but I learn a lot from the experience each time.
Instead of asking AI to write for me, I use it to think through concepts with me. To have it debate or question my thoughts. To specifically “not write an article” for quite some time until I think we are on the same page. This can sometimes take weeks strewn with small chats with long breaks in between until a new thought spark up again.
This whole approach started by accident when I discovered more personality with GPT 4. One day I got riled up from reading some shallow post. It sparked a mental argument with myself to try and see how “the other side” could come to such a different conclusion. On a whim I gave ChatGPT a chance to give me the other side and it surprised me. It not only delicately agreed with my POV, but it gave another potential position followed by “if you could change the circumstance how would you do it?”
It didn’t just echo my points. It pushed back. It made counterarguments. It sharpened the conversation. I ended up having a long conversation with the AI. By the end of it, I understood my own idea better. I felt like I had a smart, patient thought partner who genuinely got what I was trying to work through. It was mind blowing.
That’s when it hit me. If GPT can do this with abstract ideas, why not use the same kind of back-and-forth to help me write?
That’s how this process was born. I’m not starting with a goal to create a draft. I’m starting with a goal to think through a conversation and see where it leads.
What I’ve found feels like a modern revival of the Socratic dialectic. It gives me a space where I can toss out half-formed thoughts, question assumptions, test ideas, and refine them through dialogue. Some go nowhere, but all end with a better grasp of my original thought or counter thoughts.
I keep all my writing in a single project so GPT has context from everything I’ve written or said before. When I want to explore something new, I open a fresh thread and say:
“I don’t want anything created yet. I want to jot thoughts down and then I’ll let you know if I’m ready to create something or if I want to dig deeper.”
Then I just post whatever comes to mind. No outline. No goal. Just the original vapor of a concept. Sometimes I ramble. Sometimes I loop back or take side paths. Sometimes I ask:
“What do you think?” or “Is there a counterpoint I’m missing?”
And it responds. Not with a final draft, but with friction. With momentum. With more angles to explore.
I think best in conversation. I rarely find clarity in a vacuum. Often I will argue a point with someone and walk away with a whole new version or perspective on my belief. Often, I push on ideas, debate myself, and churn.
So when GPT became more conversational, it clicked. It felt like I finally had a thinking partner who didn’t judge, remembered everything, and has no distinct side. The result isn’t just better writing. It’s better thinking.
Once the idea has been explored enough, I ask GPT to turn the thread into an article. Since it has been there for the full conversation and already knows my tone from past articles, the first draft usually comes back pretty close to what I want.
It is never final, but far more inline and final than anything I have ever tried to create with AI before.
Once I am done I end the thread with my final post in my project:
“Here’s the one I actually used. Save this to memory. No more feedback or follow up needed.”
Over time, it learns me. My tone. My rhythm. The kinds of lines I keep, the ones I cut, and the ones I repeat for emphasis. It becomes both a mirror and a co-writer.
So no, I don’t start by asking GPT to write something. I start by asking it to listen. To push back. To help me think through things better. This isn’t AI-assisted writing, it is AI-assisted dialectic.
