Evaluación de madurez del desarrollo asistido por IA

Descubre hasta qué punto tus ingenieros aprovechan realmente los asistentes de programación con IA.

Pruebe esta evaluación de salud en directo

¿Qué es una evaluación de madurez del desarrollo asistido por IA?

Muchos equipos de ingeniería tienen instalados asistentes de programación con IA, pero pocos han acordado cómo usarlos: cuánto contexto darles, con qué cuidado revisar lo que generan y qué nunca debe salir del código base. La Evaluación de madurez del desarrollo asistido por IA pide a tu equipo que valore 28 afirmaciones en siete áreas: adopción de herramientas, habilidades de prompting, validación de resultados, integración en el flujo de trabajo, seguridad y cumplimiento, intercambio de conocimiento y medición del impacto. Cada afirmación se valora en una escala de cinco etapas, de Ad hoc a Optimizado, con una opción de «no aplica» para los casos en que no encaje. Algunos ejemplos son Revisamos el código generado por IA con el mismo cuidado que el escrito por personas o Sabemos detectar cuándo un defecto se originó en código asistido por IA. Los resultados muestran dónde ayuda la IA, dónde añade riesgos que el equipo aún no ha abordado y dónde merecerá la pena invertir en formación o herramientas. Realízala cada trimestre para establecer una línea base y seguir la evolución de las prácticas de tu equipo.

Dimensiones

Adopción de herramientas

Hasta qué punto el equipo adopta, configura y mantiene al día las herramientas de programación con IA, y con qué criterio lo hace.

  • Cobertura de herramientas

    Usamos herramientas de programación con IA de forma constante en nuestro trabajo diario de desarrollo.

    1. Ad hocUnos pocos ingenieros experimentan con herramientas de IA; la mayoría nunca las toca.
    2. EmergenteAlgunos ingenieros usan herramientas de IA con regularidad, pero el uso es desigual en el equipo.
    3. DefinidoLa mayoría de los ingenieros recurre a la IA en tareas rutinarias; la adopción es amplia, aunque no universal.
    4. GestionadoLas herramientas de IA forman parte del flujo diario de casi todos los ingenieros, que eligen con sensatez la adecuada para cada tarea.
    5. OptimizadoLas herramientas de IA se usan de forma natural donde aportan y se evitan conscientemente donde no; el equipo comparte un criterio claro.

  • Calidad de la configuración

    Nuestras herramientas de IA están bien configuradas para nuestro código base, nuestros flujos de trabajo y el contexto del proyecto.

    1. Ad hocLas herramientas funcionan con la configuración por defecto, sin contexto, convenciones ni salvaguardas propias del proyecto.
    2. EmergenteAlgunos ingenieros ajustan su propia configuración; no hay nada compartido a nivel de equipo.
    3. DefinidoExiste una configuración de equipo (archivos de reglas, instrucciones, listas de exclusión) para la mayoría de las herramientas.
    4. GestionadoLa configuración está versionada, se revisa y se mantiene al día a medida que evoluciona el código base.
    5. OptimizadoLa configuración es un activo de primer nivel que se mide, se itera y se ajusta para lograr la máxima precisión en nuestro código.

  • Apoyo en la incorporación

    Las nuevas personas del equipo se ponen al día rápidamente con nuestras herramientas y prácticas de IA.

    1. Ad hocLas nuevas incorporaciones se las arreglan solas con las herramientas de IA, sin orientación, ejemplos ni un punto de partida común.
    2. EmergenteHay consejos informales de los compañeros, pero ningún material escrito.
    3. DefinidoExiste una guía documentada de configuración e inicio que está bastante actualizada.
    4. GestionadoLa incorporación incluye sesiones prácticas de IA, prompts de ejemplo y un compañero de referencia para las primeras dudas.
    5. OptimizadoLos nuevos ingenieros son productivos con nuestro flujo de trabajo con IA desde la primera semana y contribuyen a mejorar el material de incorporación.

  • Conocimiento de las herramientas

    Nos mantenemos informados sobre las nuevas capacidades de programación con IA y reevaluamos nuestro conjunto de herramientas.

    1. Ad hocNadie sigue los cambios en el ámbito de la programación con IA; usamos lo primero que adoptamos.
    2. EmergenteAlgunos ingenieros siguen el sector por su cuenta, pero lo que aprenden rara vez llega al equipo.
    3. DefinidoAlguien comparte novedades relevantes de vez en cuando; sabemos más o menos qué opciones existen.
    4. GestionadoEvaluamos periódicamente nuevas herramientas y funciones frente a nuestras necesidades y cambiamos cuando merece la pena.
    5. OptimizadoExploramos activamente y compartimos experimentos; las decisiones sobre herramientas son deliberadas y se basan en evidencias, no en modas.

