Niveles de desarrollo con IA: del autocompletado al autónomo

Todo desarrollador que trabaja hoy con herramientas de IA ha oído la misma promesa vaga: «La IA te hace más productivo». Lo que casi nadie explica es cómo es realmente esa progresión: qué cambia en cada paso, cómo sabes dónde estás y qué tienes que hacer concretamente de otra manera para llegar al siguiente nivel. El resultado son desarrolladores que llevan dos años «usando IA», pero que no han avanzado de forma significativa más allá de usarla como un autocompletado más rápido.

Dan Shapiro presentó un marco que traza esta progresión como una escalera de seis niveles: desde la IA como una tecla Tab más inteligente hasta la IA como un sistema totalmente autónomo que construye y publica. Nate lo amplió con ejemplos reales de StrongDM y de las propias prácticas de desarrollo de Anthropic. En Big Hat Group hemos aplicado este marco con clientes empresariales para ayudarles a evaluar dónde están realmente sus equipos, y para añadir lo que faltaba: la capa prescriptiva. No solo «este es el nivel», sino «así es exactamente como avanzas al siguiente».

El marco: un mapa rápido

Los seis niveles describen un espectro de delegación del humano a la IA. A medida que subes por la escalera, la IA asume más trabajo de implementación, y el rol del desarrollador pasa de construir a dirigir, luego de dirigir a especificar y después de especificar a evaluar resultados.

La mayoría de los desarrolladores que leen esto opera en algún punto entre el Nivel 1 y el Nivel 3. Así puedes saber en cuál estás y qué hacer a continuación.

Nivel 0 — Autocompletado con picante

Cómo se ve: Usas GitHub Copilot, Cursor o las sugerencias en línea de Claude, pero la interacción es básicamente esta: aparece la sugerencia, la descartas y escribes a mano algo parecido a lo que se te sugirió. Quizá aceptas tal cual un 20–30 % de las sugerencias. Tratas cada sugerencia como un primer borrador que hay que editar antes de poder confiar en él.

Señales de que estás aquí:

• Vuelves a escribir sugerencias que son casi correctas, pero no del todo
• Has descartado sugerencias más rápido de lo que podías leerlas
• Alguna vez has desactivado el autocompletado porque te parecía «ruido»
• Tu interacción diaria con la IA se mide en minutos, no en horas

El techo: En el Nivel 0, la IA aporta aproximadamente un 15–20 % de mejora de productividad: real, pero modesta. La calidad del modelo está limitada por el contexto que recibe, y en este nivel no le das mucho contexto más allá del archivo actual. Estás dejando sin usar el 80 % del valor potencial.

Cómo avanzar:

1. Acepta primero, edita después. Entrénate para aceptar la sugerencia y luego corregir lo que esté mal. El objetivo es ser más rápido evaluando sugerencias, no escribiendo alrededor de ellas.
2. Confía en el modelo con los nombres. Nombres de variables, firmas de funciones, nombres de pruebas: las sugerencias del modelo suelen ser tan buenas como las tuyas. Deja de cuestionarlas.
3. Usa sugerencias de varias líneas. Si tu herramienta lo admite (Cursor, Copilot Next Edit Suggestions), deja que el modelo complete el cuerpo entero de una función antes de decidir si lo aceptas o lo descartas.

Nivel 1 — Becario de programación

Cómo se ve: Has empezado a usar interfaces de chat o herramientas agénticas (Claude, Codex, el modo agente de Cursor) para tareas de programación concretas. Le pasas a la IA un único trabajo muy acotado («escribe una función que haga X» o «corrige este bug concreto en este archivo») y luego revisas cada línea antes de aceptarlo. Tu tasa de corrección es alta. Tratas la salida de la IA igual que tratarías el código de un desarrollador júnior en quien todavía no confías.

Señales de que estás aquí:

• Pegas el contenido completo de archivos en el prompt para darle a la IA suficiente contexto
• Tus prompts incluyen instrucciones detalladas paso a paso porque no confías en que la IA tome decisiones razonables
• Dedicas tanto tiempo a revisar la salida como el que habrías dedicado a escribirla tú mismo
• Trabajar con un solo archivo te parece seguro; trabajar con varios archivos te incomoda

