Why I Built AIDEN — AI Broke Project Management, So I Fixed It

We had it figured out. Kind of.

Before AI entered the picture, software development had a rhythm. Not a perfect one — nobody loved Jira, and standups were 50% theater — but it worked.

You had a ticket. The ticket had a description, acceptance criteria, maybe a technical approach. A developer picked it up, created a branch, wrote code, opened a PR. Someone reviewed it. It got merged. You could trace any line of code back to a decision, a requirement, a conversation.

Was it slow? Sure. Was it bureaucratic? Sometimes. But when something broke in production at 3am, you could figure out what changed, why, and who decided it. That's traceability, and it matters more than most people realize — until they don't have it.

Then AI showed up and we threw it all away

Here's what happened: AI made coding so fast that we collectively decided process was optional.

Why write a spec when you can just tell Claude "build me an auth system" and get working code in 90 seconds? Why create a ticket when the feature is already half-done by the time you'd finish typing the description? Why plan a sprint when your AI can "just build it" on demand?

So we stopped planning. We stopped speccing. We stopped structuring. And what we got instead was… a succession of chat threads.

Think about it. Most AI-assisted development today looks like this:

1. Open a chat with your AI
2. Describe what you want in natural language
3. Get code back
4. Paste it somewhere
5. Open a new chat for the next thing
6. Repeat

Where's the history? Where's the "why"? If someone asks you in two months why a particular function exists, your answer is "uhh, I think I asked Claude about it in some thread somewhere." Good luck finding that thread. Good luck reconstructing the decision chain.

You can't build serious software like this. A one-off script, sure. A weekend hack, absolutely. But a product with multiple features, multiple contributors, evolving requirements? You need structure. You need traceability. You need to know what was built, why, and what comes next.

The second problem: everything feels easy, so nobody scopes

This one's sneakier.

AI gives you so much power that everything feels achievable. "Add real-time collaboration? Sure, give me 20 minutes." "Build a recommendation engine? No problem." "Rewrite the entire frontend in a different framework? Why not?"

When building feels effortless, scoping feels pointless. Why spend an hour defining what "done" looks like when you can just… start building and figure it out?

I'll tell you why: because three weeks later you have a bloated codebase with half-finished features, no clear direction, and a product that does 40 things poorly instead of 5 things well.

The power AI gives you is real. But power without direction is just chaos with better tooling.

I've seen it in my own projects. I've seen it in others'. The pattern is always the same: start fast, accumulate scope, lose focus, burn out. Not because the tech failed — because the process did.

So I built AIDEN

AIDEN started from a simple frustration: I wanted AI to help me build software, but I didn't want to lose everything that made professional development actually work.

Not the bureaucracy — I have zero interest in recreating Jira. But the principles: know what you're building before you build it, track what got built, make decisions traceable, and don't let the speed of AI become an excuse for the absence of thought.

Here's what AIDEN does and why each piece exists.

Stories and a kanban board — because traceability isn't optional

Every piece of work in AIDEN is a story. Stories live on a board. They move through stages: BACKLOG → READY → IN_PROGRESS → REVIEW → DONE.

This isn't revolutionary — it's deliberately old-school. Because the problem was never "we don't have a good board tool." The problem is that AI workflows bypassed the board entirely.

In AIDEN, the AI can't bypass it. Every feature flows through a story. The AI creates the story, writes the spec, implements it, and moves it across the board. If you come back in three months and ask "when did we add this feature?", you'll find it. The story, the spec, the commits, the decisions — all linked.

Spec-driven development — because "just build it" is a trap

Before AIDEN writes a single line of code, it writes a spec. User story. Acceptance criteria. Technical approach. Edge cases. Testing strategy.

This is the part most people skip with AI. "Why spec it when the AI can just code it?" Because the spec forces you to think. It surfaces ambiguity early. "What happens when the user has no items?" "What if the API is down?" "Does this need to work offline?"

The spec is also a contract. When the AI is done implementing, you can check the acceptance criteria and know — objectively — whether the feature is complete. No vague "looks good to me." Either it meets the criteria or it doesn't.

And here's the thing: the AI writes the spec for you. You describe what you want in plain language, and AIDEN produces a structured spec that you review. You're not doing the paperwork — you're doing the thinking. Big difference.

Agent orchestration — because one AI doing everything is a bottleneck

AIDEN doesn't use one AI for everything. It coordinates specialized agents — an architect for system design, a frontend engineer for UI work, a backend engineer for APIs, a QA engineer for testing.

Why? Same reason a real team has specialists. The architect thinks about patterns and tradeoffs. The frontend engineer knows about accessibility and component design. The QA engineer thinks about edge cases you didn't consider.

These agents work in parallel. While one is building the UI, another is building the API. AIDEN coordinates them, handles file conflicts, and makes sure they don't step on each other. It's like being a tech lead — except your team executes in minutes instead of days.

Browser and terminal tabs — because AI should see what it builds

One of the dumbest things about current AI dev workflows: the AI writes code but never sees the result. It generates a React component and has no idea if it actually renders correctly. It writes a server and can't verify it starts.

AIDEN gives agents real browser and terminal tabs. They can start a dev server, open the app in a browser, check for errors, take screenshots, click around. If something's broken, they see it — and fix it — before you ever look at it.

This sounds like a small thing. It's not. It's the difference between "here's some code that should work" and "here's a feature I built and verified."

Git integration — because version control is not optional

Every story gets a branch. Commits are tied to stories. PRs are created automatically. The AI doesn't just dump code into your repo — it follows the same git workflow a professional developer would.

No more "I asked the AI to change something and now I don't know what state my codebase is in." Every change is tracked, every branch is clean, every commit has context.

Multi-agent coordination — because parallel work needs rules

When multiple agents work simultaneously, you need coordination. AIDEN handles file locks (two agents can't edit the same file at once), API contracts (one agent publishes an interface, another implements against it), and broadcast warnings (if one agent's changes affect others).

This is the stuff that breaks in real teams too — except in AIDEN, it's automated. No merge conflicts at 5pm on a Friday. No "I didn't know you changed that function."

The philosophy

AIDEN isn't anti-AI. It's pro-structure.

The whole point is to keep everything that makes AI development powerful — the speed, the capability, the ability to build in hours what used to take weeks — while bringing back everything we lost when we abandoned process.

Think about it this way: AI is the engine. AIDEN is the steering wheel, the GPS, and the dashboard. You can have the most powerful engine in the world, but without direction and visibility, you're just going fast in circles.

The developers who'll build the best products in the next few years won't be the ones with the best AI models. They'll be the ones with the best systems around those models. Structure. Traceability. Scoping. Quality gates.

The boring stuff. The stuff that actually matters.

Where this is going

I'm building AIDEN in the open. Every feature I add is built by AIDEN — which is the most honest test I can think of. If the system can build itself reliably, it can build anything.

If you're tired of AI development feeling like a series of disconnected conversations, if you've felt the pain of losing track of what was built and why, if you've watched a project balloon because "AI makes everything easy" — you're not alone. That's exactly why AIDEN exists.

---

Try AIDEN — it's in beta

AIDEN is currently in beta and available to try right now. If anything in this post resonated — the lost traceability, the scope creep, the feeling that AI development should be better than this — give it a shot.

It's free during the beta. I'm actively building it (with itself), shipping fast, and shaping the product with early users. Your feedback will literally shape what AIDEN becomes.

👉 Get started at aidenapp.org

---

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