Cline en VS Code: lo usé dos semanas en un proyecto TypeScript y esto sobrevivió

En 2005, cuando el cyber caía a las 11pm y el local estaba lleno, no había tiempo para leer documentación. Tenías que diagnosticar, ejecutar un comando, ver qué pasaba, corregir. Eso moldeó algo en mí: el respeto por las herramientas que te dejan ver exactamente qué están haciendo antes de que lo hagan, y la desconfianza profunda hacia las que actúan sin avisarte.

Cuando empecé a evaluar agentes de coding autónomos en 2024, ese mismo instinto me empujó a prestar atención al modelo de permisos antes que a cualquier benchmark de velocidad. Cline fue el primero en el que me detuve más de una hora configurando límites antes de escribir la primera instrucción real.

Mi tesis, antes de entrar en detalle: los agentes de coding autónomos no son todos iguales, y Cline tiene un modelo de permisos que lo hace más controlable que otras herramientas — pero el diablo está en cómo configurás esos límites, no en la herramienta en sí. Si instalás Cline con defaults y le pedís que refactorice un módulo complejo, vas a tener una experiencia radicalmente distinta que si invertís 30 minutos en definir qué puede y qué no puede tocar.

Lo que sigue es un análisis basado en dos semanas de uso activo en un proyecto TypeScript real, documentando tareas delegadas, errores cometidos y decisiones de configuración. No es un benchmark. No hay números inventados. Es criterio ganado con oficio.

Cline como agente autónomo: qué dice la página oficial y qué no dice

Cline está disponible en el VS Code Marketplace como extensión open source. La descripción oficial lo presenta como un agente autónomo que puede leer archivos, ejecutar comandos de terminal, navegar el navegador y crear o editar código — todo desde dentro de VS Code.

Lo que la página dice claramente: Cline opera con un loop de aprobación por defecto. Cada acción potencialmente destructiva — escribir un archivo, ejecutar un comando de terminal — te pide confirmación antes de proceder. Podés configurar el modo "auto-approve" para categorías específicas, pero arrancás en modo seguro.

Lo que la página no dice: que la calidad del output depende casi enteramente del modelo que conectás. Cline es agnóstico al proveedor — podés usar Claude via Anthropic directamente, via OpenRouter, GPT-4o, modelos locales via Ollama, o lo que quieras. Esa flexibilidad es genuina y es una ventaja real frente a herramientas que te encierran en un proveedor, pero también significa que "usar Cline" puede significar experiencias completamente distintas dependiendo del modelo elegido.

En el experimento que voy a describir, usé claude-3-5-sonnet via Anthropic API directamente. No usé OpenRouter en esta iteración porque quería aislar la variable del modelo.

Qué tareas delegué y cómo las estructuré

El proyecto: una codebase TypeScript con Express, Prisma y PostgreSQL. Nada experimental en el stack — de hecho, deliberadamente elegí un proyecto con stack conocido para poder evaluar los errores de Cline sin confundirlos con incertidumbre propia sobre la tecnología.

Dividí las tareas en tres categorías antes de empezar:

Categoría A — Delegación total con revisión al final:

• Generación de tipos Zod a partir de schemas Prisma existentes
• Escritura de tests unitarios para funciones puras ya implementadas
• Creación de archivos de seed con datos de prueba consistentes

Categoría B — Delegación con checkpoints intermedios:

• Refactorización de un módulo de validación con acoplamiento alto
• Migración de endpoints de Express puro a una estructura de router más ordenada
• Resolución de errores de TypeScript strict en archivos específicos

Categoría C — No delegado, monitoreado:

• Cualquier cambio a schema de base de datos
• Modificaciones a lógica de autenticación
• Cambios a archivos de configuración de infraestructura

Esta clasificación no la saqué de ninguna guía — la construí después de las primeras 48 horas, cuando Cline hizo algo que no esperaba: en un task de Categoría B, decidió resolver un error de tipo cambiando un import en un archivo que yo no había mencionado, lo cual era técnicamente correcto pero me sacó de contexto. No fue un error grave, pero fue una señal de que "revisar al final" no funcionaba para tasks con dependencias laterales.

// Ejemplo de instrucción que funcionó bien para Categoría A
// (generación de schema Zod desde un modelo Prisma existente)

