Tres señales de la misma semana.

Andrej Karpathy — ex director de IA en Tesla, cofundador de OpenAI — dice que ahora programa en inglés. Su lenguaje de programación favorito ya no es Python. Es el idioma en el que describe lo que necesita.

Jensen Huang dijo en GTC 2026 que el 100% de Nvidia usa herramientas de código IA — Claude Code, Codex y Cursor. No el 30%. No un programa piloto. Todos.

Y Boris Cherny, creador de Claude Code — la herramienta de agentes que más rápido crece en la industria — lleva más de dos meses sin escribir una línea de código.

No son anécdotas sueltas. Son la misma tesis desde tres ángulos distintos.

En 25 años construyendo software empresarial, en IQ Source hemos vivido waterfall, agile y DevOps. Cada transición se sentía como un cambio grande. Lo que pasa ahora no es una transición más. Es otra cosa.

La tesis de Boris Tane: no hay fases

Boris Tane lo articuló de una forma que vale la pena repetir — y Shane Spencer lo amplificó con una lectura que conecta los puntos.

Su argumento: los agentes de IA no siguen el SDLC (Software Development Life Cycle — el ciclo de vida del desarrollo de software, la secuencia de fases que una pieza de software recorre desde la idea hasta producción). No es que lo hagan más rápido. No es que salten pasos. Es que no hay pasos. Lo que existe es intención, contexto e iteración.

El SDLC asume que el desarrollo es un proceso lineal con entregables entre fases. Requisitos primero. Luego diseño. Luego construcción. Luego pruebas. Luego revisión. Luego despliegue. Cada fase produce algo que la siguiente consume.

Cuando un agente recibe una tarea, no sigue esa secuencia. Genera código, lo prueba, lo corrige y lo entrega en un solo ciclo. Las “fases” ocurren simultáneamente dentro de cada iteración. No hay un momento de “ahora estamos en diseño” separado de “ahora estamos en construcción”.

Esto no es un SDLC más rápido. Es un modelo operativo diferente.

Qué le pasó a cada fase

No todas las fases del SDLC se rompieron de la misma manera. Cada una se rompió por un motivo distinto.

Requisitos: la especificación como subproducto

Durante décadas, el primer paso era congelar requisitos en un documento. Se escribía el PRD, se aprobaba, y ese documento gobernaba las semanas siguientes.

Esa lógica tenía sentido cuando construir una versión tomaba semanas. El costo de cambiar dirección era alto. Mejor especificar bien antes de empezar.

Cuando puedes generar diez versiones de una funcionalidad en minutos, la ecuación cambia. La especificación deja de ser un prerrequisito y se convierte en un subproducto. Pruebas la idea, ves el resultado, ajustas la intención. El documento de requisitos no desaparece — pero ya no es lo que inicia el proceso. Es lo que documentas después de iterar.

Diseño: colaboración en tiempo real con el modelo

El modelo ha visto más arquitecturas que cualquier ingeniero individual. Patrones de microservicios, monolitos modulares, event sourcing, CQRS — el agente los conoce no porque los haya implementado, sino porque ha procesado millones de repositorios donde se implementaron.

El diseño ya no es una persona frente a un pizarrón. Es una conversación con un agente que devuelve código funcional, no diagramas. La salida del diseño no es un documento de arquitectura — es un prototipo que corre.

Eso no significa que el criterio del arquitecto sobra. Significa que su trabajo cambió: de dibujar la solución a evaluar y corregir lo que el agente propone.

Pruebas: integradas en la generación

Modelo anterior	Modelo con agentes
Escribir código → enviar a QA → esperar resultados → corregir	El agente genera código y pruebas en el mismo ciclo
TDD como metodología que el equipo adopta (o no)	TDD como comportamiento por defecto de la herramienta
Suite de tests como entregable separado	Tests como parte del output de cada iteración
Bugs encontrados en fase de pruebas	Bugs encontrados durante la generación

Los agentes escriben tests al mismo tiempo que escriben código. No como una fase posterior. No como una metodología que el equipo decidió adoptar. Es cómo funcionan las herramientas por defecto.

TDD dejó de ser una decisión organizacional. Es simplemente lo que pasa cuando le dices a un agente “construye esto”.

Code review: un ritual que no escala

Este es el punto donde más duele.

Un agente como Minion de Uber genera cientos de PRs al día. Uber reporta que el 11% de sus PRs ya los abre un agente sin autor humano. Tu equipo puede revisar quizás 10 o 15 PRs al día con atención real.

La cola de code review no es un cuello de botella que puedas optimizar. Es un ritual diseñado para un mundo donde cada PR era producto de horas de trabajo humano. Cuando el PR es producto de 90 segundos de generación, la revisión línea por línea deja de tener sentido práctico.

