Curso de AID (AI Driven Development) para equipos de desarrollo

Entender qué hace un modelo de lenguaje cuando trabaja con código y por qué no “comprende” el sistema como un humano.

Diferenciar modelos generalistas, modelos optimizados para código, agentes, herramientas conectadas y entornos de ejecución.

Revisar conceptos clave: contexto, tokens, instrucciones, grounding, herramientas, memoria, llamadas a terminal, edición de archivos y ejecución de tests.

Entender por qué el código generado depende de la calidad del contexto y de las restricciones dadas.

Identificar patrones de error frecuentes: imports inexistentes, APIs obsoletas, lógica incompleta, simplificaciones peligrosas y tests que no prueban nada.

Diferenciar generación de código desde cero, modificación de código existente y comprensión de repositorios grandes.

Comprender la diferencia entre prompt puntual, flujo iterativo y tarea delegada a agente.

Revisar cómo influyen los modelos, la temperatura, el contexto, las herramientas disponibles y los permisos.

Evaluar cuándo conviene usar IA dentro del IDE, desde CLI, en web, en GitHub/GitLab o integrada en pipelines.

Crear criterios para elegir el tipo de asistencia adecuada según tarea, riesgo, tamaño y madurez del proyecto.

Comparar asistentes de IDE, agentes locales, agentes cloud, chats de documentación, generadores de tests, revisores de PR y herramientas de seguridad.

Analizar GitHub Copilot en IDE, agent mode, cloud agent, pull requests, políticas de organización y flujos de adopción.

Revisar OpenAI Codex como agente de coding para trabajar localmente, en IDE o en la nube, con tareas sobre repositorios y entornos controlados.

Explorar Claude Code como asistente/agente orientado a repositorios, edición multiarchivo, comprensión de código y automatización de tareas.

Situar Gemini Code Assist en entornos IDE y Google Cloud, incluyendo asistencia para construir, desplegar y operar aplicaciones.

Incluir herramientas tipo Cursor, Windsurf, JetBrains AI, Continue, Aider, Devin-like agents y plataformas internas según el contexto empresarial.

Identificar qué herramientas son mejores para autocomplete, cuáles para refactorización, cuáles para agentes autónomos y cuáles para revisión.

Evaluar criterios de selección: privacidad, coste, integración, modelos disponibles, controles, soporte empresarial, auditoría y rendimiento.

Evitar depender de una sola herramienta cuando el equipo necesita portabilidad de métodos, instrucciones y estándares.

Crear una matriz comparativa de herramientas según casos de uso y restricciones de empresa.

Preparar IDE, extensiones, CLI, autenticación, repositorios, terminal, linters, formateadores y ejecutores de tests.

Configurar herramientas de IA en modo individual, equipo o empresa según licencias y políticas disponibles.

Separar entornos de práctica, proyectos internos, repositorios sensibles y producción.

Gestionar permisos de lectura, escritura, ejecución de terminal, acceso a internet y creación de ramas.

Configurar exclusiones para secretos, ficheros sensibles, datasets, `.env`, certificados, dumps y claves privadas.

Revisar logs, historial de prompts, sesiones, outputs y trazabilidad cuando la herramienta lo permita.

Preparar una plantilla de proyecto con comandos claros de instalación, build, lint, test y ejecución.

Crear instrucciones de repositorio para guiar a los agentes sobre arquitectura, estilos, restricciones y definición de terminado.

Usar archivos de contexto como `AGENTS.md`, `CLAUDE.md`, documentación interna o guías equivalentes según herramienta.

Validar que el entorno permite a la IA ejecutar comprobaciones reales y no solo generar código sin probarlo.

Entender context engineering como la preparación del conocimiento necesario para que la IA trabaje bien.

Diferenciar contexto de producto, contexto técnico, contexto arquitectónico, contexto de dominio, contexto de testing y contexto de seguridad.

Crear documentos breves sobre estructura del repositorio, módulos, comandos, estándares, convenciones y límites.

