Originally published on Hashnode: [(https://aura-ide.hashnode.dev/building-aura-an-open-source-ai-coding-harness-you-can-control?utm_source=hashnode&utm_medium=feed)]
Own the Harness: An AI Coding Tool Where You See the Plan, Inspect the Edits, and Trust the Result
AI coding tools are powerful, but the workflow often feels fragile.
You ask for a change. The agent reads some files. It edits something. Maybe it runs a command. Maybe it says the task is done.
But as the user, you are often left wondering:
- What did it actually plan?
- What files did it touch?
- Did the write really apply?
- Did validation run?
- Is it fixing a real issue, or thrashing on noise?
- What changed between the tool I trusted yesterday and the one I am using today?
Aura is my attempt to build an AI coding environment around that trust problem.
It is a local, open source AI coding harness with a Planner/Worker architecture, safe file edits, visible workflow state, provider flexibility, persistent project memory, MCP integration, and Craft, a code quality pass designed to reduce common AI generated code slop.
The goal is not just to make a model write code.
The goal is to make the whole process inspectable.
The core idea: own the harness
Most AI coding workflows are controlled by someone else.
The interface changes. The model behavior changes. The limits change. The workflow you built habits around can suddenly feel different.
Aura is open source because I want the opposite.
If a version works for you, you can keep it. If a provider changes, you can switch. If the workflow does not fit your brain, you can modify it.
Aura treats the harness itself as the product.
Not just the model.
Not just the chat box.
The harness: how context is gathered, how plans are formed, how edits are applied, how failures are reported, how quality is checked, and how the user stays in control.
Planner and Worker
Aura separates thinking from execution.
The Planner is responsible for understanding the request, inspecting context, and writing a focused implementation spec.
The Worker is responsible for doing the actual codebase work: reading files, applying edits, running commands, and reporting what happened.
That split matters because single agent coding often collapses different jobs into one messy loop. The same model is trying to understand the user, search the repo, decide architecture, edit files, debug tools, and summarize results.
Aura gives those responsibilities clearer boundaries.
The Planner should answer:
- What is being changed?
- Why?
- Which files are likely involved?
- What does done look like?
- Should the Worker actually be dispatched?
The Worker should answer:
- What did I read?
- What did I edit?
- Did the write apply?
- What validation ran?
- What still needs attention?
Recent Planner diagnostic tools like get_workspace_snapshot and run_diagnostic_command help the Planner inspect the current workspace state before deciding whether to dispatch the Worker.
That matters because good planning starts with knowing what is actually true about the repo.
Safe writes and visible outcomes
One of Aura's most important rules is simple:
A write result is not success unless the write actually applied.
That sounds obvious, but it is one of the places AI coding workflows can quietly lose user trust.
A tool can return cleanly while still not changing a file. A patch can fail to apply. A symbol edit can miss its target. A validation command can fail for reasons that are unrelated to the edit.
Aura tracks write outcomes explicitly. The workflow is designed around making those states visible:
- applied
- not applied
- needs follow-up
- validation failed
- Craft blocked
- edit mechanics failed
- harness error
This avoids one of the worst AI coding failure modes: fake completion.
If Aura did not apply the patch, it should not pretend it did.
Craft: code quality without thrash
Craft exists because LLM generated code often has a texture.
It may be functional, but still full of little tells:
- narration comments
- placeholder scaffolding
- generic helper soup
- decorative banners
- pointless abstraction
- swallowed exceptions
- fake completeness
Craft is Aura's quality pass. Its job is to clean common AI slop and catch real hazards without becoming abrasive.
The design philosophy is:
- if Craft can safely clean it, clean it silently
- if Craft merely dislikes the style, warn
- if Craft knows it will break, block
That distinction is important.
Early versions of Craft were too strict and could cause repair loops. A low confidence static analysis warning could be treated like a hard failure, which made the Worker thrash instead of move forward.
Recent work adjusted the system so lower confidence diagnostics become warnings, while hard blockers remain hard.
Hard blockers include things like:
- syntax errors
- obvious stub bodies
- explicit contract violations
- unsafe destructive operations
- introduced undefined names
- introduced broken imports
Warnings include things like:
- guessed call signature concerns
- missing attribute concerns
- generic style issues
- advisory code quality observations
Craft should make the code better without making Aura feel like it is fighting itself.
The goal is not to create a second angry compiler.
The goal is to make generated code feel less generated.
Memory without wasting tokens
Aura also persists project understanding locally.
There are three layers:
- A BM25 codebase index so search stays fast across restarts.
- An AST based repo map that gives the Planner a compact structural view of the project.
- A SQLite FTS5 project memory database for completed tasks and saved notes.
The goal is to avoid paying the model to rediscover the same project every session.
Aura can keep useful project context local, searchable, and reusable. Code and memory stay on the machine unless explicitly sent to a model provider.
The BM25 cache makes codebase search fast.
The repo map gives the Planner a lightweight structural view of classes, functions, and signatures.
The project memory database stores completed Worker dispatch records, including goals, specs, touched files, outcomes, and notes. That means Aura can eventually recall past decisions instead of rediscovering them from scratch.
Memory is not just about convenience.
It is about continuity.
MCP and tool ecosystems
Aura is also designed to fit into the broader tool ecosystem through MCP.
The goal is not for Aura to be a closed island. Aura can use external tools, expose useful capabilities, and participate in workflows that extend beyond one app or one provider.
That fits the same core idea: the harness should belong to the developer.
Tools, providers, project memory, and workflow rules should be composable instead of trapped behind a single interface.
Provider flexibility
Aura is not tied to one model company.
The harness is designed so providers can change. You can use remote APIs, local models, or whatever makes sense for the job.
That matters because the AI coding space changes constantly. Models improve, regress, get repriced, disappear, or shift behavior.
Aura's goal is to keep the workflow stable even when the provider changes.
If the model changes, the harness should still make the work inspectable.
If the provider changes, the project memory should still be yours.
If a version works for you, you should be able to keep it.
Why local first matters
Local first does not mean every model must run locally.
It means the project, memory, workflow, and control surface live with the user.
Aura can use APIs, but the harness does not belong to the API provider. The repo, project memory, rules, workflow state, and release version stay yours.
That is the difference between renting a coding workflow and owning one.
What Aura is trying to become
The long term direction is an AI coding harness that can be shaped around the way a developer actually works.
That means:
- open source core
- visible planning
- safe writes
- provider swapping
- local project memory
- code quality checks
- workflow customization
- eventually, training data from Aura's own successful sessions
The most interesting future version of Aura is not just an app.
It is a harness that can teach models how to behave inside it.
Aura already records structured dispatch data around completed work: goals, specs, touched files, outcomes, validation, and repair notes. Over time, those records can become curated training examples.
The future version of this is an Aura native dataset:
- task
- repo context
- plan
- tool calls
- write outcomes
- Craft results
- validation
- final summaries
That data could eventually train Aura native chat, planner, and coder models.
Not a generic coding model.
A model that understands Aura's workflow.
A model trained not only to write code, but to behave inside a real coding harness: read before editing, patch carefully, respect tool results, avoid false success, validate when possible, and stop thrashing.
The point
Aura exists because AI coding should not feel like guessing whether the agent actually did the work.
You should be able to see the plan, inspect the edits, understand the result, and keep control of the workflow.
That is the bet.
Own the harness.
See what changed.
Trust what applied.
Aura is open source:
https://github.com/CarpseDeam/Aura-IDE
If the project resonates with you and you want to support continued development:
Top comments (0)