DEV Community: Aleks

What If Your AI App Didn’t Need All Those Services?

Aleks — Wed, 11 Nov 2026 16:00:00 +0000

Originally published on Harper. I’m Senior Manager of GTM at Harper.

The first generation of AI applications has largely been built by adding systems. Start with an application and a database, then add an LLM. Add a vector database for semantic retrieval, an embedding service to populate it, a search engine for exact retrieval, a cache to control latency and cost, and an agent framework to coordinate everything. Background jobs, queues, schedulers, and observability often follow.

Each of those technologies may be excellent at what it does. The architectural problem is what happens between them. Every boundary introduces another network call, another credential, another deployment, another place for state to become inconsistent, and another system a team has to understand and operate.

As AI moves from experimentation into production applications, that complexity matters more. Intelligent applications increasingly need data, search, business logic, models, permissions, and application state within the same interaction. When each capability lives in a different system, even a relatively simple request can become a distributed-systems problem.

There is another way to think about the AI stack: instead of adding more infrastructure around the application, move more of those capabilities into the application runtime itself.

A common assembled AI stack

The individual technologies may all be excellent. The architectural cost comes from everything between them: network calls, credentials, duplicated state, synchronization, deployments, and operational ownership.

AI applications are becoming a loop

Strip away the terminology and many AI applications perform some version of the same process: find the right information, understand what it means, decide what should happen, take an action, and learn from the result.

A support application might retrieve account history and relevant documentation, interpret what a customer is asking, classify the request, trigger the appropriate workflow, and record the outcome. A commerce application might retrieve products and customer context, understand shopper intent, decide which experience to present, respond, and use the result to improve what happens next.

Today, those steps are often distributed across different technologies. Full-text search finds exact words. Vector search retrieves information based on semantic similarity. A model interprets the request. An orchestration framework determines which tools to call. Application code applies the business rules, while databases and caches maintain the state required throughout the process.

The result works, but the application spends a surprising amount of its time and money (infrastructure) moving context between systems.

What if more of that happened inside the runtime?

Harper has always approached application architecture from the opposite direction. Instead of treating the database, application server, cache, messaging layer, and APIs as separate systems by default, Harper brings those capabilities into a single process on a multi-threaded unified runtime.

Over the last several releases, that same architectural philosophy has increasingly extended into AI. This is the more important story behind Harper 5.0 through 5.3. The individual features matter, but together they point toward a different model for building AI-enabled applications.

The goal is not to create another AI framework or to replace the models developers already want to use. It is to reduce the amount of infrastructure required around those models.

The AI application on Harper

The model can still live elsewhere. What changes is everything around it. Retrieval, state, application logic, permissions, decisions, and orchestration can operate within the same runtime.

That distinction is important. The argument is not that every model should somehow run inside Harper. The opportunity is to collapse much of the infrastructure surrounding the model, so the application can reach its data, retrieval capabilities, business logic, and AI services without traversing a long chain of systems.

The pieces have been coming together

This direction did not appear suddenly in Harper 5.3. The architecture has been developing over several releases.

Harper 5.0 established much of the foundation. Harper became fully open source at the core, expanded its storage capabilities, and continued the move toward a runtime where data and application logic can operate together. For AI applications, that smaller surface is significant because both developers and agents have fewer infrastructure boundaries to understand.

Harper 5.1 made AI a direct capability of the runtime. Applications gained a common interface for generating text and embeddings across model providers. Embeddings could be generated automatically as data was written. Harper added a built-in MCP server so AI clients could discover and invoke application operations directly, and model-driven applications could execute tool-calling loops without introducing another orchestration service solely to connect those pieces.

Harper 5.2 focused heavily on making these architectures practical at production scale. Vector retrieval became more efficient, application-level filtering could participate directly in retrieval, and capabilities such as scheduling, secrets management, caching, and routing continued moving closer to the application itself.

With 5.3, two additional pieces make the broader direction easier to see: native full-text search and model-assisted decisions.

The releases matter less as isolated feature lists than as a progression: more of the intelligent application can operate within the runtime.

Search is not one problem

Vector search has become closely associated with AI because it can find information based on meaning rather than exact wording. That makes it particularly useful for retrieval-augmented generation and other applications where a user's language may not exactly match the underlying content.

But semantic similarity is not the answer to every search problem. Sometimes the exact words matter. A query for a product number, policy name, error message, contractual term, or specific phrase may be better served by full-text search.