Incluir instrucciones sobre cómo ejecutar tests, cómo levantar servicios, cómo generar migraciones y cómo validar cambios.

Añadir información de arquitectura: capas, patrones, dependencias permitidas, módulos críticos y zonas legacy.

Definir reglas de “no tocar”: ficheros generados, APIs públicas, contratos estables, migraciones peligrosas o zonas reguladas.

Preparar ejemplos de código correcto para que la IA copie el estilo real del proyecto.

Evitar saturar contexto con documentación extensa que no se usa para la tarea.

Mantener contexto versionado junto al repositorio para que evolucione con el sistema.

Medir mejora comparando respuestas antes y después de proporcionar contexto estructurado.

Formular tareas de desarrollo con objetivo, alcance, restricciones, ficheros relevantes, criterio de aceptación y forma de validación.

Evitar prompts vagos como “arréglalo” o “mejora este código” cuando la tarea requiere precisión.

Pedir primero análisis y plan antes de permitir cambios en código.

Dividir tareas complejas en pasos verificables: comprender, diseñar, modificar, probar, documentar y revisar.

Incluir límites: no cambiar APIs públicas, no añadir dependencias, no modificar tests sin justificar o no tocar migraciones.

Pedir alternativas cuando la decisión técnica no es evidente.

Usar prompts de revisión para encontrar riesgos, duplicidades, complejidad, seguridad y rendimiento.

Crear prompts reutilizables para bugs, tests, refactorizaciones, documentación, migraciones y code review.

Evaluar cuándo conviene dar mucho contexto y cuándo basta con una instrucción mínima.

Crear una librería interna de prompts técnicos adaptados al stack de la empresa.

Identificar tareas aptas para agentes: añadir tests, corregir bugs acotados, documentar módulos, refactorizar funciones, migrar APIs y analizar dependencias.

Separar tareas pequeñas, medianas y grandes según riesgo, número de archivos y necesidad de validación.

Convertir issues en tareas delegables con descripción, contexto, restricciones, comandos y criterio de done.

Pedir al agente que investigue el repositorio antes de proponer cambios.

Exigir plan de modificación y lista de ficheros afectados antes de aplicar cambios amplios.

Usar ramas separadas para tareas de agentes y evitar cambios directos en ramas protegidas.

Revisar diffs con atención a código generado, tests añadidos, dependencias nuevas y efectos secundarios.

Rechazar cambios que funcionan por casualidad pero rompen arquitectura o estilo del proyecto.

Dividir tareas demasiado grandes en subtareas para evitar PRs inmanejables.

Definir una política de cuándo un agente puede abrir PR y cuándo solo debe generar propuesta.

Usar IA para navegar repositorios grandes, localizar puntos de entrada, identificar módulos y explicar flujos.

Pedir mapas de arquitectura, diagramas de componentes, dependencias y responsabilidades del código.

Analizar una funcionalidad existente desde endpoint, caso de uso, servicio, dominio, repositorio y base de datos.

Detectar código muerto, duplicación, módulos acoplados y dependencias circulares con ayuda de IA.

Generar resúmenes técnicos por módulo para acelerar onboarding.

Pedir explicaciones por niveles: junior, senior, arquitectura, QA o producto.

Contrastar respuestas de IA con búsqueda real en el repositorio y ejecución de tests.

Evitar aceptar explicaciones no verificadas cuando la IA no ha visto todos los ficheros relevantes.

Crear documentación viva a partir de exploraciones verificadas.

Usar sesiones de análisis para reducir tiempo de entrada en proyectos legacy.

Generar funciones, clases, componentes, endpoints, scripts o utilidades a partir de requisitos concretos.

Pedir código alineado con patrones existentes del proyecto, no soluciones genéricas de tutorial.

Solicitar primero una propuesta de diseño cuando la funcionalidad afecta a varias capas.

