Every tool I used to build software was designed for a person who no longer exists: the one who types the code.
That person was the scarce resource for forty years, so everything orbited them. The IDE put a text buffer in the center and ringed it with autocomplete, a file tree, a debugger — machinery for making one human type faster and break less. The tracker gave that human a place to write down what to type next. The terminal gave them a place to run what they typed. Three industries, all optimized for the keystroke.
Then the keystroke stopped being scarce. Agents type now, and they type faster than I can read. And I noticed I was running a whole development environment built to speed up the one thing that was no longer the bottleneck — while the things that were the bottleneck had no tool at all.
Fredrin is what you build when you stop retrofitting the old environment and start over from that fact.
The tax was never the code
Here's the day that made the decision for me.
I had six things going at once — a bug, two features, a refactor, a dependency bump, a migration. Six terminals, six branches, six worktrees I'd spun up by hand. The agents were doing fine. The code was fine. What was killing me was everything in between: remembering which branch held which change, which session was waiting on me and which had just gone quiet, what I'd decided about the migration an hour ago and told the agent and already forgotten. I'd Cmd-Tab to a window and spend thirty seconds rebuilding where was I before I could do anything useful. Then I'd do it again for the next window.
Add up those thirty-second reconstructions across a day and that's the job. Not writing software — being the message bus, the scheduler, the state store, and the memory for a small team of very fast, very forgetful engineers. The agents had gotten cheap. I had become the expensive part, and not for any reason worth paying for.
You don't fix that by adding a feature to the terminal. The terminal's unit is a session, and a session has no idea what it's for, whether it's done, or what you decided last time. Everything a session doesn't know, you supply from memory. The fix had to change the unit.
So we changed the unit
The unit in Fredrin is the ticket. Not a tab, not a session — a ticket, in the project-management sense, except it has hands.
A ticket holds three things that used to live in three different windows:
- The intent — what you want, the plan, the acceptance checks. The stuff that used to live in a tracker that didn't know agents existed.
- The memory — every conversation with the Worker, every decision, every review note. The stuff that used to scroll off the top of a terminal and die.
- The execution — its own branch, its own isolated worktree, its own AI agent session running inside it. The stuff that used to be six terminals you juggled by hand.
One ticket, one Worker, one branch, one worktree, one coherent thread of context — from idea to merged PR. Nothing gets copied between systems because there's only one system. You stop being the glue between three tools because there are no longer three tools to glue.
That's the whole move: collapse the juggling into a single object, and put a board in front of it so a glance tells you what's running, what's blocked on a question, and what's waiting for you to ship.
Built AI-first, not AI-retrofitted
This is the part I care most about, because it's the part that's easy to fake.
Almost every tool calling itself "AI-native" in 2026 is a tool from the human-typing era with a chat pane bolted onto the side. The center of gravity is still the buffer; the agent is a guest. That works until you try to run ten agents at once, and then the seams show — because the product was never shaped around the idea that the machine, not you, is the thing producing code.
Fredrin assumes that from the first primitive. You don't open a project and start editing files; you drop a ticket and a Worker picks it up. The main surface isn't an editor, it's a board, because when agents write the code, your scarce resource is attention across parallel work, and a board is the right shape for that. History is first-class because six months from now the valuable artifact isn't the diff, it's the reasoning — the plan, the conversation, the rejections — and a human-era IDE throws all of that away the moment you close the tab.
AI-first isn't a label you earn by adding a model. It's a different center of gravity. Everything in Fredrin orbits the work moving through the board, not the human moving through a file.
Thin on purpose
The other thing I refused to do was let it get fat.
Every developer tool drifts toward bloat, because bloat is how a product manager proves they were busy. Plugin ecosystems, settings panels with three hundred toggles, a marketplace, a sidebar for every team that ever asked. Each addition is defensible alone and the sum is a cockpit you need a manual to fly. I've watched editors that started thin turn into the thing they replaced.
The most magical year of my career was one terminal and a model. No ceremony, no plugins — just intent in, work out. I wrote less code than any year of my career and shipped more. That thinness was the magic, and I wasn't going to throw it away to win a feature checklist.
So Fredrin's bet is restraint: do the one loop — ticket to branch to agent to review to merge — and do it fast, and refuse almost everything else. No plugin store. No setting you don't need. The board is fast because it's spare. Lightweight isn't a missing-features apology; it's the product. The moment a tool for running agents needs its own onboarding, it has become the complexity it was supposed to absorb.
If you're tired of tools that grow heavier every release, that's not an accident you're sensing. It's the thing I built this against.
Context that tends itself
The trap with "remember everything" is that a memory you have to maintain by hand is just another chore. I'd tried the second-brain playbook — a vault of notes, decisions written down — and it helped, right up until maintaining it became its own job.
So Fredrin's context is meant to keep itself, two ways.
Per-task, the ticket is the memory. The conversation, the plan, why a change looks the way it does — it's all on the ticket, persistent, not scrollback that dies with a terminal. When you send work back from review, the reason is recorded and handed to the Worker when it resumes, so "I already told it not to do that" finally survives across sessions instead of evaporating.
Cross-project, the lasting knowledge — the glossary, the decisions, the conventions — lives as Project Context: plain files in your repo (CONTEXT.md, docs/adr/, AGENTS.md) that every Worker reads on every ticket. And here's the autonomous part: when a Worker learns something worth keeping, it doesn't ask you to write it down — it ships the refinement as a context: commit you review like any other code. The knowledge compounds as a side effect of the work, and because it lives in git, deleting Fredrin tomorrow means your context walks away with you. It was never ours to hold.
Where this is going
Today the model is one ticket, one Worker. That's deliberately the floor, not the ceiling.
The reason the unit is a ticket — and not a session — is that tickets compose in a way sessions never could. A ticket has a clear contract (the plan, the acceptance checks) and a clear signal for done (the checks pass, the PR merges). Those are exactly the handholds an automation needs to chain onto. Once "done" is a real, machine-readable event instead of a vibe, a completed ticket can open the next one. A reviewed-and-merged change can trigger the follow-up it implied. A Worker can propose tickets back onto the board instead of waiting to be told.
That's the direction Fredrin is built toward: autonomous, stacked automations — work that begets work, agents that don't just run a task but keep a whole lane of the board moving, with the human sitting at the top deciding the two things agents genuinely can't: what's worth building, and whether it ships. Not a faster terminal and not ten agents you babysit harder — a board that increasingly runs itself, one well-defined ticket handing off to the next.
We're not all the way there. But every primitive — the ticket as the unit, the contract that defines done, the context that tends itself, the merge that closes the loop — was chosen so that future could be built up from the floor we're standing on, instead of bolted on later. AI-first from day one was always about that: not the feature you ship today, but the shape that lets tomorrow's features exist at all.
That's the origin story. I was tired of being the slow part of my own workflow, tired of juggling tools built for a job that no longer exists, and tired of watching every tool get heavier as the work got faster. So I built the thin, fast, AI-first thing I wanted — and pointed it at a future where the board does more of the moving and I do more of the deciding.
Fredrin is in closed alpha on macOS. BYOS — bring your own subscription: Claude Code, Codex, Cursor, and Copilot runtimes, your keys, your context. If you're tired of juggling tools built for a job that no longer exists, we want you in the alpha: fredrin.com.