DEV Community: Alex Zerntev

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.