El techo: Tú eres el cuello de botella. Cada tarea requiere que la delimites con bastante detalle antes de que se escriba una sola línea de código. La IA no puede construir sobre su trabajo anterior dentro de una sesión porque cada tarea se trata de forma aislada. Estás obteniendo valor real, pero estás limitado por la rapidez con la que puedes escribir prompts y revisar la salida.

Cómo avanzar:

1. Crea un CLAUDE.md o un agents.md para tu proyecto. Es un documento de contexto que codifica tus convenciones, patrones y restricciones una sola vez, para que no tengas que repetirlos en cada prompt. La precisión de la IA en tu código base mejora drásticamente cuando dispone de este contexto.
2. Practica la descomposición de tareas. Divide una funcionalidad en 3–4 tareas secuenciales, entrégalas de una en una y revisa el diff entre el estado inicial y el final, no cada paso intermedio.
3. Lleva tu revisión a los diffs. En lugar de leer el archivo de salida de arriba abajo, mira qué ha cambiado. Es más rápido y detecta lo que de verdad importa.

Nivel 2 — Desarrollador júnior

Cómo se ve: Delegas cambios que abarcan varios archivos. Le das a la IA una funcionalidad o una corrección de bug que afecta a varios archivos y genera un PR. Revisas ese PR línea por línea antes de fusionarlo. Tu uso de la IA ha cruzado un umbral (produces más código del que podrías escribir tú solo), pero la revisión se está convirtiendo en el nuevo cuello de botella.

Señales de que estás aquí:

• Le das a la IA de forma habitual tareas que tocan entre 5 y 10 archivos
• Sigues leyendo cada diff línea por línea antes de aceptar un PR
• Te descubres corrigiendo cosas que no están mal, sino que simplemente son distintas de como las habrías hecho tú
• Tu rendimiento ha subido, pero también tu carga de revisión: crecen a la vez

El techo: El tiempo de revisión crece con la producción. La IA es más rápida que tú, y tu cuello de botella ha pasado de escribir a revisar. La revisión línea por línea de la salida de la IA suele ser redundante: los errores del modelo son estructurales y arquitectónicos, no sintácticos. Leer cada línea es caro y detecta el tipo de error equivocado.

Cómo avanzar:

1. Pasa a la revisión semántica. Pregúntate «¿hace este PR lo que decía la especificación?» en lugar de «¿es correcta cada línea?». Lo que importa son las carencias estructurales y arquitectónicas; el modelo maneja la sintaxis de forma fiable.
2. Añade un paso de revisión de código con IA. Usa el comando /code-review de Claude o un agente de revisión de PR. Deja que la IA revise la salida de la IA: detecta problemas estructurales sin tener que leer cada línea tú mismo.
3. Invierte ya en cobertura de pruebas. El paso al Nivel 3 exige confiar en las pruebas como tu principal red de seguridad. Si tu cobertura es demasiado escasa para detectar regresiones, ese es el requisito previo que debes resolver antes de avanzar.

Nivel 3 — Desarrollador como Manager

Cómo se ve: Revisas a nivel de funcionalidad, no de línea. Escribes especificaciones lo bastante claras para que el agente las ejecute sin que estés encima. Tú eres el arquitecto; el agente es el implementador. La mayor parte de tu tiempo se va en escribir especificaciones, tomar decisiones de arquitectura y hacer revisiones de código de alto nivel, no en implementar.

Señales de que estás aquí:

• Rara vez miras el contenido de archivos individuales durante la implementación: esperas al resumen del PR
• Tus prompts describen resultados, no pasos
• Has empezado a preocuparte más por la cobertura de pruebas que por el enfoque concreto de implementación
• Cuando algo sale mal, tu instinto es corregir la especificación, no corregir el código a mano

El techo: La calidad es ahora una función directa de la calidad de la especificación. Las especificaciones vagas o incompletas generan retrabajo. Además, sigues siendo el revisor principal, lo que limita el rendimiento a escala. El cuello de botella se ha desplazado de nuevo: ya no se trata de leer código, sino de evaluar si una funcionalidad entregada coincide realmente con la intención.