Habilidades de prompting

Lo bien que se comunica el equipo con las herramientas de IA: prompts claros, buen contexto, refinamiento y tareas del tamaño adecuado.

  • Claridad de los prompts

    Describimos las tareas a las herramientas de IA con claridad y precisión.

    1. Ad hocLos prompts son frases sueltas y vagas; los resultados son impredecibles y a menudo inservibles.
    2. EmergenteAlgunos ingenieros redactan buenos prompts; otros lanzan peticiones poco elaboradas a la IA y esperan que salga bien.
    3. DefinidoLos prompts suelen incluir la intención, los datos de entrada y el resultado esperado; los resultados casi siempre dan en el blanco.
    4. GestionadoLos prompts son siempre claros y sin ambigüedades; el equipo tiene una idea compartida de cómo es un buen prompt.
    5. OptimizadoRedactar prompts se trata como una habilidad de primer nivel; los ingenieros obtienen resultados de alta calidad al primer o segundo intento.

  • Aporte de contexto

    Damos a las herramientas de IA el contexto adecuado (código, restricciones e intención) para que den lo mejor de sí.

    1. Ad hocLos ingenieros piden cosas sin compartir el código relacionado, las convenciones ni las restricciones; el resultado ignora la realidad.
    2. EmergenteSe aporta algo de contexto cuando es evidente; las restricciones menos obvias suelen pasarse por alto.
    3. DefinidoLos ingenieros incluyen habitualmente en sus prompts los archivos, tipos y restricciones relevantes.
    4. GestionadoEl aporte de contexto es deliberado; por defecto se dirige a las herramientas hacia los archivos, ejemplos y tests adecuados.
    5. OptimizadoEl contexto está seleccionado con cuidado: la IA ve lo suficiente para ser útil sin distraerse con lo que sobra, y el resultado encaja de forma natural en nuestro código.

  • Refinamiento iterativo

    Refinamos y reorientamos eficazmente las respuestas de la IA cuando el primer intento no acierta.

    1. Ad hocLos ingenieros aceptan lo que produzca la IA o lo descartan por completo; rara vez insisten para refinarlo.
    2. EmergenteHay algo de refinamiento, pero los ingenieros suelen empezar de cero en lugar de aprovechar lo que ya tienen.
    3. DefinidoLos ingenieros iteran sobre el resultado de la IA para cubrir carencias; las conversaciones son productivas y no dan vueltas en círculo.
    4. GestionadoEl refinamiento es rápido y certero; los ingenieros saben reorientar sin perder el hilo.
    5. OptimizadoLos ingenieros sacan el máximo partido a cada conversación; saben con soltura cuándo refinar, cuándo empezar de nuevo y cuándo dejar la IA a un lado y escribirlo ellos mismos.

  • Descomposición de tareas

    Dividimos el trabajo complejo en partes manejables para la IA que producen resultados fiables.

    1. Ad hocLos ingenieros le piden a la IA funcionalidades enteras y se decepcionan con el resultado.
    2. EmergenteAlgunos ingenieros dividen el trabajo de forma adecuada; otros piden demasiado de una vez.
    3. DefinidoLas tareas suelen limitarse a una función o a un cambio pequeño; el resultado es aprovechable.
    4. GestionadoLos ingenieros descomponen el trabajo de forma fiable en partes adecuadas para la IA y encadenan pasos cuando hace falta.
    5. OptimizadoLa descomposición es intuitiva; los ingenieros saben exactamente cómo dividir el trabajo para que la IA sea precisa y ellos mantengan el control.

