Después de que la IA escribe la app: ¿puedes revisar el diff y hacer Merge?

Empecemos por la conclusión: cuando la IA puede escribir cualquier código, «escribir rápido» deja de ser una ventaja, lo tiene todo el mundo. Lo verdaderamente escaso es si te atreves o no a pulsar ese botón de Merge. Y que te atrevas depende de si lo que la IA te entrega es algo que puedes revisar, gobernar y de lo que puedes responsabilizarte.

Veamos primero una escena que ya ocurre a diario.

Una ingeniera le pide a un agent de programación que «monte una pequeña app de reembolsos para soporte al cliente». Media hora después, ahí está una app que funciona: frontend, endpoints, migraciones de base de datos, tests, todo completo, y el CI en verde. Abre el PR y ve una línea: +8,142 −0.

Y entonces se queda bloqueada.

Esas ocho mil líneas no las escribió ella; no ha leído ni una sola. ¿En qué archivo está la validación del límite del importe del reembolso? ¿Devolverá este endpoint también los reembolsos de otras personas? Si lo modifica, ¿afectará de rebote a la conciliación contable? No lo sabe, porque nadie lo sabe. Que el CI esté en verde solo demuestra que «el código corre de forma coherente consigo mismo», no demuestra que «haga lo correcto y solo lo que está permitido».

Tiene dos opciones, y las dos son malas: o aprieta los dientes, finge que lo ha revisado y pulsa Merge (metiendo en producción una caja negra que nadie entiende), o se pone de verdad a leer línea por línea esas ocho mil líneas, en cuyo caso más le valdría haberlas escrito ella misma. Este es el verdadero cuello de botella nuevo de la era de la IA: no es escribir código, es pulsar Merge.

Escribir código se ha mercantilizado; la «confianza» no

Durante la última década, la capacidad escasa del ingeniero era «saber sacarlo adelante». Esa capacidad la está nivelando la IA de forma rápida y total. Cuando el coste marginal de generar una app tiende a cero, «rápido» deja de ser la trinchera de nadie: el agent de tu competidor también es igual de rápido.

Lo que pasa al primer plano es otra cosa que siempre estuvo ahí, pero que antes quedaba tapada por el coste de escribir código: alguien tiene que responder por ese código. Tiene que haber alguien capaz de contestar a «¿qué datos leyó, qué acciones puede ejecutar, de quién es la culpa si falla, queda registro en la auditoría?». Después de que la IA haya recortado a cero el coste de «escribir», «revisar y gobernar» se convierte en el tramo más caro y más crítico de todo el proceso. La revisabilidad es la nueva trinchera de la era en que la IA escribe el código: no gana quien más genera, sino quien se atreve a poner en producción lo que genera.

Esta es la otra cara de lo mismo que ya contaron La deuda técnica de Vibe Coding y Por qué los pilotos de AI Agent fallan antes de producción: el vibe coding hace que cualquiera pueda generar una app, pero, una vez generada, nadie se atreve a desplegarla, porque nadie puede revisarla ni avalarla. La única diferencia es que aquellos dos artículos lo miran desde la óptica de la empresa y de quien decide, y este lo mira desde la tuya, la de quien tiene el dedo suspendido sobre el botón de Merge.

Por qué «que lo revise otra IA» no cierra el círculo

La objeción más natural es: si la IA puede escribir, ¿por qué no dejar que la IA haga el review? Agents de revisión de código, escaneos de seguridad automáticos, hoy los hay.

Ese camino frena una parte, pero no cierra el círculo que de verdad importa.

Volvamos a aquel GET /api/refunds. Devolvía los reembolsos de todo el mundo, y aun así pasa casi todas las comprobaciones automáticas: la sintaxis es correcta, no hay punteros nulos, tiene tests (que también escribió el mismo agent, así que naturalmente solo prueban «que se puedan consultar los reembolsos», jamás «si debería poder consultar los reembolsos ajenos»). La revisión por IA es buena evaluando si el código es correcto respecto a sí mismo: si tiene bugs, si encaja con patrones de vulnerabilidad conocidos, si el estilo es consistente. No puede responder a tres preguntas que están fuera del código: ¿este código debería leer esta tabla? ¿Esta acción debería mover ese dinero? ¿Es esta la regla de negocio que queremos?

Esas respuestas no están en el código: están en el modelo de permisos, en la política de aprobaciones, en la intención de negocio. Que dos IA asientan la una a la otra no es gobernanza. Esa respuesta de «quién autorizó, quién responde» que reclaman auditores, departamento legal y el equipo de seguridad no la puede firmar ni el modelo de revisión más listo. Así que «que la IA revise a la IA» te ahorra el esfuerzo físico de que un humano lea código, pero no te ahorra ese juicio del «debería o no debería» que tiene que hacer un humano. El problema vuelve al punto de partida: el humano tiene que poder revisar. Pero ocho mil líneas, un humano no las puede revisar.