Modern AI applications often need both. A useful way to think about the distinction is that full-text search helps an application find the words, while vector search helps it find the meaning. Harper can now perform both alongside the data and application logic they serve.

Find the words. Find the meaning. Apply judgment.

From generating answers to making controlled decisions

Most conversations about AI applications begin with generation: send a model some context and ask it to produce text. But many production workflows do not actually need another paragraph of generated language. They need a judgment.

Should this support request go to billing, refunds, or engineering? Does this new product belong in one category or another? Is this alert a duplicate, something worth investigating, or noise? In each case, the possible actions are already known. The application needs the model to help choose among them.

This pattern has recently gained more attention through Jev and other decision-model approaches. Jev is a useful reference because it makes the distinction easy to see: instead of asking a model to freely generate an answer, give it a bounded set of possibilities and ask it to judge which one best fits the input.

The underlying pattern, however, is broader than Jev or any one specialized model. Small inference models have performed classification and ranking tasks for years, and modern language models can perform the same kind of bounded judgment alongside their generative capabilities. What changes is how easily that judgment can become a first-class part of application logic.

Harper 5.3 exposes that pattern directly through models.decide().

An application provides the context and defines the allowed answers. Harper asks the configured model to evaluate those choices and returns both the selected value and a score for each permitted alternative. For example, an incoming request might be evaluated against billing, refund, or bug.

The important part is not simply that the model chooses billing. The application also receives information about the alternatives, which gives it something concrete to act on. A strong result might continue through an automated workflow. An uncertain result might be sent for human review. A separate “none of these” score can indicate that the choices themselves may not adequately describe the request.

The model contributes judgment, but the application retains control over what the possible actions are and what happens after the judgment is made.

That makes decisioning a useful middle ground between traditional deterministic software and open-ended generation. Business rules can continue handling the situations where the answer is known precisely. Generation can handle tasks where new language or content is required. Decision models handle the increasingly important space between them: situations where software knows the available actions but needs contextual judgment to choose among them.

And because models.decide() is an interface rather than a Jev-specific feature, the underlying model can change. A highly optimized decision model such as Jev could sit behind it. A local model could serve the decision. A general-purpose LLM could do the same job. The application's decision contract does not have to change with the model.

Harper can also persist those decisions and associate them with later outcomes. That creates a path toward evaluating how different models behave on an organization's actual workloads and establishing automation thresholds based on observed results rather than assuming that a model score corresponds directly to real-world accuracy.

From model input to application decision

Jev helped bring attention to decision models, but the broader pattern is more important: applications can ask models for bounded judgments without handing control of the workflow to the model.

Search finds evidence. Decisions turn it into action.

This is where the retrieval and decision capabilities start to fit together. Full-text search can retrieve information when the exact words matter. Vector search can retrieve information based on meaning. The resulting context can then inform a bounded decision about what the application should do next.

The model does not have to invent the workflow. It does not need authority over the application. It helps evaluate the evidence within a set of choices the application already understands.

That is a subtle difference, but potentially an important one as AI moves deeper into production systems. Search helps the application find the evidence. Decision models help interpret it. Application logic remains responsible for what happens next.

Fewer systems changes more than the architecture diagram

Infrastructure consolidation is often described in operational terms: fewer services, fewer vendors, and fewer things to deploy. Those benefits are real, but intelligent applications make the implications larger.

AI interactions frequently require context from several sources before the application can do anything useful. When data, retrieval, application logic, permissions, model access, and workflow coordination all sit behind separate service boundaries, that context constantly moves across the network. Each transition introduces latency, consumes resources, expands the security surface, and creates another potential failure point.

Bringing more of those capabilities together changes the economics of the request itself. Less data has to cross service boundaries, fewer systems need to coordinate the same operation, and fewer infrastructure components need to scale independently.

The fastest network call is still the one an application never needs to make.

This is not about replacing the model

Models are evolving rapidly, and organizations should be able to choose the providers and models that fit their requirements. Harper's architecture is designed around that assumption.

The model is a configurable capability used by the application. The application owns its data, state, permissions, business logic, allowed actions, and operational behavior. Models contribute generation, interpretation, or judgment where those capabilities are useful.

That separation also makes the architecture less dependent on any particular model provider. As models improve or organizations change providers, the surrounding application does not necessarily need to be redesigned with them.

The AI stack may be starting to consolidate

