Lisp vs TypeScript
for AI coding agents

A Node agent is a process. When you change its code you kill the process, reload from disk, and rebuild whatever in-memory state it had. Sessions drop. Anything the agent learned in RAM is gone. In practice this is why "learning" in a TS agent almost always means one of two things: appending to a vector store, or writing a longer prompt. The runtime can't hold new behavior; only the model can.

SBCL — the Common Lisp implementation tasa runs on — is a live image. You redefine a function and the definition is replaced in place. Callers pick up the new definition on their next call. The session doesn't drop. State survives the change. New behavior can be compiled into the running agent without restarting it. That is the raw material for a coding assistant that actually accumulates skills instead of re-prompting them every time.

JavaScript has exceptions. An exception unwinds the stack. By the time your handler sees the error, the site that raised it — the open file, the half-parsed response, the pending edit — is gone. Recovery means guessing what to do from the outside.

Common Lisp has conditions and restarts. When a call fails, the failure site stays live and offers named recovery points: retry, use-value, abort, and any custom restart the code exposes. A handler higher up the stack picks one. Nothing has been unwound. For a coding agent this is what makes "the tool failed — what should I do?" tractable: the model gets to decide from the actual failure context, and its decision is a first-class program value the agent can log, replay, and eventually learn a policy from.

An agent that improves has to read and write its own tools. In TypeScript that means shelling out to the compiler API, walking an AST, and re-emitting text — a round-trip that loses structure every time. In Lisp, source code and in-memory data are the same shape (s-expressions). A file that describes a tool is a tool. The agent can read it as data, transform it as data, and write it back as data. That is why learning in tasa can mean new tools, not just new prompts.

The consequence of a live image plus code-as-data is that behavior changes at runtime, safely. Every version of the agent's behavior is a numbered generation. A candidate generation is evaluated in a child SBCL process with an explicit capability manifest; if it wins on the Pareto fitness (with hard safety gates), it's swapped into the active image at a safe point. Roll back with one command and the session keeps going.

You can build a version of this on top of Node — spawn child processes, restart on promotion, replay sessions from logs. It costs a lot to build, and every session-drop becomes a user problem. In Lisp it's the shape of the runtime.

If you are building a chat wrapper — call model, render markdown, ship — TypeScript is the right call. The ecosystem is enormous, the hiring pool is huge, and none of the runtime traits above matter because the product isn't accumulating anything. Most "AI coding assistants" today are, structurally, chat wrappers with tools.

The trade flips the moment the product is supposed to get better between sessions in a way you can inspect and roll back. At that point the runtime under the agent is the interesting engineering, and TypeScript is fighting it.

A frozen agent is a program. An agent that compounds needs a runtime that lets it be redefined, recover at the failure site, and reshape its own tools without a redeploy. Common Lisp gives you three of those out of the box. TypeScript makes you build them.

;; that is why tasa is written in Lisp — not for the parens.