Limitar dependencias externas y exigir justificación cuando se propone añadir una nueva.

Revisar imports, tipos, errores, validaciones, seguridad, rendimiento y compatibilidad.

Evitar que la IA invente APIs internas o llame métodos inexistentes.

Exigir tests junto al código cuando la tarea sea funcionalmente relevante.

Comparar varias alternativas generadas antes de elegir una implementación.

Ejecutar linters, tests y build después de incorporar cambios.

Documentar cambios generados por IA igual que cualquier desarrollo humano.

Identificar refactorizaciones seguras: extraer función, reducir duplicación, mejorar nombres, simplificar condicionales o separar responsabilidades.

Pedir a la IA que preserve comportamiento y no cambie contratos públicos salvo instrucción explícita.

Usar pruebas existentes como red de seguridad antes de refactorizar.

Crear pruebas de caracterización con IA cuando el código legacy no tiene cobertura.

Refactorizar por pasos pequeños y revisables, no con grandes reescrituras opacas.

Detectar oportunidades: god classes, controladores enormes, servicios anémicos, helpers excesivos y duplicación.

Pedir explicación de cada cambio de diseño y motivo de mejora.

Comparar complejidad antes/después con métricas o revisión manual.

Evitar refactorizaciones cosméticas que no reducen riesgo ni coste de mantenimiento.

Crear una estrategia de refactorización gradual para módulos críticos.

Usar IA para analizar trazas, logs, stack traces, errores de compilación, fallos de tests y bugs intermitentes.

Preparar prompts con síntoma, pasos para reproducir, entorno, versión, logs, cambios recientes y comportamiento esperado.

Pedir hipótesis ordenadas por probabilidad y forma de validarlas.

Evitar que la IA proponga cambios sin reproducir el problema.

Generar pruebas que reproduzcan el bug antes de arreglarlo.

Analizar regresiones comparando commits, PRs, dependencias y cambios de configuración.

Usar IA para explicar errores complejos a perfiles menos familiarizados con el módulo.

Documentar causa raíz, solución aplicada y prevención futura.

Distinguir bug real, problema de configuración, dato corrupto, dependencia rota o expectativa incorrecta.

Crear runbooks de diagnóstico asistidos por IA para incidencias recurrentes.

Generar tests unitarios para funciones, clases, servicios, validadores, policies y lógica de dominio.

Pedir casos normales, límites, errores, valores nulos, entradas inválidas y escenarios extremos.

Evitar tests que solo comprueban que el mock fue llamado sin validar comportamiento real.

Usar IA para detectar ramas no cubiertas y condiciones no probadas.

Mejorar nombres de tests para que expresen comportamiento.

Generar datos de prueba representativos sin usar datos reales sensibles.

Revisar que los tests no reimplementan la misma lógica que el código probado.

Mantener tests deterministas, rápidos y aislados.

Usar mutation testing o revisión crítica para detectar tests débiles.

Crear plantillas de test alineadas con el framework del proyecto.

Usar IA para diseñar pruebas de integración entre API, base de datos, colas, servicios externos y frontend.

Generar tests de contrato a partir de OpenAPI, AsyncAPI, schemas o acuerdos entre servicios.

Diseñar escenarios end-to-end orientados a journeys críticos de usuario.

Pedir a la IA que identifique mocks excesivos que ocultan errores reales de integración.

Crear datos de prueba reproducibles para entornos CI.

Validar errores, timeouts, permisos, estados intermedios y condiciones de carrera.

Analizar fallos de tests E2E con logs, capturas, trazas y pasos reproducibles.

Evitar generar suites lentas que bloquean el pipeline sin aportar cobertura valiosa.

Priorizar pruebas según riesgo funcional, frecuencia de cambio e impacto de negocio.

Documentar estrategia de testing asistida por IA para cada tipo de proyecto.

Usar IA como primera pasada de revisión para detectar errores evidentes, duplicidades, complejidad y posibles vulnerabilidades.