Validación de resultados

El rigor con el que el equipo revisa, prueba y cuestiona el código generado por IA antes de confiar en él.

  • Rigor en la revisión de código

    Revisamos el código generado por IA con el mismo cuidado que el escrito por personas.

    1. Ad hocEl código generado por IA se acepta con poca o ninguna revisión; los defectos se cuelan.
    2. EmergenteLos revisores echan un vistazo al código generado por IA, pero sin examinarlo a fondo; detectan algunos problemas y se les escapan muchos.
    3. DefinidoEl código generado por IA se revisa con el mismo criterio que cualquier otro código.
    4. GestionadoLos revisores prestan especial atención a los fallos típicos de la IA (APIs inventadas, lógica que parece correcta pero no lo es).
    5. OptimizadoLas revisiones son igual de rigurosas e igual de rápidas; el equipo tiene criterios claros sobre en qué fijarse más.

  • Cobertura de tests

    Nuestro código generado por IA está respaldado por tests automatizados.

    1. Ad hocEl código escrito por IA se integra sin tests; los errores aparecen en producción.
    2. EmergenteLos tests se añaden de forma irregular; la cobertura del código de IA va por detrás del resto del código base.
    3. DefinidoSe espera que el código generado por IA se entregue con tests, y normalmente se cumple.
    4. GestionadoEscribir primero los tests es la práctica habitual con el código generado por IA; la cobertura es similar a la del resto del código base.
    5. OptimizadoLa IA redacta los casos de prueba y los ingenieros los refinan como flujo de trabajo por defecto; la cobertura del código de IA iguala o supera a la del resto del código base.

  • Evaluación crítica

    Cuestionamos y verificamos los resultados de la IA en lugar de aceptarlos sin más.

    1. Ad hocLos ingenieros confían en lo que genera la IA salvo que esté claramente roto; las alucinaciones sutiles se cuelan.
    2. EmergenteLos ingenieros se muestran escépticos al principio, pero tienden a aceptarlo en cuanto compila o se ejecuta.
    3. DefinidoLos ingenieros comprueban activamente afirmaciones, firmas de funciones y llamadas a librerías contra la documentación y los tipos reales.
    4. GestionadoEl equipo comparte una idea clara de cuándo la IA es fiable y cuándo no, y dedica el esfuerzo en consecuencia.
    5. OptimizadoLa evaluación crítica es automática; los ingenieros detectan alucinaciones y disparates dichos con aplomo sin perder ritmo.

  • Atribución de errores

    Sabemos detectar cuándo un defecto se originó en código asistido por IA.

    1. Ad hocLos defectos se corrigen sin que nadie pregunte de dónde vienen; el equipo no tiene ninguna señal sobre la contribución de la IA.
    2. EmergenteAlgún ingeniero detecta de vez en cuando un defecto introducido por la IA, pero el equipo no tiene una visión compartida.
    3. DefinidoLos defectos relevantes atribuibles a la IA se señalan en los post mortem o las retrospectivas cuando aparecen.
    4. GestionadoEl equipo puede determinar de forma fiable, a posteriori, si un defecto procede o no de la asistencia de IA.
    5. OptimizadoLa atribución a la IA es un criterio claro y compartido en cada defecto importante; el equipo tiene una imagen honesta del efecto de la IA en la calidad.

Integración en el flujo de trabajo

