From Chat Box to Orchestration: How Aura Became a Real AI Coding IDE

In my last post, I wrote about Aura as an open source AI coding harness you can control.

The core idea was that the harness matters.

Not just the model. Not just the chat box. The harness.

How plans are formed. How files are edited. How validation is reported. How memory is stored. How the user can see whether the work actually happened.

Since then, Aura has grown in a way that makes that idea feel much more real.

The biggest addition is Drones.

Aura is no longer just a main conversation that can dispatch a Worker. It now has dedicated worker surfaces that can live alongside the main chat, hold their own shape, and give the user a cleaner way to break work apart.

That changes the product.

It moves Aura closer to what I have wanted it to become from the beginning. A local AI orchestration IDE.

The problem with one giant chat thread

A lot of AI coding work still happens inside one long conversation.

That can work for small tasks, but it starts to get messy once the work branches.

One thread might contain planning, debugging, repo inspection, test output, UI polish, release notes, architecture decisions, and unrelated follow-up requests all tangled together.

Eventually the chat becomes the workspace.

That is not always what you want.

Some tasks need focus.

Some tasks need to run beside the main conversation.

Some tasks are repeatable enough that they should become reusable surfaces, not temporary prompt blobs.

That is where Drones come in.

What Drones are

Drones are focused worker surfaces inside Aura.

They are not just a note, not just a prompt template, and not just another chat tab.

They are a way to give Aura dedicated workers that can be summoned for specific kinds of work.

A Drone can represent a focused process, a reusable helper, or a specialized workflow inside the IDE.

The important part is that Drones belong to the harness.

They sit inside the same broader system Aura is built around:

project context
visible planning
Worker execution
safe edits
validation
Craft quality checks
workflow state
user approval
local memory

That matters because a Drone should not feel like opening another disconnected chatbot.

It should feel like adding a focused tool to the workspace.

Why this changes Aura

Before Drones, Aura's shape was mostly:

User asks → Planner reasons → Worker executes → Aura reports what happened.

That is still a good core loop.

But Drones expand the workspace around that loop.

Now Aura can support focused worker surfaces that are separate from the main conversation but still part of the same local harness.

This only works because the coding harness underneath is real. Each Drone inherits the full execution loop - repo awareness, spec-driven edits, diff approval, validation, recovery, project memory. Orchestration built on top of a chat box gives you parallel chat boxes. Orchestration built on top of a real coding harness gives you parallel workers that can actually be trusted with your codebase.

That unlocks a different way of thinking about AI coding.

Instead of asking one chat to do everything, you can start thinking in terms of focused workers:

a Drone for tests
a Drone for documentation
a Drone for release notes
a Drone for repo cleanup
a Drone for UI polish
a Drone for debugging
a Drone for reviewing changes
a Drone for project-specific workflows

The point is not to add complexity for the sake of it.

The point is to make the workspace match the work.

Software projects are not one linear conversation. They are branching systems of investigation, execution, cleanup, review, and iteration.

Drones give Aura a way to reflect that.

The harness still matters

This is why I keep coming back to the harness.

If the whole product is just a chat box, then every new capability becomes another message in the same scroll.

But if the product is a harness, new capabilities can become real surfaces.

They can have state.

They can have purpose.

They can be reused.

They can report outcomes clearly.

They can fit into the same safety and validation model as the rest of the app.

That is the direction Aura is moving.

The model is important, obviously.

But the model is not the whole workflow.

The workflow is the system around the model: context, planning, tools, edits, validation, memory, recovery, approval, and visibility.

Drones are a major step toward making that system feel like an actual IDE instead of a prettier prompt window.

Companion

Aura also now has a Companion preview.

Companion is a phone based surface for Aura Desktop.

The preview is live - phone pairs with desktop, messages route through, responses stream back in real time. Projects, runs, and deeper mobile controls are still being polished.

But the architecture is important.

Aura Desktop stays the brain.

The phone becomes a lightweight remote surface around it.

That means Companion is not trying to turn Aura into a cloud only app. It is not replacing the desktop workspace. It is a path toward controlling and observing a local first AI IDE from another device.

Long term, that could mean checking project context from your phone, reviewing run status, sending quick commands, viewing receipts, or steering work without sitting directly in front of the desktop window.

The shape is clearer now

Since the last post, Aura has moved beyond the original shape.

It is not only:

Planner. Worker. Safe edits. Validation. Memory.

Those are still the foundation.

But now the app has more surface area around that foundation.

The current shape looks more like this:

the main desktop workspace
project-aware conversations
Planner and Worker execution
safe diffs and approvals
visible outcomes
local project memory
Craft quality checks
Drones as focused worker surfaces
Companion as a mobile preview surface

That feels much closer to the actual product I want Aura to become.

A local AI orchestration IDE.

Not a chatbot with file access.

Not a black box agent that says "done" and hopes you believe it.

A workspace where the developer owns the harness, sees the work, controls the flow, and can shape the system around how they actually build.

Why this matters

AI coding tools are getting stronger, but the workflow problem is still real.

It is not enough for a model to be smart.

The surrounding system has to make the work trustworthy.

Did it plan clearly? Did it read the right files? Did the edit apply? Did validation run? Did it fail because of the patch, the command, the repo, or the harness? Can the user inspect what happened? Can the workflow be reused? Can different kinds of work live in different places?

Drones are a big answer to that last question.

They give Aura a way to grow beyond one conversation without losing the core idea of control.

Companion points in the same direction from another angle: more surfaces around the same desktop brain.

That is the pattern.

Aura Desktop remains the local workspace and orchestration engine. Drones become focused workers inside it. Companion becomes a lightweight remote surface around it.

The model can change. The provider can change. The UI can grow.

But the harness remains the thing the developer owns.

That is still the bet.

Own the harness. Make the work visible. Keep the developer in control.

During May 2026, Aura processed over 1.1 billion DeepSeek tokens across nearly 30,000 API requests while building itself. $35.18 in total API spend. Prompt cache hit rates run above 90%, by design.