¿Qué es Claude Code, en una frase?
Es una herramienta de IA que trabaja sobre el proyecto real: lee los archivos, escribe código, lo ejecuta, ve el error que devuelve y lo corrige. No sugiere fragmentos en una ventana aparte — opera sobre el repositorio como lo haría una persona.
¿En qué se diferencia de pedirle código a ChatGPT?
La diferencia es el bucle. Cuando le pedís código a un chat, te devuelve un texto que después alguien tiene que pegar, adaptar al proyecto, ejecutar y depurar a mano. El trabajo pesado sigue del lado humano.
Claude Code cierra ese bucle: ve el proyecto entero, hace el cambio en los archivos que corresponden, corre las pruebas y, si algo falla, lee el error e itera. La consecuencia no es que escriba mejor código — es que el costo de cada iteración se derrumba, y eso cambia qué proyectos vale la pena empezar.
¿Qué significa esto en plata y en tiempo?
Este es el punto que importa si no sos técnico.
El costo de un sistema a medida era, casi todo, horas de desarrollo. Cuando la parte mecánica de esas horas se comprime, el presupuesto de un proyecto chico deja de estar dominado por la construcción y pasa a estar dominado por entender qué hay que construir.
Eso tiene dos consecuencias prácticas:
- Proyectos que antes no cerraban por presupuesto ahora cierran. La pregunta dejó de ser “¿me lo puedo pagar?” y pasó a ser “¿este proceso es lo bastante mío como para justificarlo?”.
- La proporción del proyecto que es relevamiento y criterio subió. Lo caro ahora es elegir bien, no ejecutar.
Tres ejemplos concretos
De una planilla caótica a un sistema real. Una planilla compartida que creció durante años, con fórmulas rotas y tres versiones circulando, convertida en una aplicación con base de datos, accesos por rol y registro de quién cambió qué. Lo que antes era un proyecto que se posponía indefinidamente por costo, hoy entra en una primera etapa acotada.
Conectar dos sistemas que no se hablaban. El caso clásico: el ERP y la herramienta de ventas, sincronizados a mano con exportaciones. Construir el puente ya no depende de que el proveedor de ninguno de los dos lo agende en su roadmap.
Un análisis que llevaba dos días. Cruzar datos de varias fuentes para responder una pregunta puntual de negocio era trabajo de un par de días. Resuelto como una consulta, se vuelve algo que se puede repetir cada vez que hace falta, en vez de una vez por trimestre.
¿Qué sigue necesitando una persona?
Todo lo que decide si el proyecto sirve:
- Decidir qué construir. La herramienta ejecuta lo que le pidas, incluso si es lo equivocado.
- Entender el negocio. Saber dónde se pierde plata en esta empresa en particular no sale de leer el código.
- Revisar. Que funcione en la demo no significa que aguante el caso raro, el volumen real o el usuario que hace las cosas al revés.
- Mantener. El sistema va a necesitar cambios. Alguien tiene que poder hacerlos.
Dicho de otro modo: bajó el costo de construir, no el de equivocarse. Un sistema mal elegido ahora se construye más rápido y se abandona igual.
¿Cuándo NO conviene?
- Si nadie va a poder mantenerlo. Un sistema huérfano es peor que la planilla que reemplazó, porque la planilla al menos la entendía alguien.
- Si el proceso está roto de origen. Automatizar un proceso malo lo hace fallar más rápido y en más lugares. Primero se arregla el proceso.
- Si ya existe un SaaS que resuelve el 90%. Sobre todo en funciones commodity y reguladas —contabilidad, sueldos, facturación electrónica, pagos—, donde además de construirlo hay que mantenerse al día con la normativa.
¿Cómo se empieza?
No por la herramienta. Se empieza mapeando dónde se va el tiempo y la plata, eligiendo un proceso con volumen y criterio estable, y acotando una primera etapa que sirva sola aunque no haya segunda. La herramienta es la parte fácil; elegir bien es la parte que decide el resultado.