New technology categories often expand before they consolidate. The first generation of a new architecture naturally produces specialized systems for every emerging problem because those problems need to be solved quickly.

AI followed that pattern. Teams assembled databases, vector stores, search engines, embedding pipelines, agent frameworks, model gateways, caches, queues, schedulers, and application servers into increasingly capable systems.

The next phase may look different. Search does not necessarily need to be separated from the data being searched. Embeddings do not necessarily require a standalone pipeline. Agent tools do not necessarily need a separate gateway. Model access does not necessarily belong in custom integration code across every application. And model-assisted decisions do not necessarily need to occur somewhere outside the application responsible for acting on them.

Harper 5.3 is another step in that direction.

As AI becomes part of ordinary application behavior, the infrastructure supporting it can become part of the application runtime too.

The future of the AI stack may not be a bigger stack at all. It may be a more unified runtime.

Rails Won Because It Had Opinions. AI-Native Apps Need the Same Thing.

Aleks — Fri, 12 Jun 2026 22:48:59 +0000

We keep hearing the same comparison:

Harper feels like Ruby on Rails.

That comparison did not come from a positioning exercise. We were not sitting in a room trying to make Harper sound like Rails. It came from developers, advisors, analysts, and technical leaders trying to describe what feels different about building with Harper.

And the more we hear it, the more obvious the point becomes.

The comparison is not about Ruby. It is not about MVC. It is not about scaffolding CRUD apps or recreating Rails in JavaScript.

It is about a product philosophy.

Rails won because it had opinions.

It made choices for developers. It gave teams a coherent way to build. It reduced the number of architectural decisions required to get from idea to working application. It proved that the right constraints can make great developers faster.

That lesson matters again because software development is entering another major shift.

AI is changing who, or what, makes implementation decisions. Agents are beginning to generate code, wire services together, create workflows, and make architectural choices on behalf of teams. In that world, opinionated systems become more valuable, not less.

When humans are building software, good conventions reduce decision fatigue.

When AI agents are building software, good conventions become guardrails.

They shape what gets generated, how pieces fit together, and whether the result is a coherent application or just a pile of working parts.

That is why Harper keeps getting compared to Rails.

Just like Rails, Harper brings an opinionated, integrated model to a part of the stack that has become far too fragmented: distributed application infrastructure.

Rails Made the Path Obvious

Rails changed web development by making the common path clear.

Before Rails, every project started with a sea of open questions. Which ORM? Which templating engine? How should directories be structured? How should URLs map to code? Where should the configuration live? How should dependencies be managed? How should tests be organized? How should the database schema evolve?

Rails answered those questions with defaults.

Active Record. ERB. Routing conventions. Configuration patterns. Migrations. Testing defaults. Project structure. Naming rules that made the pieces work together.

That was the breakthrough.

Rails did not make developers faster by giving them infinite flexibility. It made them faster by reducing meaningless flexibility. It removed decisions that most teams should not need to make from scratch.

The best developers still had room to customize. But they started with a coherent system rather than a blank page.

That is what “convention over configuration” really gave us: speed, clarity, and shared understanding.

The magic was not just Ruby. It was not just MVC. It was not any single abstraction.

The magic was that Rails made application development feel like one integrated experience.

The Stack Became the Framework

Modern applications have changed around the framework.

Rails has continued to collapse more of the application tier into the framework itself. Rails 8 and the Solid stack are a perfect example. Cache, queue, jobs, real-time updates, routing, authentication patterns, and deployment have all become more integrated, more conventional, and less dependent on separate services.

That is exactly the Rails philosophy at work.

But the data tier remains different.

Even when Rails absorbs more infrastructure into the application experience, the database is still a separate process. Often it is a separate machine. At scale, it may be a separate region. And as more parts of the application depend on database-backed primitives, more of the system routes through that same boundary.

Solid Cache removes the need for Redis in many cases, but it still stores cache data in the database. Solid Queue removes the need for a separate queue service, but jobs are still stored in the database. Solid Cable brings real-time messaging into the Rails pattern, but the backing state still lives in the database.

That consolidation is a win. Rails has already moved the ecosystem toward fewer external services and stronger defaults.

But it also reveals the boundary Rails cannot fully close on its own:

The app tier and the data tier are still separated by a network hop.

Every request that needs data crosses it. Every query crosses it. Every job, cache read, message, and update that depends on the database crosses it. Replicas and multi-region deployments can improve scale and resilience, but they also make the topology more complex.