Pedir revisión por categorías: lógica, seguridad, rendimiento, mantenibilidad, estilo, tests y documentación.

Comparar revisión de IA con revisión humana para mejorar criterios del equipo.

Evitar aceptar comentarios genéricos que no apuntan a líneas, riesgos o mejoras concretas.

Usar IA para resumir PRs largos y facilitar revisión humana.

Pedir generación de checklist específico según tipo de cambio: API, migración, frontend, seguridad, infraestructura o datos.

Detectar cambios no relacionados dentro de un PR.

Revisar si los tests añadidos realmente cubren el comportamiento modificado.

Usar IA para preparar preguntas al autor del PR, no para sustituir criterio del reviewer.

Medir si la revisión asistida reduce defectos o solo añade ruido.

Analizar riesgos específicos: inyección SQL, XSS, exposición de secretos, permisos incorrectos, validación insuficiente y dependencias inseguras.

Revisar código generado con herramientas SAST, secret scanning, dependency scanning y revisión manual.

Pedir a la IA que revise amenazas siguiendo OWASP, STRIDE u otros marcos adecuados.

Evitar pegar secretos, tokens, `.env`, dumps o datos personales en herramientas externas.

Definir prompts seguros que no incluyan información sensible innecesaria.

Revisar código de autenticación, autorización, criptografía y gestión de sesiones con especial cuidado.

Exigir explicación de decisiones de seguridad cuando se genera middleware, guards, policies o validadores.

Crear tests negativos para accesos no autorizados, entradas maliciosas y errores de validación.

Mantener humanos responsables de aprobación en cambios de seguridad.

Crear una política de uso de IA en desarrollo seguro.

Generar componentes, hooks, stores, formularios, validaciones, estados de carga y manejo de errores con IA.

Pedir componentes alineados con design system, accesibilidad, estilos, arquitectura y librerías existentes.

Usar IA para detectar duplicación, props excesivas, estado mal ubicado y componentes demasiado grandes.

Generar tests de componentes, interacción y accesibilidad.

Revisar que la IA no rompe patrones de estado, routing, data fetching o internacionalización.

Pedir mejoras de UX basadas en criterios concretos, no en gustos genéricos.

Crear storybook stories, mocks y documentación de componentes con ayuda de IA.

Usar IA para migraciones de librerías o actualización de patrones frontend.

Evitar introducir dependencias visuales o utilidades sin aprobación.

Integrar IA en el flujo de diseño-desarrollo sin sustituir revisión UX.

Generar endpoints, DTOs, validators, servicios, casos de uso, repositories y migraciones con control.

Usar IA para diseñar contratos API consistentes con recursos, errores, paginación, filtros y seguridad.

Crear documentación OpenAPI y ejemplos de request/response.

Revisar lógica de negocio para evitar que quede dispersa en controladores o mappers.

Generar pruebas unitarias, integración y contrato para APIs.

Pedir análisis de rendimiento en consultas, transacciones y serialización.

Detectar problemas de concurrencia, idempotencia, retry y efectos secundarios.

Crear clientes SDK internos a partir de contratos validados.

Evitar que la IA genere CRUD genérico cuando el dominio necesita operaciones explícitas.

Documentar decisiones de diseño API con apoyo de IA.

Usar IA para escribir consultas, optimizarlas, explicar planes y detectar posibles problemas de rendimiento.

Generar migraciones con revisión estricta de compatibilidad, rollback y datos existentes.

Crear scripts de limpieza, validación, agregación o reporting con control.

Revisar riesgos de pérdida de datos, locks, cambios breaking y actualizaciones masivas.

Pedir alternativas de índice justificadas por consultas reales.

Generar consultas parametrizadas evitando concatenación insegura.

Analizar esquemas legacy y documentar relaciones entre tablas.

Crear datos sintéticos para pruebas sin usar información sensible.

Revisar que la IA no invente columnas, constraints o tablas inexistentes.

