We Stopped Using Linear. Here's Why "AI-Assisted" Project Management Isn't Enough.

A few months ago my team sat down to plan a login system. On paper it was straightforward: product had the requirements locked, and the frontend and backend engineers were both ready to build at the same time.

That's where Linear got in our way.

We wanted one ticket, "Build login system," that both engineers could own together while working in parallel. Linear doesn't really support that. A ticket has one assignee. So we did what everyone does: split it into "Login - Backend" and "Login - Frontend" and assigned one person to each.

It sounds like a small annoyance. It isn't. Split one piece of work into two tickets and you get two islands. The backend engineer changes an API contract halfway through and the frontend ticket has no idea. Someone has to ping the other channel, leave a comment, or hope it comes up in standup. Scale that across a real project, a dozen features with two or three people who need to move in lockstep, and you pay a steady tax in missed context and stale assumptions. Not because anyone was careless. Because the tool treats work as a single-threaded list, and engineering work usually isn't.

Linear isn't the whole story. The data model underneath is.

Linear, Jira, ClickUp, Monday: same basic shape. A list of tickets moving left to right through columns, one owner per ticket. Fine for plenty of work. A bad fit for software, where tasks aren't a line. They're a graph.

A login system isn't "backend, then frontend." Backend and frontend run in parallel, both blocked on a shared API contract, both blocking QA, with a database migration off to the side that has to land before either can hit staging. That's a dependency graph, not a to-do list. Force a graph into a list and you lose the structure that matters: what's blocking what, what can run together, and what breaks if one piece slips.

Sub-tasks, linked issues, labels, a dependency field added later: all attempts to simulate a graph with a model that isn't one. They hold up until they don't. By then someone has shipped against an API that changed three days ago.

So why isn't "AI" fixing this?

Everyone's adding AI to project management tools right now, and almost none of it touches this.

"AI-powered" in this category usually means auto-generated summaries, smart labels, a chatbot that drafts a status update, maybe a nudge about which ticket to pick up next. Useful. Still AI on top of the same list-of-tickets model, doing the same job a person did, just faster. One ticket, one owner, one line of progress: that assumption rarely gets questioned.

Cursor versus "VS Code with a Copilot plugin" is the closest analogy I have. One rebuilt the editor around the idea that AI understands your whole codebase. The other kept the old editor and taped an assistant on the side. Both technically "have AI." I don't think they're the same product category.

Project management tools, right now, are mostly the second kind.

What we're building instead

This is the problem Ravel exists to solve. We treat work as a dependency graph and put that at the center of the data model, not as a layer on top.

You describe the project in natural language and AI builds the graph: what blocks what, what can run in parallel, what depends on an external system. The login system becomes one unit of work with two people on it at once, not two disconnected tickets trying to stay in sync.

Progress comes from GitHub signals (branches, commits, PRs), not from someone dragging a card to reflect what already landed in code.

Drop in a new spec or requirements doc and the system re-reads project state instead of waiting for a manual re-triage.

That's not a smarter chatbot in the sidebar. It's a different core model for what a task is, how tasks relate, and how the tool learns that work happened. We built around that instead of bolting AI onto a shape that still thinks in spreadsheets and sticky notes.

This is still an early bet

I'll be upfront: this is a hypothesis we're actively testing, not a solved problem. We're a small team (closer to "one engineer and a lot of coffee") building this because we hit the wall ourselves and got tired of working around it. If the login-system story sounds familiar, if you've ever split one piece of work into artificial tickets just to satisfy a tool's assignee field, I'd like to hear how you've been dealing with it.

Next: why AI task generation is easy but dependency graphs are not.

We're building Ravel at theravel.app. Take a look, or tell me I'm wrong about Linear. Either way I want to know what you're using instead.