Llevo más de veinticinco años en esto. He visto llegar internet, los primeros CMS, el boom de las agencias, el diseño responsive, el JAMstack, el no-code. Cada vez que llegaba algo nuevo, alguien decía que iba a terminar con los desarrolladores web. Y cada vez lo que ocurrió fue que el perfil evolucionó, que el tipo de trabajo cambió, y que los clientes siguieron necesitando a alguien que entendiera sus problemas antes de escribir la primera línea de código.
Claude Code no es diferente en ese sentido. Pero sí lo es en otro: es, técnicamente, la herramienta más capaz que he tenido nunca en las manos. Y lo digo sin exagerar.
Lo que hace bien (y lo hace muy bien)
Empiezo por aquí porque me parece importante no caer en el tópico del desarrollador que habla de la IA con condescendencia para tranquilizarse a sí mismo. Claude Code es bueno. Muy bueno. Y mejora a una velocidad que, si te despistas seis meses, el salto es perceptible.
En mi día a día lo uso para varias cosas concretas.
- El código repetitivo y el boilerplate. Configuraciones, plantillas de componentes, estructuras que siguen siempre el mismo patrón. Aquí no solo es rápido: es consistente. Mientras yo podría copiar mal un import o cometer una errata en el cuarto componente idéntico que escribo en el mismo día, Claude Code no se cansa ni baja la guardia.
- Depurar errores. Y no solo encontrarlos, sino entender por qué ocurren. Cuando algo falla de forma críptica, explicarle el contexto y pedirle que razone el error me ahorra, muchas veces, veinte minutos de buscar en Stack Overflow respuestas de 2019 que ya no aplican. Sigo siendo yo quien valida que el razonamiento tiene sentido. Pero el punto de partida llega antes.
- Explorar librerías y APIs nuevas. Este es uno de mis usos favoritos. Antes de abrir la documentación oficial puedo pedirle que me muestre cómo funciona algo con un ejemplo de mi caso concreto. Llego a la documentación con preguntas más precisas y aprendo la sintaxis básica en la mitad de tiempo.
- Refactorizar código existente. Dado un fragmento que funciona pero que no me convence, me propone alternativas. No siempre son mejores, pero con frecuencia abren una dirección que no había considerado.
En todos estos casos la herramienta rinde bien porque el tipo de problema está acotado, tiene una respuesta técnicamente verificable y el contexto que necesita para resolverlo cabe en lo que le cuento.
El matiz que no esperaba
Cuando empecé a usarlo esperaba que fallara en las cosas complejas. Que se perdiera en proyectos grandes, que alucinara con APIs inexistentes. Y eso también pasa, pero no es lo que más me ha llamado la atención.
Lo que más me ha sorprendido es una característica muy específica: Claude Code tiende a resolver los problemas a fuerza bruta.
Me explico con un ejemplo real. Puede escribir una función de doscientas líneas que funciona perfectamente, que pasa todos los tests, que no tiene un solo error. Y ese mismo problema, muchas veces, se resuelve en cuatro líneas tirando de una característica del lenguaje que ya está ahí, de la librería que ya tenemos importada, de algo que un desarrollador con cierto recorrido haría de forma casi instintiva.
El asistente llega a la solución. Pero no siempre toma el camino más corto.
Pasa igual con CSS y con los estilos en general. Claude Code puede hacer una web preciosa. Visualmente, el resultado es bueno. Pero si miras bajo el capó a veces encuentras que ha definido clases con nombres ligeramente distintos en cada sección, y que está aplicando estilos casi idénticos en tres sitios diferentes en lugar de definir un patrón compartido. El resultado se ve igual, pero el código no es reutilizable ni fácil de mantener. Funcionalmente correcto. Arquitectónicamente mejorable.
Esto no es una crítica a la herramienta: es una característica que hay que entender para trabajar bien con ella.
El problema de "si funciona, no lo toques"
Aquí es donde me parece importante pararse un momento, sobre todo pensando en quien empieza.
Hay una cultura muy arraigada en el desarrollo que dice que si algo funciona, no tiene sentido tocarlo. Y en muchos contextos esa es una postura sensata: no refactorices código estable sin motivo, no cambies lo que está en producción si no hay un problema real. Lo entiendo.
Pero esa misma actitud, aplicada al código que genera la IA, puede convertirse en un problema. Si alguien que está aprendiendo acepta la función de doscientas líneas porque funciona y porque la IA la ha generado, nunca desarrolla el criterio para reconocer que hay una solución de cuatro líneas. Y ese criterio no se aprende viendo código que funciona. Se aprende iterando, cuestionando, preguntándose si lo que tienes es lo más simple que podría funcionar.
Yo siempre he dicho que el código no solo debe funcionar: debe ser bonito. No en sentido estético, sino en el sentido de que cuando alguien lo lee seis meses después entiende por qué está escrito así, y que cuando hay que cambiarlo se cambia en un sitio y no en doce. El código feo que funciona acumula deuda técnica silenciosa. Y la IA, si no le exiges ese estándar, tiene tendencia a acumularla.
La buena noticia es que si se lo dices, si le pides que itere, que simplifique, que busque el patrón reutilizable, lo hace. El criterio tiene que ser tuyo. La herramienta responde a él.
¿Me va a sustituir?
Honestamente, no lo sé. Tal vez. Al menos en parte.
Creo que el punto humano entre el cliente y la máquina va a seguir siendo necesario durante un tiempo. Alguien tiene que entender lo que el cliente necesita antes de que ese problema esté lo suficientemente bien definido como para resolverlo con código. Alguien tiene que hacer las preguntas incómodas, gestionar las expectativas, reconocer cuándo lo que se pide no es lo que se necesita. Esa parte no cabe en un prompt.
Pero que vaya a tener que redefinir mi perfil profesional me parece muy probable. Y eso no me preocupa especialmente. En veinticinco años ya lo he hecho varias veces. Desde los primeros pasos de internet hasta hoy, el tipo de trabajo que hago, el perfil de cliente que tengo, las herramientas que uso han cambiado radicalmente. En cada salto hubo un momento de incertidumbre y luego una adaptación. No veo razones para que esta vez sea diferente.
Lo que me parece más relevante ahora mismo no es si la IA me sustituye a mí, sino qué hábitos desarrollan quienes empiezan hoy con estas herramientas. Si aprenden a iterar, a exigir elegancia, a cuestionar el primer output que funciona: van a ser mejores desarrolladores. Si aprenden a validar lo que la IA genera porque funciona y punto: van a construir muchas cosas que se verán bien por fuera y serán frágiles por dentro.
La herramienta es buenísima. El criterio sigue siendo tuyo.
