DEV Community: Alex Zerntev

Why AI Content Looks Good but Feels Wrong

Alex Zerntev — Mon, 02 Nov 2026 11:02:02 +0000

Software and AI engineers were among the early adopters of AI and have already gone through several phases of figuring out how to use it, what works, and what doesn't. Now the rest of the world is catching up, going through many of the same phases with some delay.

Although models are much more powerful today than they were back then (and will keep improving), some problems around AI slop remain. The solution isn't always for the models to magically become better. Some of these problems require users to develop new skills, judgment, and taste.

In this article, we'll discuss some of these problems and practical ways to address them.

What is slop?

AI slop refers to low-quality, mass-produced content generated by artificial intelligence with little human thought, creativity, or critical judgment. It often appears polished and convincing on the surface but lacks substance, originality, depth, or genuine insight.

AI slop isn't defined simply by the use of AI, but by the absence of meaningful human intention and quality control. Whether it's an article, image, video, or piece of software, the defining characteristic is that producing content becomes more important than creating something valuable.

In the AI engineering community, @swyx declared war on slop in December 2025, encouraging the community to produce high-quality content for a better internet.

The general problem

Most users approach AI with simple, lazy prompts, providing little direction about what they actually want. This saves an enormous amount of time, but it also often produces slop.

Why? Because of how these models are trained. They learn patterns from enormous amounts of existing content, and when given little direction, they tend to fall back on familiar, common patterns from their training. The result is often something statistically conventional: technically correct, perhaps even impressive at first glance, but lacking specificity, originality, and taste.

Humans are different. We bring our own experiences, preferences, knowledge, and intentions into whatever we create. Even when given the same task, different people will approach it differently.

AI can produce extraordinary results, but without sufficient direction, it often gravitates toward the generic. And while better models can reduce this tendency, they cannot always know what you consider good, what you are trying to communicate, or what makes something valuable to you.

That is where the user comes in.

Tools to avoid slop

Inspiration

Sometimes it's hard to even imagine what the desired result should look like. So before generating anything, it helps to do some research for inspiration.

Explore existing work, different styles, approaches, and techniques. Look at what others have created and try to understand what makes some examples better than others. Alternatively, ask AI to generate several different directions before committing to one.

This not only improves the quality of the final result but also helps you develop taste over time. The more you expose yourself to good work and consciously compare alternatives, the easier it becomes to recognize what you like and articulate what you want.

Eventually, you'll spend less time figuring out what to ask for and more time refining the things that matter.

Prompt engineering

One strategy to avoid slop is prompt engineering, which is a fancy term for writing good instructions.

Instead of giving AI a vague request, specify what you're trying to achieve, the intended audience, the desired style, the constraints, what should be included, and what should be avoided. The more relevant direction you provide, the less the model has to fill in the gaps with its own defaults.

Although this works well, there is a limitation: describing exactly what you have in mind with words can be surprisingly difficult. Sometimes you don't even know how to articulate what makes something good.

That's why references, examples, and visual material can be just as important as the prompt itself.

Iterations

Another strategy is to start with a simple prompt and then iterate.

Rather than attempting to describe the perfect result upfront, generate an initial version, identify what is wrong or missing, and ask the model to improve those specific aspects.

This approach works with or without elaborate prompt engineering. In fact, for many tasks, it is more practical than trying to anticipate every detail in advance.

The important part is not to accept the first result simply because it looks good enough. Treat it as a draft, evaluate it critically, and continue until it meets your expectations.

The real skill here is learning to recognize what needs to change and communicating it clearly.

Strategies for specific kinds of content

The principles above apply to almost everything AI can generate, but different kinds of content have their own challenges. Let's look at some practical examples.

Images

Imagine asking AI to "generate a picture of a house."

You'll probably get a perfectly recognizable house, but there's a good chance it will look like countless other AI-generated houses. Pleasant lighting, conventional architecture, carefully arranged surroundings, and that strangely familiar AI aesthetic.

The problem isn't that the model cannot generate interesting architecture. It's that you haven't given it any reason to choose something more specific.

Instead, start by looking for inspiration. Explore architectural styles, photography, paintings, lighting conditions, and compositions. Decide what kind of house you want, what atmosphere it should communicate, and which details matter.

For example, instead of a generic house, you might ask for a small brutalist concrete house on a rocky coastline, photographed on an overcast winter morning, with minimal vegetation and an asymmetrical composition.

You can also provide reference images rather than trying to explain everything in words. Then iterate on the result, changing the composition, lighting, materials, or individual details until it feels right.

