Hay dos errores que los agentes de IA cometen en SwiftUI con una insistencia casi cómica: romper la identidad de las vistas dentro de un ForEach y colocar el estado en el nivel equivocado de la jerarquía. Los cometen tanto, y son tan difíciles de ver leyendo por encima, que Apple ha terminado publicando skills oficiales para corregirlos.
Párate un segundo en esa frase. La empresa que fabrica el framework ha tenido que escribir instrucciones para que las máquinas dejen de escribir mal su propio framework.
Ese código compila. Funciona en el simulador. Pasa una demo. Y se cae más tarde, en producción, delante de usuarios reales, de una forma que solo ve venir quien entiende lo que ocurre por debajo.
Ahí está resumido todo 2026.
Llevamos setenta años quitándole teclas al programador
Lo primero que hay que decir es que esto no es nuevo. Es, de hecho, lo único que ha hecho esta profesión desde que existe.
Cuando el equipo de John Backus presentó FORTRAN en 1957, su obsesión no era que el lenguaje resultara agradable: era demostrar que el código que escupía el compilador podía competir con el ensamblador escrito a mano. Porque si no competía, nadie lo iba a usar. Había programadores —buenos, de los que sabían de verdad— convencidos de que dejar que una máquina escribiera el código de otra máquina era una manera elegante de perder el control.
Después llegó la gestión automática de memoria. Después los lenguajes de alto nivel de verdad. Después las librerías que ya no tenías que escribir. Después Stack Overflow, que convirtió el copiar y pegar en una competencia laboral. Y en nuestra casa, en 2011, llegó ARC y nos quitó los retain y los release de las manos.
Yo me acuerdo perfectamente de aquellos foros. «Esto va a crear una generación entera que no entiende la gestión de memoria».
¿Y saben qué? Tenían razón. Hoy hay desarrolladores iOS estupendos que no sabrían llevar un contador de referencias a mano. Y también hay más apps, mejores y más ambiciosas que en ningún otro momento de la historia. Las dos cosas son verdad a la vez, y llevan siendo verdad a la vez desde 1957.
Cada abstracción se llevó una tarea. Ninguna se llevó el oficio. Porque el oficio nunca fue teclear.
Pero esta vez la abstracción no es determinista
Y aquí es donde me bajo del cómodo «esto ya lo hemos vivido antes».
Me explico: un compilador es una función. Le metes lo mismo, te devuelve lo mismo. Si un día genera un binario incorrecto, eso es un bug, se abre un radar, se arregla y deja de ocurrir. Puedes confiar en un compilador con la misma tranquilidad con la que confías en que mañana dos y dos seguirán sumando cuatro.
Un modelo de lenguaje no es una función. Es una distribución de probabilidad. No te da la respuesta correcta: te da la respuesta plausible, la que estadísticamente encaja mejor con lo que ha visto un millón de veces. Y te la da exactamente con el mismo tono de seguridad cuando acierta que cuando se la está inventando.
Es la primera herramienta en la historia del desarrollo que puede equivocarse con convicción.
Eso mueve el trabajo de sitio. Durante setenta años el programador fue subiendo niveles de abstracción, sí, pero siempre con el suelo firme debajo. Ahora el suelo opina. Y cuando el suelo opina, tu tarea deja de ser escribir y pasa a ser juzgar.
No lo digo por intuición. En un ensayo controlado de 2025, desarrolladores expertos tardaron un 19 % más en completar sus tareas usando IA… convencidos de que estaban yendo un 20 % más rápido (METR, 2025). El 84 % de los desarrolladores ya usa IA a diario, pero solo uno de cada tres se fía de lo que produce (Stack Overflow Developer Survey 2025). Y desde la irrupción de estas herramientas, el código duplicado en los repositorios ha pasado del 8,3 % en 2021 al 12,3 % en 2024, mientras casi se duplicaba el código que hay que reescribir antes de dos semanas (GitClear, 211 millones de líneas analizadas).
Y ahora la otra cara, que también es real: en experimentos de campo con casi 5.000 desarrolladores, quienes usaban IA completaron un 26 % más de tareas, y los que más ganaron fueron los de menos experiencia (Cui et al., Microsoft/MIT, 2025). Los dos resultados son ciertos y no se contradicen: la IA amplifica lo que ya hay. Si hay criterio, multiplica. Si no lo hay, multiplica el caos.
Porque no razona. Porque no abstrae. Porque no sabe qué significa «correcto» en tu proyecto: nadie se lo ha dicho nunca.
El criterio no se copia ni se genera. Se entrena.
Con esa idea hemos reconstruido entero el Swift Engineering Program 2026. Y el cambio de nombre —de developer a engineer— no es marketing: un developer escribe; un engineer analiza, diseña, planifica y responde por la calidad del resultado, sea quien sea quien haya escrito cada línea.
Lo que no vas a encontrar aquí es un módulo de IA al final del temario, con su hora de prompts y su foto de familia. La relación con el agente se construye durante todo el programa, con permisos progresivos. Como un carnet de conducir por etapas.
En las primeras semanas está prohibido pedirle código al agente y es obligatorio pedirle explicaciones. El asistente de Xcode 27 es un profesor particular disponible a las tres de la mañana: te explica por qué ese opcional necesita unwrapping, o qué separa realmente a un closure de una función. La IA amplifica a quien quiere entender; jamás sustituye el entendimiento.
En la segunda fase el agente baja de categoría: pasa de profesor a compañero falible. Tú escribes, él propone, tú auditas. Y cada semana llega nuestro ejercicio estrella, «Encuentra el fallo del agente»: código generado por IA con errores sutiles de verdad, de los que cometen los modelos reales. Tu trabajo es cazarlos. Nadie sale de ahí pensando que la máquina le sustituye. Sales entendiendo que tu criterio es el producto.
Y en la tercera, Agentic Coding pleno con Xcode 27: plan mode, skills, MCP, sub-agentes, autovalidación. Tú un nivel por encima, escribiendo la especificación, revisando el plan antes de que se toque una sola línea y validando el resultado.
Además, la última hora de clase es sagrada: es el Laboratorio de Criterio, donde escribes tus propios prompts y tus propias skills y evaluamos la precisión de la petición. Porque si no entiendes ni el problema ni el código, ¿cómo pretendes que la IA te ayude a resolverlo?
Lo que hay dentro, sin adornos
124 horas de clase en directo repartidas en 31 días lectivos, de lunes a jueves, de 19:00 a 23:00 hora española, del 5 de octubre al 26 de noviembre de 2026. Después, 13 semanas de proyecto guiado, del 7 de diciembre al 7 de marzo de 2027. Todo grabado y publicado a las 12 horas de terminar cada sesión, así que puedes seguirlo en directo, en híbrido o completamente offline. 40 plazas, ni una más.
Antes de octubre hay dos módulos pregrabados en septiembre. El primero es algoritmia pura, porque hay millones de «desarrolladores» que no saben desarrollar: copian, pegan y rezan. El segundo no tiene una sola línea de código y probablemente sea el más importante del programa: qué es realmente un modelo de lenguaje, qué son los tokens y la ventana de contexto, por qué alucina y por qué es brillante con lo común y peligroso con lo nuevo. Conoce la herramienta antes de dejarla tocar tu código.
A partir de ahí, el recorrido completo: Swift 6.4, SwiftUI con Liquid Glass —sin una sola API deprecada y compatible desde iOS 17—, arquitectura con MVVM y Clean Architecture, concurrencia estricta con @MainActor y @concurrent, Swift Testing como asignatura troncal (en la era de los agentes tus tests son la herramienta con la que la máquina valida su propio trabajo), red, SwiftData y, al final, MCP, ACP y Spec Driven Development en directo con la clase entera funcionando como equipo de producto.
Y termina con el Expediente: una app en SwiftUI contra una API REST nuestra, con el núcleo escrito por ti, una funcionalidad construida obligatoriamente con el agente y acompañada de un diario de decisiones —qué le pediste, qué aceptaste, qué rechazaste—, más una defensa en vídeo explicando tu arquitectura.
Ese diario es la parte que más me importa de todo el programa. Porque en 2026 ya da exactamente igual quién escribió cada línea. Lo que importa es si puedes defenderla.
Setenta años después, sigue haciendo falta alguien que decida
Va a haber gente que construya apps sin saber programar. Ya la hay. Y algunas aguantarán un tiempo, igual que aguanta un edificio hasta el día en que hay que cambiar una tubería y descubres que nadie sabe por dónde pasan.
La pregunta nunca ha sido si la máquina puede escribir el código. Llevamos desde 1957 respondiendo que sí, un poco más cada década. La pregunta es quién decide qué código merece llegar a producción. Ese sitio sigue vacío, y es el único que la IA no puede ocupar.
Aprender a encontrar el camino es tu trabajo. Evitar que te pierdas es el nuestro.
