TL;DR: Linear just launched an integrated AI agent. Cool, but it doesn’t address the problem developers face when working with coding agents in the terminal. What we actually need isn’t another AI agent but a rock-solid CLI that our existing agents can use seamlessly. And if we’re going to build one, it should be in Rust — which is why lql exists: a CLI for Linear, purpose-built for agents.
Yesterday, Linear launched their AI agent. It’s an integrated chatbot that gets your roadmap, your issues, and even your code. You can chat with it on Slack, mention it in a comment, and it’ll synthesize context, suggest actions, and even create issues for you.
Sounds awesome. Seriously, it sounds great.
And yet, when I read the announcement, the first thought that crossed my mind was: “This is not what I needed.”
The Linear Saga
To understand why I’m saying that, some context might help. My relationship with Linear has been a love-hate story worthy of a daytime soap opera.
Act I: The MCP. Linear had this MCP server for AI agents to interact with. It worked like a lighter in a hurricane: technically it could light up, but the flame wouldn’t last more than two seconds. It was janky, slow, and had a special talent for failing right when you needed it the most. I uninstalled it.
Act II: The GraphQL API. The alternative was interacting directly with Linear via GraphQL. And, yes, it worked. Until the moment you had to input special characters in an issue description, and dealing with escaping made you question your life choices. There was this one time I spent more time figuring out how to escape a parenthesis than writing the actual code the issue described.
Act III: The Linear CLI. Enter linear CLI, a community-driven project. brew install schpet/tap/linear and off you go. It was a humble tool, no frills, but it did exactly what I needed: create, list, and update issues from the terminal without wrestling GraphQL or ghost MCPs. No pop-ups, no frills.
}}">In a previous post, I wrote about retiring other tools in favor of this CLI. I managed to create 49 issues in under one minute with a bash script. With MCP, it would’ve taken me an hour and a half.
Enter the Agent
And now Linear rolls out their new AI agent. The pitch: an integrated assistant that understands your workspace, connects with your codebase, and automates workflows.
Check this out: you know what the agent doesn’t do? Work via the terminal. It’s not a tool for your AI agent. It’s a Linear AI agent that lives entirely within Linear.
If you’re working with Claude Code, Codex, or any coding agent in the terminal, Linear’s agent isn’t helpful to you at all. Your agent can’t invoke Linear’s agent to create an issue. It’s not composable. It’s not a Lego piece that plugs into your workflow. It’s a closed product within a closed product.
That is to say: Linear built an agent for product managers working inside the Linear app — not for developers working in the terminal with AI agents.
You Already Had Your Agent
Here’s the epiphany I had while reading that announcement: I already have an agent for Linear. It’s called Claude Code.
I don’t need Linear to put a chatbot inside their app for me. What I need is for Linear’s programmable interface to not be a hack job. To simply ensure that when I tell my agent, “Create an issue with these details,” it just works. Every time, hassle-free.
And that’s precisely what a good CLI is supposed to do. My agent — Claude Code — already knows how to use the terminal. It already knows how to execute commands. It already knows how to parse output. All it needs is a reliable tool on the other side.
I tell Claude Code, “Create an issue in Linear with high priority,” and it executes a terminal command. It works. Next task. No chatbot, no fancy GUI, no Slack. One command, one result.
The Future is CLI (Surprisingly)
Here’s a hot take: in a world where everyone is building AI agents with conversational interfaces inside their apps, the future for developers is, paradoxically, the command-line interface.
Why? Because the CLI is the universal interface for agents. Your coding agent can’t click buttons. It can’t navigate a web app. It can’t use a chatbot embedded in another app. But it can execute a command and read its output.
The CLI is the most democratic API out there. No SDKs, no 15 OAuth redirects, no MCP that breaks every other Tuesday. One binary, a few flags, stdin/stdout. Unix nailed it 50 years ago because it works.
The real problem is that most SaaS tool CLIs are an afterthought. “Oh, you also need a CLI? Fine, let an intern slap a wrapper on our REST API.” And the result? Tools that spew unreadable JSON, lack autocomplete, fail silently, or require a token that expires every 37 minutes.
500+ Errors No One Noticed
But before talking about rewriting anything, I wanted data. Not gut feelings — actual data. So I did something only someone with an LLM and 1 million context tokens would think to do: I asked Claude Code to parse its own past sessions and identify every time it failed while interacting with Linear.
165 sessions. 11 projects. Months of history. And the results were... eye-opening.
500+ errors. 370+ retries. A conservative estimate of 700,000 tokens wasted per month just battling Linear.
The errors break down into categories that are downright cringeworthy when viewed together:
The classic:
--sortforgotten. Linear CLI requires--sort priorityon everylist. No default. Omitted it? Error. Claude forgot it 40 times.The translator: UI vs CLI states. In Linear’s UI, states are labeled as "Todo," "In Progress," and "Done." But in the CLI, they’re
unstarted,started,completed. Claude used the UI names 12 times.--state "Todo"→ error.--state "In Progress"→ error. Same mistakes, over and over.The optimist: flags that don’t exist.
--statusinstead of--state(11 times).--priority urgentinstead of--priority 1(17 times).--no-pageron unsupported commands (15 times). And the list goes on — all errors due to guesswork.
And the cherry on top? 171 calls to Linear’s MCP — which had already been uninstalled. Across four projects. Even after I typed out: “Linear’s MCP is trash, use the API.”
How lql Addresses All of This
It’s one thing to complain. But every problem has a straightforward solution.
| Issue | Frequency | Solution in lql |
|---|---|---|
--sort forgotten |
40+ | Default priority. No arguments needed for lql list. |
| UI vs CLI state mismatch | 12+ | Automatic aliasing. Todo → unstarted, Done → completed. |
--priority urgent mistake |
17+ | Automatic aliasing. urgent → 1, high → 2. |
--no-interactive absent |
64 | No interactive mode. Commands never hang. |
| Broken JSON escaping | 25+ (80+ retries) | Native GraphQL variables. No broken strings, only properly built JSON. |
Everything boils down to reducing friction. A good CLI should make it easy. Nothing more, nothing less.
If You’re Rewriting, Use Rust
Here’s where the unexpected twist comes in (or expected, if you know me).
If a CLI is the critical bridge between your agent and your issue tracker, then it should be written with care. In a language that prevents you from shipping garbage. With proper error handling. With a static binary that doesn’t rely on Node or Python runtime environments.
Let’s beat the dead horse here: if we’re rewriting anything, it should be in Rust.
And the project name? lql — Linear Query Language. Like SQL, but for your issue tracker. SQL is the language for querying databases; lql is the language for querying your backlog.
Oh, and one last juicy note: Linear's official CLI? It’s 157 MB (bundled Node.js runtime). lql? Just 4.7 MB. A static binary, 33 times smaller, with no JavaScript baggage.
Ferris the crab approves. 🦀
Series: Adversarial Programming
- Next: Adversarial programming: when your AI copilot invents APIs
- Previous: The wrong path shouldn’t be forbidden, it should be impossible
Top comments (0)