Esto no significa eliminar la revisión. Significa que el mecanismo de control cambia: de revisar cada línea de código a monitorear el comportamiento del sistema en producción.

El nuevo ciclo: intención, construcción, observación, repetición

Lo que reemplaza al SDLC no es caos. Es un ciclo más corto con controles diferentes.

Intención. En lugar de un documento de requisitos, defines qué necesitas en lenguaje natural con el contexto relevante. La ingeniería de contexto — decidir qué información, restricciones y ejemplos recibe el agente — es la habilidad que reemplaza a la gestión de sprints. La calidad del output del agente es directamente proporcional a la calidad del contexto que recibe.

Construcción. El agente genera código, tests y documentación en un solo ciclo. No hay handoff entre equipos. No hay espera de sprint. La iteración es continua.

Observación. Cuando el code review manual no escala y los requisitos no se congelan, ¿qué te dice si el software funciona? Lo que ves en producción. La observabilidad — logs, métricas, alertas, trazas — se convierte en la última línea de defensa. Ya no es “nice to have”. Es el control primario.

Repetición. Cada observación alimenta la siguiente intención. El ciclo se repite, pero cada vuelta dura minutos, no semanas.

La preocupación legítima de la empresa

Cada semana nos llega la misma pregunta en alguna variante: “Si no hay sprints, ¿cómo estimo? ¿Cómo reporto al board? ¿Cómo cumplo con la regulación?”

La preocupación es legítima. Pero no es nueva.

Cuando las empresas migraron de waterfall a agile, el pánico fue similar. “¿Cómo le digo al cliente cuándo va a estar listo si no tengo un Gantt?” Resultó que la respuesta era medir velocidad de entrega en lugar de predecir fechas. El mundo no se acabó.

Ahora la transición es similar, pero un nivel más profundo:

• Sprint velocity → se reemplaza por calidad de contexto como métrica líder. Si el contexto que le das al agente es preciso, el output es correcto en la primera iteración. Si es ambiguo, necesitas tres.
• Gobernanza pre-aprobación (story points, estimaciones, aprobación antes de construir) → se reemplaza por monitoreo post-despliegue. Auditorías automatizadas sobre el código generado, pruebas de regresión continuas, alertas en producción.
• Story points y estimaciones → se reemplazan por tasa de iteraciones hasta resultado correcto. Si tu equipo necesita una iteración para resolver un ticket, el proceso funciona. Si necesita siete, el problema está en el contexto, no en el agente.

El cumplimiento normativo no desaparece. Se traslada. En lugar de verificar que el equipo siguió el proceso correcto antes de construir, verificas que el resultado cumple los criterios después de generarlo. La evidencia de cumplimiento viene de logs de generación, resultados de tests automatizados y monitoreo en producción — no de actas de reuniones de planificación.

Cuatro cosas que puedes hacer esta semana

No te estoy diciendo que elimines tus sprints mañana. Te estoy diciendo que evalúes si tu proceso refleja cómo tu equipo realmente trabaja.

1. Mide tu tasa de adopción de agentes. ¿Qué porcentaje del código que tu equipo envía cada semana fue generado por un agente? Si no tienes ese número, no sabes si tu proceso todavía aplica. Una encuesta interna de cinco preguntas te da un punto de partida en 48 horas.

2. Deja de optimizar la cola de code review. Si estás buscando formas de hacer que tu equipo revise PRs más rápido, estás resolviendo el problema equivocado. Rediseña tu proceso de revisión para distinguir entre código humano y código generado. Aplica criterios diferentes a cada uno. Invierte en herramientas que filtren señal útil del ruido.

3. Invierte en ingeniería de contexto. Entrena a tus tech leads en cómo estructurar contexto para agentes: qué archivos incluir, qué restricciones definir, qué ejemplos de output esperado entregar. La diferencia entre un agente que produce basura y uno que produce código listo para producción suele ser la calidad del contexto, no la calidad del modelo.

4. Traslada gobernanza a post-despliegue. Si tu mecanismo de control depende de aprobaciones antes de construir, empieza a complementarlo con monitoreo después de desplegar. Alertas de regresión. Auditorías automatizadas de código generado. Dashboards de incidentes por fuente (humano vs. agente). Cuando tu equipo genera más código del que puede revisar manualmente, la observabilidad es lo que te protege.

---

Si no sabes qué porcentaje de tu código es generado por agentes ni cómo tu proceso de gobernanza se adapta a esa realidad, eso es exactamente lo que resolvemos. En IQ Source armamos un diagnóstico de madurez de ingeniería IA en dos semanas: medimos adopción real, evaluamos tus controles actuales y te entregamos un plan de transición concreto. Hablemos.