This is the next layer of decision fatigue.

The developer is no longer just asking how to structure the app. They are asking where data should live, where logic should run, how far each request needs to travel, how state moves across regions, and how the system behaves when the data boundary gets stretched.

Rails made the app tier coherent.

The data tier is the remaining frontier.

AI Raises the Cost of Bad Defaults

This problem gets sharper in the AI era.

AI agents are very good at producing code. They can generate endpoints, write functions, create schemas, connect services, and propose architectures quickly.

But without strong conventions, they can also create systems that technically work and architecturally sprawl.

An agent can add a service because a service seems reasonable. Add a cache because performance matters. Add a queue because async work is needed. Add a table because state has to go somewhere. Add another API because something needs to call something else.

Very quickly, the application becomes a collection of generated parts.

This is where the Rails lesson becomes newly important.

Rails gave human developers a paved path. AI-native development needs paved paths even more.

If agents are going to make more implementation decisions, the platform needs to encode better architectural defaults. It needs to guide decisions about data, logic, messaging, caching, and locality. It needs to make the coherent path easier than the fragmented one.

AI does not eliminate the need for opinionated platforms.

It increases it.

Why Harper Keeps Getting Compared to Rails

Harper is not Rails.

It is not a Ruby framework. It is not trying to recreate MVC. It is not asking Rails developers to abandon what made Rails great.

The comparison is philosophical, not literal.

Rails brought convention, integration, and a coherent developer experience to web application development. Harper brings that same philosophy to distributed application infrastructure.

Harper is a unified application platform that combines database, caching, messaging, and application logic into a single high-performance runtime. Instead of forcing teams to assemble separate systems for each backend concern, Harper gives developers a more integrated way to build and run distributed applications.

That is where the Rails-like feeling comes from.

Rails made the application feel coherent.

Harper makes the distributed backend feel coherent.

Rails reduced the number of decisions required to build a web app.

Harper reduces the number of systems required to build a distributed app.

Rails gave developers a productive default path.

Harper gives developers and AI agents a stronger architectural path for data, logic, messages, and caching.

That is also why the Node.js and JavaScript foundation is not a barrier to the comparison. Developers are not saying Harper feels like Rails because they think it is Ruby. They are saying it because the experience reminds them of what Rails got right: strong opinions, integrated primitives, and a system that helps you move faster by making better decisions on your behalf.

JavaScript simply makes that model accessible to the modern application ecosystem. It gives teams a familiar language for writing logic inside a platform that is doing much more than running Node.js code.

The important thing is not that Harper is built on JavaScript.

The important thing is that Harper is built with opinions.

The Difference Is Fewer Seams

Consider a commerce application.

A product page seems simple until it has to be fast, dynamic, personalized, and globally available.

Some content is stable: product descriptions, images, specifications, editorial copy. Some content changes constantly: price, inventory, promotions, recommendations, loyalty status, delivery estimates, and customer-specific offers.

The traditional answer is to spread those concerns across a growing stack.

The app handles the request. The database stores the source of truth. The cache accelerates hot reads. A queue handles updates. Workers process changes. The CDN caches what it can. Custom invalidation logic tries to keep everything from lying to the user.

Again, none of these tools are bad.

But the team is no longer just building a product page. It is maintaining a distributed coordination system.

A more opinionated platform changes the shape of the problem. Data, logic, messaging, and caching can live in one runtime. Application behavior can be placed closer to the data and closer to the user. Updates can move through the system without every team having to rebuild its own coordination layer.

The value is not merely fewer tools.

The value is fewer seams.

Fewer places where the developer has to stop building the product and start designing infrastructure. Fewer places where an AI agent can make a technically reasonable but architecturally messy choice. Fewer places where performance, consistency, and developer velocity are traded against each other by default.

That is the “oh, I get it” moment for Rails developers.

The same reason Rails felt magical for building web applications is the reason an opinionated distributed runtime feels powerful now.

It gives you a path.

Distributed Apps Need Their Rails Moment

The lesson of Rails was that coherent systems win.

Developers move faster when the platform makes good decisions. Teams build better software when the common path is clear. Applications are easier to reason about when the pieces are designed to fit together.

That lesson is becoming more relevant with AI.