But don't just look at the overall picture. Observe the details. Does everything look consistent? Are the shadows and reflections correct? Are there architectural elements that make no sense, like a door with two knobs on the same side, stairs leading nowhere, or windows with impossible geometry? Zoom in, inspect the image carefully, identify mistakes, and iterate on them. Sometimes fixing a few small details makes the difference between an obviously AI-generated image and a convincing one.

The goal isn't necessarily to write longer prompts. It's to make deliberate creative decisions instead of leaving them all to the model.

Videos

Video generation introduces another dimension: time.

A video might look impressive frame by frame, yet feel artificial because of its pacing, camera movements, transitions, or the way objects behave. AI often defaults to dramatic camera movements, cinematic lighting, and exaggerated action because these create immediately impressive results.

But impressive doesn't necessarily mean good.

Before generating a video, think like a director. What is happening in the scene? Where is the camera? What moves, what stays still, and how long should the shot last? What emotion should the viewer experience?

Instead of asking for "a cinematic video of a city," you could describe an eight-second static shot of a rainy street at night, with a single cyclist passing through the frame and reflections moving across the pavement.

For more complex videos, break the idea into individual shots, plan their sequence, and generate them separately. Pay attention to visual consistency, continuity, and pacing during editing.

Then watch the generated video critically, preferably more than once. Do objects suddenly change shape or disappear? Do people's movements look natural? Are the lighting, shadows, and surroundings consistent between frames? Does the camera move in a physically plausible way? Look for subtle mistakes that might be easy to miss on the first viewing. Regenerate problematic shots or adjust the instructions until the inconsistencies are resolved.

Often, restraint produces a more convincing result than spectacle.

Music

Music is particularly interesting because people can recognize something that sounds generic even when they cannot explain exactly why.

Ask AI to generate "epic background music," and you'll likely get something that follows familiar patterns: predictable chord progressions, dramatic buildups, conventional instrumentation, and an obvious emotional direction.

It might sound professionally produced, but that doesn't mean it has character.

The solution is to approach music generation with some understanding of musical structure. Think about the instruments, rhythm, tempo, dynamics, harmony, and progression of the piece. Listen to music you admire and try to understand what makes it distinctive.

For example, rather than asking for "sad cinematic music," you could request a slow instrumental piece built around sparse piano notes and low strings, with unresolved harmonies, long silences, and tension that gradually increases without reaching a dramatic climax.

Generate alternatives, listen critically, and refine individual aspects. Sometimes removing an instrument or simplifying the arrangement improves the result more than adding complexity.

Pay attention to the details when listening. Do the transitions between sections feel natural? Are there strange changes in tempo, instruments that suddenly appear or disappear, unnatural vocals, or noticeable audio artifacts? Does the composition develop in a meaningful way, or does it simply repeat familiar patterns? Identify the parts that don't work and regenerate or edit them instead of accepting the entire track as it is.

Musical taste, just like visual taste, develops through listening, comparison, and experimentation.

Copy and text

AI-generated writing is probably one of the most common forms of slop, partly because it's so easy to produce and so easy to publish.

It tends to be grammatically correct, well-structured, and polished, yet strangely empty. Generic introductions, unnecessary explanations, predictable conclusions, exaggerated enthusiasm, and phrases that sound impressive without saying very much.

The problem becomes especially apparent when people ask AI to write about a subject without contributing any original thoughts.

Before asking AI to write something, decide what you actually want to say. What is the central argument? Why is it worth reading? What observations, experiences, or examples do you have that the model wouldn't know?

For instance, instead of "write a LinkedIn post about AI and software," provide your actual argument, your reasoning, and the tone you want. You might even write a rough draft yourself and ask AI to improve its structure, clarity, and grammar without changing your voice.

Providing samples of writing you admire can also help, as can explicitly asking the model to avoid clichés, unnecessary adjectives, or generic conclusions.

One particularly useful approach is to use AI as an editor rather than an author. Let it challenge your arguments, identify weak passages, suggest improvements, and help you express your own ideas more clearly.

And always read the result carefully. Does the argument make sense from beginning to end? Are there contradictions, repetitions, or paragraphs that don't add anything? Are there factual claims that need verification? Does the text actually communicate your ideas, or has the model introduced opinions and conclusions you never intended? Remove unnecessary content, verify the facts, and keep iterating until every paragraph serves a purpose.

Good writing begins with having something worth saying. AI can help you say it better, but it shouldn't replace the thinking behind it.

Web design

AI-generated websites have developed their own recognizable aesthetic.

Ask an AI coding tool to build a landing page, and you will often get a familiar combination of oversized headings, gradient backgrounds, rounded cards, generic icons, and a hero section that looks like a thousand other SaaS websites.

