DEV Community: Alex Zerntev

Reality Doesn’t Fit in a Prompt

Alex Zerntev — Tue, 28 Jul 2026 14:33:26 +0000

LLMs took the tech industry by storm and changed our relationship with machines. They can answer questions, reason through unfamiliar problems, and increasingly act on our behalf. Yet something still feels absent. A model can process a description of what is, but it does not share the lived context from which we decide what should be. That gap is what I want to explore.

How we got here

In 2022, ChatGPT launched and went viral. Everyone was amazed and excited. Yet by mid-2024, what a pure LLM could do had started to plateau. Then reasoning arrived, and the ceiling moved again. Models stopped merely answering and became genuinely capable of acting on your behalf. Agentic systems followed. Now the ambition is to let models perceive and act in the world more directly. Notice the pattern: every leap came from giving the model more room to see and act. And yet, as amazing as they are, LLMs still don't feel like Artificial General Intelligence (AGI).

How humans operate

Evolution made us state machines of a kind. Every waking moment, you are observing "What is" and deciding to act on "What should be". You are doing it right now, reading this. The mechanism is so sophisticated that we cannot comprehend it, and it is running you regardless. A way of evolution to navigate an infinite world.

The two loops run in parallel. "What is" continuously consumes memory and sensory information. "What should be" continuously produces actions. Walk into a room and before you have formed a single word, you have already read the situation and know what needs doing. That takes milliseconds and fires an incomprehensible number of neurons.

This is also how we model agents - only far more primitively. Nature had a few billion years of a head start.

The Limit

There is a huge gap in complexity between how humans operate and how LLMs do.

Pick the simplest object near you and try to describe it completely. Not usefully - completely. You will find that every sentence you write demands three more. What it is made of, why it is here, what it is not, what you would notice if it changed. Description never bottoms out. A single chair is already infinite.

And you hold thousands of these at once, effortlessly, without a word. That is what "What is" actually means.

So the real limit is not the size of the context window. Even at a billion tokens, an infinite state has to squeeze through the narrow straw of what you can type. That is the bottleneck.

The Workaround

So we built a workaround. The chat box is not really an interface, it is a compressor. You hold the infinite state, you decide what matters, you type a few sentences, and the model acts on that thin slice.

It works remarkably well. Well enough that we stopped noticing how strange it is: the most capable software ever built, waiting for a human to tell it what the situation is.

But the compression is lossier than it feels. Depending on the state you are in, the same words mean different things to you - and you are often not aware of which state that is. So the summary you type is not just incomplete, it is unstable. You cannot transmit what you cannot see in yourself.

That is a partnership, not an intelligence. And notice who does the hard part.

Where human judgment enters

That bottleneck is already narrowing. Agents can search documents, observe screens, perceive their surroundings, and act through tools. The more they can perceive directly, the less they depend on us to compress reality into a prompt. But access to information is not the same as judgment. A model may see the same artifacts you see without knowing which constraints matter, which risks are acceptable, or which outcome is worth pursuing.

You have had this moment. You describe a situation, the model responds with something confidently wrong, and you think: why don't you get it?

Often, the problem is not its reasoning but the context and priorities it does not share. Even a perfect prompt cannot encode everything you know, because much of what you know was never put into words.

This is what human judgment actually does, and it is easy to miss because it feels effortless. You absorb knowledge across a lifetime, recall the fragment that matters, and correct yourself through feedback you barely register. Then you decide what should be done. Current models can increasingly access the same information, but information alone does not determine what matters.

But be honest about the other side. When a model has enough context and a bounded set of actions, it is already excellent. At RAW Labs we've developed Kora: not to make an agent understand the entire world, but to define a world small enough for it to act reliably. Humans provide the context, constraints, and purpose; the model operates within them.

Kora does not remove the narrow straw. It engineers it.

Conclusion

One clarification: I deliberately wrote LLM and not AI. AI is a broader concept, and something beyond today's models could surpass these limitations. Nobody can predict that, and anyone who claims otherwise is selling something.

Models will perceive more, and the boundary between human and machine judgment will continue to move. But the central problem remains: intelligence is not only processing what is. It is deciding what matters and what should happen next. For now, humans close that loop - either directly or by designing the context in which machines can act.

