TL;DR: Linear lanzó un agente de IA integrado. Está bien, pero no resuelve el problema de los desarrolladores que trabajan con coding agents en la terminal. Lo que necesitamos no es otro agente, sino una CLI sólida que nuestro agente ya existente pueda usar. Y si hay que construirla, que sea en Rust — por eso nace lql, una CLI para Linear diseñada para agentes.
Ayer Linear anunció su agente de IA. Un chatbot integrado en la app que entiende tu roadmap, tus issues y tu código. Le hablas en Slack, le mencionas en un comentario, y él sintetiza contexto, sugiere acciones, y hasta crea issues por ti.
Suena genial. En serio, suena genial.
Y sin embargo, al leer el anuncio, lo primero que pensé fue: «esto no es lo que yo necesitaba».
La odisea Linear
Para entender por qué digo esto, necesitas el contexto. Mi relación con Linear ha sido una historia de amor-odio digna de telenovela venezolana.
Acto 1: el MCP. Linear tenía un servidor MCP para que los agentes de IA interactuasen con él. Funcionaba como un mechero en un huracán: técnicamente encendía, pero la llama no duraba ni dos segundos. Intermitente, lento, y con un talento especial para fallar justo cuando estabas en medio de algo importante. Lo desinstalé.
Acto 2: la API GraphQL. La alternativa era hablar con Linear a pelo, vía GraphQL. Que funciona, sí. Hasta que intentas meter caracteres especiales en la descripción de un issue y el escaping te hace cuestionar tus decisiones vitales. Una vez tardé más en escapar correctamente un paréntesis que en escribir el código que el issue describía.
Acto 3: el CLI de Linear. Y entonces apareció linear CLI, un proyecto de la comunidad. brew install schpet/tap/linear y a correr. Una herramienta de terceros, humilde, sin pretensiones, que hacía exactamente lo que necesitaba: crear, listar y actualizar issues desde la terminal sin pelearme con GraphQL, sin MCPs fantasma, sin popups.
Escribí un post entero jubilando herramientas gracias a este CLI. Creé 49 issues en menos de un minuto con un script de bash. Con el MCP habría tardado hora y media.
Entra el Agente
Y ahora Linear lanza su agente. La promesa: un asistente integrado que entiende tu workspace, conecta con tu código, y automatiza flujos de trabajo.
Ojo al dato: ¿sabes lo que no hace el agente? Funcionar desde la terminal. No es una herramienta para tu agente de IA. Es un agente de Linear que vive dentro de Linear.
Si trabajas con Claude Code, Codex o cualquier coding agent en la terminal, el agente de Linear no te sirve de nada. Tu agente no puede invocar al agente de Linear para crear un issue. No es composable. No es una pieza de Lego que encaja en tu flujo. Es un producto cerrado dentro de un producto cerrado.
Usease: Linear ha construido un agente para product managers que trabajan dentro de la app de Linear. No para desarrolladores que trabajan en la terminal con agentes de IA.
Ya tenías tu agente
Aquí está la epifanía que tuve leyendo el anuncio: yo ya tenía un agente para Linear. Se llama Claude Code.
No necesito que Linear me ponga un chatbot dentro de su app. Necesito que la interfaz programática con Linear no sea una chapuza. Que pueda decirle a mi agente «crea un issue con estos datos» y que funcione. Siempre. Sin drama.
Y eso es exactamente lo que hace una buena CLI. Mi agente — Claude Code — ya sabe usar la terminal. Ya sabe ejecutar comandos. Ya sabe parsear output. Lo único que necesita es una herramienta fiable al otro lado.
Le dices a Claude Code «crea un issue en Linear con prioridad alta», y él ejecuta un comando en la terminal. Sale bien. Siguiente tarea. Sin chatbot. Sin interfaz gráfica. Sin Slack. Un comando, un resultado.
El futuro es la CLI (por increíble que parezca)
Aquí viene la opinión fuerte: en un mundo donde todos están construyendo agentes de IA con interfaces conversacionales dentro de sus apps, el futuro para los desarrolladores es, paradójicamente, la command-line interface.
¿Por qué? Porque la CLI es la interfaz universal entre agentes. Tu coding agent no puede hacer clic en botones. No puede navegar una webapp. No puede usar un chatbot dentro de otra app. Pero sí puede ejecutar un comando y leer su output.
La CLI es la API más democrática que existe. No necesita SDK, no necesita autenticación OAuth con quince redirects, no necesita un MCP que se cae cada martes. Un binario, unos flags, stdin/stdout. Unix lleva 50 años con este modelo porque funciona.
El problema es que la mayoría de CLIs de herramientas SaaS son una ocurrencia tardía. Un afterthought. «Ah, ¿también necesitan una CLI? Bueno, que un becario le meta un wrapper al API REST.» Y así te salen herramientas que escupen JSON ilegible, que no tienen autocompletado, que fallan silenciosamente, o que requieren un token que caduca cada 37 minutos.
500 errores que nadie vio
Pero antes de hablar de reescribir nada, quería datos. No intuiciones — datos. Así que hice algo que solo se le ocurre a alguien con un LLM con un millón de tokens de contexto: le pedí a Claude Code que parsease sus propias sesiones pasadas y extrajese cada vez que había fallado al interactuar con Linear.
165 sesiones. 11 proyectos. Meses de historial. Y el resultado fue… revelador.
500+ errores. 370+ reintentos. Una estimación conservadora de 700.000 tokens al mes desperdiciados en pelear con Linear.
Los errores se agrupan en categorías que dan vergüenza ajena cuando las ves juntas:
El clásico: --sort olvidado. La CLI de Linear requiere --sort priority en cada list. No tiene default. Si lo olvidas, error. Claude lo olvidó 40 veces. Cuarenta. El mismo error. Una y otra vez. Porque entre una sesión y la siguiente, no hay memoria muscular.
El traductor: estados de la UI vs la CLI. En la interfaz de Linear ves «Todo», «In Progress», «Done». En la CLI son unstarted, started, completed. Claude usó los nombres de la UI 12 veces. --state "Todo" → error. --state "In Progress" → error. Siempre el mismo fallo, siempre el mismo reintento.
El optimista: flags que no existen. --status en vez de --state (11 veces). --priority urgent en vez de --priority 1 (17 veces). --no-pager en comandos que no lo soportan (15 veces). --comment en update (11 veces — es un subcomando separado). --filter, --query, --label en list — ninguno existe. Claude los inventaba por analogía con git o gh, y el error nunca era claro.
El asesino silencioso: --no-interactive ausente. 64 veces Claude ejecutó linear issue create sin --no-interactive, y el comando se quedó colgado esperando input de teclado. Sin mensaje de error. Sin timeout claro. Solo… silencio. Y al cabo de dos minutos, timeout de la herramienta.
La pesadilla: escapado JSON/GraphQL. Cuando la CLI fallaba y tocaba caer a la API GraphQL directa, las descripciones con markdown producían JSON roto. Comillas, backticks, saltos de línea — cada uno de estos caracteres podía romper la query. 25 errores de escapado, cada uno con 3-5 reintentos mientras Claude intentaba arreglarlo. 80+ comandos desperdiciados solo en esta categoría.
El zombi: el team retirado. El team TOK se retiró cuando consolidamos de 12 teams a 5. Claude siguió usando --team TOK durante 97 comandos más, hasta que falló con «Could not modify retired team». Documentarlo en la memoria ayudó, pero no lo eliminó del todo.
¿Y la traca final? 171 llamadas al MCP de Linear — el que ya estaba desinstalado. En 4 proyectos distintos, Claude seguía intentando usarlo. El usuario (yo) llegó a escribir, literalmente: «el MCP de Linear es una mierda, usa el API».
Cómo lql resuelve cada uno
No basta con quejarse. Cada error tiene una solución mecánica:
| Error | Frecuencia | Solución en lql |
|---|---|---|
--sort olvidado |
40+ | Default priority. lql list funciona sin argumentos. |
--state "Todo" |
12+ | Alias automático. Todo → unstarted, Done → completed. |
--priority urgent |
17+ | Alias automático. urgent → 1, high → 2. |
--no-interactive ausente |
64 | No existe modo interactivo. Nunca se cuelga. |
| Escapado JSON roto | 25+ (80+ retries) | Variables GraphQL nativas. El JSON se construye con tipos, no con strings. |
--no-pager donde no toca |
15+ | Sin pager nunca. Flag ignorado si se pasa. |
--status vs --state |
11+ | Alias de flag. --status se normaliza a --state. |
--comment en update |
11 | Subcomando separado: lql comment PROD-587 "texto". |
| Team retirado (TOK) | 97+ | Config fija con teams activos. Error claro: «TOK is retired, use PROD». |
| Labels inventados | 10+ | Validación contra API. lql labels para ver los reales. |
| MCP de Linear | 171 | No existe. lql es la única interfaz. |
La clave: el LLM no tiene que recordar nada. No hay flags obligatorios que olvidar. No hay nombres internos que memorizar. lql list funciona. lql create "Fix bug" --priority urgent funciona. lql update PROD-587 --state Done funciona. La herramienta se adapta al usuario, no al revés.
Si hay que reescribirlo, que sea en Rust
Y aquí es donde la historia da el giro que nadie esperaba (o que todo el mundo esperaba si me conoce).
Si la CLI es la interfaz crítica entre tu agente y tu issue tracker, entonces esa herramienta merece estar escrita con cariño. Con un lenguaje que no te deje compilar basura. Con error handling de verdad. Con un binario estático que no necesite un runtime de Node o Python.
Leña al mono: si vamos a reescribir algo, que sea en Rust.
Y aquí no puedo evitar la broma. El proyecto se llama lql — Linear Query Language. Como SQL, pero para tu issue tracker. Si SQL es el lenguaje para consultar bases de datos, lql es el lenguaje para consultar tu backlog. Y como todo proyecto que se precie en 2026, está escrito en Rust.
Lo cual significa que Ferris — la mascota de Rust, el cangrejo más famoso del mundo del software — aprueba. Pero yo siempre que oigo «Ferris» pienso en Ferris Bueller, el chaval de los 80 que se escaqueaba de clase con una creatividad admirable. Y eso es exactamente lo que hace una buena CLI: te permite escaquearte de la interfaz gráfica. Saltarte la app. Ir directo al grano.
Ferris Bueller’s Day Off, pero para tu issue tracker. El cangrejo se toma el día libre de la GUI.
Lo que lql necesita hacer
No es un rewrite del CLI de Linear entero. Es una CLI opinada, diseñada para que un coding agent la use de forma fiable:
| Lo que necesito | Por qué |
|---|---|
lql create "Fix auth" con descripción en stdin |
Escaping cero. Sin peleas con strings |
| Output compacto, una línea por issue | Mi agente necesita leer la respuesta sin gastar 7.000 tokens |
| Errores tipados y códigos de salida claros | exit 1 no basta. ¿Es auth? ¿Es rate limit? ¿Es input inválido? |
| Tolerancia de interfaz | --status Done funciona aunque el flag real sea --state completed |
| Binario estático sin dependencias | cargo install y a correr. Un solo binario en ~/.local/bin/ |
Nada de esto es revolucionario. Es lo mínimo que una CLI debería hacer. Pero cuando miras las CLIs que existen para herramientas SaaS, te das cuenta de que «lo mínimo» es sorprendentemente raro.
La lección
Linear ha construido un agente de IA impresionante. En serio, el Code Intelligence que analiza tu codebase y diagnostica funcionalidades suena muy bien. Pero es un agente para humanos que trabajan dentro de Linear.
Si tú trabajas con un coding agent en la terminal, lo que necesitas no es otro agente. Es una herramienta sólida que tu agente pueda usar. Y esa herramienta, por increíble que parezca en 2026, es una CLI.
La ironía es deliciosa: mientras todo el mundo corre a construir agentes que hablan en lenguaje natural, la interfaz más útil para los propios agentes sigue siendo la que inventaron Thompson y Ritchie en los 70. Flags, argumentos, códigos de salida. Cero ambigüedad.
Y si esa CLI va a ser la pieza crítica entre tu agente y el mundo exterior, merece estar escrita en un lenguaje que no te deje compilar chapuzas.
Ah, un dato: la CLI oficial de Linear pesa 157 MB (Node.js empaquetado). lql pesa 4.7 MB. Un binario estático, 33 veces más pequeño, sin runtime. Eso es lo que pasa cuando no arrastras un intérprete de JavaScript para ejecutar curl con pasos extra.
Ferris el cangrejo aprueba este mensaje. 🦀
Serie: Adversarial Programming
- Siguiente: Adversarial programming: cuando tu copiloto IA inventa APIs
- Anterior: El camino incorrecto no debe estar prohibido, debe ser imposible
Read this article in English.
