Claude Code y la ilusión del 90%
La IA puede hacer el 90% del trabajo en minutos. El problema es el último 10%. Una reflexión crítica sobre Claude Code y el desarrollo de software.
Si tuviese que elegir un término que ha destacado con fuerza en el sector tecnológico durante el parón navideño, sin duda escogería “Claude Code“.
Durante los últimos 10 días, ha sido casi imposible abrir un timeline que no contuviera algún post mencionándolo. Y casi todos en positivo.
Para quién no lo conozca, Claude Code es una herramienta de Anthropic, que vive en un terminal, una interfaz de texto que permite interactuar mediante comandos con el sistema operativo. Es donde los ingenieros ejecutan código, gestionan repositorios, automatizan tareas y depuran problemas, entre otros.
Así pues, la ventaja de que Claude Code se ejecute sobre en este entorno es que tiene acceso al sistema de ficheros donde reside el código y los comandos que permiten manipularlo. Esto, por así decirlo, le da superpoderes y le permite crear flujos de trabajo que hasta ahora eran imposibles.
Por ejemplo, si iniciáramos Claude Code sobre el directorio de uno de nuestros proyectos, le podríamos pedir que resolviera un bug. Con acceso al terminal, podría hacer un flujo similar a este:
Entender el bug: Accediendo a todos los archivos del proyecto y entendiendo cómo funciona el sistema
Localizar el origen: Leyendo directamente el código.
Analizar la causa raíz: Revisando cambios recientes y consultando documentación online.
Aplicar una corrección: Editando los archivos directamente.
Validar la solución: Ejecutando comprobaciones, tests y builds desde el entorno real del proyecto.
Verdadera magia. Si funcionase, claro.
Espera, ¿realmente funciona?
Hay muchísima gente, mucho más inteligente que yo, diciendo que sí. Que los nuevos modelos, Opus 4.5, GPT 5.2 y Gemini PRO 3 han supuesto un punto de inflexión, y que hoy son posibles cosas que hace meses no lo eran.
Quería probarlo por mí mismo, así que hace unos días le volví a dar una oportunidad a Claude Code, esta vez con Opus 4.5. Y debo decir que me emocioné, por lo menos el primer día.
Le pasé una especificación de un proyecto que llevaba tiempo queriendo hacer, y comencé a hacer pairing con él como si fuera un ingeniero. Escribía historias detalladas de cómo esperaba que funcionara el sistema, y se las pasaba para que las implementase. Las primeras dos las bordó, y entonces llegó la tercera.
La tercera era sin duda una historia más complicada que las dos anteriores, pero tampoco era algo que un ingeniero sénior no hubiera podido resolver (con tiempo).
En mi primer intento, pasé un buen rato iterando hasta que Anthropic me cortó el acceso. Este es un detalle importante, y es que el acceso a estos modelos, a día de hoy es “caro”. En mi caso, una suscripción PRO (20€ al mes) me da acceso a unos 45m de uso de Opus cada 5 horas (el periodo de cooldown que aplica Anthropic). Y eso teniendo en cuenta que la suscripción está fuertemente subvencionada. Previamente a pagarla, pagué 5$ de créditos API que me volaron en un abrir y cerrar de ojos.
Pasadas 5 horas volví a probar. Y volví a fracasar. Iteré en la forma de pedirle las cosas a Claude, de una tarea, a subtareas funcionales incrementalmente testables. Reinicié el repositorio no sé cuántas veces, pero aquello no avanzaba.
Durante el próximo parón forzado, decidí probar suerte con Codex Cli, la alternativa a Claude Code de OpenAI. Tampoco lo conseguí. Pasé a Antigravity, el IDE agéntico de Google, para probar suerte con Gemini 3 PRO. Mismo resultado.
Os prometo que no le estaba pidiendo nada especialmente complicado, pero por alguna razón, di con un muro. Y entonces recordé la regla 90-90:
El primer 90% del código se lleva el 90% del tiempo de desarrollo. El 10% restante, se lleva el otro 90% del tiempo. — Tom Cargill, Bell Labs
Ese último 10% en mi caso, sin duda se ha llevado ya más tiempo que el inicio del proyecto. Y esta es una de las claves para entender el estado actual de la IA. Impresiona a novatos como yo, porque es capaz de hacer el 90% del trabajo en un santiamén, lo cual nos da esperanzas. Sin embargo, cerrar ese último 10% para que algo funcione, sigue siendo un reto.
Asumamos que funciona
Asumamos que soy un torpe, y no he sido capaz de hacer que Claude Code completara mi proyecto, pero que gente mucho más avispada que yo, y con más tablas a la hora de programar, es capaz de hacerlo funcionar 100% autónomamente.
Si fuera el caso, se derivan unas cuántas implicaciones interesantes.
¿Dónde queda el trabajo de los ingenieros de software?
Aunque muchos asocian el trabajo de un ingeniero al de programar el código que la máquina ejecuta, la realidad es que el verdadero trabajo es entender bien el problema que le han pedido resolver. Básicamente descifrar lo que el cliente expresa y diseñar un sistema que le dé solución.
Ahora mismo, se expresa en lenguajes de programación, pero hace años se expresaba en ensamblador. Mi sensación es que los LLMs van a ser un nuevo nivel de abstracción, y el valor estará en expresarlo en las palabras correctas que necesita el LLM para crear la solución. Una especie de prompting avanzado que incluirá decisiones de arquitectura y validación.
Aquel ingeniero cuyo trabajo sea simplemente programar historias de usuario que le lleguen perfectamente definidas sí que está en riesgo. Al ingeniero que rechaza una tarea porque no está 100% definido lo que hay que hacer le quedan dos telediarios. Y es que, en el momento en el que la especificación es completa, ya está la IA para hacer tu trabajo. Las consultoras van a ser los mejores clientes de los Anthropic y compañía. No tengo dudas.
¿Si todo el código lo escriben los LLMs, quién va a solucionar un problema cuando aparezca?
Hoy en día, gran parte del valor que aporta un ingeniero sénior es el conocimiento del sistema que ha parido. ¿Qué ocurrirá cuando todo el código de la aplicación lo haya escrito un LLM y aparezca un problema grave que este no puede resolver?
Podemos llegar a imaginar hasta un futuro distópico: una variante ULTRA del modelo capaz de solucionar cualquier bug y que factura en función de la estimación del volumen de negocio de tu empresa. La IA revisaría el problema, estimaría el impacto económico del mismo basado en tu facturación, y te pasaría un presupuesto de X miles de euros por solucionarlo.
¿Os sorprendería que esto llegara a pasar? A mí, cero, la verdad.
El control de calidad y la seguridad va a ser más importante que nunca
Si los modelos multiplican por 5 o por 10 la capacidad de construir software, esto a su vez incrementa por mucho las posibilidades de generar errores e incidentes de seguridad. El control de calidad, garantizar que nuestro software hace lo que debería y que no introducimos nuevos fallos se debería volver crítico.
El trabajo de los QAs será eminentemente técnico, claro. Igual que se automatiza la creación de nuevo código, se automatizará la creación de tests, por supuesto, pero diría que necesitaremos más testers cualificados que nunca, lo cual, por cierto, es una buena noticia para la industria.
¿Qué pasará cuando los modelos dejen de estar subvencionados?
A día de hoy es bastante difícil conocer el coste real del uso de los modelos porque todas las empresas están subvencionándolos para hacerse con la mayor cuota de mercado posible.
Pero esto no puede durar eternamente. Una vez el mercado se consolide y no quede un programador júnior en la tierra que sepa programar a la antigua usanza, podrán subir precios a voluntad.
Los que peinamos canas estamos reviviendo el mismo modus operandi con el que la industria introdujo el Cloud en nuestras vidas, y por el que ahora empresas que podrían correr toda su infra en dos servidores pagan decenas de miles de euros en servicios que no necesitan.
Lo que es fácil de construir, no tiene valor
Una de mis clásicas que nunca desaprovecho para airear: cuando cualquiera puede construir cualquier cosa, el mero hecho de construirla carece de valor.
Vamos a ver el mercado inundado de copias de copias de copias generadas en un día con Claude Code. Va a dar igual.
El otro día leí un tweet en el que alguien había recreado Typeform con Claude Code. Muy bien, chaval. Tienes un clon de Typeform. Ve ahora al mercado y ponte a ver si alguien te lo compra.
Encontrar problemas que valga la pena solucionar, el verdadero trabajo de producto, y la distribución, llegar a tus posibles clientes para que te compren, serán más importantes que nunca.
Conclusiones
Por mi parte, voy a seguir iterando con Claude Code. Confío en la gente más inteligente que yo que dice haberlo conseguido. Seguiré intentándolo, sobre todo porque sí que veo claro que esta forma de interacción, iterar en lenguaje natural y convertir ideas en productos va a ser lo normal.
Aprender a convivir con estas herramientas, entender sus límites y apoyarse en ellas sin perder pensamiento crítico será una de las habilidades clave de los próximos años.
Hablando de habilidades clave en este nuevo paradigma, tener criterio va a ser una de las más importantes: decidir qué construir, qué no, cómo validarlo, cuándo parar, qué riesgos asumir y cuáles no.
Y el buen juicio, de momento, no se compra con una suscripción PRO.
Nota y ejemplo de caso de uso de Claude Code: al terminar de escribir cada entrada y antes de publicarla la paso por un LLM para hacer una revisión editorial.
Hoy he copiado el texto a un archivo para que Claude tuviera acceso, y le he pedido que haga cosas que casi nunca hago por falta de tiempo, como por ejemplo: identificar los términos susceptibles de llevar un enlace, buscarlos en Internet, y añadirlos.
Del mismo modo, le he pedido que aplicase los cambios que detectaba en la revisión. Así, en lugar de ir yo aplicando las correcciones una a una, sólo me he encargado de revisar y aprobar.
Ha funcionado perfecto y Claude Code ya pasa, sin duda, a formar parte del equipo de edición de Estrategia de Producto.
Tras meses usando Cluade Code y sus diferentes modelos, te comparto mi workflow de manera muy resumida por si te sirve. A mí me funciona maravillosamente bien. Lo cual no quiere decir que a veces una tarea se atasque un poco y cueste más sacarla:
1. Optimiza el coste de los modelos: Opus es carísimo, solo lo uso para planificación y/o aquellas tareas muy complejas que se atascan. Para ejecutar lo planificado por Opus, uso Haiku. Es muy muy rápido, muy directo (hace lo que está planificado) y muchísimo más barato que Opus y que Sonnet. Sonnet ya casi no lo uso. Yo también tengo la suscripción de $20. Me niego a pagar $200.
2. Contexto: Dale todo el contexto posible a través del CLAUDE.md. Sobre todo estilo, buenas prácticas, ejemplos de cómo sí y cómo no, etc.
3. Planifica la tarea antes de ejecutar. Opus es muy muy bueno en esto. Es como tener un programador senior con muchos tiros dados y muy caro por tanto. Aún así hay que revisar y supervisar esa planificación de tareas y a veces modificar alguna cosa. Casi más por preferencias personales, que porque esté mal en sí.
4. Ejecuta en pair programming con Haiku. Como decía, es muy bueno y directo al grano y muy muy rápido. Aún así hay que estar con el mano a mano y evitar que se salga de los guardaraíles del contexto y la planificación, que a veces pasa.
5. Utiliza Agentes y Skills: Los agentes son muy buenos para subtareas muy específicas: Fronten, Backend, Testing, Seguridad. Las Skills consumen muy pocos tokens para lo que hacen y son muy útiles para procesos muy específicos, especialmente si les das las rutas de los archivos a tocar y los ejemplos.
6. No agotes la ventana de contexto: Cada vez que inicies una nueva subtarea, haz /clear. Haz /compact para continuar dentro de una misma tarea. Conforme se va quedando sin contexto, el LLM se va volviendo menos "inteligente", comete más fallos o tiene más alucinaciones.
Por último, Git. Al contrario de lo que hacen muchos, no le doy la responsabilidad de los commits a Claude Code, tan solo le digo que me sugiera un comentario para el commit. Pero yo reviso fichero por fichero cada commit y tanto el commit como el push, los hago yo manualmente. No quiero sorpresas desagradables en el repo remoto.
Nota adicional: Sé que puede sonar a tontería, pero leí un paper hace unas semanas de cómo funciona la "psicología" de los LLMs y cómo tienden a hundirse a medida que cometen un error, comienzan a decaer y cometer cada vez más errores. Y de cómo el concepto conocido en psicología como "efecto pigmaleon" parece funcionar en los LLMs. Y si tras un error, te pones negativo con él, es como le entrase ansiedad y nerviosismo y cada vez la lía más. Es como si entrara en un bucle de negatividad.
Desde entonces, cada vez que lo borda le felicito, cuando comete un error, se lo hago saber con amabilidad y sin dramas. Le animo a que lo intente de nuevo, que seguro que entre los dos lo vamos a resolver. Parece como que se motiva y suele mejorar en rendimiento (o me lo parece).
De paso, no tratarle como una máquina y más como a un compañero, hace que mis ocho horas de trabajo remoto en solitario se hagan más amenas. Aunque solo sea por eso, ya merece la pena.
Espero que alguna de estas ideas te sirva de algo. Un saludo
Con la versión pro no basta, hay que tener la MAX, hay ofertas para empresas y equipos. Son muy buenos los consejos de Fernando Val, solo añadiría el crear agentes responsables de cada tipo de tarea o proceso, con documentación compartida entre tipos de procesos o tareas, con un único origen de la verdad y referencias entre ellos. Lanzar claude con dangerously-skip-permissions, pasandole unicamente documentacion necesaria, en varios pasos (flow) y con toda la documentación y prompts bien organizados puede automatizarte tareas. Todos los skills apra mi gusto en python. Próximos pasos, que no se si llegaré a hacerlos, es intentar aislar mis procesos de automatización de tareas del LLM, poder cambiar solo la key, pero eso ya en el 2026. Feliz año