La demo que no daba el ancho
La primera vez que vi a un agente de IA construir una función a partir de una sola frase, sentí dos cosas al mismo tiempo: asombro y una pequeña inquietud, muy conocida.
El asombro es fácil de explicar. Describes lo que quieres y la cosa aparece: completa, verosímil, corriendo. Se siente como magia y, para cierto tipo de trabajo, casi lo es.
A la inquietud me costó más ponerle nombre. Hasta que la ubiqué. Llevo más de quince años entre robots y aprendí a desconfiar de todo lo que se ve terminado antes de haber hecho trabajo de verdad. He armado máquinas preciosas en la mesa de trabajo e inútiles en la cancha. La demo de IA tenía esa misma cualidad: hermosa, segura de sí misma y sin una sola prueba en el mundo real en la que tuviera que sobrevivir.
Esa distancia —entre lo que se ve bien y lo que está bien— es toda la historia de lo que está pasando hoy en el software. Y es por eso que dejé de hablar de “vibe coding” y empecé a hablar de ingeniería de IA.
Para qué sirve el “vibe coding” (y para qué no)
El término proviene de Andrej Karpathy, a principios de 2025: describe lo que quieres, deja que la IA lo escriba y sácalo a producción. No leas el código con lupa. Déjate llevar por la vibra.
Para un prototipo de fin de semana, una landing page, un script de una sola vez, esto es maravilloso. La sorpresa se vale porque no hay nada en juego. Si se rompe, te encoges de hombros y lo vuelves a intentar.
Ahora mete esa misma petición en un sistema del que dependen personas de verdad. En mi mundo hay dos: la plataforma de registro que usan miles de estudiantes y voluntarios para llegar a un campeonato mundial de robótica y —en mi trabajo de todos los días— la ingeniería dentro de una industria financiera regulada, donde un error que apenas se ve como verosímil no es para encogerse de hombros. Es un defecto que le da la cara al cliente, un problema de cumplimiento, un número equivocado en la cuenta de alguien.
En esos sistemas, “verosímil” no es la vara. La vara es correcta, defendible y revisada.
Hay una idea sobre la educación en robótica a la que regreso una y otra vez. Damien Kee, en una ponencia de un taller de RoboCup, sostenía que los robots fracasan en el salón de clases cuando se les trata como juguetes —objetos de entretenimiento— y funcionan cuando se les trata como herramientas que amplían lo que un estudiante puede hacer. Como trustee de RoboCup, llevo años viéndolo pasar, así que para mí la distinción no es prestada. Es vivida.
La IA en el software presenta exactamente la misma bifurcación. Trátala como juguete —a ver qué genera— y te llevas demos y deuda. Trátala como herramienta —déjame planear el trabajo para que la herramienta haga bien su parte y luego contrasto el resultado con el plan— y te llevas software que sí sale a producción. El mismo modelo. Los mismos tokens. Un resultado completamente distinto. La variable nunca fue la herramienta. Es la práctica en torno a la herramienta.
La brecha de contexto
Esto es lo que, en realidad, trae una petición hecha al estilo de vibe coding: una meta, una estética y cierta tolerancia a la sorpresa. Y esto es lo que deja fuera, es decir, todo lo que hace que el software sobreviva en producción:
- Contexto del sistema: la arquitectura, las dependencias, los contratos con los servicios vecinos.
- Contexto de riesgo: qué pasa cuando esto falla, a quién le pega, cómo se ve el rollback.
- Contexto de calidad: los estándares que este código ya se exige a sí mismo.
- Contexto regulatorio: qué va a leer un auditor, qué va a preguntar un examinador.
Cuando le entregas a una IA una petición vaga, ella rellena el vacío con suposiciones. Casi siempre son verosímiles. Pero las suposiciones verosímiles son justo la falla que reconocí en la mesa de trabajo del robot: eso que se ve terminado y no lo está.
A esto le acabé llamando la brecha de contexto y aquí viene lo importante: no es una falla del modelo. Es una falla en la petición. Y una falla en la petición es algo que un ingeniero sí puede corregir.
El trabajo no se encogió. Se movió.
El miedo más ruidoso a la IA es que reemplace al ingeniero. Yo creo que ese miedo lee la situación exactamente al revés.
Lo que antes era el oficio visible —teclear el código— hoy es la parte más barata. Pero el resto del trabajo no desapareció. Se movió. Como dijo el desarrollador Peter Steinberger, el pensamiento difícil —planear, diseñar el sistema, elegir dependencias— es el trabajo que le queda al ingeniero. La IA acelera la ejecución. No reemplaza el pensamiento.
Así que el valor del ingeniero se desplazó a los dos extremos del trabajo: río arriba, hacia la planeación, y río abajo, hacia la revisión. En medio —el tecleo—, el agente toma el control. El ingeniero se convierte en el arquitecto de la petición y en el auditor de la respuesta.
Ese no es un trabajo más chico. En un sistema difícil, es el trabajo más difícil. Y se reduce a dos hábitos.
Uno: escribe el plan antes de que el agente toque el código. No una novela: una página. ¿Para qué es este cambio en términos de negocio? ¿Qué entra y qué queda explícitamente fuera? ¿Qué puede salir mal y a quién le pega si sale mal? ¿Cuál es la vara de calidad, entendida como estándares y no como vibra? ¿Qué evidencia va a demostrar que funciona, escrita antes del cambio? Un plan así cierra casi por completo la brecha de contexto de un solo golpe y, no por casualidad, le da a quien revisa algo concreto con qué comparar.
La objeción de siempre es: “eso no es más que un documento de diseño; siempre los hemos tenido”. Cierto, y la mayoría dejamos de escribirlos bien, calladitos, porque hacerlo bien se sentía más lento que sacar el trabajo. La IA cambió esa cuenta. Hoy un buen plan es el acelerador más barato para todo lo que viene después. El plan siempre valió la pena. La IA hizo que se pagara solo por días, en lugar de trimestres.
Dos: revisa el resultado contra el plan, no contra el código. La pregunta equivocada para un cambio asistido por IA es: “¿Este código se ve bien?”. Puede verse bien y estar mal de maneras que jamás vas a cachar línea por línea, y de todos modos hay demasiado como para leerlo así. La pregunta correcta es: ¿esto entrega lo que el plan dijo que entregaría, ni más ni menos? Los errores que importan casi nunca están en el código. Están a la distancia entre lo que el código hace y lo que el plan prometió. (Cómo funciona esa revisión en la práctica, cuando un agente veloz está produciendo los cambios, es el tema de un texto posterior. La revisión es el producto.)
Pruebas, no teoría: un sistema del que dependen personas de verdad
Quiero ser concreto porque de esto es muy fácil hablar al aire.
La plataforma de registro de RoboCup la lleva un equipo de dos voluntarios —mi colaborador Marek y yo—, ambos con carreras de tiempo completo en otro lado. Brinda servicio a participantes de más de 45 países y debe funcionar durante las ventanas de registro en vivo, cuando los operadores reales dependen de ella en tiempo real. Le aplicamos cambios a un ritmo de varios pull requests al día.
Ese ritmo solo se sostiene porque la disciplina está codificada, no improvisada. Cada cambio que no es trivial pasa por una revisión ajustada a su riesgo: un arreglo de una línea y un refactor que afecta todo no reciben el mismo escrutinio. Los cambios más grandes pasan por varias revisiones independientes, cada una con una mirada fresca, porque a un solo revisor al que le dices que “cubra todo” te entrega un resumen, no una revisión. En los cambios más riesgosos, hasta metemos una segunda IA de otro proveedor —un modelo distinto con puntos ciegos distintos—, justo para que cache lo que a la nuestra ni se le ocurrió buscar.
Dos momentos lo demuestran mejor que cualquier teoría.
Una vez, se nos pasó un cambio en la primera revisión que contenía un error de privacidad silencioso: una clase de usuario podía ver una rebanada de datos que le pertenecía a otro. No se veía en el diff. Lo cachó una revisión que corría un modelo distinto, porque esa revisión leyó el comportamiento, no solo las líneas: siguió el rastro de lo que cada tipo de usuario iba a ver de verdad en pantalla.
Otra vez, un revisor levantó la mano porque una pequeña etiqueta de “New” iba a dejar de aparecer sin previo aviso, a raíz de un cambio en cómo se agrupaban las actualizaciones: una regresión que nadie podía ver leyendo el código, porque vivía en el comportamiento renderizado una semana después. El revisor la cachó corriendo el comportamiento hacia adelante en su cabeza.
Aquí viene la parte que más me importa. En todo ese sistema, nadie saca nada solo. El agente nunca elige qué construir. Nada se mergea solo. Y siempre hay un humano cuyo nombre queda en la decisión. La IA es asombrosamente útil dentro de esos límites. Los límites son lo que hace que la velocidad sea segura.
Que siga siendo humano
Así que esta es la frase que defiendo donde sea: la IA escribe el código —hasta lo commitea—, pero un humano hace el merge. El merge es donde reside la responsabilidad y es el único paso que nunca automatizamos.
Cuando un auditor —o un cliente, o un compañero de equipo dentro de seis meses— pregunta “¿quién decidió esto?”, la respuesta tiene que ser una persona, no un prompt. Eso no es nostalgia por un mundo en el que los ingenieros tecleaban todo a mano. Es responsabilidad y es lo único de lo que las herramientas no pueden encargarse, porque la responsabilidad es justo lo que menos queremos automatizar.
Y también es, muy convenientemente, hacia donde van las reglas. Los reguladores están convergiendo en una lista corta y conocida —transparencia, documentación, supervisión humana y una línea clara de responsabilidad sobre lo que hace un sistema— y la Ley de IA de la Unión Europea ya va avanzando por ese camino. Lo cual quiere decir que las disciplinas que hacen que la IA sea segura son precisamente las que los reguladores están a punto de exigir. Los ingenieros que trataron a la IA como herramienta ya van a estar parados ahí cuando eso llegue. Los que la trataron como un juguete van a estar explicando un año de deuda acumulada.
Lo que aprendí: la llegada de la IA no hizo la ingeniería más fácil. Hizo que el pensamiento importara más, al hacer que el tecleo importara menos. El oficio se movió hacia donde siempre valió más: decidir qué construir y responder por ello.
Por qué importó: cambió lo que busco en los ingenieros y en mí mismo. No “quién produce más código” —esa ya la gana la máquina—, sino “quién escribe el plan más claro, hace la pregunta de revisión más filosa y pone su nombre en el resultado, dando la cara sin titubear”.
Ese es todo el cambio, en una sola línea:
Trata a la IA como herramienta, no como juguete. Planea el trabajo. Revisa contra el plan. Saca algo real a producción.
La demo siempre se va a ver terminada antes de haber hecho un solo trabajo. Nuestra chamba —la chamba humana— es saber cuál es la diferencia.