In the last post, we killed the "Tool Abstraction" layer. By replacing 50 brittle JSON-RPC wrappers with a single eeva process (Elixir on the BEAM).
Here is how we moved our agent from text-based hacking to actual AST-aware refactoring.
Standard agents "edit" files by outputting search blocks:
Plaintext
<<<< SEARCH
def hello_world, do: "hi"
==== REPLACE
def hello_world, do: "hello elixir"
>>>>
This is fundamentally broken. It relies on the model perfectly hallucinating the exact state of the file, including indentation, hidden newlines, and context. If the file has changed by one space since the last read, the entire operation fails. It is brittle, state-blind, and expensive. Coding agents are trying to work this out by introducing not so easy algorithms for multi-edits. Each time model changes a file, for the next edit it needs to read the file again. If this would be standard flow, it would cost you a huge amount of tokens to make it right. Coding agents try to fix it with a few ninja tricks by keeping last edits in memory and shifting next edits. But model doesnt know about this. Eventually, the simple operation of editing files becomes a guessing game both for model and for the harness.
We didn't solve this by introducing custom "edit primitives" or specialized editing tools. Writing unique tool APIs just forces you back into prompt engineering hell.
Instead, we give the model full Elixir execution to edit files directly. Because the code is the tool, the model can execute a complete chain of multi-edits across multiple files in a single, atomic operation using standard language features.
The model doesn't output raw diff blocks; it pipes the files through pure functional transformations.
elixir
config_path = "config/config.exs"
File.read!(config_path)
|> String.replace(":old_port, 4000", ":new_port, 8080")
|> then(&File.write!(config_path, &1))
"lib/workspace/"
|> File.ls!()
|> Enum.filter(&String.ends_with?(&1, "_worker.ex"))
|> Enum.each(fn file ->
path = "lib/workspace/#{file}"
File.read!(path)
|> String.replace("get_port(:old_port)", "get_port(:new_port)")
|> then(&File.write!(path, &1))
end)
By using the raw programming language as the editing engine, we unlock a few massive architectural advantages:
Zero Context Re-Reads
The model does not need to execute an edit, wait for the harness to update, read the file again, and format a second diff. The state lives inside the Elixir evaluation stream. It can pipe the output of one file read directly into the modification of another, completing complex refactors in a single API call.
Localized Logic, Less Hallucinations
The model doesn't need to guess line numbers or spaces. It writes native Elixir filters, regex matches, or map functions to locate exactly what it wants to change. The search logic is executed live by the BEAM runtime, completely removing the brittle dependency on matching precise whitespace layouts.
Native Multitasking
Because eeva executes inside a supervisor tree, this entire multi-edit code runs inside an isolated, transient BEAM process. If the model makes a logic error mid-stream, the process crashes safely, and the compiler drops the exact structural failure back into the context.
Dynamic Introspection
In a standard text-based setup, the model edits a file, hopes for the best, and then has to call a separate tool to run tests or verify syntax. If the edit broke a dependency three folders over, the agent is blind to it until the entire run crashes.
With pure Elixir execution, the model can introspect its edits inline before finishing the operation. It can pipe its file mutations directly into the live compiler to verify the changes don't break the system:
elixir
File.read!("lib/math.ex")
|> String.replace("def add(a, b), do: a + b", "def add(a, b), do: b + a")
|> then(&File.write!("lib/math.ex", &1))
case Code.compile_file("lib/math.ex") do
{:ok, _modules} -> "Success"
{:error, errors} -> "Failed compilation inline: #{inspect(errors)}"
end
Try it out: https://github.com/beamcore/agent