Sources
AI Engineer - Daniel Han talk

Maps of meaning - Dr. Jordan B. Peterson

Constrained Space, Better Code: MXCP & Claude Skills

Alex Zerntev — Mon, 12 Jan 2026 09:41:36 +0000

Introduction

Large Language Models have become remarkably effective at software development tasks, from navigating large codebases and refactoring complex logic to identifying bugs and generating working implementations with impressive speed. At the same time, they can just as easily break a functioning system, introduce subtle errors, or produce code that looks correct but fails in practice, a behavior that follows directly from how LLMs generate code in a largely unconstrained space. When there is no built-in validation, the gap between productive automation and failure becomes thin, making reliability the central challenge in real-world systems.

In this post, we explore how Claude Code, when augmented with Skills and operating inside the MXCP framework, addresses this challenge by deliberately restricting the coding space and reinforcing correctness through structure and feedback. Skills provide concrete, in-context knowledge about how MXCP is intended to be used, while the framework constrains generation to a small set of well-defined, valid operations and enforces schemas, constraints, and operational guarantees. In real-world projects, this combination has enabled Claude Code to generate even complex MXCP-based MCP servers with minimal guidance, reducing development timelines from weeks to days while increasing confidence in correctness and stability, and providing a predictable path toward production-ready systems.

A Core Problem: Unconstrained Generation

At their core, LLMs are probabilistic token generators. Given a prompt, they predict the next token based on learned patterns, not on an understanding of correctness or system constraints. The space of possible tokens they can produce is effectively infinite, while the subset that represents valid, safe, and useful code within a real system is relatively small. When this output space is left unconstrained, even highly capable models are forced to guess what “valid” looks like. Small variations in context or probability can then push the model toward drastically different outcomes - some correct, others destructive. The fundamental problem is not model intelligence, but the absence of boundaries that define what is allowed to exist.

Why Validation Changes Model Behavior

![Validation feedback loop: LLM Agent generates code, which goes through validation (tests, schemas, type checks, runtime assertions). Pass results in valid output; failures feed back as error signals allowing the agent to adjust and retry.]

Validation introduces feedback, something raw LLM generation fundamentally lacks. Without validation, a model can only optimize for plausibility - producing code that looks correct but may fail at compile time, runtime, or under real workloads. When validation mechanisms such as tests, schemas, type checks, or runtime assertions are built into the system, they provide an explicit signal of success or failure. This signal allows the model to iteratively adjust its output, converging toward correctness rather than guessing it in a single attempt. Validation does not make the model smarter; it makes the environment smarter, transforming one-shot generation into an adaptive process grounded in observable outcomes.

Structural Constraints, Not Better Prompts

A software framework is a reusable, semi-complete application that provides a predefined structure for developing software by defining control flow, extension points, and common functionality.

Frameworks are the mechanism through which constraints and validation become enforceable. Instead of relying on prompts to describe what a model should or should not do, frameworks encode these rules directly into the system. They restrict the model’s output space by exposing only valid operations, enforcing schemas and types, and embedding domain rules into the execution flow.

In such systems, invalid states are impossible to express. By shaping the environment in which generation occurs, frameworks turn probabilistic models into reliable components, ensuring that creativity exists only within well-defined boundaries.
![Frameworks constrain the action space of coding agents. The environment, not the prompt, governs what is valid or invalid.]

Familiarity Matters: When Models Know the Framework

Frameworks only provide their full benefits when the model understands how to use them. If a framework is widely adopted and well represented in training data, LLMs tend to perform extremely well. A common example is frontend development: code generated with React is often significantly higher quality than equivalent implementations written in vanilla HTML and JavaScript. The model has seen enough real-world React code to internalize its patterns, conventions, and best practices.

The situation changes dramatically when the framework is custom or poorly represented in training data. In those cases, the model has no reliable prior knowledge to draw from and is forced to rely on guesswork. Sometimes this guesswork succeeds, but just as often it produces incorrect, inconsistent, or entirely unusable output. Without additional structure, the benefits of a framework alone are not enough.

Claude Skills to the Rescue