La salida: reducir lo que la IA te entrega hasta que sí puedas revisarlo

Que no puedas revisar ocho mil líneas y que este sistema se pudra dentro de medio año tienen la misma causa: nadie entiende de verdad ese mazacote de implementación (esto es la «deuda de comprensión» de la que habla aquel artículo).

Pues cambiemos la forma de lo que entrega la IA: que no genere implementación, que genere declaración. Para esa misma app de reembolsos, lo que la IA debería entregarte no son ocho mil líneas de código, sino un diff de metadatos como este:

+ object: support_refund
+   amount: currency (min 0)
+ permission: support_agent
-   allowDelete: true        # la primera versión del agent dio de más
+   allowDelete: false       # retirado en la revisión: soporte no puede borrar reembolsos
+ flow: refund_amount > 500 → requiere aprobación de finanzas

Estas diez y pico líneas las puedes leer y entender una por una, las puedes revisar en cinco minutos, las puedes revertir con un clic. Y lo más importante son esas últimas partes: la revisión ya no es «¿podré leérmelo entero?», sino «¿es correcto este permiso, es razonable este umbral de aprobación?», una pregunta de negocio que de verdad puedes juzgar y que de hecho te corresponde juzgar. Aquel GET /api/refunds que filtraba datos aquí ni siquiera puede aparecer: el permiso de lectura de support_refund se declara como «según los permisos de quien llama», el runtime lo fuerza en consecuencia y la vía de la escalada de privilegios queda cerrada desde el origen.

¿Y dónde quedó la implementación? La implementación pertenece a un runtime (ObjectOS) auditado una y otra vez y compartido por todas las apps, no a una copia generada por cada app. El «qué debería o no hacerse» (si puede leer, si puede borrar, si requiere aprobación) lo fuerza el runtime en el momento de ejecutar, en vez de quedar enterrado en ocho mil líneas y librado a la suerte.

Un círculo que de verdad se cierra

Si dibujamos esto como un flujo, queda un círculo en el que el humano siempre está presente, pero sin quedar sepultado bajo el volumen de código:

Fíjate en el paso ④: como la propia definición de negocio ya declara los objetos y los permisos, el runtime la proyecta en un conjunto de herramientas gobernadas, de modo que ese mismo agent no solo «escribió» esta app, sino que después puede operarla dentro de los mismos límites de permisos (consultar reembolsos, iniciar reembolsos), y cada paso lleva identidad y deja rastro. Escribir y usar comparten una misma gobernanza.

Primero, un jarro de agua fría

Esta jugada tiene sus límites, y conviene dejarlos claros.

Primero, no todo se puede convertir en metadatos. Un algoritmo nuevo en tiempo real, una tubería de renderizado original, siguen necesitando código de verdad y siguen necesitando que alguien apriete los dientes y revise esa parte; los metadatos ahí no te ayudan, y forzarlos solo estorba. En lo que destacan es en ese 90 % de sistemas de negocio que las empresas reconstruyen una y otra vez.

Segundo, la confianza se traslada, no se elimina. Ya no revisas la implementación de cada app una por una, pero apuestas tu confianza a ese runtime, que tiene que auditarse a fondo una vez y mantenerse de forma continua. Pero echa la cuenta: con el enfoque tradicional, cada vez que la IA genera una app tienes que volver a confiar en un mazacote de código nuevo; con el enfoque de metadatos, auditas el runtime una vez y, a partir de ahí, cada app que se deriva hereda automáticamente el mismo conjunto de permisos y auditoría ya verificado. Auditar una vez vale más que auditar mil veces. Es un trato mucho más rentable, pero es un trato, no magia.

Cierre

Que la IA sepa escribir código no va a dejar al ingeniero sin trabajo, pero sí va a cambiar el puesto de control que más debe custodiar: de «¿soy capaz de escribirlo?» a «¿me atrevo a firmar lo que la IA ha escrito?».

Y que te atrevas a firmar depende casi por completo de qué te ha puesto la IA delante: si ocho mil líneas de implementación que no puedes leerte enteras, o unas decenas de líneas que puedes revisar y que el runtime puede gobernar. No mandes a tu agent a escribir un montón de código; mándalo a generar un objetivo que tú puedas revisar y que el runtime pueda sostener.

npm i -g @objectstack/cli && os start

Apunta a tu agent de programación hacia un objetivo declarativo y gobernable, en lugar de soltarle un «hazme un CRUD», y luego mira el diff del siguiente PR, a ver si por fin es tan pequeño que te atreves a darle a «Merge».