DEV Community: CarpseDeam

How I Used Aura to Build a Lead Discovery Tool Without Burning Tokens

CarpseDeam — Sun, 07 Jun 2026 19:45:00 +0000

Signal Desk finds relevant conversations, ranks them as leads, writes reviewable inbox cards, and helps draft outreach replies. I built it with Aura’s phased workflow, visible diffs, validation, and cheap models for about ten cents.

While building Aura, I try to greenfield real projects with it as often as possible.

Not toy prompts. Not “make a todo app.” I mean projects that are actually useful, a little messy, and close to the kind of work I do in real life.

Most of the time, I run the same project twice: once before a major Aura change, and once after. It becomes a practical A/B test:

Did Aura get faster?
Did the output get cleaner?
Did the project shape improve?
Did I have to fight it less?

That is the test I care about, because real codebases do not behave like polished demos. They evolve in phases. Requirements shift. Some parts are obvious, some are fuzzy, and the tool has to stay useful through all of it.

For this release, the dogfood project was Signal Desk, a local lead discovery and outreach tool.

What Signal Desk Does

Signal Desk scans sources like RSS and Hacker News, turns relevant posts into candidates, scores them as potential leads, writes reviewable inbox cards, and helps draft replies.

The product loop is:

sources → candidates → dedupe → scoring → findings → inbox cards → show / ignore / reply

That is the kind of workflow I like testing Aura against. It is small enough to build quickly, but real enough to expose whether the generated code has an actual product shape.

The Setup

For this run, I used cheap models for both planning and implementation.

Aura running Planner and Worker on DeepSeek V4 Flash. The full dogfood build cost about ten cents in model usage._

That cost matters, but the point is not just “cheap tokens.”

The point is that cheap models are getting good enough that the harness around them matters more and more. If Aura can keep the work focused, visible, and validated, low-cost models can go much further than people expect.

The model is the fuel.

Aura is the harness that turns it into controlled work.

My Aura Workflow for Larger Projects

For larger projects, I usually do not ask Aura to build the whole thing in one giant prompt.

My workflow is:

Write a real spec.
Ask Aura to split it into phases.
Dispatch one phase at a time.
Let Aura execute the slice.
Inspect the output, validation, files, and commits.
Move to the next phase.

This keeps the model focused, and it keeps me in control.

Instead of reviewing a huge mystery blob at the end, I can inspect each slice as it lands.

The Phase Plan

Signal Desk was split into phases:

Phase 1: Project skeleton and init command
Phase 2: Data models and storage
Phase 3: Source adapters
Phase 4: Scoring and ranking
Phase 5: Reply drafting
Phase 6: Inbox and remaining CLI commands
Phase 7: Tests and polish

Aura starts from a real spec, then turns it into a focused phase with concrete files and validation targets._

That phase structure matters. Aura is not just being asked to “make an app.” Each dispatch has a focused job.

The Flow Is the Feature

My favorite part of using Aura is the flow.

When Aura is working well, it feels smooth and quick. Planner shapes the slice, Worker moves through the files, validation runs, the project tree changes, and the output starts becoming real.

That is the feeling I am chasing: AI coding that does not feel like wrestling. It feels like watching the work click into place.

A good run looks like this:

spec → phase → files → validation → next phase

Not chaos. Not blind trust. Not “hope the agent did the right thing.”

Just a controlled build loop.

Caption: Phase 1 completed with acceptance criteria checked, validation run, and a clean handoff to the next phase.

What Aura Built

By the end, Signal Desk had:

an installable Python package
signal-desk init
local config and workspace setup
SQLite storage
RSS and Hacker News sources
candidate deduplication
deterministic scoring
markdown inbox cards
reply drafting
scan, watch, inbox, show, ignore, and reply commands
109 tests passing

Caption: By the end, Signal Desk had a full project structure and 109 tests passing.

The final user loop looked like this:

scan sources → rank leads → review inbox → inspect details → ignore or draft a reply

That is the difference between generated files and a usable product slice.

Example: The Main Product Loop

This is the kind of output I am looking for from Aura.

The scan command is not just a placeholder. It follows the actual product flow.

def _run_scan(config_dict: dict) -> dict:
    started_at = datetime.utcnow()

    conn = db.init_db(paths.get_db_path())
    logging_setup.setup_logging(paths.get_logs_dir())

    sources_cfg = config_dict.get("sources", {})
    scoring_cfg = config_dict.get("scoring", {})
    dedupe_days = scoring_cfg.get("dedupe_days", 14)

    source_instances = []

    if sources_cfg.get("rss", {}).get("enabled", True):
        source_instances.append(RSSSource(sources_cfg["rss"], config_dict))

    if sources_cfg.get("hackernews", {}).get("enabled", True):
        source_instances.append(HNSource(sources_cfg["hackernews"], config_dict))

    all_candidates = []

    for source in source_instances:
        candidates = source.fetch()
        all_candidates.extend(candidates)

    new_candidates = []

    for candidate in all_candidates:
        existing = find_candidate_by_url_or_normalized_title(
            conn,
            candidate.url,
            candidate.title,
            dedupe_days,
        )

        if existing is None:
            new_candidates.append(candidate)

    findings = rank_candidates(conn, new_candidates, config_dict)

    for finding in findings:
        if finding.priority in ("high", "medium"):
            write_inbox_card(finding, paths.get_inbox_dir())

    insert_scan_run(conn, scan_run)

What I like here is the shape:

config → sources → candidates → dedupe → scoring → inbox → scan record

That is a real product loop. The code is not trying to be impressive. It is trying to be useful.

Example: Domain-Shaped State

