Not an autocomplete.
A software engineer.
Point Eshlon at a folder and describe what you want. It reads the codebase, writes the files, runs the commands, reads what came back, and keeps going until the thing actually works.
Eshlon mid-build: file tree on the left, a diff open, a terminal running tests underneath. Ideally a real project, not a toy.
16/9Describe the outcome. It handles the rest.
It works on your machine, on your files
There is no upload step and no sandbox copy of your repository to keep in sync. Eshlon reads and writes the actual files on your disk, in the folder you pointed it at, using the same toolchain you already have installed. When it runs your test suite, it is your test suite, with your dependencies, on your operating system.
The file tree and an open diff, mid-edit. Show a real edit to a real file.
4/3Running the code is part of writing it
Most tools stop at producing text that looks like a solution. Eshlon runs it. It executes commands, reads stdout and stderr, and treats a failing build as information rather than a finished answer. That loop — write, run, read the error, correct — is the difference between code that compiles and code that was merely plausible.
A command running with output streaming, then a correction after a failure. A short screen recording would be stronger than a still here.
4/3Whole projects, not snippets
Apps, games, internal tools, scripts, migrations. Build is the default agent, which means it is what Eshlon does when you have not asked for a deck or a report — and it holds the whole project in view rather than the file currently open. When a change touches nine files, it changes nine files.
It can ask for help
When a job is genuinely too large for one pass, Build hands it to Swarm: the work is split, run in parallel, checked at merge, and returned as one result. You do not have to decide that up front, and you do not have to manage it.
The moment Build commissions a swarm — the panel appearing with workers listed.
4/3What people point it at
A working prototype
Describe the idea, get a running application you can open — not a folder of files that nearly compile.
A codebase you inherited
Ask what something does before you change it. It reads the code rather than guessing from names.
The migration nobody wants
Mechanical changes across hundreds of files, done consistently, with the test suite run after each pass.
A game
Loops, state, assets, input handling. Small games are a genuinely good test of whether a tool can finish anything.
How it goes
- 1Open a folderPoint Eshlon at a project, or an empty directory if you are starting from nothing.
- 2Describe the outcomePlain language. What should exist when this is done, not which functions to write.
- 3Let it runIt writes, runs, reads the output and corrects. You watch, and step in when you want to.
FAQ
Which languages does it work in?
Whatever is installed on your machine. Eshlon runs your toolchain rather than shipping its own, so the answer is the same as the answer for your computer.
Does my code leave my machine?
The files stay on your disk. What is sent to the model is the context needed to answer — the parts of files being worked on, command output, your instructions. Nothing is stored by Eshlon.
Can it run commands without asking?
Only if you let it. The approval control sits in the composer, and you can require confirmation for every command, or hand it the wheel for a run.
What happens when it gets something wrong?
Usually it finds out itself, because it runs the code. When it does not, you tell it, and the correction happens in the same session with the whole context intact.
Is there a file size or project size limit?
No hard limit. Large projects are handled by reading what is relevant rather than everything, and by splitting genuinely large work across a swarm.