Con qué naturalidad encaja la asistencia de IA en los hábitos diarios, las herramientas, los procesos del equipo y el equilibrio entre personas e IA.

  • Hábito diario

    La asistencia de IA forma parte natural de nuestro trabajo diario de ingeniería.

    1. Ad hocLa asistencia de IA es una novedad que se usa de vez en cuando; no forma parte de cómo trabajan realmente los ingenieros.
    2. EmergenteAlgunos ingenieros recurren a la IA a diario; otros, casi nunca.
    3. DefinidoLa mayoría de los ingenieros usa la IA en su flujo normal varias veces al día.
    4. GestionadoLa asistencia de IA está totalmente integrada en el trabajo diario; los ingenieros también saben cuándo prescindir de ella.
    5. OptimizadoEl equipo trabaja con un ritmo deliberado entre personas e IA: usa la IA donde aporta valor y confía en su propio criterio donde no.

  • Encaje en el pipeline

    Las herramientas de IA encajan sin fricciones en nuestro entorno de desarrollo y en nuestro pipeline de CI/CD.

    1. Ad hocEl uso de la IA queda totalmente fuera del pipeline; los resultados se pegan a mano y la fricción es alta.
    2. EmergenteLas herramientas de IA funcionan en los editores, pero se quedan a las puertas del CI/CD; la integración es superficial.
    3. DefinidoLa IA está integrada en los editores y en la revisión de código; hay puntos de contacto con el CI/CD para los casos habituales.
    4. GestionadoLas herramientas de IA encajan en toda la cadena de herramientas (IDE, revisión, CI e incluso respuesta a incidentes).
    5. OptimizadoLa integración en el pipeline es invisible: la asistencia de IA aparece donde es útil y no estorba en el resto.

  • Adaptación de procesos

    Hemos adaptado nuestros procesos para sacar el máximo partido al desarrollo asistido por IA.

    1. Ad hocLos procesos son los mismos que antes de la IA; el equipo usa la IA dentro de un flujo de trabajo antiguo.
    2. EmergentePequeños ajustes en las dailies o las revisiones para hablar de la IA; nada estructural.
    3. DefinidoSe han incorporado prácticas concretas (foco en la revisión, prompting en pareja, intercambio de prompts) a la forma de trabajar del equipo.
    4. GestionadoEl proceso del equipo se diseña activamente en torno a la asistencia de IA y se revisa con regularidad.
    5. OptimizadoEl proceso y la IA evolucionan juntos; los cambios se prueban, se mantiene lo que funciona y se descarta lo que no.

  • Equilibrio entre personas e IA

    Sabemos cuándo apoyarnos en la IA y cuándo confiar en nuestro propio criterio.

    1. Ad hocLos ingenieros o confían demasiado en la IA (y entregan sus errores) o se niegan a usarla (y desaprovechan lo que aporta).
    2. EmergenteLos ingenieros van descubriendo el límite caso por caso; las decisiones son incoherentes.
    3. DefinidoLa mayoría de los ingenieros tiene un criterio sensato sobre cuándo ayuda la IA y cuándo no.
    4. GestionadoEl equipo tiene criterios compartidos y explícitos sobre qué trabajo corresponde a las personas y cuál a la IA; los nuevos ingenieros los asimilan rápido.
    5. OptimizadoEl equilibrio es algo natural; los ingenieros pasan de un modo a otro con soltura y hablan abiertamente del límite.

Seguridad y cumplimiento