Signal Desk has a simple domain:

sources produce candidates
candidates become findings
findings go into the inbox
scan runs record what happened

@dataclass
class Candidate:
    id: str
    source: str
    source_item_id: str | None
    title: str
    body: str
    url: str
    author: str | None
    created_at: datetime | None
    fetched_at: datetime
    raw: dict


@dataclass
class Finding:
    id: int | None = None
    candidate_id: str = ""
    source: str = ""
    title: str = ""
    url: str = ""
    score: int = 0
    priority: str = "low"
    reason: str = ""
    best_angle: str = ""
    avoid_note: str = ""
    draft_reply: str = ""
    status: str = "new"


@dataclass
class ScanRun:
    id: int | None = None
    started_at: datetime | None = None
    finished_at: datetime | None = None
    candidates_found: int = 0
    new_candidates: int = 0
    findings_created: int = 0
    errors: str | None = None

This is boring in the right way.

The names match the product. The state is explicit. The rest of the project has something clean to build around.

That is the kind of code I want from AI: not generic DataManager soup, but simple concepts that belong to the thing being built.

Example: Scoring That Explains Itself

For a lead discovery tool, scoring needs to be inspectable. I do not just want a number. I want to know why something landed in the inbox.

def score_candidate(candidate: Candidate, config: dict) -> dict:
    aura_cfg = config.get("aura", {})

    include_kw = aura_cfg.get("include_keywords") or []
    pain_kw = aura_cfg.get("pain_keywords") or []
    avoid_kw = aura_cfg.get("avoid_keywords") or []

    title = candidate.title or ""
    body = candidate.body or ""
    combined = title + " " + body

    score = 0
    reason_parts = []
    avoid_note_parts = []

    for keyword in _check_exact_matches(title, include_kw):
        score += 35
        reason_parts.append(f"Matched '{keyword}' in title (+35)")

    for keyword in _check_exact_matches(body, include_kw):
        score += 20
        reason_parts.append(f"Matched '{keyword}' in body (+20)")

    if _has_alternative_intent(combined):
        score += 10
        reason_parts.append("Alternative intent detected (+10)")

    for keyword in _check_exact_matches(combined, avoid_kw):
        score -= 40
        avoid_note_parts.append(f"Avoid keyword '{keyword}' matched (-40)")

    score = max(0, min(100, score))

    return {
        "score": score,
        "reason": "; ".join(reason_parts) or "No strong signals detected",
        "best_angle": best_angle,
        "avoid_note": "; ".join(avoid_note_parts),
    }

This is exactly what I want for this kind of tool.

The scoring is deterministic. The reasons are visible. The user can inspect why something matched before deciding whether to respond.

Example: Reviewable Inbox Cards

Signal Desk does not just dump rows into a database. It writes markdown cards that can be reviewed directly.

def format_finding_card(finding: Finding, include_draft: bool = True) -> str:
    priority_emoji = {
        "high": "🟢",
        "medium": "🟡",
        "low": "⚪",
    }.get(finding.priority, "⚪")

    lines = [
        f"# {priority_emoji} {finding.priority.upper()} · score {finding.score}",
        "",
        f"**Source:** {finding.source}",
        f"**Title:** {finding.title}",
        f"**URL:** {finding.url}",
        f"**Status:** {finding.status}",
        "",
        "## Why this matters",
        finding.reason or "No reason recorded.",
        "",
        "## Best angle",
        finding.best_angle or "No angle recorded.",
        "",
        "## Avoid",
        finding.avoid_note or "None",
    ]

    if include_draft and finding.draft_reply:
        lines += ["", "## Draft reply", finding.draft_reply]

    return "\n".join(lines)

That is product thinking.

The user’s job is not “own a database.” The user’s job is to review useful conversations and decide whether to respond.

The output supports that job.

Caption: Signal Desk generated ranked lead cards from scanned conversations.

Example: Reply Drafting

Signal Desk also helps draft replies from a finding.

It supports different styles and a no-Aura mode for cases where I want to respond without mentioning the project directly.

def generate_reply(
    finding: Finding,
    style: str = "helpful",
    no_aura: bool = False,
) -> str:
    ctx = _build_context(finding)

    if no_aura:
        reply = no_aura_template(ctx)
    elif style == "technical":
        reply = technical_template(ctx)
    elif style == "short":
        reply = short_template(ctx)
    else:
        reply = helpful_template(ctx)

    if no_aura and "aura" in reply.lower():
        reply = no_aura_template(ctx)

    return reply

Again, this connects back to the workflow.

Signal Desk is not just finding leads. It helps move from discovery to outreach.

Why This Matters

What I liked about this run was not that Aura generated a lot of code.

It was that the code had a shape I could keep working with.

The CLI followed the user flow. The models matched the domain. The storage layer served the product. The scoring explained itself. The inbox output was reviewable. The reply drafting connected back to the findings.

That is what I want from AI coding:

not a pile of files
not blind trust
not an expensive black box
not code I have to babysit forever

I want a useful slice I still control.

That is what Aura is built around.

Where Aura Is Headed

Aura is an open-source desktop AI coding harness.

The goal is simple:

Ask for something real.
Break it into phases.
Keep control.
Review the work.
Validate the result.
Spend almost nothing.
Get code that feels like it belongs in the repo.

That is the workflow I want to build with every day.

Aura is open source on GitHub:

[(https://github.com/CarpseDeam/Aura-IDE)]

Building Aura: An Open Source AI Coding Harness You Can Control

CarpseDeam — Thu, 04 Jun 2026 13:43:28 +0000

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:

https://buymeacoffee.com/snowballkori