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:

1. Entender el bug: Accediendo a todos los archivos del proyecto y entendiendo cómo funciona el sistema

2. Localizar el origen: Leyendo directamente el código.

3. Analizar la causa raíz: Revisando cambios recientes y consultando documentación online.

4. Aplicar una corrección: Editando los archivos directamente.

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