Lo bien que el equipo protege los datos sensibles, cumple las políticas y gestiona los riesgos de propiedad intelectual, licencias y seguridad del código generado por IA.

  • Tratamiento de datos

    Evitamos exponer información sensible o confidencial a las herramientas de IA.

    1. Ad hocLos ingenieros pegan cualquier cosa en las herramientas de IA (secretos, datos de clientes, código propietario) sin pensarlo.
    2. EmergenteLa mayoría de los ingenieros sabe que no debe pegar secretos, pero aún hay errores con datos menos evidentes (datos personales, diseños internos).
    3. DefinidoHay reglas claras sobre qué puede y qué no puede enviarse a las herramientas de IA, y los ingenieros suelen cumplirlas.
    4. GestionadoLos flujos de datos aprobados se conocen bien, están respaldados por herramientas (anonimización, listas de permitidos) y se refuerzan en las revisiones.
    5. OptimizadoLa exposición de datos sensibles a las herramientas de IA se impide estructuralmente, no solo se desaconseja; el equipo puede describir los controles con seguridad.

  • Cumplimiento de políticas

    Seguimos de forma sistemática las políticas de uso de IA de la organización.

    1. Ad hocLos ingenieros desconocen la política de IA de la organización o se la saltan deliberadamente.
    2. EmergenteLa política existe, pero se sigue a medias; a veces los ingenieros usan herramientas no aprobadas.
    3. DefinidoLos ingenieros conocen las reglas y las respetan en lo que importa.
    4. GestionadoLa política está presente en los flujos de trabajo (listas de herramientas aprobadas, plugins del IDE) y cumplirla es lo más sencillo.
    5. OptimizadoEl equipo comparte la responsabilidad de la política; las carencias y fricciones se trasladan a quien la mantiene en lugar de sortearlas.

  • Conciencia sobre propiedad intelectual y licencias

    Entendemos los riesgos de propiedad intelectual y de licencias del código generado por IA.

    1. Ad hocLos ingenieros no se plantean de dónde procede el código generado por IA ni qué implicaciones de licencia conlleva.
    2. EmergenteHay cierta conciencia, pero no se actúa; al equipo le costaría responder a las preguntas de un auditor.
    3. DefinidoLos ingenieros conocen lo básico (tipo de licencia de las sugerencias, normas de atribución) y evitan los riesgos evidentes.
    4. GestionadoLas comprobaciones de propiedad intelectual y licencias forman parte de la revisión; el equipo puede defender su postura de forma creíble si se le pregunta.
    5. OptimizadoLa propiedad intelectual y las licencias son una parte explícita y con responsable de cómo se entrega el código asistido por IA; los controles y las excepciones están documentados.

  • Vigilancia de vulnerabilidades

    Revisamos activamente el código generado por IA en busca de problemas de seguridad.

    1. Ad hocEl código generado por IA llega a producción sin revisión de seguridad; los ingenieros dan por hecho que está bien porque funciona.
    2. EmergenteLos analizadores estáticos detectan los problemas evidentes; los revisores rara vez van más allá.
    3. DefinidoLos revisores buscan activamente fallos de seguridad habituales en el código generado por IA (inyecciones, secretos, configuraciones por defecto inseguras).
    4. GestionadoEl equipo tiene claro dónde la asistencia de IA aumenta el riesgo de seguridad y aplica un escrutinio adicional en esos puntos.
    5. OptimizadoLos patrones de vulnerabilidad introducidos por la IA se registran, se incorporan a los prompts y a las listas de revisión, y rara vez se repiten.

Intercambio de conocimiento

Con qué apertura el equipo recopila prompts, comparte éxitos y fracasos, colabora con otros equipos y desarrolla sus habilidades con IA.

  • Bibliotecas de prompts

    Documentamos y compartimos los prompts y patrones de IA que funcionan.

    1. Ad hocCada ingeniero reinventa los mismos prompts; no se comparte nada.
    2. EmergenteDe vez en cuando alguien pega un prompt útil en el chat y vuelve a perderse.
    3. DefinidoUn espacio compartido (repositorio, wiki, archivo) reúne prompts y patrones; la gente contribuye y lo consulta.
    4. GestionadoLa biblioteca está cuidada, actualizada y se usa como punto de partida para las tareas habituales.
    5. OptimizadoLos prompts compartidos evolucionan con el código base; la biblioteca es un verdadero activo de productividad que evita retrabajo de forma demostrable.

  • Cultura de aprendizaje

    Compartimos abiertamente éxitos, fracasos y experimentos con el desarrollo asistido por IA.

    1. Ad hocLos ingenieros no hablan de cómo usan la IA; los éxitos y los fracasos quedan en privado.
    2. EmergenteSe comparte algo por canales paralelos (mensajes privados, comentarios de pasada); nada estructurado.
    3. DefinidoLas experiencias con IA salen en retrospectivas, demos o dailies; se comentan tanto los éxitos como los fallos.
    4. GestionadoCompartir es un ritmo habitual del equipo, con sesiones, documentos o puntos recurrentes en la agenda.
    5. OptimizadoEl equipo tiene una auténtica cultura de curiosidad en torno a la IA; los fracasos se valoran como aprendizaje, no se buscan culpables.

  • Colaboración entre equipos

    Intercambiamos prácticas de programación con IA con personas de fuera de nuestro equipo.

    1. Ad hocNuestras prácticas de IA se quedan dentro del equipo; no sabemos qué hacen otros equipos.
    2. EmergenteDe vez en cuando hay conversaciones informales con otros equipos, pero no un intercambio real.
    3. DefinidoLos ingenieros comparten notas con otros equipos cuando importa; los patrones útiles circulan.
    4. GestionadoExisten foros o comunidades de práctica entre equipos sobre IA, con una participación real.
    5. OptimizadoEl equipo aporta y aprende continuamente de otros equipos; la práctica con IA se extiende con un efecto bola de nieve.

  • Desarrollo de habilidades

    Invertimos de forma deliberada en mejorar nuestras habilidades de desarrollo asistido por IA.

    1. Ad hocLa mejora de habilidades es accidental; los ingenieros solo mejoran cuando por casualidad prueban algo nuevo.
    2. EmergenteHay algunas personas que aprenden por iniciativa propia; la mayoría se queda en el nivel con el que llegó.
    3. DefinidoEl equipo dedica algo de tiempo explícito a mejorar sus habilidades con IA (sesiones, trabajo en pareja, lectura).
    4. GestionadoEl desarrollo de habilidades es una inversión habitual; las nuevas técnicas se prueban, se evalúan y se adoptan en equipo.
    5. OptimizadoEl crecimiento continuo y deliberado forma parte de la identidad del equipo; los ingenieros mejoran visiblemente en el trabajo asistido por IA cada trimestre.

