Cómo usar la IA para programar como un senior (no como un junior)

Uso IA para programar todos los días — en codebases reales, con millones de usuarios encima. Y lo que veo en 2026 es una brecha que se agranda: la IA hace que los buenos ingenieros produzcan mucho más, y que los que no entienden lo que pegan se estanquen más rápido que nunca.

La diferencia no es la herramienta. Es el criterio con el que la usas.

El junior le pide código. El senior le da una especificación.

El uso junior de la IA es: 'hazme una función que haga X', copiar, pegar, rezar. El uso senior es spec-driven: el prompt es una especificación técnica con contexto, restricciones y criterio de aceptación. La diferencia en el resultado es brutal.

Un prompt spec-driven tiene cuatro partes:

1. Contexto: qué es el proyecto, qué stack, qué convenciones sigue el código existente.
2. Tarea acotada: qué debe hacer exactamente, con entradas y salidas concretas.
3. Restricciones: qué NO debe hacer — no agregar dependencias, no tocar tal módulo, mantener el patrón existente.
4. Criterio de aceptación: cómo se verifica que quedó bien — casos borde incluidos.

Revisar a la IA como revisas un PR

El código que genera la IA es un pull request de un desarrollador muy rápido, muy seguro de sí mismo, y sin ningún contexto de tu negocio. Lo revisas igual que a un humano — con tres preguntas:

• ¿Qué caso borde ignoró? La IA optimiza el happy path. Entradas vacías, nulos, duplicados, concurrencia: ahí vive el bug sutil que te va a explotar en producción.
• ¿Qué se inventó? Dependencias que no existen, APIs con firma incorrecta, métodos que suenan plausibles. Verifica cada import que no reconozcas.
• ¿Rompe mis boundaries? La IA no conoce tu arquitectura salvo que se la des. Sin contexto, mete lógica de negocio en la capa que no es y acopla módulos que tenías separados.

“Nunca firmes código que no entiendes. Ni de la IA, ni de nadie. El que firma responde — en la review y en producción.”

Cuándo NO usar la IA

Hay decisiones que son tuyas y no se delegan: los boundaries de tu sistema, el modelo de datos, la estrategia de errores, qué tradeoff aceptas y cuál no. La IA ejecuta muy bien dentro de un diseño; diseñar el sistema — y defender esa decisión frente a un equipo — sigue siendo el trabajo que te hace valioso. Es exactamente lo que evalúan cuando quieres subir de nivel.

El flujo con agentes (Claude Code y similares)

Con agentes tipo Claude Code, el flujo cambia: ya no pegas snippets, diriges a un agente que trabaja sobre tus archivos. El patrón que me funciona a diario:

1. Parte la tarea en pasos que se puedan verificar por separado — un agente con una tarea gigante y ambigua se pierde a mitad de camino.
2. Dale el contexto de arquitectura ANTES de que escriba: qué módulos existen, qué patrón sigue el código, dónde NO debe meterse.
3. Haz que corra los tests y el linter después de cada cambio, y revisa el diff completo antes de commitear — tú eres el quality gate.

Con este flujo, la IA deja de ser un generador de snippets y se convierte en palanca real: produces features completas más rápido, sin sacrificar la arquitectura ni acumular deuda escondida.

Aprende el flujo completo, en vivo

Este flujo — spec-driven, revisión con criterio y trabajo con agentes — es exactamente lo que enseño en mis cursos en vivo: en Fundamentos + AI Coding si estás empezando (aprendes a programar Y a usar la IA bien desde el día uno), y en el curso de arquitectura de software si ya programas y quieres usar la IA a nivel de producción sin que te rompa los boundaries. Seis horas en vivo, enseño yo, y mi código está público en GitHub para que lo audites antes de pagar un sol.