How to Use AIDEN to Manage & Develop Features — The Three Workflows

You've got AIDEN. Now what?

In my last post, I talked about why AIDEN exists — the lost traceability, the missing specs, the chaos of building with AI without structure. If you haven't read it, the short version is: AI made us faster but sloppier, and AIDEN brings the structure back.

This post is the practical one. How does AIDEN actually manage a feature from idea to shipped code? And — the part that matters more than you think — how does it handle your git workflow?

Because here's the thing: not every project needs the same approach. A weekend hack doesn't need the same process as a production app with three contributors. AIDEN gets this, and it gives you three distinct workflow modes to match how you actually work.

Let's walk through the whole flow, then dig into each mode.

The feature lifecycle — from "I have an idea" to "it's shipped"

Every feature in AIDEN follows the same lifecycle, regardless of which workflow mode you choose:

1. You describe what you want. Natural language. "Add a dark mode toggle" or "Build a payment integration with Stripe." You don't need to be precise — that's AIDEN's job.

2. AIDEN creates a story and writes the spec. User story. Acceptance criteria. Technical approach. Edge cases. Testing strategy. All of it. You review, tweak if needed, and approve.

3. AIDEN delegates to agents. This is where it gets interesting. AIDEN doesn't just start coding — it breaks the work into phases and routes each phase to the right specialist agent. Architecture decisions go to the architect. Frontend work goes to the frontend engineer. API work goes to the backend engineer. They work in parallel.

4. Agents build, verify, and report back. They don't just write code — they start the dev server, open the app in a browser, check for errors, and fix issues before you ever see them.

5. AIDEN delivers. Commits, pushes, creates a PR. The story moves to REVIEW on your board. Every change is traced back to the story that required it.

That's the universal flow. What changes between workflow modes is step 5 — how the code gets versioned, isolated, and delivered. And that choice affects everything from speed to safety.

The three workflows

When you create a project in AIDEN, you pick a versioning strategy. This isn't just a setting — it fundamentally shapes how work gets done.

Vibe Mode — move fast, stay loose

What it is: No branches. No PRs. Everything happens on your current branch (usually main). AIDEN commits directly where you are.

The vibe:

You → describe feature → AIDEN specs it → agents build it → commit to main → done

When to use it:

• Solo projects where you're the only one touching the code
• Prototypes, hackathons, weekend projects
• Early-stage products where speed matters more than process
• When you're exploring an idea and don't know if it'll stick

Why it's great:

• Zero friction. No branch checkout, no PR creation, no merge step. Describe → build → commit → move on.
• Perfect for that flow state where you're shipping three features in an afternoon and don't want git ceremony slowing you down.
• You still get stories, specs, and traceability on the AIDEN board — you just skip the git branching overhead.

The tradeoff:

• No isolation. If an agent writes broken code, it's on your working branch. No clean branch to fall back to.
• No PRs, so no review gate. You trust the agents (and yourself) to get it right.
• Parallel stories can conflict — two stories touching the same files on the same branch is a recipe for pain.

Bottom line: Vibe mode is for when speed is the priority and you're comfortable with the risk. It's the "move fast and fix things" approach. No shame in it — some of the best projects start this way.

Branch Mode — the professional default

What it is: One feature branch per story. Classic git flow. feature/s-3-dark-mode-toggle gets created, agents work on it, and a PR gets opened when it's done.

The flow:

You → describe feature → AIDEN specs it → checkout feature branch → agents build → commit → push → PR → merge

When to use it:

• Any project with more than one contributor
• Production apps where you need a review step
• When you want clean git history with PRs tied to stories
• Most professional projects — this is the safe default

Why it's great:

• Full traceability. Every feature has its own branch, its own commits, its own PR. You can see exactly what changed and why.
• Review gate. The PR gives you (or your team) a chance to review before it hits main. Agents are good, but an extra pair of eyes never hurts.
• Clean rollbacks. Feature broke something? Revert the PR. The branch is self-contained.
• AIDEN handles the git ceremony for you — branch creation, commits, push, PR creation. You don't touch git at all unless you want to.

The tradeoff:

• Sequential. While one story is in progress on its branch, starting another means switching branches or stashing work. AIDEN manages this, but it's inherently one-at-a-time.
• Merge conflicts. If you've got multiple stories in flight and they touch the same files, you'll deal with conflicts when merging PRs. AIDEN can't eliminate this — nobody can.

Bottom line: Branch mode is the sensible default for 90% of projects. You get structure, traceability, and review without giving up speed. AIDEN automates the boring parts (branch naming, commits, PR creation), so it doesn't feel heavy.

Worktree Mode — parallel isolation for power users

What it is: Each story gets its own git worktree — a full, isolated copy of your repo. Multiple stories can be built simultaneously, in parallel, without ever touching each other.

The flow:

You → describe features A, B, and C → AIDEN specs all three → each gets its own worktree
→ three agent teams build simultaneously → three PRs created → merge independently

When to use it:

• When you have a backlog of independent features and want them all built now
• Teams or advanced solo devs who want maximum throughput
• Projects where features are cleanly separable (different areas of the codebase)
• When you want the confidence that story A literally cannot break story B

Why it's great:

