Living Servers -

Creating a Code Kandra

18/02/2026

Introduction

I'm proposing the concept of having your AI be the server, at least in an abstract sense. Here I'll explain and demonstrate a system where prompting doesn't generate code in a file, it causes the server to rewrite itself as it's running. No downtime or availability issues, no restarts, no deployments, and so on. We enable a new paradigm of software engineering where instead of generating files in a repo and going through the pesky process of validating and committing, running CI/CD pipelines and blue-green rollout strategies, your server patches itself in real time as it's running. It fixes itself without stopping, implements its own features without availability issues and independently grows over time.

By removing the barrier of generating code (yourself or with AI), shipping that code to production, and every step in between, the experience feels more like interacting with a living being, only constrained by the rules you place on it -- some sort of eery, ever-growing code kandra.

Demonstration

We have a dashboard to talk to our server and some information on the side -- server status and other basic server functions, as well as route definitions. The routes represent currently live routes on our 'living server', which for demonstration purposes, is currently a HTTP server with a health check. There's already a lot of magic going on here with showing routes, which I'll revisit later. We tell our server that we want it to add some new functionality. I want it to handle a URL parameter and some basic logic, including server state.

What follows is some LLM processing and thinking about the code. It is self-aware of what is currently live and available. For debug purposes we can see the patch being proposed, though there's no need for the end user to necessarily see this. After clicking run, we see our new route appear on the left, now it exists. There was no restart, no server refresh, the server didn't turn off and on again, it didn't write and exec a file or string. Nothing got deployed, it patched itself in real time.

The first route is a 'person' route that returns a name based on a URL parameter and a random age between two given values. The next couple increment and decrement a counter which persists in memory, if you caught a glance of the code, this is a global variable it created for itself. I can retrieve that state with the third route it created.

It now gets asked to make a third party API call with some additional logic. It'll introduce a third party package for making a HTTP request.

We get it to update an existing route, showing that we can patch and update existing handlers.

Finally, to show we're not constrained to API routes, we have it create a web page for us, also implementing a counter. Hopefully this demonstrates that we don't have to stop at API functionality, as long as we're okay with server side rendering, we could have entire apps served by it and have frontends be self maintained and patched also.

For this demonstration, the server is running my localhost for convenience whilst I iterate on the prompts on the backend. I've tested this on a Hetzner VPS and this would work the same in a production environment. If the server was receiving requests and under load, it would patch even during mid-flight requests with no availability degradation. I also have no constraints on the technology it implements. I can ask it to become a Graphql server, have realtime frontend/backend features with websockets or SSE, become a gRPC service, anything. So what exactly is going on here, and are there any benefits?

Explanation

The Lisp programming language, specifically Common Lisp, is an important part of this puzzle. This covers concepts and capabilities Lisp developers have been taking advantage of for decades. I've sprinkled a couple of extra moving parts on top, in order to create a more unified experience. I'll try my best to avoid going too deep into Lisp concepts, but I definitely encourage you to learn about the language if you're unfamiliar with it and what it's like writing it in production.

We have 2 main components driving this project. The first is the living server, our kandra. This is a Lisp HTTP server. It doesn't need to be a HTTP server, or a server at all, as long as whatever is running is accessible from the internet. The server is very plain, it's a Woo server with some helper functions for introspection, as well as providing access to it via 'Swank', the glue between our chat and itself. The service boils down to 5 lines of code for the actual logic.

The second is the chat server. It is important that we make this a separate service instead of bolting it on to the side of the living server in order to sandbox the experience. If I didn't, the server would be able to cannibalize the chat features, destroying itself. The chat server is currently where the bulk of the work lives, it also includes the frontend, as well as the LLM implementation (I'm using Claude sonnet). There are plenty of better ways to interact with LLMs, our main goal with this was to create a demo interface to talk to Claude and present the HTTP routes. The core logic is its ability to talk to our Lisp server via 'Swank'.

Lisp is our real secret sauce. There are a lot of ways you could attempt to implement similar looking features in another language, or rather if you abstract the user experience away, you could fool people into thinking it's identical. Elixir has BEAM for example, and Clojure inherits some of Lisp's functionality, but with a JVM underneath that constrains the full image model. To elaborate on what I said earlier, we're patching our server as it's running, there's no down time, there's nothing restarting or recompiling. This is how Lisp works out of the box.

A running Common Lisp process isn't a compiled binary in the traditional sense, it's a live image. Every function, variable, class, and data structure exists as a mutable object in memory. When a Lisp developer works on a project, they don't edit code, recompile, and restart. They connect to the running image (typically through SLIME in Emacs), write a new function definition, send it to the process, and it takes effect immediately. The old definition is replaced on the spot. This is the normal, everyday development workflow, not a special feature or additional developer tooling. Our living server in this case exposes this same mechanism to an LLM instead of a human sitting in Emacs, that's all, and therefore affords the user the ability to essentially drop the code, and everything that comes with coding in an AI environment entirely.

This is a development paradigm that's been around for more than half a century. There's an incredible recollection of NASA engineers patching Deep Space 1 a hundred million miles away to fix a live bug in production with no downtime. It feels somehow more strange and magical when your way of communicating is through chat.

Talking to an AI is like communicating with a person (albeit an annoying one). Now, by eliminating nuisances such as deployments, restarts, and writing files, you remove the final barriers of software engineering. Direct text to production provides an experience where you're talking directly to your server. Your server is self aware, it can heal independently, you can extend it with an agent that keeps it updated with new features, essentially feeding itself.

The benefits of Lisp for this don't stop at patching code in real time. There's no admin API or management endpoint on this server to retrieve its general state. The dashboard reaches directly into the running process's memory via Swank, calls a function that introspects the route table, and reads back what's registered. The server doesn't even know it's being observed. This is how the HTTP routes can be shown in the dashboard.

Lisp's ecosystem is equally impressive. Quicklisp, the dependency management tool, lets our living server install, import and use new libraries without restarting. If the base libraries we start with aren't enough, our LLM is more than capable of finding a new one and adding them on the fly.

Closing thoughts

On a day to day basis engineers strive towards the kinds of living servers I'm describing here. We have container orchestration platforms for managing application lifecycles and availability, CI/CD pipelines for carrying code from repos into production, and now we have LLMs writing files for us.

My implementation is a proof of concept. With more time, there could be incredible and interesting results. I wouldn't advocate for using something like this in production right now. Lisp offers a wide range of features for type checking, inference and error reporting, that would help create safer systems; but in a world where AI is already creating problems for people and software, maybe removing those last few barriers isn't a good thing.

You can find a minimal version of my example here with some additional explanation on how things work, there's also a few features implemented I didn't mention such as rebuilding servers in the case of a real restart or deployment. One of the main areas I've struggled with was third party libraries. I'm not very experienced in Lisp, so implementing the ability to install them dynamically has been a bit of a pain. I ended up trying to leave it to Claude which has, of course, broken most things by now, but the core functionality works.

github.com/glensargent/living-server

If you'd like to discuss this topic or get advice on how to implement these ideas yourself, you can find me on twitter: @glensarge or email me