Can Aldena be vibe coded?

Build brief — a focused alternative to Aldena

Verdict: Partly, if you narrow it · Buildability: 43/100 · Category: Automation

Source: https://www.canitbevibecoded.com/aldena

Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from Aldena. Verify current pricing and capabilities before acting.

Context

Aldena — Role-based AI agent teams that do project work on a server of their own. It currently costs $99/mo.

One room's worth of this is a focused implementation now that the agent loop ships as an SDK: five role-scoped agents in a Docker sandbox, a manager that hands work down, a prompt before anything destructive, a pull request at the end. What does not fall out of that weekend is the rest of it. A server per project that somebody else patches and meters, ten OAuth integrations that stay authorized, memory that survives the run, and a screen where the person paying for the work can watch it and approve it. Build the room. The building around the room is the subscription.

This brief describes a focused, single-operator replacement for the part of Aldena that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.

What you are building

Run several role-scoped agents against one Docker sandbox, let a manager agent hand work to the others and collect their replies, gate the dangerous tools behind an approval prompt, and end the run with a branch and a pull request.

Automate a small number of known workflows with logs, retries, and manual recovery.

A responsive interface with real empty, loading, success, and error states.

Requirements

Functional

Docker.

GitHub CLI authenticated against the repo.

Node.js 24.

Data and integrations

Anthropic or OpenAI API key.

Each of these needs a real account, credential, or quota. Set them up before writing feature code.

Non-functional

Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.

Security: server-side secrets, validated input, and no credentials in the client bundle.

Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.

Portability: the operator can export their data and leave without losing it.

Implementation brief

Build me a local team of AI coding agents that ships pull requests, to replace Aldena. Requirements:

A CLI plus a local web page: Node 24 + Express + better-sqlite3, server-rendered with

a little vanilla JS. agents run "add rate limiting" starts a run and the page on

localhost:7070 streams what every agent is doing.

Agents are rows in SQLite: name, role, instructions, model. Seed five (manager, analyst,

backend, frontend, reviewer) from a roles.json I can edit, each calling the Anthropic API

with the key from .env.

Only the manager takes my request. It hands work to at most 3 agents per turn and stops

at depth 5. Every hand-off, reply and tool call is a row in SQLite so I can read a run

back a week later.

File edits and shell commands run inside one Docker container per project, mounting only

that project's checkout. Never on my host, never two agents in the same container at once.

A tools.json of allow / ask / deny per tool. On ask the run blocks and the web page shows

the exact command with Approve and Reject buttons; on deny the tool is not in the schema

the agent sees at all.

Memory is two Markdown files loaded at the start of a run and appended to at the end:

.agents/project.md that all of them read, .agents/NAME.md private to one agent. Cap each

at 100 lines and make the agent delete a line before it writes a new one.

A run ends with a branch, a commit and gh pr create. No agent gets the merge command,

that stays mine.

Out of scope: multi-user accounts, seat billing, and OAuth into Jira, Linear or Slack.

Do not provision servers, the Docker container is the whole runtime.

No accounts, no telemetry, everything on my machine except the model calls. Secrets in .env.

Include a README with setup, where the SQLite file lives, and how to authenticate gh

before the first run.

Delivery standard

Inspect the repository first, then write a short implementation plan before writing code.

Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.

Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.

Include responsive layouts plus genuine empty, loading, success, validation, and failure states.

Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.

Add structured logs around every external call and return actionable errors without leaking sensitive details.

Write unit tests for the core logic and one automated test of the main user journey.

Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.

Acceptance criteria

A clean install starts the app using only the README and .env.example.

The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.

Invalid input, missing configuration, provider failure, and an empty database each have a usable state.

The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.

Tests, type checking, linting, and a production build all pass with no ignored failures.

No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.

Non-goals

Do not build these, and do not claim to have replaced them:

A machine per project that someone else provisions, patches and bills by the hour.

Connected GitHub, Bitbucket, Jira, Linear, Notion, Slack, Drive, Gmail, Sentry and Vercel, and the upkeep behind those tokens.

Memory that outlives the run, private per agent and shared per project.

A screen a non-engineer can watch the run in and approve from.

One prepaid balance metering every model and every server hour.

What you still own after launch

Secure credentials, rotate secrets, and handle provider rate limits.

Run migrations, backups, restores, and dependency updates.

Test the critical journey after every model, API, or hosting change.

Monitor failures and fix the edge cases a first prompt will miss.

Maintain every third-party integration as APIs and OAuth rules change.

Risk

Operational risk. The code is achievable; dependable data, integrations, and ongoing operations are the real cost.

Editorial confidence in this assessment: medium. No reviewed project implementation is linked yet.

Existing alternatives

Before building, compare these checked options:

OpenHands — Agents that work in a container instead of on your laptop, with the UI, the CLI and the sandbox in the box. You supply the container host and the model bill

goose — A desktop agent that spawns subagents and drives your own tools through MCP. Vendor-neutral under the Linux Foundation, which is more than most of this field can say

Cline — The approval gate as an editor extension: it plans, then asks before each edit and each command. One agent, your repo, your keys

Prior art

Working open-source software you can read, fork, or borrow from before starting:

Claude Agent SDK — the agent loop, tool schemas and permission callbacks, already written

OpenHands — read its runtime for how to put an agent in a container safely

Model Context Protocol servers — off-the-shelf tool servers for GitHub, Slack and the rest

Generated by Can It Be Vibe Coded? · Full report: https://www.canitbevibecoded.com/aldena