// Instrucción a Cline:
// "Generá un schema Zod para el modelo User del archivo schema.prisma.
// Solo el archivo src/schemas/user.schema.ts.
// No modifiques ningún otro archivo.
// Usá z.string().uuid() para el campo id."

// Resultado esperado y obtenido:
import { z } from 'zod'

export const UserSchema = z.object({
  id: z.string().uuid(),
  email: z.string().email(),
  nombre: z.string().min(1),
  creadoEn: z.coerce.date(),
  actualizadoEn: z.coerce.date(),
})

export type User = z.infer<typeof UserSchema>

La precisión de la instrucción importa más que la complejidad del task. Eso es lo primero que aprendí.

Dónde Cline se equivocó — y qué reveló cada error

Error 1: Sobre-generalización de un fix local

Pedí que resolviera un error de TypeScript en un archivo específico. Cline resolvió el error correctamente, pero además modificó un tipo compartido en un archivo de definiciones porque "era más limpio". Técnicamente impecable. Contexto completamente perdido para mí.

Lo que reveló: Cline razona sobre la codebase completa, no sobre el scope que le dás. Si no le decís explícitamente "no modifiques nada fuera de X archivo", va a explorar lateralmente. Esto puede ser una ventaja cuando querés que encuentre la causa raíz real; es un problema cuando querés un cambio quirúrgico.

Error 2: Tests que pasaban pero no testeaban nada útil

En tasks de generación de tests, Cline entregó archivos con cobertura del 100% que en realidad testeaban implementaciones, no comportamientos. expect(fn()).toBeDefined() en lugar de expect(fn(input)).toEqual(expectedOutput). Pasaban. No aportaban.

Lo que reveló: la instrucción "escribí tests para esta función" es demasiado abierta. Necesitás especificar qué casos de borde querés cubrir, qué comportamientos son críticos y qué nivel de assertion esperás. Si no lo hacés, Cline optimiza para cobertura, no para utilidad.

// Instrucción vaga → tests que pasan pero no sirven
// "Escribí tests para la función calcularDescuento"

// Lo que entregó (resumido):
describe('calcularDescuento', () => {
  it('debería retornar un valor', () => {
    // ← esto no testea nada útil
    expect(calcularDescuento(100, 10)).toBeDefined()
  })
})

// Instrucción precisa → tests que sí importan
// "Escribí tests para calcularDescuento.
// Casos obligatorios:
// - descuento 0% retorna el precio original sin modificar
// - descuento 100% retorna 0
// - descuento negativo lanza un Error con mensaje 'Descuento inválido'
// - precio 0 con cualquier descuento retorna 0"

describe('calcularDescuento', () => {
  it('descuento 0% retorna precio original', () => {
    expect(calcularDescuento(100, 0)).toBe(100)
  })
  it('descuento 100% retorna 0', () => {
    expect(calcularDescuento(100, 100)).toBe(0)
  })
  it('descuento negativo lanza error', () => {
    expect(() => calcularDescuento(100, -5)).toThrow('Descuento inválido')
  })
  it('precio 0 retorna 0 independiente del descuento', () => {
    expect(calcularDescuento(0, 50)).toBe(0)
  })
})

Error 3: Autonomía sin checkpoint en refactorizaciones largas

El error más costoso en tiempo. En una refactorización de Categoría B, Cline completó 12 pasos de edición antes de que yo revisara el estado intermedio. El resultado final era correcto, pero había una decisión de diseño en el paso 4 con la que no estaba de acuerdo — y revertirla a esa altura requirió más tiempo que haberlo discutido antes.

Lo que reveló: para tasks de más de 5 pasos, el loop de revisión necesita ser explícito. Podés pedirle a Cline que pause y espere confirmación antes de continuar con cada fase — y vale la pena hacerlo.

Cline vs Claude Code: autonomía vs costo, sin romantizar ninguno

Claude Code (la herramienta de terminal de Anthropic) y Cline comparten el mismo modelo de base cuando configurás Cline con Claude. La diferencia no está en la inteligencia del modelo — está en el entorno de ejecución y el modelo de costo.

Cline:

• Vivís dentro de VS Code. El contexto visual de la codebase está disponible.
• Pagás por token via API de Anthropic (o el proveedor que uses). El costo es proporcional a cuánto contexto mandás y cuántas acciones ejecuta el agente.
• El modelo de permisos es granular y configurable. Podés decirle exactamente qué directorios puede tocar.
• Cada conversación es una sesión nueva — no hay memoria persistente entre sesiones sin configuración extra.

Claude Code:

• Operás desde terminal con un CLI propio de Anthropic.
• Tiene un modelo de suscripción Pro que puede ser más predecible en costo si usás mucho contexto.
• La integración con git es más fluida por diseño.
• El contexto de la codebase lo construye leyendo el filesystem activamente.

Mi postura honesta: para workflows de edición puntual dentro de VS Code, Cline es más ergonómico. Para tasks que cruzan muchos archivos con dependencias complejas, Claude Code tiene una ventaja en cómo maneja el contexto de la conversación completa. No son equivalentes — son herramientas con fortalezas distintas.

Si ya tenés posts sobre rate limiting en aplicaciones web o patrones de middleware en Next.js, sabés que la elección de herramienta siempre depende del constraint más caro del sistema. Acá el constraint es: ¿cuánto contexto necesitás mantener entre pasos? Eso determina qué herramienta conviene más.

Workflows que no le daría nunca — y por qué

Esta sección es la más importante del post, porque la tentación de delegar todo es real y el costo de aprenderlo por las malas también.

1. Cambios a schema de base de datos
Cline puede generar una migración Prisma. También puede equivocarse en la dirección de la migración, o no considerar datos existentes, o ignorar constraints de foreign keys. El costo de un error acá no es "un archivo mal" — es datos. No le doy este control a ningún agente autónomo sin revisión humana total del SQL generado.

Si querés ver cómo pienso sobre migraciones Prisma con criterio, el post sobre Prisma 5 → 6 breaking changes tiene el framework que uso.

2. Lógica de autenticación y autorización
El modelo puede generar código funcionalmente correcto pero con una superficie de ataque que no detectás hasta que alguien la explota. Este es un dominio donde el criterio de seguridad no es negociable y no se puede delegar a una revisión superficial.

3. Refactorizaciones sin tests previos
Si no tenés tests que cubran el comportamiento actual, no podés saber si Cline rompió algo. Este no es un problema de Cline — es un problema de cualquier cambio sin red de seguridad. Pero los agentes autónomos amplifican el riesgo porque la superficie de cambio es mayor.

4. Decisiones de arquitectura
Cline puede sugerir una arquitectura. Puede implementar la que le pedís. No puede evaluar los trade-offs de negocio, el contexto del equipo, o las restricciones de deuda técnica que solo vos conocés. Para pensar sobre esas decisiones, sigo prefiriendo el razonamiento explícito — el tipo de análisis que está en el post sobre arquitectura de identidad digital.

Checklist de decisión: cuándo usar Cline, cuándo no

Antes de delegar un task a Cline, paso por esta lista mentalmente:

Verde — delegá con instrucción precisa:

• [ ] El output es un archivo nuevo sin dependencias laterales
• [ ] Hay tests existentes que cubren el comportamiento que vas a cambiar
• [ ] El scope del cambio es un archivo o módulo aislado
• [ ] Podés definir el criterio de éxito en una oración

Amarillo — delegá con checkpoints explícitos:

• [ ] La tarea tiene más de 5 pasos secuenciales
• [ ] El cambio toca más de 3 archivos
• [ ] El resultado depende de un patrón específico del proyecto que no está documentado
• [ ] Es la primera vez que Cline trabaja sobre ese módulo

Rojo — no delegues, usá Cline solo para draft inicial:

• [ ] Cualquier cambio a schema de base de datos o migraciones
• [ ] Lógica de autenticación, autorización o manejo de secretos
• [ ] Cambios en archivos de configuración de infraestructura (Docker, CI, variables de entorno)
• [ ] Decisiones de arquitectura que afectan múltiples equipos

Límites de lo que podés concluir con esto

Quiero ser directo sobre lo que este análisis no prueba:

• No prueba que Cline es mejor o peor que otras herramientas en términos absolutos. El modelo conectado cambia todo.
• No hay métricas de velocidad verificables acá. "Más rápido que sin agente" es una percepción, no un número.
• Los errores descritos son patrones observables, no bugs reproducibles en todos los contextos. La misma instrucción en una codebase distinta puede dar resultados distintos.
• El costo real depende de cuánto contexto mandás por sesión. No hay un número general válido sin conocer el tamaño de la codebase y la frecuencia de uso.

Lo que sí podés concluir: la configuración de permisos y la precisión de las instrucciones tienen más impacto en la calidad del output que el hecho de usar Cline vs otra herramienta comparable. Ese aprendizaje es transferible.

FAQ — Preguntas frecuentes sobre Cline como agente de coding

¿Cline funciona con modelos que no son Claude?
Sí. Cline es agnóstico al proveedor — podés conectarlo con GPT-4o, modelos de OpenRouter, Gemini via Google AI Studio, o modelos locales via Ollama. La calidad del output varía con el modelo. La página oficial del Marketplace de VS Code documenta los proveedores soportados.

¿Cómo controlás qué archivos puede tocar Cline?
Hay dos mecanismos principales: el .clinerules (archivo en la raíz del proyecto donde definís reglas de comportamiento del agente) y el loop de aprobación por defecto que te muestra cada acción antes de ejecutarla. En modo default, nada se ejecuta sin que vos lo aprobés explícitamente.

¿Tiene sentido usarlo si ya uso GitHub Copilot?
Son herramientas distintas. Copilot es autocompletado inteligente — sugiere mientras escribís. Cline es un agente que ejecuta tareas completas de forma autónoma. Pueden coexistir sin conflicto. La pregunta relevante es si necesitás delegación de tareas completas o asistencia inline.

¿Qué pasa con el costo si dejás el agente correr en tareas largas?
El costo escala con los tokens consumidos — tanto el contexto de entrada como el output generado. En tareas largas con muchos archivos en contexto, el gasto puede sorprender si no lo monitoreás. La recomendación práctica: empezá con tasks pequeños y medí el costo por task antes de delegar refactorizaciones grandes.

¿Es viable en TypeScript con strict mode activo?
Sí, y en mi experiencia el modo estricto ayuda — los errores del compilador son señales claras que Cline puede leer e iterar. Si querés saber cuáles flags de strict mode impactan más en producción, el post sobre TypeScript strict mode y tsconfig es el lugar por donde arrancar.

¿Cómo se compara el modelo de autonomía de Cline con Claude Code?
Cline te da más control granular dentro de VS Code — podés aprobar acción por acción. Claude Code tiene una integración más fluida con git y maneja mejor el contexto de sesiones largas con muchos archivos. Para edición puntual dentro del editor, Cline es más ergonómico. Para tasks que cruzan muchos módulos con historial de conversación largo, Claude Code tiene ventaja.

Mi postura después de dos semanas

Cline sobrevivió el experimento. Sigue en mi flujo de trabajo para tasks de Categoría A — generación de boilerplate preciso, tipos, seeds, tests con criterios explícitos. Para el resto, tengo los checkpoints.

Lo que no compro: la narrativa de que configurar bien un agente autónomo es trabajo de cinco minutos. No lo es. El .clinerules, la clasificación de tasks, la definición de scope por instrucción — eso requiere tiempo y se refina con error. Si alguien te dice que instaló Cline y delegó todo sin problemas desde el día uno, o tiene una codebase muy simple o no revisó bien el output.

Lo que sí acepto: para un arquitecto de software que ya tiene criterio técnico formado, Cline es una herramienta que multiplica la velocidad en las partes correctas del trabajo — las que son repetibles, definibles y verificables. Las decisiones que importan siguen siendo propias.

El próximo paso concreto si querés reproducir esto: instalá Cline desde el VS Code Marketplace, creá un archivo .clinerules en la raíz de tu proyecto TypeScript con los directorios que el agente no puede tocar, y arrancá con un task de Categoría A. Medí el costo de esa sesión. Después escalás.

Fuente original:

• Cline — VS Code Marketplace: https://marketplace.visualstudio.com/items?itemName=saoudrizwan.claude-dev

Este artículo fue publicado originalmente en juanchi.dev