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

Source: Dev.to

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 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. 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

La precisión de la instrucción importa más que la complejidad del task. Eso es lo primero que aprendí. 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. 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. 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 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
3. Refactorizaciones sin tests previos
4. Decisiones de arquitectura arquitectura de identidad digital. 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 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. ¿Cline funciona con modelos que no son Claude? Marketplace de VS Code documenta los proveedores soportados. ¿Cómo controlás qué archivos puede tocar Cline? .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? ¿Qué pasa con el costo si dejás el agente correr en tareas largas? ¿Es viable en TypeScript con strict mode activo? 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 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