Claude Skills, developed by Anthropic, provide a powerful solution to this problem. Skills allow developers to preload useful information, scripts, references, and assets that support in-context learning when working with a framework. Instead of relying on vague natural language descriptions, the model gains access to concrete, executable knowledge about how the framework should be used.

By embedding this information directly into the model’s working context, Skills effectively “train” the agent at runtime. This dramatically reduces guesswork and aligns the model’s behavior with the framework’s intended design. When combined with a constrained and validated environment, Skills enable LLMs to work reliably even with custom or domain-specific frameworks.

Generating an MCP Server: A Concrete Example

The Model Context Protocol (MCP) is a widely used protocol designed to enable communication between agents and systems. While there are multiple MCP implementations across different programming languages, they all share a common characteristic: the developer is free to implement almost anything. This flexibility is powerful, but it comes at a cost.

Building a reliable MCP server requires far more than just implementing protocol handlers. Production-grade systems need observability, logging, validation, testing, authentication, and policy enforcement. Implementing these concerns repeatedly results in large amounts of boilerplate code. This boilerplate significantly increases the number of tokens that must be included in the model’s context for effective code generation, which directly increases cost. It also creates long-term maintenance problems: copying and adapting similar MCP servers across projects leads to divergence, fragility, and codebases that are difficult for both humans and LLMs to reason about.

This is a textbook case for introducing a framework.

MXCP: A Production-Ready MCP Framework

Most LLM-driven agent workloads follow a small number of recurring patterns: CRUD operations over data and the execution of custom business logic. MXCP is built around this observation and deliberately restricts the execution space to three well-defined domains: YAML for endpoint definitions, SQL for data access (over any supported data source), and Python for custom logic.

With MXCP, developers define MCP endpoints declaratively using a YAML schema that specifies inputs and outputs. The executable behavior of each endpoint is then implemented using either SQL or Python - YAML handles the "what," while SQL and Python handle the "how." This design dramatically narrows the space of possible implementations. While the space remains theoretically infinite, it is constrained to forms that are predictable, auditable, and easier for models to generate correctly.

MXCP also provides built-in support for observability, logging, drift detection, policy enforcement, and authentication. Because these concerns are handled by the framework, the coding agent does not need to generate, read, or maintain large volumes of boilerplate code. This reduces context size, lowers token costs, and improves generation quality.

Validation as a Feedback Loop

Restricting the implementation space is necessary, but it is not sufficient. Even within a constrained framework, the space of possible implementations remains infinite - just a much smaller and more structured infinity than unconstrained code generation. Models can still make incorrect assumptions, misunderstand requirements, or choose suboptimal implementations within those bounds.

This is where validation becomes essential. MXCP provides multiple layers of validation and testing that create explicit feedback loops for the coding agent:

mxcp validate - schema validation and type checking
mxcp test - end-to-end unit tests for MCP endpoints
mxcp lint - quality and consistency checks for MCP implementations
mxcp evals - evaluation of how well different models understand and interact with the MCP server
Custom unit tests - project-specific validation logic

Each layer further narrows the effective space the model can operate in. While the theoretical space of valid implementations remains infinite, repeated validation collapses it toward a subset that is correct, maintainable, and production-ready. The coding agent is no longer exploring an open-ended search space, but iterating within a guided process where failures are observable and correctness is reinforced. Reliability, in this setup, is not assumed - it is converged upon.

Real World

In real-world projects, Claude Code paired with the mxcp-expert skill has been able to generate even highly complex MXCP servers with minimal guidance. Tasks that previously required weeks of development were reduced to a single day at most, while confidence in correctness and stability increased significantly. We are now on track to automate the entire MCP server development process. This improvement did not come from better prompts, but from operating within a constrained and validated framework.

The relationship between the user, the coding agent, and the MXCP framework is inherently multidirectional. The user defines intent and reviews outcomes, the coding agent generates implementations and iteratively validates and tests them through MXCP, and the framework itself enforces structural and safety guarantees. In this setup, the agent not only produces code but also actively prevents critical failures - for example, by avoiding secret exposure, a class of errors Claude Code is explicitly designed to guard against.

Evaluation

