Aura: Agents + Git + Intent Open Source

Hey Product Hunt, Mo here, founder of Aura. When we launched Aura the first time, we honestly did not expect the response we got. We thought we were launching a semantic version control tool for AI-written code. Simple idea: Git shows line changes. Aura shows logic changes. But the feedback made the real problem much clearer. Developers are no longer just using one AI coding assistant. They are using Claude Code, Cursor, Codex, Gemini and other agents inside the same repos. These agents can move fast, but the control layer around them is still messy. Terminal logs. Scattered chats. Huge Git diffs. Unclear intent. No clean way to prove what the agent actually did. So we took what we learned from the first launch and rebuilt Aura around that. Aura is now a Git-native workspace for controlling AI coding agents. You can run agents from one desktop app, manage tasks, review AI-written code, inspect semantic diffs, track changes at the function/class level, connect work back to intent, and prove whether a task was actually delivered before you commit. It is not trying to replace Git. It sits on top of the Git workflow teams already use and gives you a better way to work with agent-written code. Git tells you what lines changed. Aura tells you what the agent actually did. This second launch is our next step: from semantic source control to a full desktop control layer for AI coding agents. Would love feedback from builders using Claude Code, Cursor, Codex, Gemini or multiple agents in real codebases. Question for everyone: What is the scariest thing an AI coding agent has changed in your repo without you noticing? Show more

How do you keep function- level tracking accurate as Claude Code and Cursor update their output?

@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 [email protected] if you want to discuss further or see how you can adopt it. Show more

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?

@amjad_shaik Both, and the loop does more than you’d expect. You can hand Crew explicit tasks, but you don’t have to: give it a one-line goal and Aura’s own model decomposes it into a small task graph with the dependencies wired for you. Or drop in a pile of existing tasks and it infers the order across them. From there it runs the graph itself, starts a task only once its dependencies are done, runs several ready tasks in parallel (each in its own isolated git worktree, merged back at the AST level), and checks every finished step against the goal it was meant to deliver. If a step fails that check, the work is rolled back automatically instead of polluting the branch, and the task loops back to be retried. So it’s less “adapt to how the agent feels” and more gate on whether the work actually landed, it adapts to proof, not vibes. Same loop runs from the CLI (aura crew run), chat (/loop), or the Crew board.

@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?

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.

@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.

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

@galdayan thanks for the question, yes, Aura understands and writes the intent automatically from diff using the same agents and cli models available in the system for coding. It makes total sense that nobody’s gonna wait to write intent after each change for AI edits. It’s fully automated, you can even chose to use a fully local model or just let Aura use Claude code or other agents in the background to keep things well organised on the intent and session matters.

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?

@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.

@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.

@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?

@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.

@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.

@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.