As applications become more distributed, and as AI agents participate more directly in building them, the need for opinionated architecture will only grow. The future will not belong to teams that assemble the most tools. It will belong to teams that can turn ideas into coherent, high-performance applications the fastest.

Rails gave developers convention over configuration for web apps.

Harper brings that idea to distributed application infrastructure.

And once you see that, the comparison becomes hard to ignore.

The Next Step After AI Codegen: Self-Modifying Systems

Aleks — Fri, 20 Mar 2026 16:39:48 +0000

A follow-up to Designing Tech Stacks for AI-Generated Code

AI agents are moving from code generation into live system intervention. That transition changes what "good architecture" means, and most current stacks are not designed for it.

The previous piece was about reducing the surface area agents have to reason about when writing code. This one is about a harder question: what architectural conditions make it safe for an agent to modify the thing it's already running on?

Two different problems

There is a meaningful gap between an AI agent that writes code and one that maintains a running system. The first is a productivity story. The second is an architectural one, and it's the one the industry has not seriously engaged with yet.

When an agent can not only write a schema migration but also apply it, validate the system's behavior afterward, and roll back autonomously if something looks wrong, the infrastructure is no longer a static target. It is a dynamic surface the agent is continuously touching. That is a different class of problem.

Self-modifying software is not new. Stored procedures, metaprogramming, adaptive systems: code that changes its operating environment at runtime is as old as the discipline. But those patterns were always bounded. A program adjusted its internal state within a runtime. The schema, the API contracts, the deployment configuration were maintained by humans, on a different timescale, with different tools.

What agents introduce is a collapse of that boundary. The autonomous loop writing the migration is the same loop running the system. And that changes the question you have to ask about architecture fundamentally.

What the failure looks like

Before the theory, the concrete case.

An agent adds a column to a user profile schema. Simple enough. But in a conventional multi-service stack, here is what that change touches:

The database migration runs. The new column exists.

The cache layer is still serving serialized user objects in the old shape. It does not know the schema changed.

The API layer has deserialized expectations about the structure of that data. Its contracts are now subtly wrong.

Background jobs consuming user events were written against the old schema. They will silently handle the new shape incorrectly, or fail loudly, depending on how they were written.

The agent attempts a rollback. The database reverts. But the cache is still populated with objects that were written during the window when the new schema was live. The message queue still has events that were produced in that window. The rollback does not reach them, because rollback is a database primitive, not a system primitive.

This is not an edge case. It is the ordinary failure mode of autonomous change in a fragmented architecture. Each component has its own notion of version, its own failure mode, and its own rollback semantics. There is no system-level transaction boundary. The agent modified a distributed agreement, not a thing.

Now contrast the same change in a unified runtime, where database, cache, application logic, and messaging are the same in-memory process deploying as a single atomic unit. Either the new version is running or the old version is running. The cache cannot hold objects in the old shape because the cache is the same process as the database. The API layer cannot have deserialized expectations that diverge from the schema because they are derived from the same schema definition. Rollback means rolling back one artifact, not coordinating across five systems with different rollback mechanics.

The failure mode does not disappear. But the blast radius is bounded by a coherent system boundary, not distributed across a web of implicit contracts.

Coherence as a prerequisite

Here is the thesis: safe self-modification requires a coherent self. That sounds philosophical, but it has a precise architectural meaning.

A system has a coherent self when there is a single shared notion of version, state, and transaction boundary. When you can answer the question "what is the system's current state" with one answer rather than aggregating across multiple components that may have diverged.

It's worth being precise about what this does and does not mean. Coherence is not the same as monolithic. Formally coordinated distributed systems, well-typed service contracts, transactional deployment patterns, migration frameworks that enforce compatibility across versions, and policy engines that make inter-service dependencies legible are all genuine paths toward a more coherent distributed system. Teams with deep investment in those approaches are not doing it wrong.

But there is a structural argument for why runtime coherence, fusing the components into a single process with a shared transaction model, is particularly suited to the self-modification problem. It is not just that the agent can reason about fewer files. It is that the agent can reason about the change as an atomic operation against a unified state. Deploy, validate, roll back: one action, one artifact, one audit trail. The alternative requires the agent to coordinate that sequence across components whose failure modes interact in ways that are difficult to observe and harder to reverse.

The unified runtime is a strong answer to the self-modification problem. It is not the only answer. But it is the one where the guarantees are structural rather than procedural, which matters when the entity enforcing those guarantees is an autonomous agent rather than a careful human.

