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 and does not know what you were doing yesterday. Getting work into it and answers back out is a copy-paste round trip, and that friction limits people to questions worth the interruption, when the many small ones are where it would help most.
A better model does not fix this. Putting the model where the text already is does: 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 very good at this because it is a Lisp environment that happens to edit text, rather than an editor with a plugin API. Wiring a model into a workflow means writing a few lines yourself instead of waiting for someone else to ship a feature.
Argumenten · The case
Six reasons,
in order of how often they matter.
Ranked by what makes the difference once a local model is in daily use and no longer being evaluated.
01 The model is where the text is
It works on the region, the buffer, the diff or the Org subtree you already have open. There is no copy-paste round trip, and that friction is what 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 do not wait for a vendor to decide your use case is worth supporting, and nobody can deprecate what you build.
03 Everything is plain text
Notes, runbooks, configuration and prompts are files in Git that you can diff, review and grep, and that will still be readable in thirty years. The model's context is your own corpus rather than a proprietary workspace.
04 One environment for all of it
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 switching to a different application for each.
05 It has already outlived everything
It has forty years of continuous maintenance behind it, and configuration still works after a decade. A working environment is a long-term investment, and one that forces a migration every five years adds cost to everything built on it.
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 downside) |
| Suits everyone on the team | Broadly yes | Broadly no |
Nackdelar · The downsides
This is the most opinionated thing we sell.
We would rather you bought the local model and skipped the editor than take on an engagement that ends with half a team going back to what they had. The drawbacks:
- The learning curve takes weeks, not an afternoon with a cheat sheet. A team with no slack to absorb that should not start here.
- Some people in any team will bounce off it, and that is a legitimate preference. A plan that requires everyone to convert is a bad plan.
- It does not help with hiring. New engineers are unlikely to arrive knowing it, and “we use Emacs” is not a recruiting line, so budget realistic onboarding time.
- The packages are community-maintained. They are excellent and freely given, but a package can go unmaintained. We pin versions in the flake, so when that happens we deal with it on our own schedule.
- It is optional. The local model, the endpoint, the retrieval index and the runbooks all work from any editor. Emacs is the best way we know to use them, but it is not what you are buying.
The engagement is built so that nothing depends on Emacs. Runbooks export to Markdown and 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 it still sounds like your kind of thing after all that, it probably is, and we can get you set up faster than you would on your own.