• True parallel execution. Three features building at the same time, in isolated directories, on separate branches. No conflicts during development.
• Complete isolation. Each worktree is a full checkout. Agents in story A can't accidentally modify files that story B depends on. It's like having three separate clones — but managed for you.
• Independent delivery. Story B is done but A is still in progress? Ship B. No waiting.
• AIDEN handles the worktree lifecycle — creation, branch association, cleanup after merge.

The tradeoff:

• Disk space. Each worktree is a full repo checkout. For large repos, this adds up.
• Merge complexity. If stories A and B both modified the same utility file, you'll still get a conflict when merging the second PR. The isolation protects you during development, not at merge time.
• Cognitive overhead. You (or AIDEN) need to know which worktree you're in at any given moment. AIDEN tracks this, but if you're poking around manually, it's easy to get confused.
• Overkill for simple projects. If you're building a landing page, three worktrees is ceremony you don't need.

Bottom line: Worktree mode is the power tool. When you need maximum throughput and confident isolation, nothing else comes close. But it's a chainsaw — powerful and overkill for cutting butter.

Quick comparison

| | Vibe | Branch | Worktree | |---|---|---|---| | Branching | None | One per story | One per story | | Isolation | None | Branch-level | Full directory | | Parallel stories | Risky | Sequential | Fully parallel | | PRs | No | Yes | Yes | | Git overhead | Zero | Low (automated) | Medium (automated) | | Best for | Hacking | Most projects | High throughput | | Risk level | Higher | Low | Low | | Disk usage | Minimal | Minimal | Higher |

AIDEN features that make all of this work

The workflow mode is just the versioning layer. Underneath, AIDEN has a set of features that make the whole system tick — regardless of which mode you pick.

Agent delegation

You don't tell AIDEN how to build something — you tell it what you want. AIDEN figures out the how, breaks it into phases, and delegates to specialist agents.

A typical feature might look like this:

• Phase 1: Architect agent analyzes the codebase and designs the approach
• Phase 2: Backend agent builds the API while frontend agent builds the UI — simultaneously
• Phase 3: QA agent tests every acceptance criterion

You created these agents. You defined their specialties. AIDEN matches work to agents based on their descriptions. The architect agent you built for system design gets the system design work. The frontend agent you set up with React expertise gets the component work.

Spec-driven development

Nothing gets built without a spec. This is AIDEN's most opinionated feature, and I think it's the most important.

The spec includes:

• User story — who wants what, and why
• Acceptance criteria — the checklist that defines "done"
• Technical approach — how we're building it
• Edge cases — what could go wrong
• Testing strategy — how we verify it works

You review the spec before any code is written. This is your steering moment. Change the approach, add criteria, remove scope — all before a single line of code exists. Way cheaper to change a spec than to change an implementation.

Browser and terminal tabs

Agents don't just write code — they run it. AIDEN gives agents real browser and terminal tabs:

• Start a dev server in a terminal tab
• Open the app in a browser tab
• Check the console for errors
• Click around the UI to verify behavior
• Take screenshots

This is the difference between "code that should work" and "a feature that actually works." When an agent says it's done, it means it built the thing and verified it renders, functions, and doesn't throw errors.

Multi-agent coordination

When multiple agents work on the same story (or across stories in worktree mode), AIDEN coordinates them:

• File locks — two agents can't edit the same file simultaneously
• API contracts — one agent publishes an interface, another implements against it
• Broadcasts — if one agent's changes affect another's work, it warns them
• Conflict detection — before merging, AIDEN checks for potential conflicts

You don't manage any of this. It happens automatically. The goal is to give you the throughput of a team without the coordination overhead of a team.

Choosing your workflow

Here's my honest take:

Start with Branch mode. It's the right default for almost everyone. You get structure, traceability, and a review step. AIDEN automates the git parts, so it doesn't feel heavy.

Switch to Vibe mode when you're hacking. Building a prototype? Exploring an idea? Testing a concept? Drop the ceremony and just ship. You can always move to Branch mode when the project gets serious.

Graduate to Worktree mode when you've got a real backlog and want to ship multiple features simultaneously. You'll know when you need it — it's when you find yourself thinking "I wish I could build all five of these at once."

The beauty of AIDEN is that the feature lifecycle stays the same regardless. Stories, specs, agents, verification — all of that works identically. You're just choosing how the code gets versioned and delivered.

What this actually looks like

Here's a real example. You open AIDEN and type:

"Add a contact form with email validation and a success toast"

AIDEN:

1. Creates story #7 on your board
2. Writes a full spec — form fields, validation rules, toast behavior, error states, accessibility considerations
3. Shows you the spec and asks "Ready to implement?"
4. You say "go"
5. Checks out feature/s-7-contact-form (in Branch mode)
6. Delegates frontend work to your frontend agent, who builds the form component, wires up validation, adds the toast
7. The agent starts the dev server, opens the page, fills in the form, submits it, verifies the toast appears
8. Commits, pushes, creates a PR
9. Story moves to REVIEW on your board

You didn't write a spec. You didn't create a branch. You didn't write a commit message. You didn't open a PR. But all of those things happened, and they're all traceable. That's the point.

---

Try it yourself

AIDEN is in beta right now. Pick a project, pick a workflow mode, and see what happens when AI development has actual structure behind it.

The spec-driven approach, the agent delegation, the workflow modes — it all clicks once you try it on a real project. Not a demo. Your actual codebase, your actual features, your actual constraints.

👉 Get started at aidenapp.org

---

I'm Kylian — building AIDEN to bring structure back to AI-powered development. Follow the journey on X.