Cómo avanzar:

1. Crea una plantilla de especificación que te obligue a definir criterios de aceptación, casos límite y requisitos de pruebas antes de delegar una tarea. La disciplina de la plantilla es lo que hace que la salida de la IA sea coherente.
2. Integra agentes de revisión de código automatizada en CI. Un segundo revisor que se ejecuta en cada PR detecta problemas estructurales antes de que tú revises, y detecta cosas que se te escaparían cuando vas rápido.
3. Define los requisitos de pruebas en la propia especificación. «Esta funcionalidad está terminada cuando se superan [escenarios de prueba concretos]» traslada la barrera de calidad de tu criterio a criterios objetivos y auditables.

Nivel 4 — Desarrollador como PM

Cómo se ve: El código es una caja negra. La especificación y las pruebas son tus interfaces con él. Escribes requisitos y criterios de aceptación; el agente construye la funcionalidad y la verifica frente a ellos. Compruebas si las pruebas se superan, no si el código tiene buen aspecto. Tus artefactos principales son especificaciones y planes de prueba.

Señales de que estás aquí:

• Rara vez (o nunca) abres los archivos de implementación durante una tarea
• Tus especificaciones se parecen más a requisitos de producto que a diseños técnicos
• Tu definición de «terminado» es «las pruebas se superan y se cumplen los requisitos», no «he revisado el PR»
• Mides la salida del agente por criterios de aceptación de funcionalidades, no por métricas de calidad del código

El techo: En el Nivel 4, la cobertura de pruebas lo es todo. Tus puntos ciegos en las pruebas se convierten en tus puntos ciegos en las funcionalidades publicadas. Sin una cobertura exhaustiva (incluidos casos límite, escenarios de integración y pruebas de rendimiento), la calidad no es alta: es imposible de medir. Un segundo riesgo: la deriva arquitectónica. La IA toma decisiones correctas a nivel local que se acumulan en problemas sistémicos que no verás porque no estás leyendo el código.

Cómo avanzar:

1. Invierte en suites de pruebas automatizadas exhaustivas: unitarias, de integración y de extremo a extremo. Las pruebas de mutación son valiosas aquí: encuentran carencias en la calidad de la cobertura, no solo en la cantidad de cobertura.
2. Define métricas de resultado para las funcionalidades: tasas de error, umbrales de rendimiento, tasas de éxito de cara al usuario. Te preparan para el modelo de evaluación de resultados del Nivel 5.
3. Añade puntos de control de revisión arquitectónica. Incluso en el Nivel 4, programa revisiones periódicas del estado arquitectónico del sistema para detectar la deriva antes de que se agrave.

Nivel 5 — Fábrica Oscura

Cómo se ve: Escribes una especificación y por el otro lado sale un artefacto verificado y desplegable. El humano no está en el ciclo de implementación ni de revisión durante el funcionamiento normal. El sistema construye, prueba y publica basándose en barreras de calidad automatizadas. Tú evalúas los resultados y ajustas el sistema; no interactúas con funcionalidades individuales durante la construcción.

Cuándo es apropiado y cuándo no: La fábrica oscura funciona en dominios estrechos y bien acotados, con una cobertura de pruebas existente profunda y métricas de resultado claras y medibles. No es apropiada para funcionalidades nuevas con criterios de aceptación poco claros, para entornos regulados sin verificación automatizada del cumplimiento normativo, ni para ningún dominio en el que los fallos no se detecten con pruebas antes de llegar a producción. El modo de fallo de un sistema de Nivel 5 mal instrumentado no es una entrega lenta: es la entrega rápida de cosas equivocadas.

Lo innegociable:

• Observabilidad. Si no puedes ver qué ha construido el sistema y cómo está funcionando, has perdido por completo el ciclo de retroalimentación. El registro, el trazado y las alertas son requisitos previos, no complementos.
• Reversión automatizada. Un despliegue automatizado sin reversión automatizada es un riesgo, no una mejora de eficiencia.
• Medición de resultados. El ciclo de especificación a resultado es tu única señal de calidad en el Nivel 5. Si no está instrumentado, el sistema vuela a ciegas.