The constraint that cannot live inside the system

There is one piece of this architecture that cannot be automated, and it is worth being direct about it.

The permission model for agent self-modification cannot live inside the agent. It cannot live inside the system the agent is modifying. It has to be external and structurally inaccessible to the agent itself.

This is not a novel security principle. It is the same logic that makes a well-designed access control layer work: the control layer is not accessible to the entities it controls. We are applying that principle to a new kind of entity.

What this means practically: the agent operates against a defined API surface that enforces what it can read, write, and deploy. That surface is not controlled by the agent. Certain schema primitives are immutable to the agent regardless of its reasoning. Core identity structures, audit log tables, and permission tables: not writable by an agent under any circumstances. Every action the agent takes is logged to an append-only audit trail that the agent cannot modify or delete.

An agent that can grant itself new permissions is not a safe agent. The coherent runtime buys you legibility. The external permission boundary buys you control. Legibility without control is a transparent but ungoverned system. Control without legibility is a safe but opaque one. You need both, and they require deliberate design rather than emergent safety from capable agents.

The hard edges we have not solved

The honest version of this argument has to name what we do not know.

Schema evolution under live load is a genuinely hard problem that the unified runtime framework does not fully resolve. Backward and forward compatibility, dual writes during transitions, schema version skew across concurrent clients, and the observability lag that makes autonomous validation difficult during partial rollout states are all real constraints. A coherent runtime makes these problems more legible. It does not make them disappear.

We do not have a strong empirical answer to where the right boundary sits between what an agent can safely modify autonomously and what requires human review. The intuitions are informed but not validated at the scale and concurrency that real multi-tenant systems operate at. Many agents operating against shared infrastructure with different permission surfaces is a genuinely open problem.

And the failure mode of an agent that reasons confidently but incorrectly about the downstream effects of a change is not well characterized. Human error tends to occur at human speed, with natural review steps built into workflows. Agent errors can compound across many instances before anyone notices, faster than any human escalation path.

The teams with the right instinct are the ones asking hardest about rollback semantics and audit trails before they ask about capability. Open-source, non-critical paths, and environments with instrumentation to closely observe agent behavior are where this should be proven out before it reaches regulated or high-stakes systems.

Where this leaves the architecture conversation

The previous piece described a shift in evaluation criteria: not just "how productive is a human developer on this stack" but "how well does an AI agent perform against this architecture." Stacks that score well on both dimensions will have an advantage.

This piece describes the next frame after that one. Not just stacks that AI can write against, but stacks that AI can maintain, modify, and redeploy autonomously. Infrastructure that is not just a target but a participant.

The prerequisite for that is not more capable agents. It is infrastructure with a coherent self to reason about and a permission boundary that the agent cannot reach. Both of those are design decisions that can be made now, before the agents are sophisticated enough to act on them.

Most of the conversation about AI and backend architecture has been about what the agents can do. The more consequential question is what we build for them to do it against.

Designing Tech Stacks for AI-Generated Code

Aleks — Wed, 18 Mar 2026 21:07:39 +0000

Something interesting is happening in backend engineering. The tools writing our code are getting smarter every month, but the infrastructure those tools have to target hasn't changed much in a decade. We're pointing increasingly capable AI agents at the same multi-service architectures we built for human developers, and in many cases, the output is more fragile than it needs to be.

The conversation around AI-assisted development has been almost entirely about the models. Which agent is best. Which IDE integration is fastest. Which model scores highest on SWE-bench. But there's a quieter, more consequential question that fewer people are asking: what should the target architecture look like when AI is writing a growing share of the code?

I don't think this requires throwing out everything we know about backend engineering. But I do think it's worth examining which architectural patterns help AI agents succeed and which ones create unnecessary friction.

Where the friction actually lives

Here's the core tension. Modern backend architecture evolved to solve human organizational problems. Microservices exist because teams needed to deploy independently. ORMs exist because developers didn't want to write SQL. Docker exists because "works on my machine" was destroying release cycles. Kubernetes exists because container orchestration is hard.

These tools work. Teams ship production software on them every day and will continue to do so. But none of them were designed with the assumption that a language model would be writing and modifying the code. They were designed for humans working in teams across long time horizons with institutional knowledge about how the pieces fit together.

An AI coding agent doesn't have institutional knowledge. It has a context window. And every additional service in your stack, every configuration file, every implicit dependency between systems, consumes that context window and introduces another surface where the agent can make mistakes.

