🪜 Identifica las tres fases de la IA en el código
La evolución del uso de IA en el desarrollo pasó por tres fases. No se sustituyen entre sí: conviven en tu día a día. Lo que cambia en cada una es cuánto de la ejecución sale de tus manos — y, por consiguiente, qué tipo de control necesitas establecer.
🆕 ¿Nuevo por aquí?
LLM es el modelo de IA que genera texto: el mismo tipo que funciona detrás de ChatGPT o de Claude. Herramientas ("tools") son acciones que este modelo puede ejecutar por sí solo: leer un archivo, ejecutar un comando en la terminal, buscar en la web. Agente es el modelo más estas herramientas más un ciclo que lo hace repetirse hasta creer que terminó. Guarda estos tres: todo el curso los usa.
Autocomplete
La IA sugiere líneas, funciones o pequeños fragmentos mientras escribes.
El humano sigue siendo responsable de prácticamente todas las decisiones. El posible error es puntual: una sugerencia equivocada que aceptas sin leer. El costo de revisar es bajo porque el diff es pequeño.
Asistente
La IA responde preguntas, explica código, crea funciones y genera archivos.
Ya participa en la implementación, pero todavía depende de instrucciones frecuentes. Aquí aparece el primer riesgo de escala: aceptas bloques enteros que no leíste línea por línea porque «parecía correcto».
Agente
Recibe una tarea y la ejecuta: explora el repositorio, lee la documentación, modifica archivos, ejecuta comandos y pruebas, analiza el error e intenta corregir su propia implementación.
Esta fase exige un nuevo tipo de ingeniería. El agente no debe tratarse como un chatbot inteligente, sino como un componente operativo dentro de un sistema controlado — con permisos, límites, verificación y registro.
Sugerencia
Fase 1: riesgo local
Respuesta
Fase 2: riesgo de bloque
Ejecución
Fase 3: riesgo sistémico
Control
Pasa de línea a sistema
🧩 Enumera lo que un agente necesita para funcionar
Cuando un agente "no funciona", casi nunca la causa es el modelo. Falta un elemento de esta lista. Úsala como diagnóstico: recorre los trece puntos y marca lo que falta en tu configuración actual.
Cómo leer: la caja central es lo único que muchos equipos configuran, y es la parte más pequeña del problema. Todo lo que está alrededor en cian es lo que tú construyes. Si una de estas cajas está vacía, el agente falla justo ahí: sin "criterio de finalización" no se detiene; sin "registro" no descubres qué hizo.
✓ Setup que funciona
- ✓Acceso al repositorio con alcance declarado (qué puede leer y qué puede escribir)
- ✓Comando de prueba que se ejecuta en segundos y falla de forma evidente
- ✓Criterio de finalización explícito y verificable
- ✓Log de todas las acciones ejecutadas
✗ Setup que se convierte en un accidente
- ✗Acceso total a la máquina «para facilitar»
- ✗Ninguna prueba: la verificación consiste en que tú revises el diff
- ✗"Termina cuando esté bien" como criterio
- ✗Sin registro: nadie sabe qué comandos se ejecutaron
Contexto
Qué puede ver
Permiso
Qué puede hacer
Verificación
Cómo saber si funcionó
Registro
Qué quedó como evidencia
🎛️ Asume el nuevo rol del ingeniero
El trabajo no disminuyó: cambió de lugar. Menos tiempo escribiendo la implementación y más tiempo definiendo qué es correcto, preparando el contexto, fijando límites y evaluando el resultado. Quien hace esto bien multiplica la capacidad de todo el equipo.
🎯 El cambio en una frase
Antes, tu producto era el código. Ahora, tu producto es el sistema que produce código confiable — la spec, el harness, el loop, los gates. El código es el resultado de este sistema.
- •Escribes menos líneas y revisas más cambios.
- •Transformas el conocimiento tácito del equipo en documentos y pruebas.
- •Tú decides dónde termina la autonomía y dónde interviene el humano.
💡 Consejo práctico
En la próxima tarea que vayas a delegarle a la IA, dedica 10 minutos a escribir la spec antes de abrir el agente. Mide: ¿cuántas idas y vueltas te ahorraste? Ese número es el argumento que convence a tu equipo, no el discurso.
Especificar
Definir qué es correcto
Contextualizar
Elegir lo que ve
Limitar
Definir dónde parar
Juzgar
Aceptar o rechazar
🏗️ Entiende por qué los fundamentos volvieron a importar
La IA genera código rápidamente, pero no sustituye el conocimiento de ingeniería. Cuanto más código produce, más valiosa se vuelve tu capacidad de evaluar el resultado — y esa capacidad viene de los fundamentos, no de conocer la herramienta de turno.
🔍 Lo que pasa desapercibido sin fundamentos
Todos estos defectos pasan las pruebas del camino feliz. Por eso mismo llegan a producción.
El conocimiento duradero
Arquitectura, pruebas, sistemas operativos, redes, APIs, seguridad, bases de datos e infraestructura. Nada de eso envejece a la velocidad de las herramientas.
El conocimiento duradero no consiste en memorizar una herramienta.
Está en comprender cómo funcionan los sistemas.
Verificación rápida (no bloquea nada): un agente entregó una corrección y todas las pruebas pasaron. ¿Cuál es la conclusión correcta?
Evaluar > producir
El cuello de botella ahora es el criterio
Camino adverso
Es donde vive el defecto
Duradero
Sistemas, no productos
Escala
Más código, más revisión
🚧 Reconoce los límites actuales de las herramientas
Saber dónde falla la herramienta no es pesimismo: es lo que define qué tareas delegas hoy y cuáles todavía requieren aprobación humana. Estos cuatro límites explican la mayoría de los malos resultados.
1. Solo existe el contexto que diste
El agente no sabe de la conversación de pasillo, de la regla que solo conoce Paulo ni del sistema vecino que consume su API de una manera no documentada. Lo que no se incluye en el contexto, lo completa con una suposición plausible.
2. "La prueba pasó" no significa "la intención se cumplió"
Optimiza para el verificador que le diste. Si el verificador es débil, la solución será débil justo de la forma que el verificador no detecta.
3. Confianza constante, acierto variable
El tono de la respuesta no varía según su calidad. No puedes usar «parecía seguro» como señal.
4. Efectos secundarios fuera del repositorio
La base de datos, la infraestructura, los permisos y las integraciones externas no se recuperan con un git revert. Por eso estas acciones requieren aprobación, no autonomía.
⚠️ Atención
Los cambios en producción, bases de datos, infraestructura, permisos y seguridad siempre necesitan controles adicionales. Ningún ahorro de tiempo compensa una migración irreversible aplicada por un loop automático a las 3 de la mañana.
Contexto ausente
Se convierte en suposición
Verificador débil
Solución débil
Tono ≠ acierto
La confianza no es una señal
Irreversible
Requiere intervención humana
⚠️ Evita el desarrollo basado solo en prompts
El desarrollo basado únicamente en prompts es aquel en el que la única entrada es la frase del momento: sin especificación, sin pruebas, sin límites, sin revisión independiente. Parece productivo durante una semana y pasa la factura al mes siguiente.
🧪 Ejercicio copiable — la misma solicitud, dos niveles
Objetivo: sentir en la práctica la diferencia que hace el contexto. Ejecuta ambos en tu agente (Claude Code, Codex, Cursor — da igual), en un repositorio de prueba.
Prompt A (solo prompt):
Adicione cache no endpoint de listagem de produtos.
Prompt B (la misma tarea, con ingeniería alrededor):
Tarefa: adicionar cache na listagem de produtos em <caminho/do/arquivo>. Fora do escopo: não alterar o contrato da resposta, não tocar em outros endpoints, não adicionar dependências novas sem me perguntar antes. Critérios de aceitação: - resposta idêntica à atual para os mesmos parâmetros (byte a byte); - invalidação do cache quando um produto é criado, alterado ou removido; - TTL configurável por variável de ambiente, com default de 60s; - teste automatizado cobrindo hit, miss e invalidação. Antes de implementar: me mostre o plano em até 10 linhas e espere aprovação. Ao terminar: rode <comando de teste do seu projeto> e cole a saída real.
Cómo verificar: compara los dos diffs. Cuenta los archivos modificados, las dependencias agregadas y las pruebas creadas. El prompt A suele inventar una capa de caché genérica y modificar archivos que no se pidieron; el B entrega un cambio revisable en minutos. Guarda ambos diffs: son tu argumento ante el equipo.
✓ Señal de que saliste del «solo prompt»
- ✓Existe un artefacto escrito que define qué significa «correcto» antes de la ejecución
- ✓Existe un comando que responde «¿salió bien?» sin depender de la opinión humana
- ✓Existe un límite que define qué no se puede tocar
- ✓Existe un segundo par de ojos (humano o agente revisor)
✗ Síntomas de la deuda por prompt
- ✗Dos soluciones para el mismo problema en módulos diferentes
- ✗PR demasiado grandes para revisarlos de verdad
- ✗Pruebas que solo cubren el camino feliz
- ✗Dependencias que nadie sabe explicar por qué se agregaron
Velocidad doble
De entrega y de error
Frontera
Alcance negativo por escrito
Verificador
Comando, no opinión
Sistema
La verdadera diferencia
📌 Resumen del módulo
Próximo módulo:
1.2 - Spec-Driven Development: transformar la intención en criterios verificables.