The copy often suffers from the same problem. Headlines like "Unlock the Power of AI," "Transform Your Workflow," or "Take Your Business to the Next Level" might sound professional, but they communicate almost nothing. Entire sections can be filled with marketing language that never explains what the product actually does or why anyone should care.

The result might be responsive, functional, and technically well-built, yet have no visual identity or meaningful message.

To avoid this, approach AI-assisted web design the way a designer would. Start with inspiration from existing websites. Study their typography, spacing, color palettes, composition, navigation, and use of imagery.

More importantly, think about the purpose of the website. Who is the audience? What should visitors notice first? What actions should they take? What impression should the design communicate?

The copy deserves just as much attention as the visuals. Define the message before generating the page. What problem does the product solve? What makes it different? Can a visitor understand its value within a few seconds? Write headlines that say something specific, descriptions that provide useful information, and calls to action that clearly explain what happens when clicked. Avoid filling space with meaningless marketing phrases or unsupported claims.

Instead of asking AI to "build a modern landing page for an analytics product," you could specify an editorial layout with restrained colors, strong typography, generous whitespace, real product screenshots, and a clear hierarchy that prioritizes the product over decorative elements. Provide the actual product description, its main benefits, and the message you want the website to communicate rather than letting the model invent them.

References are especially powerful here. Providing screenshots or an established design system often works better than describing a visual direction through adjectives alone.

And don't stop once the website renders correctly. Inspect individual sections, evaluate spacing and alignment, test different screen sizes, and iterate on the details.

Look closely for inconsistencies. Are the margins and paddings consistent? Do buttons, icons, and typography follow the same design language? Are elements properly aligned? Does the layout break on smaller screens? Are there buttons that don't work, awkward text wrapping, or accessibility issues such as insufficient contrast?

Read through all the copy as well. Does every headline communicate something useful? Are there repetitive sections, vague promises, or sentences that sound impressive but mean nothing? Is the terminology consistent across the website? Does the text match what the product can actually deliver? Go through the website as an actual visitor would, test its functionality, question its messaging, and fix what doesn't feel right. Small inconsistencies accumulate, and they can make an otherwise good website feel unfinished.

A website that works is not necessarily a website that is well designed. Functionality, communication, and taste are different problems, and all deserve attention.

Say no to slop

It's understandable that not everyone has time for research, iterations, and careful prompt engineering in a fast-moving world. AI makes it tempting to take the easiest route and publish whatever comes out. But these easy gains can come at a long-term cost. People notice when something lacks thought or effort, and over time, they become less likely to pay attention to or trust the person behind it.

The consequences go beyond individual creators. Flooding the internet with slop produces enormous amounts of noise, making genuinely valuable content harder to discover. The more we produce without considering quality, the harder it becomes for everyone to find something worth their attention.

AI has made producing content almost effortless. But making something worth consuming still requires thought, intention, and taste. If anything, those qualities have become more valuable than ever.

Old Software, New Hands

Alex Zerntev — Tue, 20 Oct 2026 14:35:57 +0000

In the age of AI, anyone can build an application for their specific need without ever looking at the code. So is traditional software dead? Far from it.

Software exists to solve problems, and much of the work is defining the problem precisely and then designing a solution that solves it well. Software companies have spent years doing exactly that, shaped by feedback from real users. Even if AI becomes good at writing requirements and maintaining code, why rebuild a solution that already works? Existing software carries years of experience with real problems.

So let’s start with the claim that “everyone can build a SaaS now,” and then look at what AI actually changes about software: not who builds it, but who operates it.

Building software takes more than code

Models keep getting better. Ask for something specific and they will build it, and build it well. The hard part is knowing what to ask for.

Take building your own ERP. You have to decide where it runs, how it handles exceptions, how it scales, how it stays secure, and what the UI should look like, which is hard to get right without real research. Then you have to maintain it, extend it, and adapt it as requirements change. Even with very good models, none of this is trivial. An app nobody designed, only generated, feels great in the first week; a year later it can easily be a liability.

For a small personal tool or a one-off task, building your own software makes sense. You know who will use it, and the requirements are narrow. The harder case is software that other people depend on every day and expect to keep working as their needs change.

Traditional software companies have answered these questions over years, and keep answering them, because they have the best validation mechanism there is: real users. Those answers become part of the product, including workflows and edge cases a new builder hasn’t encountered yet.

The main benefit of models as coders is speed. Being able to build anything matters less than shortening the loop between an idea, a working version, and feedback from real users. That speed helps existing software companies too: they can use it to test and improve what they already have.

A product still needs users

Building faster helps, but turning that software into a business raises a different question: who will use it? Software needs users, whether people or agents, to be viable. And that introduces a second bottleneck: distribution.