Incorporar revisión DBA o técnica en cambios de datos críticos.

Generar pipelines CI/CD para build, test, lint, análisis de seguridad, empaquetado y despliegue.

Usar IA para explicar errores de pipeline, fallos de dependencias y problemas de entorno.

Crear Dockerfiles, compose files, manifests Kubernetes, Helm charts o Terraform con revisión técnica.

Revisar seguridad de contenedores, permisos, secrets, imágenes base y configuración de red.

Generar scripts de automatización para tareas repetitivas de plataforma.

Usar IA para documentar runbooks de despliegue, rollback, backups y troubleshooting.

Analizar logs de despliegue y proponer causas probables.

Evitar aplicar infraestructura generada sin revisión, plan de rollback y entorno de prueba.

Incorporar agentes en pipelines solo cuando existan permisos, límites y auditoría.

Crear una estrategia de IaC asistida por IA con validaciones automáticas.

Usar IA para generar README, guías de instalación, documentación de arquitectura, ADRs y manuales técnicos.

Crear documentación desde código real, comandos verificados y estructura del repositorio.

Evitar documentación generada que suena bien pero contiene comandos incorrectos.

Actualizar documentación después de cambios de API, migraciones, configuración o arquitectura.

Generar diagramas Mermaid, PlantUML o C4 con revisión técnica.

Crear resúmenes de módulos para onboarding.

Pedir a la IA que detecte inconsistencias entre documentación y código.

Generar changelogs y notas de release a partir de commits y PRs.

Crear documentación para soporte, QA, producto y desarrolladores.

Establecer ownership para mantener la documentación generada viva y fiable.

Usar IA para explorar alternativas arquitectónicas con trade-offs, costes, riesgos y dependencias.

Pedir comparativas entre patrones: monolito modular, microservicios, event-driven, serverless, hexagonal o clean architecture.

Generar ADRs con contexto, opciones, decisión, consecuencias y revisión futura.

Analizar dependencias entre módulos y proponer límites más claros.

Revisar acoplamientos, ciclos, duplicidades y responsabilidades mal ubicadas.

Usar IA para preparar diagramas de contexto, contenedores, componentes y secuencias.

Pedir evaluación de escalabilidad, seguridad, resiliencia, observabilidad y mantenibilidad.

Evitar decisiones arquitectónicas tomadas por IA sin debate técnico ni contexto de negocio.

Documentar supuestos y restricciones que la IA no puede conocer por sí sola.

Crear una práctica de arquitectura asistida donde la IA acelera análisis, pero no sustituye al arquitecto.

Usar IA para comprender sistemas antiguos, mapear dependencias y explicar flujos poco documentados.

Generar pruebas de caracterización antes de modificar código legacy.

Migrar versiones de frameworks, librerías, lenguajes o APIs por lotes pequeños.

Pedir planes de migración con riesgos, pasos, validaciones y rollback.

Detectar patrones obsoletos, código duplicado y zonas de mayor deuda.

Refactorizar módulos legacy con protección de tests y PRs revisables.

Generar documentación técnica de sistemas sin documentación actualizada.

Automatizar transformaciones repetitivas cuando el patrón es estable.

Evitar reescrituras completas propuestas por IA sin análisis de impacto.

Crear una hoja de ruta de modernización incremental asistida por IA.

Diferenciar trabajar con IA interactiva, agente de IDE, agente CLI y agente cloud.

Diseñar tareas autónomas con contexto, permisos, límites, comandos y criterio de finalización.

Revisar cómo un agente puede investigar, planificar, modificar, ejecutar pruebas y preparar un PR.

Controlar el alcance para evitar cambios excesivos o fuera de objetivo.

Definir checkpoints donde el agente debe pedir confirmación.

Configurar entornos sandbox para que el agente no opere sobre producción ni datos sensibles.

Revisar logs de sesión para entender qué hizo el agente y por qué.

Ejecutar varios agentes en paralelo solo cuando las tareas no se pisan entre sí.

