Why the Smartest AI Systems Start by Getting Smaller

Mark Erdmann

Hatched by Mark Erdmann

Jul 03, 2026

10 min read

87%

0

The counterintuitive lesson hiding in plain sight

What if the fastest way to make an LLM system smarter is to make each part of it dumber?

That sounds backwards at first. When a prompt fails, the instinct is to add more instructions, more examples, more exceptions, more reasoning steps, more guardrails. We build a bigger prompt, then a bigger prompt to manage the bigger prompt, and eventually we have a 2,000 token creature that can do almost anything except reliably do the one thing we actually need.

This is not just a prompt-writing problem. It is a deeper design problem about complexity, abstraction, and control. The same tension that makes software rot into a “God Object” also appears in AI systems: every time we ask one component to absorb too many responsibilities, it becomes less predictable, harder to evaluate, and often worse at the common case.

The surprising insight is that language models reward a different kind of engineering than we are used to. Not bigger instructions, but cleaner decomposition. Not one giant act of intelligence, but a chain of smaller, testable acts that together produce something more robust than any single heroic prompt.


Why bigger prompts often make worse systems

There is a familiar failure mode in software: a single class or function that knows too much, does too much, and depends on everything. It begins as convenience. Then come the edge cases. Then the special handling. Then the one-off exceptions that somehow become permanent. Eventually the code still works, but nobody trusts it.

Prompts follow the same path. A team starts with a simple instruction, maybe a few examples. Then output format drifts, users ask odd questions, the model misses a nuance, and the prompt grows. Soon it must infer intent, apply policy, identify tone, handle ambiguity, resist hallucination, and preserve structure. The prompt has become a miniature operating system.

The problem is not only ugliness. Large prompts create a hidden tax on performance. They blur the signal. They compete with themselves. A model that is told to be concise, but also comprehensive, but also cautious, but also friendly, but also highly structured, is being pulled in multiple directions at once. The result is often not sophisticated judgment, but inconsistent compromise.

This is where the analogy to software matters. A good system is not one with the most capability packed into one place. A good system is one where responsibilities are separated enough that each piece can be understood, improved, and verified independently. The same principle applies to AI, but with an extra twist: language models are not deterministic functions. They are probability machines. That means clarity is not just a style preference, it is a control mechanism.

When a prompt tries to do everything, it stops being a prompt and becomes a negotiation.

That is the real danger. The model is no longer executing a focused task. It is trying to infer which instruction matters most, under conditions of ambiguity you created. Complexity in prompts is not free power. It is a form of noise.


The missing frame: LLMs are not just tools, they are dynamics

It helps to step back from prompt craft and ask a more fundamental question: what kind of system is an LLM, really?

One useful answer is that it is not a traditional machine with fixed internal rules, but a system shaped by emergent behavior. Its output depends on training, context, phrasing, and the interaction between many learned patterns. That makes it powerful, but also hard to fully reason about in the way we reason about ordinary code.

The deeper conceptual frame here is computational irreducibility. In plain terms, some systems cannot be shortcut cleanly. You cannot always predict their exact behavior without letting them run. That is part of what makes LLMs fascinating and frustrating. They can appear intelligent in one context and strangely brittle in another, not because they have secretly become inconsistent people, but because their behavior depends on a high-dimensional interaction you do not directly control.

This matters for system design. If a process is irreducible in important ways, then stuffing more intelligence into one prompt is not the same as making the system more reliable. It may actually make the system less legible, because now you are relying on a single opaque execution to perform several logically distinct jobs at once.

The better answer is to design around irreducibility, not pretend it is gone. Instead of demanding that one prompt simultaneously extract, verify, prioritize, and narrate, we create a pipeline in which each stage has a narrow contract. The system as a whole can still be sophisticated, but its sophistication is distributed across stages.

This is a profound shift in mindset. Traditional engineering often chases centralization of logic. LLM engineering rewards orchestration of constrained inference.


A better model: split cognition into verbs

The most useful mental model is to stop thinking in terms of “a prompt” and start thinking in terms of verbs.

What does the system need to do, exactly? Not “summarize a meeting,” because that is not one act. It is several acts pretending to be one. First, identify the important facts. Then distinguish decisions from action items. Then associate owners with tasks. Then check whether the extracted details are consistent with the transcript. Only after that should you write the polished summary.

Each verb can be small, legible, and testable. Each one can have its own input and output format. Each one can be evaluated separately. And because each one has less to do, the model is less likely to confuse objectives or hallucinate its way through a bloated instruction set.

This is where AI system design starts to look less like prompt writing and more like good architecture.

Consider a restaurant kitchen. A single chef could theoretically do everything: take orders, chop vegetables, cook, plate, and run the register. But the kitchen is not organized that way because peak performance does not come from one overburdened actor. It comes from a sequence of narrow roles, each optimized for a specific function, with handoffs that preserve information.