When everyone can build software, competition grows, the market noise becomes overwhelming, and even a well-designed, carefully thought-out product might not make it. Getting something built does not mean getting it adopted. Software remaining useful does not guarantee that today’s software companies or business models will remain successful.

This makes an existing user base a real advantage, but not a permanent moat. For traditional software companies, those customers represent trust, distribution, and years of feedback that competitors cannot copy overnight.

That advantage depends on adapting to a new kind of user: the agent. Products will need reliable APIs and agent-facing interfaces, including protocols such as the Model Context Protocol (MCP), permissions and approval flows designed for automation, and infrastructure able to handle many agents working at once. Companies that make their products easy and safe for agents to operate can strengthen their position. Companies that fail to adapt, however, leave an opening for competitors, regardless of how many customers they have today.

Agents as operators

The same thing that makes established software difficult to reproduce also makes it valuable to agents: it already contains years of knowledge about how work gets done. Its workflows, business rules, data structures, and handling of exceptions have been developed and refined through real-world use.

An agent doesn’t need to rebuild all that knowledge to benefit from it. Instead of building a new application from scratch, it can operate the software that already exists. The product provides the capabilities, while the agent understands what you want to achieve and coordinates those capabilities to get the work done.

Let’s return to the ERP example. Imagine asking an agent to replenish stock for next month. The agent could check expected demand, compare suppliers and prepare a purchase order. The ERP would provide stock records, purchasing rules and order history, and track the order once placed. The agent could use these capabilities without rebuilding the inventory system.

Coordinating that same purchase with accounting and delivery planning would extend this from operating one application to managing a workflow. The existing software becomes the foundation on which the agent can take on more of the work.

OpenClaw offers an example of what it looks like when agents can do more than answer questions. It runs on its own machine, communicates through the chat apps you already use, and remembers your projects across conversations. With the appropriate permissions, it can navigate websites, fill out forms, read and modify files, execute shell commands, and operate other tools. Skills and plugins extend its capabilities, and it can even create reusable skills from workflows it has learned. That is the shape of the thing: an agent that operates existing software, grows with the work you give it, and belongs to you.

But moving from a personal assistant to an enterprise operator is not simply a matter of giving an agent more access. Companies need clearly defined responsibilities, permissions limited to each agent’s role, human approval for consequential actions, audit trails, and reliable ways to handle exceptions, especially when many agents operate across the same systems.

OpenClaw Enterprise takes the concept a step further, bringing multi-tenancy, isolated agent workloads, scoped permissions, and governance to the OpenClaw model. These are the foundations for moving from personal assistants to agents that can take responsibility for processes across an organization.

A prediction for the future

My prediction is that, in the not-too-distant future, you will open an agentic app, connect it to your company’s software and data, and let it learn how the business operates. It will start with specific tasks, within the permissions and approval boundaries you set. As it proves reliable, you will delegate processes that span multiple systems. With enough context, it will begin identifying bottlenecks, suggesting improvements, and eventually proposing opportunities for expansion and longer-term strategies for growth.

OpenClaw helped popularize this model of agents that actively operate software. Its rapid rise brought the idea into the spotlight, and other projects are now following its lead, each taking the concept further in its own direction:

Grok Bot is a team of always-on agents with their own cloud computer. Show a Bot a workflow once and it runs it as a routine; the team describes an ops Bot processing invoices from Gmail and an engineering Bot reproducing a bug, filing the ticket, and handing the fix to another Bot.
Muse is Meta’s agent for billions of people, each running on its own secure VM with a separate Sentinel gating what reaches the internet. It takes a goal, builds a plan, and keeps working after you close the app.
Hermes Agent, from Nous Research, is the other serious open-source contender: self-hosted, builds its own skills from problems it has solved, and runs scheduled reports and briefings unattended.
OpenAI’s dots have their own cloud computer and plugins into over 4,000 apps. An early tester’s dot noticed an unbilled job, prepared the invoice, and sent it after approval. Specialist dots, now in preview, take on defined responsibilities like procurement and invoice processing inside a company.

These examples show individual tasks and workflows being handed to agents, not entire businesses being run autonomously. The next step is connecting these workflows into the way an entire company operates, with the responsibilities, permissions, and oversight discussed earlier.

As that responsibility grows, deciding what we want agents to achieve matters more, not less. People still define what improvement means: lower costs, faster delivery, better service, or something else. An agent can propose changes and carry them out within agreed limits, while people judge the results. The difficulty of defining the right problem remains, even when most of the execution can be delegated.

Software still matters in that future. It provides the records, rules, and tested capabilities the business depends on. What changes is how we use it: we describe what we want to achieve, and an agent coordinates the work across the tools we already have, building additional capabilities only where needed.

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.