Diseñar colas de tareas para agentes en equipos con backlog técnico grande.

Crear una política de uso de agentes autónomos según riesgo y criticidad.

Entender Model Context Protocol y enfoques equivalentes como forma de conectar asistentes con herramientas y datos.

Identificar herramientas útiles: repositorios, tickets, documentación, bases de datos, navegadores internos, observabilidad y APIs.

Configurar conectores con permisos mínimos necesarios.

Evitar dar a un agente acceso amplio a herramientas críticas sin auditoría.

Diseñar herramientas internas seguras para que la IA consulte información sin exponer secretos.

Crear acciones limitadas: buscar ticket, leer documentación, consultar estado de build, obtener logs o crear issue.

Separar herramientas de lectura y herramientas de escritura.

Registrar uso de herramientas para trazabilidad.

Probar conectores en entornos de práctica antes de producción.

Diseñar una arquitectura de IA conectada que aporte contexto sin comprometer seguridad.

Usar IA para convertir notas, reuniones, tickets o incidencias en historias de usuario y tareas técnicas.

Detectar ambigüedades, dependencias, criterios de aceptación incompletos y riesgos de alcance.

Generar escenarios BDD, ejemplos, casos límite y reglas de negocio.

Separar requisitos funcionales, no funcionales, técnicos, de seguridad y de operación.

Pedir a la IA que identifique preguntas pendientes antes de pasar a desarrollo.

Crear descomposición de épicas en features, historias y tareas.

Mantener trazabilidad entre necesidad, requisito, código, test y documentación.

Evitar aceptar requisitos inventados por IA cuando no aparecen en la fuente original.

Usar IA para preparar documentación funcional clara para negocio y QA.

Integrar este flujo con Jira, Azure Boards, Linear, GitHub Issues o herramientas equivalentes.

Diseñar sesiones de trabajo donde la IA actúa como copiloto, segundo par de ojos o generador de alternativas.

Definir turnos: humano plantea intención, IA propone, humano revisa, IA ajusta, humano valida.

Usar IA para explicar código a perfiles junior durante sesiones de pairing.

Pedir alternativas de implementación para debatir trade-offs en equipo.

Evitar que un desarrollador acepte código sin entenderlo.

Usar IA durante mob programming para acelerar boilerplate y liberar tiempo de discusión.

Crear dinámicas de aprendizaje donde la IA ayuda a practicar patrones, tests y refactorizaciones.

Establecer normas de equipo para cuándo se permite usar IA durante una sesión compartida.

Revisar cómo afecta la IA al mentoring, onboarding y transferencia de conocimiento.

Medir si el pairing con IA mejora calidad, velocidad y comprensión del equipo.

Definir qué código, datos, documentación y secretos pueden enviarse a herramientas de IA.

Clasificar repositorios según sensibilidad, cliente, regulación, propiedad intelectual y criticidad.

Elegir herramientas con controles empresariales adecuados para repositorios sensibles.

Revisar políticas de retención, entrenamiento, auditoría, permisos, logs y residencia de datos.

Establecer normas de uso: qué herramientas se permiten, para qué tareas y con qué restricciones.

Crear aprobación especial para código de seguridad, criptografía, autenticación, datos personales o sectores regulados.

Evitar subir credenciales, dumps, logs sensibles o información de cliente.

Documentar uso de IA cuando el proceso interno, cliente o regulación lo exige.

Crear un proceso de revisión de proveedores de IA para desarrollo.

Mantener una política viva porque herramientas, modelos y capacidades evolucionan rápidamente.

Medir impacto de IA más allá de líneas de código generadas.

Analizar lead time, cycle time, tiempo de PR, cobertura de tests, defectos, retrabajo y satisfacción del equipo.

Medir adopción por herramienta, tipo de tarea, perfil, proyecto y frecuencia de uso.

Separar productividad percibida de productividad real validada por entregables y calidad.

