Hoy vamos a ponernos prácticos.
Esta semana no voy a explicar qué es la IA generativa ni por qué es importante para el futuro de la ingeniería. Si estás leyendo esto, ya lo sabes.
Lo que voy a hacer es contarte exactamente qué herramientas están usando los equipos técnicos que ya han integrado IA en su flujo de trabajo real, para qué sirve cada una, en qué momento del proceso de desarrollo usarla y en qué procesos no tener IA ya es una desventaja competitiva.
Y al final, algo que está cambiando silenciosamente la forma en que se estructuran y presupuestan los equipos de producto.
El mapa de herramientas por fase del proceso
No existe una herramienta que lo haga todo bien. Lo que sí existe es una herramienta adecuada para cada momento del proceso. Esto es lo que está funcionando en la práctica.
Fase 1: Análisis, definición y arquitectura
Claude Sonnet es la herramienta que mejor funciona en esta fase. No por ser la más potente en términos de código, sino porque tiene una capacidad de razonamiento y síntesis que lo hace especialmente útil para procesar documentación compleja, analizar requisitos, detectar inconsistencias en una especificación y generar estructuras de decisión claras.
En la práctica esto se traduce en cosas concretas: analizar un documento de requisitos y extraer los riesgos técnicos no explícitos, generar diagramas de arquitectura en formato texto que luego se renderizan con Mermaid o PlantUML, comparar opciones de diseño con sus trade-offs, o preparar el contexto estructurado que luego se usará en las fases de implementación.
El flujo que funciona: definir el problema con claridad, cargar el contexto relevante y usar Claude para clarificar, estructurar y generar los artefactos de definición antes de escribir una sola línea de código.
Fase 2: Implementación
Aquí hay dos aproximaciones según el perfil del equipo y el tipo de proyecto.
- Claude Code con Opus es la opción para implementación compleja donde el razonamiento profundo importa. Opus tiene una capacidad de comprensión del contexto y de mantenimiento de coherencia en proyectos grandes que lo diferencia del resto. Funciona especialmente bien en refactorizaciones complejas, implementación de patrones de arquitectura y situaciones donde el código generado tiene que encajar en una base de código existente con muchas dependencias.
- Codex con GPT-5 es la alternativa dentro del ecosistema OpenAI. Funciona bien para generación de código en proyectos donde ya se está usando la stack de OpenAI o donde la integración con otras herramientas del ecosistema tiene peso.
- Cursor es la opción todo en uno para equipos que quieren integrar IA directamente en el editor sin cambiar de contexto. Combina un editor basado en VS Code con acceso a modelos de última generación y una integración en el flujo de trabajo que reduce la fricción al mínimo. Para equipos que empiezan con IA en desarrollo, Cursor tiene la curva de adopción más baja. Para equipos más avanzados, la flexibilidad de Claude Code o Codex puede ser más útil según el caso.
Fase 3: Revisión, testing y documentación
Son las tres fases donde la IA tiene más impacto inmediato y donde menos equipos la están usando de forma sistemática.
- Revisión de código: cualquiera de los modelos anteriores puede analizar un PR con contexto suficiente y detectar problemas que una revisión manual pasa por alto: inconsistencias con patrones existentes, casos edge no cubiertos, problemas potenciales de rendimiento o seguridad. No reemplaza la revisión humana, pero la hace más eficiente y más profunda.
- Testing: generación de casos de prueba a partir de la especificación, identificación de escenarios no cubiertos, generación de datos de prueba realistas. Es una de las tareas con mejor ratio esfuerzo-resultado cuando se integra bien en el flujo.
- Documentación: el cuello de botella eterno de cualquier equipo. La IA genera documentación técnica de calidad a partir del código cuando el contexto está bien estructurado. No al revés.
Los procesos en los que ya no eres competitivo sin IA
Hay un conjunto de tareas donde la diferencia de velocidad entre un ingeniero que usa IA y uno que no, es tan grande que ya no es una ventaja, es una brecha estructural.
- Scaffolding y boilerplate. Generar la estructura inicial de un proyecto, configurar pipelines, crear las capas base de una aplicación. Lo que antes llevaba días ahora lleva horas. Un equipo que no usa IA aquí está invirtiendo tiempo en trabajo que no aporta valor diferencial.
- Análisis de logs y debugging complejo. Cargar trazas de error con contexto y pedir análisis. La capacidad de procesar volumen de información y correlacionar patrones es donde los modelos grandes tienen ventaja real sobre el análisis manual.
- Generación y revisión de PRs. Descripciones de PR generadas automáticamente a partir del diff, revisiones iniciales antes de la revisión humana, detección de cambios que rompen contratos de API. Equipos que no tienen esto integrado están haciendo trabajo manual que ya no tiene justificación.
- Preparación de decisiones técnicas. Comparativas de tecnologías, análisis de trade-offs, evaluación de opciones de arquitectura. La capacidad de procesar documentación técnica extensa y sintetizar criterios de decisión claros es una de las aplicaciones más infrautilizadas y de mayor impacto.
La economía del token y lo que está cambiando en los equipos
Hay algo que está ocurriendo en los equipos de producto más avanzados que todavía no tiene mucha visibilidad pero que va a cambiar la forma en que se estructuran y presupuestan los proyectos.
El modelo de estimación tradicional se basa en horas hombre por precio hora. Un proyecto de tres meses necesita X ingenieros durante Y semanas a Z euros por hora. Ese modelo está empezando a romperse.
Lo que está emergiendo se conoce como economía del token: el coste real de construir software ya no es solo tiempo de ingenieros, es una combinación de tiempo de ingenieros senior orientando y revisando, agentes ejecutando tareas de implementación y coste de inferencia de los modelos que los alimentan.
En la práctica esto se está traduciendo en squads de producto más pequeños donde un ingeniero senior con criterio puede orquestar varios agentes haciendo trabajo en paralelo. Tareas que antes requerían un equipo de cinco están siendo ejecutadas por equipos de dos o tres con apoyo de agentes especializados.
Esto no significa que los ingenieros estén desapareciendo. Significa que el perfil que tiene valor está cambiando. El ingeniero que sabe orquestar agentes, mantener la coherencia del sistema, revisar con criterio lo que la IA genera y tomar las decisiones que los agentes no pueden tomar tiene un multiplicador de impacto que no existía hace dos años.
Por dónde empezar si todavía no has integrado esto
Si tu flujo de trabajo todavía no tiene IA integrada de forma sistemática, el orden que tiene más sentido es este:
- Primero, empieza por la fase de análisis y definición con Claude Sonnet. Es donde la curva de aprendizaje es más baja y el impacto más inmediato. Aprenderás a estructurar contexto y a trabajar con el modelo antes de depender de él para implementación.
- Segundo, prueba Cursor si quieres integración directa en el editor sin fricción. Es la forma más rápida de ver el impacto en implementación.
- Tercero, cuando tengas criterio propio sobre cómo trabajan los modelos, evalúa Claude Code u Opus para proyectos más complejos donde el razonamiento profundo importa.
El objetivo no es usar todas las herramientas. Es encontrar el flujo que funciona para tu contexto y construir sobre él.
Si te gusta este contenido no olvides compartirlo y, si quieres ser de esos ingenieros que saquen provecho de la IA, suscríbete a la newsletter, es GRATIS 😉