08 Module · Why Emacs
The least likely
AI interface, and the
most durable one.
A model in a browser tab cannot see your repository, forgets yesterday, and makes you copy-paste your way between thinking and working. An editor that is programmable all the way down has none of those problems.
- First released
- 1976 · GNU Emacs 1985
- Extension language
- Emacs Lisp
- Still maintained
- Continuously, for 40 years
- Licence
- GPL v3
Almost every organisation that adopts a language model ends up with the same architecture by accident: a good model, in a browser tab, in the wrong place.
It cannot see the repository. It does not know what you were doing yesterday. Getting work into it and answers back out is a copy-paste round trip, and the friction quietly limits what people use it for — to questions worth the interruption, rather than the many small ones where it would actually help most.
The fix is not a better model. It is putting the model where the text already is: in the buffer, on the region you have selected, against the file you are looking at, with your notes and your codebase indexed beside it.
Emacs is unreasonably good at this, for one reason. It is not an editor with a plugin API — it is a Lisp environment that happens to edit text. Wiring a model into a workflow is a few lines you write, not a feature you wait for someone else to ship.
Argumenten · The case
Six reasons,
in order of how often they matter.
Ranked by what makes the difference once a local model is actually in daily use rather than being evaluated.
01 The model is where the text is
Operating on the region, the buffer, the diff or the Org subtree you already have open. No copy-paste round trip, which is the friction that decides whether a tool gets used for the small things.
02 Integrations are yours to write
A workflow-specific command is a few lines of Lisp, evaluated without restarting anything. You are not waiting for a vendor to decide your use case is worth supporting, and nothing you build can be deprecated out from under you.
03 Everything is plain text
Notes, runbooks, configuration and prompts are files in Git — diffable, reviewable, greppable, and readable in thirty years. The model's context is your actual corpus rather than a proprietary workspace.
04 One environment, not six
Editing Nix, reading Rails, writing Markdown for a Jekyll site, running a shell, browsing a Redmine issue and asking the model about any of it — without the context switch of a different application for each.
05 It has already outlived everything
Forty years of continuous maintenance, and configuration that still works after a decade. A working environment is a long-term investment, and the ones that force a migration every five years tax everything built on them.
06 No telemetry, no account
There is no sign-in, no usage reporting and no subscription to lapse. Combined with a model on your own hardware, the entire loop from keystroke to answer stays inside your network.
Jämförelse · Side by side
Against the usual setup
Compared with a hosted assistant in a browser tab, and with an AI-enabled commercial editor.
| Concern | Browser tab / commercial editor | Emacs on a local model |
|---|---|---|
| Sees your repository | Partly, via an upload or a plugin | Natively — it is the same buffer |
| Where the prompt goes | The vendor's infrastructure | Your GPU, over WireGuard |
| New workflow command | Wait for the roadmap | A few lines of Lisp, evaluated live |
| Notes and runbooks | A separate proprietary app | Org files in the same repository |
| Telemetry | Usually, and often not optional | None |
| Config portability | Per-machine, per-account | A Nix flake, identical everywhere |
| Lifespan of your setup | Until the next major rewrite | Decades, in practice |
| Time to first useful day | Minutes | Weeks — the honest disadvantage |
| Suits everyone on the team | Broadly yes | Broadly no |
Ärligt talat · Honestly
This is the most opinionated thing we sell.
We would rather you bought the local model and skipped the editor than take an engagement that ends with half a team quietly going back to what they had. So, plainly:
- The learning curve is real and it is weeks. Not an afternoon, not a cheat sheet. A team with no slack to absorb that should not start here.
- A proportion of any team will bounce off it, and that is a legitimate preference rather than a failure of character. Any plan that requires everyone to convert is a bad plan.
- It is not a hiring advantage. New engineers are unlikely to arrive knowing it, and “we use Emacs” is not a recruiting line. Budget onboarding time honestly.
- The ecosystem is community-maintained. Excellent and freely given, but a package can go quiet. We pin versions in the flake so that is a scheduled problem rather than a surprise.
- It is not required. Everything valuable in the engagement — the local model, the endpoint, the retrieval index, the runbooks — works from any editor. Emacs is the sharpest handle we know of, not the thing itself.
So the engagement is built to degrade gracefully. Runbooks export to Markdown. Configuration is plain text. The endpoint is OpenAI-compatible, so a colleague who prefers something else points their own tooling at the same GPU and loses nothing but our key bindings.
If after all that it still sounds like your kind of thing, it probably is — and we will get you there faster than doing it alone.