I've watched Claude Code try to set up a standard production stack: Express, Prisma, Postgres, Redis, a WebSocket server, and Docker Compose. It gets each individual piece maybe 80% right. But the integration between them is where things get shaky. Environment variables don't match between services. The ORM generates a migration that conflicts with the seed data. The cache invalidation logic doesn't account for the way the WebSocket server reads from the database. Each bug is small. Together they cost you an afternoon.

Can strong teams mitigate this with existing practices? Absolutely. Good tests, thorough code review, and solid CI pipelines catch most of these issues regardless of whether the code was written by a human or an AI. The question isn't whether traditional practices still work. They do. The question is whether the architecture itself could make the AI's job easier in the first place.

How teams are responding

The industry hasn't converged on a single answer yet. Teams are at very different stages of adoption, from simply adding Copilot to their existing workflow to rethinking their infrastructure from the ground up. Many are somewhere in between, and that's fine. But several patterns are emerging that are worth understanding.

Adding AI to existing stacks

The most common approach today is incremental. Keep your existing architecture. Add an AI coding assistant. Use it for boilerplate, test generation, code review, and documentation. Improve your CI pipeline to catch AI-introduced errors.

This works, and it's the right starting point for most teams. You get productivity gains without migration risk. The ceiling on this approach is that the AI is still targeting an architecture that wasn't designed for it, so you're relying more heavily on validation layers (tests, reviews, linting) to catch the integration mistakes that the architecture's complexity makes likely.

There's nothing wrong with this. It's where most of the industry is today and where it will remain for a while.

Backend-as-a-Service platforms

Supabase, Firebase, Appwrite, and Convex all reduce surface area by bundling database, auth, storage, and functions into a managed platform. The developer writes application logic. The platform handles infrastructure.

This works well for AI agents because there's less to configure. An agent writing Supabase code really only needs to know the client SDK and the database schema. It doesn't need to reason about connection pooling or deployment manifests.

The tradeoff is control. You're renting someone else's architecture. When you need something the platform doesn't support, you either work around it or migrate, and migration from a BaaS is notoriously painful. The other tradeoff is performance ceiling. When your database, your auth layer, and your edge functions are all separate services behind a network boundary, there's a latency floor you can't optimize below, no matter how good your queries are.

Infrastructure-from-code tools

Encore, SST, and Pulumi's newer offerings let you declare infrastructure as part of your application code. Instead of writing Terraform separately, you annotate your TypeScript with infrastructure semantics and the tool provisions everything.

This is clever because it keeps the infrastructure definition close to the application logic, which means an AI agent reading your codebase can see both at once. Fewer files to reason about. Fewer implicit dependencies.

The tradeoff is that you're still running multiple services at runtime. The code might be co-located, but your database is still a separate process from your API server, which is still a separate process from your cache. The deployment is simplified, but the runtime architecture is not. An agent can more easily set things up, but the same class of integration bugs still exists once the system is running.

Declarative frameworks

NestJS, Redwood, and Blitz collapse some of the decision space by being opinionated about project structure. They pick the ORM, the testing framework, the file layout. An agent working in a Redwood project has fewer choices to make, which means fewer wrong choices.

But these are still frameworks, not runtimes. They sit on top of the same multi-service architecture underneath. Your Redwood app still needs a database connection, still needs a deployment target, still needs infrastructure decisions that the framework doesn't make for you.

Unified runtimes

This is the approach I find most architecturally interesting, though it's also the most opinionated and the earliest in adoption. Instead of bundling services together at the management layer or the code layer, unified runtimes actually fuse them at the process level. Database, cache, application logic, and messaging run in the same memory space.

Harper is the most developed example of this pattern I've come across. Your data model is a GraphQL schema. REST APIs are generated automatically from that schema. Custom endpoints are JavaScript classes that extend your tables. Real-time messaging is built in via WebSockets, MQTT, and server-sent events. Caching isn't a separate layer because all data access is already in memory and persistent on disk (really, solid-state drives).

The entire application is three files. A schema, a config, and a resources module. That's not a simplification of the developer experience on top of hidden complexity. That's the actual architecture. There is no separate database process. There is no Redis instance. There is no message broker to configure.

For AI agents, this is a fundamentally different target. The agent doesn't need to reason about how services communicate because there's only one service. The agent doesn't need to manage connection strings because there are no connections. The schema is the source of truth for the data model, the API, and the access patterns simultaneously.