We have observed these patterns consistently across multiple production projects. To make the difference concrete, we ran a controlled comparison: two identical Claude Code sessions were given the same task. One session used the MXCP framework with the mxcp-expert skill, and the other used the pure MCP Python SDK with mcp-creator skill. The goal was not to prove that one approach is more capable, but to show how constraints and built-in validation affect reliability, iteration count, and implementation complexity.

The task: Build a production-ready e-commerce MCP server with 9 tools: CRUD operations (create_product, get_product, update_product, delete_product, list_products), analytics (get_sales_summary, get_category_stats, get_low_stock_report, get_top_sellers), and role-based authentication (admin-only vs public access). The server must use parameterized queries, validate all inputs, implement soft deletes, and pass all validation checks. The database includes 20+ products across 4 categories and 50+ sales records.

MXCP produced 65% less code (843 vs 2,404 lines), used 70% fewer output tokens (~15K vs ~50K), and completed 50% faster (5 min vs 10 min). Both implementations delivered all 9 tools with identical functionality: parameterized queries, input validation, role-based authentication, and proper error handling. The pure MCP version required 3x more test cases (56 vs 18) to achieve similar coverage - a direct consequence of having to test manually what MXCP validates by design. The difference is how reliably the framework guides generation toward a clean, production-ready result.

Follow-up: Extending the Implementation

Initial implementation is only part of the story. Real-world systems evolve as requirements grow. To simulate this, we ran a follow-up experiment: a user returns one month later to extend the existing implementation with features typically required for production - additional policies, a complementary CSV data source for cross-queries, auditing, observability, and LLM evals.

The extension task: "Consume a complementary CSV data source for cross-queries, add relevant policies, enable auditing and observability, and include LLM evals."

The MXCP extension was straightforward: policies are declarative CEL rules, CSV data sources are configured in YAML, auditing and observability are single-line configuration toggles, and LLM evals are defined alongside tool definitions. Features that required additional code in MXCP are features the framework was designed to support - the agent simply activated them.

The pure MCP extension tells a different story. Adding the same features required implementing policies from scratch (669 lines), building an observability module (650 lines), creating an auditing system (560 lines), and developing CSV tools (478 lines) - each with comprehensive tests. The agent consumed ~110K tokens and exhausted the context window, requiring careful management to complete. What MXCP enables with configuration, pure MCP requires as custom infrastructure.

The workflow difference matters. MXCP provides a single path: mxcp init, write YAML and Python, then mxcp validate, mxcp test, mxcp lint - all integrated, all immediate. Pure MCP requires assembling project structure, tests, and quality checks manually using pytest, ruff, and mypy. The MXCP implementation is declarative - endpoints in YAML, validation in schemas, tests alongside definitions. The pure MCP version concentrates more logic in custom Python, which works but requires more coordination to get right. The framework does not remove work - it standardizes it, making successful outcomes easier to reproduce.

During the pure MCP implementation, the agent encountered database concurrency issues that required additional debugging and iteration to resolve - a common problem when building data-driven services from scratch. MXCP handles connection pooling and concurrent access by default, eliminating this entire class of issues before they occur.

Both approaches passed their validation suites. The framework trades some flexibility for guardrails, and in LLM-driven development those guardrails translate directly into more consistent results. But the difference extends beyond correctness - MXCP includes production concerns that pure MCP leaves as future work:

These gaps are manageable in a small project, but they compound as systems grow. The pure MCP implementation shows patterns that degrade with complexity: tight coupling, validation logic that can drift from schemas, and no hooks for cross-cutting concerns. MXCP addresses these at the framework level - observability, authentication, and policy enforcement are part of the execution model, not afterthoughts. When an LLM generates within MXCP, it inherits those guarantees automatically. The framework does not just constrain what can be generated - it makes the default output closer to production-ready.

Conclusion

LLMs can act as autonomous authors of software, but reliability emerges from the systems they operate within. Their probabilistic nature is not a weakness to be eliminated, but a property to be shaped through structure and feedback. By restricting the space of valid outputs and introducing validation as a continuous signal, frameworks like MXCP turn autonomous generation into predictable execution. As the evaluation shows, these constraints reduce iteration, cognitive load, and failure modes while improving production readiness. In practice, reliability at scale comes from environments that encode boundaries, guarantees, and verification, not from prompts alone.