Aura is not another chat box for coding.
It is a Git-native IDE for working with AI coding agents. You can run agents, track their changes at the function and class level, compare the code against the original intent, and prove whether a task was actually completed before you commit.
Git shows you lines changed.
Aura shows you what changed in the logic.
This is the 2nd launch from Aura : Agents + GIt + Loops OSS ADE. View more
Aura: Agents + Git + Intent Open Source
Launched this week
Aura is not another chat box for coding.
It is a Git-native IDE for working with AI coding agents. You can run agents, track their changes at the function and class level, compare the code against the original intent, and prove whether a task was actually completed before you commit.
Git shows you lines changed.
Aura shows you what changed in the logic.
Free
Launch Team / Built With
Aura : Agents + GIt + Loops OSS ADE
the AST-level diffing instead of parsing agent output is the smart call, that's the part that'll actually survive tool updates. question on the "intent" side though - where does the original intent come from? is it the prompt you gave the agent, a spec you write separately, or does Aura infer it from the diff itself? asking because if intent has to be written by hand for every task, that's extra overhead people will skip under deadline pressure, which is exactly when you'd want the check most
Aura : Agents + GIt + Loops OSS ADE
@mhdashiquek that's fully automated intent inference from the diff itself then, not from the original prompt. does that risk being a post-hoc story that fits the final code rather than what was actually asked for - like if the agent tried three approaches and reverted two, does aura only ever see the winning diff, or does it also capture the abandoned attempts as part of the intent record?
Aura : Agents + GIt + Loops OSS ADE
@galdayan
you're right that if the why were reverse-engineered from the final diff, it'd just be a story that rationalizes whatever shipped. That's the failure mode we built against.
The why isn't authored from the winning diff, it's captured during the session (the agent logs intent as it works, via hooks/MCP), and the diff is only used to detect what changed at the AST level and match the right why to the right code. If there's no recorded reason for a change, Aura won't invent one, it says so plainly rather than fabricating a plausible story. When a model does phrase the explanation, it's grounded in that stated intent, not the final code.
On your three-approaches example: Aura auto-snapshots each file before an AI edit into a durable store that survives even without a commit, each snapshot linked to the intent that was live at the time. So the approaches tried and reverted aren't erased just because git's committed diff only shows the net change, they're retained and browsable in Rewind/Time-Machine.
Honest boundary: for a tool we can only observe post-hoc (a raw diff, no live session), you get the net-change intent, not the full journey, the richer history needs the live capture hook, which is on by default for the agents we drive. Only if it is turned off the system wouldn't perform as it's intended to be.
The AST-diff-over-parsed-output call is right — Gal already flagged that's the part that survives tool updates. What I'd poke at is Mo's answer to him: if intent is inferred from the diff by the same class of model that wrote the code, then "does the code match intent?" is comparing the diff to a description of the diff, both downstream of the same generation. That catches the agent fumbling syntax. I don't see how it catches the agent confidently doing the wrong thing, because the reconstructed intent will just narrate whatever the diff did and call it deliberate. I hit exactly this running eval on my own app's output — an inferred rubric inherits the generator's blind spots and rates the confident-wrong case as a pass. Is there any mode where intent is anchored to something upstream of the diff — the original task, a human note — so the check has an independent reference?
Aura : Agents + GIt + Loops OSS ADE
@narek_keshishyan
you're right that a rubric reconstructed from the diff inherits the generator's blind spots. That's why the diff-derived note is only the display fallback, not the check. The actual verification anchors upstream: you (or the task) state a goal in plain language, "users can sign in via Google", Aura decomposes it once into concrete requirements, and then re-checks those against the real code over time, independent of whatever any diff claims.
Crucially it returns "unknown" rather than a pass when it can't confirm, it won't rate confident-wrong as done. There's also a second, non-LLM guard: the pre-commit check is deterministic, every symbol the commit touched has to actually appear in the stated intent, so a "fix typo" message on a 30-function refactor gets flagged mechanically, no model narrating involved.
How do you keep function- level tracking accurate as Claude Code and Cursor update their output?
Aura : Agents + GIt + Loops OSS ADE
@kellyops
Great question, here's the honest answer:
Aura doesn't parse agent output at all. That's the key. It tracks changes at the AST level directly from the code on disk, not from anything Claude Code or Cursor emit. So when those tools change their output format, prompt, or diff style, there's nothing for us to break against, we re-parse the actual source files with tree-sitter and diff the syntax trees. The agent could hand us code by carrier pigeon; we only ever look at the resulting bytes.
Three things make the function-level tracking robust across agent updates:
Language grammars, not tool contracts. Function/class boundaries come from tree-sitter grammars per language. Those track the language, which moves slowly and independently of any agent vendor. A Cursor update can't shift where a Rust `fn` begins.
Rename-proof node identity. We identify logic nodes by structure and content, not by line number or name, so a function that gets renamed or moved is followed as the same node rather than counted as a delete + add. This is the same mechanism whether a human, Claude Code, or Cursor made the edit, the source of the change is irrelevant to identification.
Capture is at the git/filesystem boundary, agent-agnostic. Intent + AST snapshots hook in at commit/edit time on the repo itself. We deliberately built one renderer / one tracking path that any agent flows through, rather than an integration per tool, so there's no per-vendor adapter to maintain as they update.
So the maintenance burden isn't "keep up with N agents changing their output", it's "keep up with tree-sitter grammars," which is a much smaller, slower-moving surface that the whole ecosystem shares.
The one real edge is brand-new language syntax (e.g. a new language version adds a construct the grammar doesn't know yet), that's a grammar bump, not an agent-tracking problem, and it's the same fix regardless of which tool wrote the code.
I hope this helps, you can reach me at mo@auravcs.com if you want to discuss further or see how you can adopt it.
The built-in loops caught my attention since that’s usually where agent workflows start getting more interesting. Are those loops something developers configure themselves, or can Aura adapt them based on how the agent is performing?
Aura : Agents + GIt + Loops OSS ADE
@mhdashiquek That’s a helpful explanation. I like the idea of validating work against the intended goal instead of just retrying blindly—it feels like a cleaner way to keep long-running agent workflows on track. Thanks for taking the time to explain it.
An open-source ADE sitting on top of local agent CLIs like Claude Code and Cursor is the missing control layer — the agents ship fast but there's no cockpit over them. Two setup questions: does Aura run fully local against my own repo and agent binaries, or does the orchestration route through a hosted service? And where does the loop/intent state live — committed into the repo alongside git, or in a separate Aura store I'd have to sync per machine?
Aura : Agents + GIt + Loops OSS ADE
@noctis06
Local-first, yes, the loop runs entirely on your machine. The desktop app and CLI drive your agent binaries (Claude Code, Codex, Cursor, Gemini) as local subprocesses, against your git repo. There's no hosted orchestrator in the path, the kick-agent → check-diff → prove → commit loop executes locally and works fully offline. The only cloud touchpoints are opt-in and additive: team awareness/collab sync, consent-gated anonymous telemetry, and our hosted "brain" if you choose it instead of your own binaries. Nothing about running agents against your repo requires our servers.
State lives in the repo, not a side store you babysit. Aura keeps two planes. Your code stays in plain git, untouched. The meaning plane, intent log, the goal/proof ledger, session records, lives in a .aura/ directory inside the repo and is git-tracked, so it travels through your normal git push/pull with no separate per-machine sync. Purely local artifacts (rewind snapshots, caches) stay on the machine by design and aren't something you need to move around. So: committed alongside git, portable with the repo, and readable/diffable like anything else in it.
@mhdashiquek The .aura/ git-tracked meaning plane is the right call — keeping intent/proof diffable in the repo instead of a side DB is what makes it portable. One team question that follows: when two people run agents on different branches and merge, do the intent-log and goal/proof ledger entries in .aura/ merge cleanly, or conflict like any hand-edited file and need resolution? Curious whether they are append-only or structured to avoid merge churn.
Aura : Agents + GIt + Loops OSS ADE
@noctis06
They're built to combine, not collide. The intent log and goal/proof ledger are append-only JSONL every entry is one immutable line, nothing is ever rewritten in place, so a merge is just two sets of rows coming together, never a "which version wins" fight. The why also travels as git notes under a dedicated ref that's union-merged and idempotent: the same entry from two branches dedupes instead of duplicating.
Code itself merges through an AST-aware driver. The one honest caveat: if two branches append to the exact same file tail, git can still flag a textual conflict like any log, but it's a keep-both, zero-loss resolution, and dropping .aura/*.jsonl merge=union in .gitattributes makes even that auto-resolve.
The built-in loop is the part I keep hand-rolling myself: kick the agent, check the diff, re-run. How does Aura decide a loop is done versus stuck in a rewrite spiral? That's usually the moment I have to step in and babysit mine.
Aura : Agents + GIt + Loops OSS ADE
@chielephant
That babysitting moment is exactly what we built the loop around, so the short version: Aura judges "done" by the goal, not by "the agent stopped talking." Every task carries an explicit goal, and after each pass Aura runs a proof against it, checking the logic your change was supposed to add actually exists and is wired in, plus tests and an intent-vs-change match. "Done" = that verdict comes back verified and the work commits cleanly.
The rewrite-spiral case falls out of the same mechanism: passes are bounded, and because each iteration is scored against the goal, a spiral shows up as iterations that keep running without moving the verdict (checks still failing / not wired). At that point the loop stops and hands the task back as failed, with the proof verdict attached, so instead of watching every diff, you get pulled in once, with a straight answer to "what's still not satisfied." It also flags when an agent's edits drift from the stated intent, which is usually the earliest signal a run is going sideways.
Fair disclosure: automatic rollback-on-failed-verify and worktree-parallel passes are still landing, today it stops and surfaces rather than auto-reverting, but the goal-anchored "is this actually done" check is the live core.