Durante los últimos tres meses dejé que Claude Code escribiera cerca del 40 % del código nuevo en uno de nuestros proyectos. Funciona. Pero no como la mayoría imagina.
La expectativa era sencilla. Yo describo las tareas, el agente escribe el código, yo reviso y hago merge. Como dirigir a un desarrollador júnior rápido. La realidad es distinta. Paso el mismo tiempo frente al teclado que antes. El trabajo se desplazó. Menos escritura, más lectura. Menos esfuerzo mecánico, más reflexión sobre si lo que el agente propuso tiene realmente sentido dado un contexto que no puede ver.
He probado la mayoría de lo que hay. Cursor, Claude Code, GitHub Copilot, OpenAI Codex. Todos son decentes, y todos se diferencian en aspectos que importan según cómo trabaje uno.
Cualquier cosa de peso va a Claude Code, ya sea reescribir un servicio, construir una suite de pruebas o refactorizar una capa del proyecto. La interacción en la terminal encaja con mi manera de pensar los cambios grandes. Cursor es mejor cuando quiero quedarme dentro de mi editor y hacer ediciones pequeñas y localizadas. Copilot lo conservo para el autocompletado y nada más. Codex lo probé en dos proyectos y volví a Claude Code. Los resultados estaban bien, pero el modelo de interacción no me convenció.
Actualización, julio de 2026. Codex volvió a nuestra rotación cuando OpenAI lo pasó a facturación de pago por uso. Hoy se encarga de tareas agénticas junto a Claude Code y el resto del artículo sigue igual que en abril.
Nada de esto es una recomendación. Cada equipo, cada persona, encuentra lo que le va. Lo interesante no es qué herramienta se elige. Es lo que pasa después.
El equipo de Vercel detrás de Turborepo publicó su experiencia con agentes de IA en el desarrollo. Los bucles totalmente autónomos (el agente escribe código sin supervisión) no produjeron resultados con calidad de producción. Sus agentes generaban código que pasaba las pruebas, pero contenía errores de lógica que un desarrollador experimentado habría detectado por instinto. El código parecía correcto. No lo era.
Shopify ha hablado públicamente de usar IA para herramientas internas. Google la usa para generar pruebas a gran escala. Microsoft lanza Copilot y presumiblemente lo usa internamente. El patrón en todas ellas es el mismo. La IA genera, las personas verifican. Nadie que tenga sistemas en producción en juego lleva la salida de un agente directa al despliegue.
Y aun así, el discurso de LinkedIn sigue dando vueltas a publicaciones del tipo «la IA reemplazó a mi equipo». Esas tratan sobre MVP, proyectos paralelos o ficción.
En un proyecto de cliente le encargué al agente reescribir una capa de middleware. Unas 1200 líneas. Nada difícil de entender, solo mucho trabajo mecánico. Lo hizo en veinte minutos. Yo dediqué una hora a revisarlo y el resultado quedó más limpio que el código original. Las pruebas pasaron, los casos límite estaban cubiertos y hasta el nombrado de las variables era más coherente que lo que habían escrito las personas. Quedé impresionado.
Una semana después, en el mismo proyecto, le pedí que diseñara un cambio en la capa de base de datos. Parecía correcto. Las pruebas pasaron.
Durante la revisión manual (línea por línea, porque así es como reviso ahora la salida del agente) encontré un escenario en el que se borrarían registros que debían conservarse. La suite de pruebas no lo cubría. El agente no había incluido esa prueba porque, desde su punto de vista, el escenario no era evidente en el código. La información estaba en un correo de un cliente de tres meses atrás.
Un agente no es un desarrollador júnior que hace preguntas. Llena el silencio con código verosímil.
Esa segunda tarea cambió mi forma de trabajar con estas herramientas más que cualquier artículo de blog o charla de conferencia. La pregunta dejó de ser «¿puede el agente escribir este código?» y pasó a ser «¿qué no sabe el agente que yo sí sé?».
Hace un año, la conversación giraba en torno a si la IA podía siquiera escribir código. Hoy nadie serio lo pone en duda. La conversación se ha desplazado a los modelos de supervisión. ¿Cuánta supervisión humana necesita el código generado por IA? ¿Cuándo se puede confiar en él y cuándo no?
Por lo que veo en nuestro propio trabajo y por lo que reportan otros equipos:
El código mecánico (endpoints CRUD, migraciones, definiciones de tipos, componentes repetitivos) el agente lo maneja bien y el coste de revisión es mínimo. El ahorro de tiempo aquí es real. Una tarea de 3-4 horas pasa a ser de 1,5-2 horas. No porque el agente lo haga todo, sino porque hace las partes que no requieren criterio.
Arquitectura, seguridad, lógica de negocio con reglas no escritas. Eso sigue necesitando a una persona que entienda el dominio del problema, no solo el código. Ningún modelo que haya usado sabe razonar sobre lo que no está escrito. Y el contexto más importante de cualquier sistema de negocio suele ser precisamente lo que nadie escribió.
Esto surge en conversaciones con otros CTO y sigo sin tener una buena respuesta. Si los desarrolladores júnior aprenden a programar trabajando con agentes desde el primer día, ¿aprenden a escribir código o aprenden a leer y aprobar código? Son habilidades distintas. Leer código que escribió otra persona es más fácil que escribirlo desde cero. La memoria muscular de resolver los problemas por uno mismo es difícil de reemplazar.
No sé qué significa esto para la profesión dentro de cinco años. Lo que sé es que, ahora mismo, los desarrolladores de mi equipo que mejor trabajan con agentes son los que ya eran fuertes sin ellos.
Los agentes de codificación con IA hacen a mi equipo más rápido en el trabajo mecánico. No nos hacen más inteligentes. Son peligrosos justo donde parecen más seguros, en tareas que requieren un contexto del que carecen. Nuestro proceso funciona porque la revisión atrapa lo que el agente pasa por alto, y esa revisión es lenta y humana a propósito.
Si esto es una fase de transición o la forma permanente del desarrollo asistido por IA, sinceramente no lo sé.
Si está intentando averiguar dónde encaja la IA en su proceso de desarrollo, hablemos.
Fundador y responsable técnico de Rise.sk. Diseña y entrega aplicaciones web, sistemas de datos y automatizaciones, y escribe sobre decisiones de software, IA y servicios digitales.
OpenAI dice que GPT-5.6 Sol supera a Claude Fable 5 en programación por un tercio del coste. Anthropic dice que Fable 5 lidera en capacidad bruta. Ambos tienen razón. Aquí tiene qué modelo gana qué trabajo.
Los tokens de API pueden costar menos que una hora de desarrollador, pero no son todo el proyecto. Una comparación práctica del uso del modelo, la revisión, las pruebas y los costes operativos.
Un agente de IA puede ahorrar horas, pero solo si los permisos, los registros, las aprobaciones, los responsables y las vías de fallo se diseñan antes de que toque los sistemas de producción.
Su contexto determina la respuesta