Detectar si la IA acelera codificación pero aumenta revisión, bugs o deuda técnica.

Comparar tareas con y sin IA en pilotos controlados.

Medir reducción de tiempo en onboarding, comprensión de legacy, documentación y generación de tests.

Crear dashboards de uso respetando privacidad y evitando vigilancia individual tóxica.

Usar métricas para mejorar prácticas, no para presionar a los desarrolladores.

Crear un informe de madurez AID con riesgos, beneficios, próximos pasos y prioridades.

Preparar a los equipos para pasar de “usar chats” a trabajar con una metodología AID.

Formar a desarrolladores en prompts, contexto, revisión, seguridad, testing y agentes.

Formar a perfiles no técnicos para convertir necesidades en tareas delegables a equipos técnicos con IA.

Evitar la división entre quienes usan IA sin control y quienes la rechazan por completo.

Crear comunidades internas de práctica para compartir prompts, workflows, errores y aprendizajes.

Definir champions por equipo para acompañar adopción.

Establecer normas de calidad: no se acepta código generado que no se entiende, prueba y revisa.

Usar casos reales de la empresa para demostrar valor y límites.

Integrar IA en onboarding de nuevos desarrolladores.

Crear una hoja de ruta de madurez: piloto, estándares, agentes, automatización, métricas y gobierno.

Detectar vibe coding sin validación, donde el equipo acepta cambios porque “parecen funcionar”.

Evitar PRs gigantes generados por IA que nadie puede revisar con rigor.

Rechazar tests generados solo para cubrir líneas sin validar comportamiento.

Evitar dependencias nuevas, frameworks o patrones introducidos sin justificación.

Detectar documentación generada que no se corresponde con el código real.

Evitar que la IA concentre conocimiento en prompts privados no compartidos.

Reconocer pérdida de aprendizaje en perfiles junior si solo aceptan respuestas.

Controlar alucinaciones sobre APIs internas, comandos, versiones o arquitectura.

Evitar automatizar tareas peligrosas sin permisos, sandbox y rollback.

Crear una lista interna de antipatrones AID y señales tempranas de uso irresponsable.

Evaluar madurez actual: herramientas, repositorios, testing, seguridad, documentación, CI/CD y cultura técnica.

Elegir casos piloto con valor alto y riesgo controlado: tests, documentación, bugs pequeños, legacy o onboarding.

Definir herramientas autorizadas, repositorios de prueba, responsables, métricas y criterios de éxito.

Crear instrucciones de repositorio, guías de prompting, checklists de revisión y políticas de seguridad.

Formar al equipo antes de abrir el uso en proyectos críticos.

Ejecutar pilotos comparando resultados, tiempo, calidad, defectos y experiencia del equipo.

Ajustar normas según aprendizajes reales.

Escalar a refactorización, agentes cloud, CI/CD, PR review, documentación y automatización interna.

Mantener revisión humana obligatoria en código generado o modificado por IA.

Crear un modelo operativo AID sostenible para toda la organización.

Seleccionar un repositorio de práctica, proyecto ficticio o código anonimizado con funcionalidad, tests, documentación y deuda técnica.

Crear contexto estructurado para la IA: arquitectura, comandos, estándares, restricciones, definición de done y zonas prohibidas.

Transformar un requisito funcional en una tarea delegable con criterios de aceptación y plan de validación.

Usar IA para analizar el código existente y proponer estrategia de implementación.

Generar o modificar código de forma controlada, manteniendo cambios pequeños y revisables.

Añadir tests unitarios, integración o contrato según riesgo de la funcionalidad.

Ejecutar lint, build, tests y revisión de seguridad antes de cerrar la tarea.

Pedir a la IA una revisión crítica del diff y contrastarla con revisión humana.

Generar documentación, changelog, notas técnicas y resumen de PR.

Presentar el flujo final AID con métricas, riesgos, controles, aprendizajes y propuesta de implantación en equipo real.