Medición del impacto

Con qué honestidad el equipo mide el efecto de la IA en la productividad y la calidad, e incorpora esas lecciones a su forma de trabajar.

  • Seguimiento de la productividad

    Evaluamos si las herramientas de IA mejoran realmente nuestra velocidad de entrega.

    1. Ad hocNadie sabe si la IA nos hace más rápidos o más lentos; damos por hecho que ayuda.
    2. EmergenteSe habla de productividad a partir de impresiones; no hay más señal que las anécdotas.
    3. DefinidoEl equipo sigue algunos indicadores (tiempo de ciclo, volumen de PR) junto con la adopción de la IA.
    4. GestionadoEl impacto en la productividad se mide de forma deliberada; el equipo puede describir el efecto de la IA con evidencias.
    5. OptimizadoEl seguimiento de la productividad es honesto con las ganancias y las pérdidas; el equipo ajusta el uso de la IA según lo que muestran los datos.

  • Métricas de calidad

    Evaluamos si la asistencia de IA mejora o empeora la calidad de nuestro trabajo.

    1. Ad hocNo hay visibilidad sobre cómo afecta la IA a la tasa de defectos, a las idas y vueltas en las revisiones o a la mantenibilidad.
    2. EmergenteLos ingenieros notan patrones de calidad de forma anecdótica; no hay una señal compartida.
    3. DefinidoEl equipo sigue indicadores de calidad (tasa de defectos, retrabajo, comentarios de revisión) en relación con el uso de la IA.
    4. GestionadoEl impacto en la calidad forma parte de cómo el equipo piensa en la IA; se ven tanto los efectos positivos como los negativos.
    5. OptimizadoLa calidad es un criterio de primer nivel en el uso de la IA; el equipo ha cambiado sus prácticas a partir de lo que ha descubierto.

  • Integración en las retrospectivas

    Reflexionamos sobre el desarrollo asistido por IA en nuestras retrospectivas.

    1. Ad hocEl uso de la IA nunca sale en las retrospectivas; queda fuera de la reflexión del equipo.
    2. EmergenteLa IA se menciona de vez en cuando en las retrospectivas, normalmente como un comentario aislado.
    3. DefinidoLa IA es un tema recurrente en las retrospectivas; el equipo lo trata cuando importa.
    4. GestionadoLas retrospectivas sacan a la luz de forma sistemática observaciones sobre la IA y las convierten en acciones.
    5. OptimizadoEl uso de la IA es un enfoque habitual en las retrospectivas; las conclusiones se traducen rápidamente en cambios de práctica.

  • Mejora continua

    Ajustamos nuestro uso de la IA según el feedback, los resultados y las lecciones aprendidas.

    1. Ad hocNuestra forma de usar la IA no cambia; funcionamos por el primer instinto.
    2. EmergenteAjustes ocasionales por la frustración de alguien o por un buen consejo llegado de fuera.
    3. DefinidoEl equipo revisa sus prácticas de IA con regularidad; los cambios se mantienen cuando demuestran su valor.
    4. GestionadoLa mejora es un ciclo real (medir, ajustar, volver a medir) y el equipo puede señalar cambios concretos que ha hecho.
    5. OptimizadoLa mejora continua de las prácticas con IA forma parte de cómo funciona el equipo; nada en nuestro uso de la IA es estático.

