Después de casi 30 años desarrollando software, pocas herramientas me han hecho replantearme tanto mi forma de trabajar como Claude Code. He vivido muchos cambios: la llegada de internet, la evolución de PHP, los frameworks, Git, Composer, Docker, los despliegues en la nube… pero la inteligencia artificial aplicada al desarrollo tiene algo distinto. No solo acelera tareas. Cambia el papel del desarrollador dentro del proceso.
Al principio es fácil pensar que una herramienta como Claude Code sirve simplemente para escribir código más rápido. Y sí, lo hace. Pero después de usarla de forma continuada, mi conclusión es otra: la IA no ha cambiado tanto mi forma de programar como mi forma de desarrollar software.
Claude Code no programa por mí
Esta idea me parece importante. Claude Code no sustituye mi trabajo como desarrollador. Lo amplifica. Me ayuda a documentar, revisar, refactorizar, preparar estructuras, generar pruebas, plantear alternativas y explorar soluciones. Pero sigue necesitando dirección.
La diferencia está en que ahora dedico menos tiempo a picar cada línea y mucho más a pensar cómo debe ser el sistema: qué responsabilidades debe tener cada pieza, qué flujo tiene sentido, qué problemas pueden aparecer después y cómo mantener el proyecto estable cuando crezca.
Del campo al banquillo
La mejor metáfora que se me ocurre es el fútbol. Si te gusta jugar desde pequeño, disfrutas tocando el balón, corriendo, chutando y participando directamente en cada jugada. Programar durante años tiene algo de eso: disfrutas escribiendo código, resolviendo detalles, ajustando una función, encontrando una solución elegante.
Con la IA, a veces siento que he pasado del campo al banquillo. Sigo dentro del partido, pero mi papel ha cambiado. Ahora preparo la estrategia, explico lo que quiero, reviso lo que se ha hecho, corrijo errores y tomo decisiones. No soy quien toca cada balón, pero soy quien debe conseguir que el equipo juegue bien.
Y sí, reconozco que hay cierta nostalgia. Echo de menos algunas partes del desarrollo más manual, esa sensación de construir algo línea a línea. Pero también es cierto que ahora puedo poner en marcha proyectos e ideas que antes, trabajando solo, eran difíciles de abordar por falta de tiempo.
Más análisis, menos ejecución mecánica
La consecuencia más clara es que el análisis pesa más que nunca. Antes, un mal análisis llevaba a escribir mal el código. Ahora, un mal análisis puede hacer que la IA genere mucho código incorrecto muy rápido. El problema no desaparece: se amplifica.
Por eso la experiencia sigue siendo fundamental. Un desarrollador con años de oficio detecta cuándo una solución está sobrecomplicada, cuándo una clase tiene demasiadas responsabilidades, cuándo una consulta no va a escalar o cuándo una interfaz parece correcta pero no resuelve el problema real del usuario.
La IA puede proponer, pero alguien tiene que decidir. Y esa decisión no sale de la herramienta: sale del conocimiento del negocio, de la experiencia técnica y de la capacidad para anticipar problemas.
Si te interesa profundizar en el papel actual de la inteligencia artificial dentro del desarrollo de software, puedes leer también IA para desarrollo: beneficios reales, riesgos y cómo integrarlas sin perder el control del proyecto.
Prompt engineering: no es magia, es especificar mejor
Durante mucho tiempo se ha hablado de prompt engineering como si fuera una disciplina casi mágica. En la práctica, mi experiencia es mucho más sencilla: hacer buenos prompts se parece muchísimo a escribir una buena especificación técnica.
Las recomendaciones de Anthropic sobre Prompt Engineering coinciden bastante con las buenas prácticas de análisis: definir bien el objetivo, aportar contexto, dividir tareas grandes, indicar el formato esperado, dar ejemplos y revisar por iteraciones.
- Explicar qué problema se quiere resolver, no solo qué código se quiere generar.
- Aportar contexto del proyecto: arquitectura, restricciones, nombres, convenciones y objetivo funcional.
- Dividir el trabajo en pasos pequeños para poder revisar cada resultado.
- Indicar claramente el formato esperado: código, análisis, lista de cambios, riesgos o plan de trabajo.
- Pedir alternativas cuando la decisión no está clara.
- Revisar siempre el resultado antes de integrarlo.
Mis primeros prompts eran muy cortos. Hoy muchos son mucho más largos, no porque la IA necesite adornos, sino porque yo entiendo mejor lo que necesito explicar. Y cuanto mejor explico el problema, mejor trabaja la herramienta.
Lo que realmente he aprendido trabajando con Claude Code
La lección más importante no es que ahora pueda escribir más código. Es que puedo dedicar más energía a pensar mejor el proyecto. Claude Code me permite avanzar más rápido en partes repetitivas o mecánicas, pero también me obliga a ser más claro en la definición del problema.
Cuando trabajo bien con la IA, el proceso se parece menos a pedir código y más a dirigir un desarrollo: planteo el objetivo, reviso la propuesta, marco límites, corrijo desviaciones y valido que el resultado encaje con el proyecto real.
Ese cambio tiene impacto en la calidad. Al reducir el tiempo dedicado a tareas mecánicas, puedo invertir más atención en arquitectura, consistencia, documentación, pruebas y experiencia de usuario. En mi caso, incluso ha mejorado áreas en las que tradicionalmente me sentía menos cómodo, como la parte visual o la organización de interfaces.
Loop engineering: ¿el siguiente paso?
En los últimos meses empieza a hablarse de loop engineering, una idea que va más allá de escribir un buen prompt. En lugar de realizar una única petición a la IA, el proceso se convierte en un ciclo donde el propio sistema analiza el problema, planifica una solución, ejecuta tareas, revisa el resultado y vuelve a iterar hasta aproximarse al objetivo esperado.
El concepto ha ganado notoriedad gracias a desarrolladores como Peter Steinberger, fundador de PSPDFKit y creador del proyecto OpenClaw, quien defiende que el siguiente paso no consiste en escribir mejores prompts, sino en diseñar procesos o "loops" capaces de generar, evaluar y refinar automáticamente esos prompts y las acciones derivadas de ellos.
Aun así, conviene ser prudentes. No sabemos todavía si el término “loop engineering” se consolidará o si será una etiqueta más dentro de la evolución natural de las herramientas de IA. Lo importante, al menos para mí, no es el nombre. Lo importante es que el desarrollo asistido por IA se está moviendo hacia procesos más iterativos, más autónomos y más cercanos a cómo trabaja un equipo técnico.
El riesgo de delegar demasiado
Cuanto más capaz parece la herramienta, mayor es el riesgo de bajar la guardia. La IA puede generar código convincente, documentación razonable y explicaciones aparentemente sólidas. Pero eso no significa que haya entendido el negocio, las prioridades del cliente o las consecuencias futuras de una decisión técnica.
Delegar tareas es útil. Delegar criterio es peligroso. Si el desarrollador deja de revisar, de entender y de cuestionar, la productividad inicial puede convertirse en deuda técnica acelerada.
Conclusión: no programamos menos, pensamos distinto
La IA escribe código mucho más rápido que yo. Pero todavía necesita que alguien piense antes de empezar. Y esa es, probablemente, la mayor lección que me deja trabajar con Claude Code: el valor del desarrollador no desaparece; se desplaza.
Después de casi treinta años desarrollando software sigo creyendo algo muy parecido a lo que pensaba al empezar: la herramienta más importante no es el lenguaje, el framework ni ahora la inteligencia artificial. La herramienta más importante sigue siendo la capacidad de comprender un problema antes de intentar resolverlo.
Claude Code me ha permitido programar más rápido, sí. Pero sobre todo me ha obligado a analizar mejor, explicar mejor y revisar mejor. Y quizá ese sea el verdadero cambio: la IA no sustituye el oficio del desarrollador. Lo obliga a evolucionar.