The tradeoff is real. You're not using Postgres. You're not using standard ORMs. Your team needs to learn Harper's model, and if you decide to leave, you're migrating data and rewriting your API layer. That's a meaningful cost, and for teams with deep investment in their current stack, it may not be worth it.

But there's something worth watching in where this goes long-term. Harper's deployment platform, Harper Fabric, distributes your application across a global cluster by selecting regions and latency targets. Because the runtime knows everything about your application from those three declarative files, it can make deployment decisions that would require significant DevOps expertise in a traditional stack. The gap between "I wrote the code" and "it's running in production across three continents" collapses to a single command.

When you project this forward into a world where AI agents are writing a larger share of initial code, the combination of a minimal-surface-area runtime and an infrastructure-aware deployment platform is compelling. Whether it becomes a dominant pattern or a niche one is still an open question, but it's worth tracking.

What makes a stack AI-friendly

Regardless of which approach you take, a pattern emerges. The stacks where AI agents produce the best output share a few properties. These aren't requirements. They're design principles that reduce the surface area for AI-introduced errors.

Fewer files that matter. Every file in your project is context the agent needs to hold. A three-file application is easier to reason about than a thirty-file application. This isn't about lines of code. It's about the number of distinct configuration surfaces.

Explicit over implicit. When your data model is declared in a schema that generates the API, the agent can see the relationship between data and endpoints. When your API is hand-wired through a routing layer that references a service layer that references a repository layer that references an ORM, the agent has to trace four levels of indirection to understand what a GET request returns.

Declarative over imperative. Telling the system what you want rather than how to do it means the agent makes fewer implementation decisions. Fewer decisions means fewer wrong decisions. A unified runtime's schema annotation like @export that generates a REST endpoint is one line the agent needs to write. Compared to a hand-coded controller with validation, error handling, and serialization, which is forty lines, the agent needs to get right.

Co-located concerns. When your database schema, your API definition, your caching behavior, and your deployment config all live in the same place or are derived from the same source, changes propagate automatically. The agent doesn't need to remember to update the cache invalidation logic when it changes the data model because they're the same thing.

Deterministic deployment. If the deployment system can derive everything it needs from the application definition, the agent never needs to touch infrastructure config. If deploying requires a separate Dockerfile, Kubernetes manifest, and CI pipeline, the agent needs to maintain consistency across all of them.

None of this means your existing stack is broken. If you have strong engineering practices, good test coverage, and a team that reviews AI output carefully, you can get excellent results with a traditional architecture. These principles just describe what makes the AI's job easier, which in turn means less time spent on review and debugging.

The shift that's forming

I think we're in the early stages of a broader evolution in how developers and AI collaborate on backend systems. Not a revolution where everything gets replaced overnight, but a gradual shift in what we optimize for when choosing tools.

For twenty years, we've been decomposing backend systems into smaller, more specialized pieces. Separate database. Separate cache. Separate message broker. Separate API gateway. Separate auth service. Each piece is independently excellent. The complexity lives in the composition.

That composition complexity was manageable when humans were doing all the wiring, because humans carry implicit context about how the pieces relate. An experienced engineer knows that when you change the user schema, you also need to update the cache key format and the WebSocket subscription filter. That knowledge lives in their head, not in the codebase.

AI agents don't carry that implicit context. They have what's in the files. And if the relationship between your schema change and your cache invalidation logic is implicit, mediated through three layers of abstraction across two services, the agent is more likely to miss it. Not because it's incapable, but because the architecture made the dependency invisible.

The direction I see forming is toward stacks that make dependencies explicit, keep surface area manageable, and derive as much as possible from a single source of truth. For some teams that means a BaaS. For others, it means infrastructure-from-code. For teams starting fresh, a unified runtime is worth serious consideration.

This doesn't mean traditional stacks are going away. Postgres isn't dying. Kubernetes still has its place. Microservices will continue to be the right answer for large organizations with complex deployment requirements. But the evaluation criteria for choosing tools are expanding. "How productive is a human developer on this stack" is no longer the only question. "How well does an AI agent perform against this architecture" is becoming a real factor in the decision, and the stacks that score well on both dimensions will increasingly have an advantage.

We're early. The patterns are still forming. But the teams paying attention to this question now will have a head start when the rest of the industry catches up.