La mayoría de los equipos empresariales debería apuntar al Nivel 3–4. El Nivel 5 es una inversión específica de cada dominio con requisitos de infraestructura significativos. Avanzar hasta él antes de tener los requisitos previos implantados es peor que quedarse en el Nivel 3.

Qué significa esto para los líderes de ingeniería

La estructura del equipo cambia en cada nivel. En los Niveles 0–1, no cambia gran cosa en la forma en que se organizan tus equipos: los desarrolladores son dueños de la implementación y la IA ayuda. En el Nivel 2, necesitas invertir en infraestructura de pruebas y herramientas de revisión. En el Nivel 3, la combinación de capacidades empieza a cambiar: necesitas desarrolladores capaces de escribir especificaciones claras y completas tanto como desarrolladores capaces de escribir código limpio. En el Nivel 4, contratas por habilidades de pensamiento de producto: redacción de criterios de aceptación, arquitectura de pruebas, definición de resultados. En el Nivel 5, estás operando un sistema.

La implicación para la contratación es real. A medida que los equipos avanzan del Nivel 2 hacia el Nivel 4, se necesitan menos implementadores puros y más desarrolladores fuertes en especificación y arquitectura. El desarrollador capaz de escribir una especificación que una IA ejecuta sin fallos es más valioso en una organización nativa de IA que uno que puede implementar esa especificación a mano. No se trata de reducir plantilla, sino de la combinación de capacidades y del perfil de contratación.

Los Niveles 4–5 sin infraestructura de pruebas son un riesgo, no una mejora de eficiencia. Los equipos que llevan su flujo de trabajo humano al Nivel 4 sin la correspondiente inversión en cobertura de pruebas están sacando al revisor del ciclo sin añadir una barrera de calidad que lo sustituya. El resultado es una producción más rápida con una calidad sin medir. Eso es un paso atrás respecto al Nivel 1, no hacia delante.

La brecha de productividad acumulativa es real. Las organizaciones que hoy están en el Nivel 1 se enfrentan a una desventaja acumulativa frente a los equipos nativos de IA en el Nivel 3. La brecha no es lineal: se acumula porque los equipos de nivel superior asumen tareas más grandes más rápido, invierten en mejor infraestructura y avanzan más. Cada trimestre la brecha crece. El momento de cerrarla es ahora.

Tu plan de avance de 30 días

1. Evalúa tu nivel actual con honestidad. Usa las descripciones de «Señales de que estás aquí» anteriores, no estimaciones autodeclaradas. Las señales son conductuales y observables; úsalas.
2. Elige un hábito de la sección «Cómo avanzar» de tu nivel actual y practícalo de forma constante durante dos semanas. Un hábito bien ejecutado vale más que tres adoptados a medias.
3. Instrumenta tu proceso de revisión. Registra el tiempo dedicado a cada PR y qué porcentaje es revisión a nivel de línea frente a nivel de funcionalidad. Los datos mostrarán exactamente dónde estás atascado.
4. Identifica tu carencia de cobertura de pruebas. Es el cuello de botella oculto que impide a la mayoría de los equipos avanzar del Nivel 2 al Nivel 3. No puedes confiar en las pruebas como red de seguridad hasta que la cobertura sea real.
5. Consigue una hoja de ruta. Big Hat Group ayuda a equipos empresariales a evaluar su nivel actual de desarrollo con IA, identificar qué les impide avanzar y construir las herramientas, la infraestructura de pruebas y los marcos de gobernanza que hacen sostenible la transición.

Consultoría empresarial de desarrollo con IA

Big Hat Group trabaja con equipos de ingeniería empresariales para hacer avanzar sus prácticas de desarrollo con IA: desde evaluar los niveles actuales de los distintos equipos hasta implantar las herramientas agénticas, las plantillas de especificación y la infraestructura de pruebas que consolidan ese avance.

Contáctanos para iniciar tu evaluación de desarrollo con IA →

Relacionado: Claude Code vs Codex vs Gemini CLI: guía empresarial · El estándar agents.md para la programación con IA en la empresa