Cuándo debe realizarse esta revisión médica

  • Cuando tu equipo ya ha adoptado asistentes de programación con IA y quiere una línea base honesta de lo bien que los utiliza.
  • Antes de fijar objetivos o invertir en herramientas, formación o gobernanza de IA.
  • Cuando el código generado por IA plantea dudas sobre calidad, seguridad o rigor en la revisión que el equipo quiere abordar abiertamente.
  • Como punto de control trimestral para seguir la evolución de vuestras prácticas de desarrollo asistido por IA.
  • En una retrospectiva o una jornada fuera de la oficina, para hablar con franqueza de dónde ayuda la IA y dónde añade riesgos.

Consejos y trucos

  • Pide que cada persona valore por su cuenta antes de debatir, para que afloren las diferencias reales de percepción y no el pensamiento de grupo.
  • Empieza la puesta en común por las dimensiones con mayor dispersión de puntuaciones. El desacuerdo suele señalar la conversación que más necesitáis.
  • Trata los niveles de madurez como un lenguaje común, no como una nota. Una valoración honesta es más útil que una alta.
  • Elige una o dos dimensiones en las que actuar entre sesiones en lugar de intentar mejorarlo todo a la vez.
  • Repite la evaluación cada trimestre y compara los resultados para ver si los cambios están funcionando.
  • Usa la opción «No aplica» sin reparos. No todas las dimensiones son relevantes para todos los equipos o etapas.
  • Para analizar el uso de la IA más allá del código, utiliza la Evaluación de madurez en IA para equipos.

Preguntas frecuentes

¿Quién debería participar en este health check?
Cualquier persona que escriba, revise o entregue código con ayuda de la IA, normalmente todo el equipo de ingeniería, incluidos los líderes. Contar con distintos niveles de experiencia da una imagen más honesta que preguntar solo a los entusiastas o solo a los escépticos.
¿Cómo se estructuran los niveles de madurez?
Cada dimensión se valora en cinco etapas: Ad hoc, Emergente, Definido, Gestionado y Optimizado. Las etapas describen lo sistemáticas y deliberadas que son las prácticas del equipo, no cuántas herramientas utiliza.
¿Una puntuación más alta es siempre mejor?
Los niveles más altos indican prácticas más maduras, pero la conversación y las acciones que surgen de ella importan más que la cifra. Un equipo con una puntuación modesta que habla de ella con honestidad saca más provecho que otro que persigue un resultado perfecto.
¿Con qué frecuencia deberíamos realizarlo?
Cada trimestre es lo adecuado para la mayoría de los equipos: con la frecuencia suficiente para seguir el progreso y con tiempo entre sesiones para que haya cambios reales. También conviene realizarlo después de un cambio importante en las herramientas o los procesos.
¿Qué hacemos con los resultados?
Usa la dispersión de las puntuaciones para ver en qué está de acuerdo el equipo y en qué no, elige una o dos dimensiones y conviértelas en acciones concretas. Repite la evaluación más adelante para comprobar si esas acciones han mejorado las puntuaciones.
¿Qué es un modelo de madurez en programación con IA?
Es un marco para valorar las prácticas de desarrollo asistido por IA de un equipo de ingeniería en una escala de cinco etapas, de Ad hoc a Optimizado. Este cubre la adopción de herramientas, el prompting, la validación de resultados, la integración en el flujo de trabajo, la seguridad, el intercambio de conocimiento y la medición del impacto.

Revisiones médicas relacionadas