Or think about a legal process. Nobody expects one person to draft, verify, redline, fact-check, and sign off on every clause with equal authority. The process is broken into specialized steps precisely because reliability improves when judgment is compartmentalized.

LLM workflows benefit from the same principle. The model is strongest when it is asked to do one thing at a time with high precision. The system around the model is strongest when it manages those steps explicitly.

The goal is not to make the model think harder. The goal is to make the system think more cleanly.

That distinction matters. “Thinking harder” usually means piling on more instructions. “Thinking more cleanly” means separating concerns so the model can stay inside a narrower cognitive lane.


Why smaller prompts can produce bigger intelligence

At first glance, splitting a task into multiple prompts sounds like adding overhead. More steps. More latency. More moving parts. In some cases, that tradeoff is real. But the hidden gain is that you have converted a vague, brittle prompt into a set of verifiable micro-decisions.

That changes everything.

A big prompt often fails silently. You know the final output looks off, but you do not know which instruction caused the drift. Was the summary too verbose because the prompt overemphasized completeness? Was the action item missing because extraction and summarization interfered with each other? You can only guess.

A modular workflow gives you leverage. If the extraction step is wrong, you fix extraction. If verification catches mismatches, you improve the checker. If the final summary is weak, you tune the synthesis stage without touching the parser. This is not just easier to debug. It is a way to make progress faster over time.

This is especially important because LLM behavior often improves more from removing ambiguity than from adding sophistication. A short, sharp instruction can outperform an elaborate one because the model can more easily infer the intended task boundary. In that sense, simplicity is not the opposite of intelligence, it is a condition for it.

There is also a psychological benefit for teams. Large prompts become intimidating artifacts that no one wants to edit. Small prompts invite experimentation. They are easier to version, test, and reason about. The people building the system can develop real intuition about what each stage does, instead of treating the prompt as a mystical incantation that must not be disturbed.

That is a quiet but important cultural shift. The more a team can see the system, the more it can improve the system.


The practical synthesis: design for narrow competence, not universal competence

The deepest connection between prompt modularity and the broader story of how LLMs work is this: these systems are powerful precisely because they are flexible, but that flexibility does not mean we should use them as if they were omniscient. Their strength is pattern completion under constraints. So the best architecture gives them constraints intentionally.

A useful framework is to ask three questions for every AI task:

  1. What is the smallest unit of work?
  2. What is the cleanest way to check whether it worked?
  3. What should happen if it did not?

These questions push you away from monolithic prompts and toward robust systems.

For example, imagine a customer support assistant. A single giant prompt might try to classify the issue, infer urgency, decide policy, draft a response, and keep tone consistent. A modular design would separate those concerns:

  • Classify the request category
  • Detect sentiment and urgency
  • Retrieve relevant policy or knowledge
  • Draft a response from structured facts
  • Run a consistency and safety check

Now the system is not only more maintainable. It is also easier to govern. You can inspect outputs at each stage, measure where failures occur, and decide whether a human needs to intervene.

This is the key move: replace trust in a single miraculous output with trust in a disciplined process.

That is a much more scalable form of confidence. It is also the right response to computational irreducibility. You may not be able to perfectly predict the model, but you can shape the environment in which it behaves. You can narrow the task, isolate failure modes, and create feedback loops that convert ambiguity into structure.


Key Takeaways

  • Break one vague AI task into multiple verbs. Extraction, verification, and generation are usually different jobs and should often be separate steps.
  • Treat long prompts as a smell, not a badge of sophistication. More instruction often means more interference between goals.
  • Design for evaluation at each stage. If you cannot tell which step failed, your workflow is too monolithic.
  • Use the model where it is strongest: narrow, local judgment under clear constraints. Do not ask one prompt to become a whole product.
  • Think in systems, not incantations. Reliability comes from orchestration, not from one giant prompt doing everything at once.

The real lesson: intelligence scales by subtraction

The instinct in a new technology wave is always to add. More parameters, more context, more instructions, more automation. But one of the most important lessons from building with LLMs is that progress often comes from subtraction. Remove the extra role from the prompt. Remove the accidental ambiguity. Remove the hidden dependency between tasks that should not have been coupled in the first place.

That is not austerity. It is architecture.

When you design AI systems this way, you stop asking a model to be a magical all-purpose intellect and start using it as something subtler and more powerful: a sequence of constrained inferential steps, each doing one job well. In practice, that produces systems that are easier to trust, easier to improve, and often better at the ordinary inputs that matter most.

The most surprising insight here is that the path to more capable AI may look less like building a bigger brain and more like building a better society of small, specialized minds.

That reframes the whole problem. The question is no longer, “How do we write the smartest prompt?” The better question is, “How do we arrange intelligence so it stays legible, testable, and useful?”

And once you ask that, the answer becomes clear: start smaller than you think.

Sources

← Back to Library

Hatch New Ideas with Glasp AI 🐣

Glasp AI allows you to hatch new ideas based on your curated content. Let's curate and create with Glasp AI :)

Start Hatching 🐣