For about a year, my entire development environment was one terminal running Claude. And honestly? It was great.
Type what you want, watch it happen, ship. The CLI era of agentic coding was magical precisely because it was so thin: no IDE ceremony, no plugin ecosystem, just you and a model that could actually do the work. I wrote less code in that year than in any year of my career, and shipped more.
Then my ambitions grew, and the thin layer started to crack.
The workarounds were the spec
It didn't crack all at once. It cracked one workaround at a time.
First I wanted two things running simultaneously, so I learned to juggle tmux panes. Then the agents started stepping on each other's branches, so I wrote a shell script to spin up git worktrees by hand. Then I closed a terminal and lost the entire conversation that explained why a change looked the way it did — so I started pasting decisions into a notes app. Then I couldn't remember which of five branches was reviewed and which was still cooking, so I added a tracker. Then the tracker had no idea what the agents were doing, so I kept the real state in my head.
Every one of those workarounds was a four-line fix for a structural problem. And at some point I looked at the pile — the tmux config, the worktree script, the notes file, the tracker nobody updated — and realized I wasn't using a development environment anymore. I was being one. I was the scheduler, the state store, the message bus, and the audit log for a small team of very fast, very forgetful engineers.
The CLI never failed me. It just had nothing to say about everything that happens around a session: what the task was, what we decided, where the work stands, what's waiting on me. As agentic needs got more complex, the gap between "run a session" and "run my work" became the whole job.
That pile of workarounds was the spec for Fredrin. I just didn't know it yet.
A second brain with hands
The closest thing I had to a fix was the second-brain playbook. Obsidian, a vault of notes, decisions written down, context captured. And it genuinely helps — a second brain remembers.
But that's all it does. A note about a refactor cannot do the refactor. The vault holds your intent perfectly and your execution not at all, so you're back to being the bridge: read the note, re-explain it to an agent, watch the agent work, write down what happened. Every trip across that bridge is you, manually, copying context between a system that remembers and a system that acts.
Fredrin started from a simple question: what if the memory and the hands were the same object?
That object is the ticket. A ticket in Fredrin holds the intent (description, plan, acceptance criteria), the memory (every conversation with the agent, every decision, every review note — persistent, not scrollback that dies with a terminal), and the execution (its own branch, its own isolated worktree, its own AI agent session running inside it). Nothing gets copied between systems because there's only one system. The note about the refactor is the thing doing the refactor.
A second brain remembers what you were doing. Fredrin remembers — and then goes and does it. A second brain with hands.
What "agentic IDE" actually means
I call Fredrin an agentic IDE, and I mean something specific by it — not an editor with a chat pane bolted on.
The IDEs we have were built around the scarce resource of their era: the human typing. Everything orbits the buffer — the file tree, the autocomplete, the debugger. But when agents write the code, typing isn't scarce anymore. What's scarce is your attention across many parallel streams of work. An agentic IDE should be built around that instead.
So Fredrin's primitives are different:
- The unit of work is the ticket, not the file. You don't open a project and start editing; you drop a ticket and a Worker picks it up in its own branch and worktree.
- History is first-class. Every ticket carries its full task history — the plan, the conversation, the rejections and re-runs. Six months later you can open a shipped ticket and see not just the diff but the reasoning. Try reconstructing that from a closed terminal.
- Context is durable and lives in your repo. A project's glossary, decisions, and conventions live as files (
CONTEXT.md,docs/adr/,AGENTS.md) that every Worker reads on every ticket — and improves via commits you review like any other code. Delete Fredrin tomorrow and your accumulated context walks away with you. - The board is the editor. Your main surface isn't a buffer, it's a kanban: backlog, planning, building, review. A glance tells you what's running, what's blocked on a question, and what's waiting for you to ship. Review is the human's real job now, so the UI optimizes for the glance — diff, CI status, merge, done.
One ticket, one Worker, one worktree, one branch, one coherent context. Run ten at once. That's the whole model.
The gaps nobody was filling
When I went looking for this before building it, everything I found solved one slice and ignored the rest.
The terminal multiplexers — tmux setups, cmux — solved spawning. Genuinely. Running six sessions in parallel is a solved problem, and the terminal community solved it without anyone's permission. But a session viewer can tell you who's printing text right now; it can't tell you what's done, what's blocked, or what you already reviewed before lunch. Sessions, no lifecycle.
The chat-based tools have the opposite problem: the conversation is the product, and a time-ordered scrollback is where context goes to die. Your decision from Tuesday gets the same treatment as "ok" and a 400-line stack trace, and it's gone the moment it scrolls. Memory, no structure.
The trackers — Linear and friends — have the structure and none of the hands. A ticket in Linear is a noun in a different window from all the verbs. It doesn't know an agent exists, let alone what one did.
And the note vaults, as covered, remember everything and do nothing.
Each tool is fine at its slice. The cost is the seams — you, refreshing the whole graph in your head, every switch, all day. The thing nobody built was the full loop in one opinionated surface: ticket to branch to agent to review to merge, with the context riding along the entire way. That loop is not a feature you bolt onto a session viewer or a tracker. It's a product, and it has to be built as one.
Where it landed
So that's what I built. Fredrin is a desktop kanban where every ticket gets its own branch, worktree, and AI agent, where the task history never evaporates, and where your job collapses to the two things agents genuinely can't do: deciding what's worth building, and deciding whether it ships.
It's BYOS — bring your own subscription. Workers run on the Claude, ChatGPT, Cursor, or Copilot plan you already pay for, so flat monthly does the work instead of a metered API bill. Your repo, your keys, your context.
The CLI got me here, and I'm grateful for it. But one terminal at a time was always a stage, not a destination. The destination is an environment built for the actual shape of the work now: many agents, one human, and a surface that holds everything so your head doesn't have to.
Fredrin is in closed alpha on macOS. If you've felt your own pile of workarounds turning into a job description, we want you in the alpha: fredrin.com.