Repository navigation
13_Why Imza
Why Imza exists, and the direction it deliberately takes.
Agents write code faster than anyone can read it.
Approve the summary, move on, repeat. The codebase fills with changes nobody read. The tests pass, the feature ships, and the people who built the product slowly stop understanding it. They cannot explain why a function is the way it is, because they never saw it arrive.
The damage is a loss of comprehension, and for software that has to be right, a loss of accountability as well.
I built Imza because I wanted to use it at work, and nothing like it existed.
I have spent my career on software that is not allowed to be wrong. On an aircraft program, I automated a stress-analysis workflow where every result had to hold up under engineering sign-off. For electron-microscopy instruments, I built a motion simulation layer, image-processing software, and the diagnostics around them, where the instrument had to behave identically every time. At a national bank, I built back-end systems moving high-value transfers, where a lost event meant a lost transaction.
Different domains, same rule: the engineer has to understand the change, and the review is the record. Automation was always welcome. A change nobody understood was not.
Most coding agents are built to remove the human from the loop. Imza keeps the human in it, and enforces that instead of merely asking for it.
The field is moving toward full autonomy: how much the agent can do before you look. Imza answers a different question: whether you still understand your own software, and can show what changed and why.
Those are different products for different audiences, too far apart to be settings on one tool. Something optimized to hide the code cannot also be what you trust with code that must be right.
Imza is not an autonomous agent that happens to keep a log. You design the change in a plan before a line is written, watch it land as diffs while it is built, and review it in place when it is done. Because you see every change as it happens, you still know your own codebase. The record falls out of a loop you are part of, rather than a transcript of something that ran without you.
Imza redesigns the two phases agents rush past, planning and review, and builds the rest of the tool around them.
Planning is a document, not a chat mode. In most tools, "plan mode" is a toggle: the agent thinks longer and answers in prose, and the plan scrolls away with the next message. That is why some people call plan mode useless, and they are right about that version of it. Imza makes planning a document that lives beside the conversation. It has a fixed shape, and you can edit that shape yourself: annotate any section with a note, or ask in chat, and the agent revises the document in place. Every revision is kept. You catch a wrong approach before it is built, and afterward the document is what the build is held against. In regulated work it is the deliverable itself.
Plan mode cannot edit files. The permission layer refuses mutations outright, rather than asking the model to behave. Grants cannot override it. A plan is only trustworthy if the tool can guarantee it was not changed underneath you.
Review is a phase you work in, not a report you read. In most tools, "code review" is the model scanning a diff and printing a list of suggestions. You read it, or you do not. Imza makes review a place you work: the diff is the screen, you comment on any line yourself, and the agent's AI review adds its findings to the same list instead of a separate document. Your comments and its findings sit together and carry the same weight. One action sends the whole set back into planning as the next revision. Review is where the next plan comes from.
Every action passes one gate. The model composes its work as a script, and every file it touches and every command it runs goes through the same permission check. There is no second path around it. That is what makes the permission model trustworthy: one chokepoint you can point at, rather than a list of prompts you hope are asked.
Everything runs on your machine. One native binary, no runtime, no cloud, no telemetry. The dependency list is a handful of C and C++ libraries (libcurl, FTXUI, Lua, tree-sitter, and a few more), not a tree of thousands of packages pulled from a registry at install time. You can read what you are running, and you can build it yourself. Any model you already pay for works, including one running locally, and headless mode uses the same tools and permission system as the terminal UI.
- Your code stays on your machine. No cloud execution; the workspace stays where it lives.
- No telemetry and no account. Imza does not phone home, upload sessions, or require sign-in.
- Autonomy is opt-in. Full access exists for those who ask for it, never as the default.
- Prompts are for mutations. Reads happen without interruption.
- The prompts ship with the tool. The instructions the model runs on are in the repository.
- Feature parity is not a goal. A capability earns its place only if it serves the loop.
Imza is for developers who cannot move fast and break things.
Some of us ship to a web page, where a bug is a bad afternoon. Others ship to an aircraft, a pacemaker, or a payment rail, where a bug is a recall, a patient, a lost transaction. The second group is being handed the same tools built for the first: tools that optimize for speed and treat review as friction.
The dividing line is not the industry but the stakes: anyone for whom a silent wrong answer is unacceptable and a review trail is not optional. Engineers are being told to adopt AI while forbidden from adopting unreviewed autonomy.
If you want the agent to write the code and you never want to read it, Imza is the wrong tool. That is by design.
Every feature is measured against one question: does it strengthen the loop, or does it weaken the engineer's grip on the code? The roadmap follows from that question rather than from what the competition shipped last month.