tu agente de código debería poder reconstruir tu app

Este es un pedido real que puedes escribirle a Claude Code en una Mac con NotchNull instalado:

Use the notchnull skill: add a widget with my open pull requests, and show a red wing beside the notch while CI is failing.

El agente escribe un archivo JSON, dibuja el notch en un PNG para revisar su trabajo, y el cambio queda en vivo sin reiniciar nada. Sin API de plugins, sin una pantalla de ajustes hecha para ese caso exacto.

La mayoría de las apps no pueden hacer esto, y no es porque los agentes no sean lo bastante buenos. Es porque la app se hizo para una persona con un mouse. Su estado vive detrás de una interfaz, sus errores salen como un toast, y la única forma de saber si un cambio funcionó es mirar la pantalla.

Hice NotchNull y ukiyo al revés. Uno es un notch de MacBook y el otro un motor de juegos en C#. Son apps muy distintas, y terminaron siguiendo las mismas cinco reglas.

1. El estado son archivos que el agente puede leer

Cada ajuste de NotchNull vive en ~/.notchnull/settings.json, y cada widget es su propio archivo en widgets/. La ventana de Settings y el archivo se sincronizan en los dos sentidos, y la app vigila la carpeta y aplica los cambios mientras corre.

En ukiyo, las escenas, entidades y componentes son C# plano. No hay estado del editor escondido en otro lado. Lo que el agente escribe es exactamente lo que corre.

Si la verdad vive en una base de datos detrás de la interfaz, el agente tiene que adivinar. Si vive en un archivo, el agente la lee.

2. La app dice qué entendió de tus archivos

Un agente que edita un archivo y no recibe respuesta te va a decir que terminó de todas formas. Por eso NotchNull escribe status.json: el estado de cada widget, sus datos y su error, y cualquier ajuste que no pudo leer. El agente lee eso en vez de adivinar.

ukiyo hace lo mismo con errores tipados y snapshots estructurados en cualquier tick. Un fallo es algo que el agente puede leer, no un mensaje rojo en una pantalla que no ve.

3. El agente puede ver el resultado

Esta es la pieza que hace funcionar todo lo demás. notchnull render out.png --tab widgets dibuja el notch con los archivos reales en una imagen, así el agente ve lo que vas a ver tú y lo corrige antes de decir que terminó.

En ukiyo, ukiyo_capture devuelve frames reales del renderer, y un juego corriendo responde en localhost: pausar, avanzar un tick, snapshot, inyectar input, parchear la escena. El agente trabaja sobre el juego mientras corre, no sobre una descripción del juego.

Sin esto, cada cambio visual es una apuesta y el que revisa eres tú.

4. Los agentes rompen cosas, así que deshacer viene incluido

NotchNull copia tus archivos a backups/ la primera vez que corre una versión nueva y antes de aplicar cualquier preset. notchnull restore devuelve la última copia. ukiyo puede guardar en cualquier tick y rebobinar un juego en vivo.

No confío en un agente más de lo que confío en mí, y yo también rompo cosas. Poder deshacer es lo que hace seguro decirle que sí al agente rápido.

5. Cuando los archivos no alcanzan, el código está abierto

Los archivos cubren la mayoría de los pedidos. "Un gauge radial" o "una sección nueva en Settings" no caben en un JSON, así que necesitan el código Swift. NotchNull es open source y su skill explica dónde vive cada cosa, así que el agente cambia la app misma y la vuelve a compilar.

Una app cerrada se detiene justo ahí. Te quedas con los ajustes que otra persona decidió que ibas a necesitar.

Lo que cuesta

Más que una app normal. El formato de archivos ahora es un contrato público, así que no puedo renombrar una clave sin romper los widgets de alguien. Dibujar en un PNG significa que la app tiene que poder dibujar sin ventana. Cada ajuste necesita una referencia que el agente pueda leer; NotchNull genera settings.reference.md desde la app misma para que no se desactualice.

Y ukiyo está en pre-alpha. Las reglas aguantan en un notch y en un plataformero chico. Todavía no sé si aguantan en un juego grande.

Pruébalo con la tuya

Elige una app que hagas y pídele a tu agente que cambie algo que un usuario querría. Fíjate dónde se traba. Casi siempre es una de estas cinco: no encuentra el estado, no sabe si funcionó, no ve el resultado, tiene miedo de romper algo, o el código no está.

Las dos apps están en GitHub: NotchNull y ukiyo. Si hiciste algo que los agentes pueden cambiar, me gustaría ver cómo lo hiciste.