La gente está usando agentes de coding para hacer ingeniería inversa de dispositivos de casa y escribir su automatización en pocas horas. Algo que antes requería días de análisis sobre protocolos no documentados, y que casi nadie abordaba porque no valía la pena.

Simon Willison recopila las anécdotas y extrae el punto central: el costo de escribir código se ha desplomado, y eso cambia la ecuación.

Antes, entender cómo comunica un dispositivo sin documentación era viable pero antieconómico. El tiempo para descifrar la API superaba el valor de la automatización que conseguías. Y había un segundo problema: las APIs no documentadas cambian o se rompen, y había que rehacer todo el trabajo.

Con los agentes de coding el cálculo cambia. El costo de un primer intento es bajo, y el costo de reintentar si falla es igual de bajo. Si la API cambia en seis meses, tirar el código y reescribirlo cuesta una fracción de lo anterior.

Por qué te importa. Si tienes un dispositivo que hace algo útil pero la app del fabricante es terrible o restrictiva, el umbral a partir del cual vale la pena escribir tu propia automatización ha bajado. No necesitas ser un especialista en ingeniería inversa: solo necesitas capturar el tráfico de red del dispositivo (herramientas como Wireshark o un proxy HTTPS) y decirle al agente qué quieres lograr.

El límite es honesto: son anécdotas, no un benchmark. No sabemos cuántos dispositivos se prestan a este tratamiento ni cuánto durará el código en el tiempo. Pero la señal es coherente con lo que contábamos el 18 de julio: los agentes de coding salieron de las demostraciones y están cambiando qué vale la pena hacer.

En detalle

Cómo era antes.

Hacer ingeniería inversa en un dispositivo del hogar siempre fue posible. Enciendes Wireshark, capturas el tráfico entre la app del fabricante y el dispositivo, estudias el patrón de los mensajes, escribes un script que reproduce esos mensajes. Funciona. La gente lo hacía ya hace diez años.

El problema era el retorno. Descifrar un protocolo no documentado requiere horas, a veces días. Y un programador experimentado sabe que las APIs no documentadas son inestables: el fabricante puede cambiarlas con una actualización de firmware, y entonces todo tu trabajo se va al traste. Te ves metido en un ciclo frustrante de mantenimiento solo para controlar una bombilla.

Qué cambia.

Los agentes de coding reducen dos costos simultáneamente. El primero es el costo del intento: en lugar de pasar una tarde leyendo logs binarios, le describes al agente qué capturaste y le pides que escriba el código que reproduce el comportamiento. El segundo es el costo del fracaso: si el código no funciona, lo descartas e intentas de nuevo, porque reescribir cuesta poco.

El punto de Willison es psicológico además de económico. Cuando escribir código sale barato, la idea de tener que mantenerlo en el futuro (o descartarlo y empezar de nuevo) deja de pesar. La fricción mental que bloqueaba el bricolaje desaparece.

Cómo funciona para quien no programa.

Un dispositivo smart comunica con su app enviando mensajes por la red WiFi de casa. Si interceptas esos mensajes, ves un patrón: envía estos bytes, la luz se enciende; envía aquellos, cambia de color. Un agente de coding puede leer el registro de ese tráfico y escribir un script que hace lo mismo, sin pasar por la app oficial. El resultado es una automatización tuya, que puedes activar con un comando de voz, un temporizador, o un script del sistema.

Los límites de lo que sabemos.

La fuente es un post de blog que recopila anécdotas, no un estudio sistemático. Quedan abiertas tres preguntas concretas.

La primera: ¿cuántos dispositivos se prestan a este tratamiento? Muchos fabricantes ahora cifran el tráfico entre app y dispositivo, y si el protocolo está encriptado la interceptación se vuelve mucho más difícil.

La segunda: ¿cuánto durará el código en el tiempo? Una actualización de firmware puede cambiar el protocolo, y la automatización se rompe. El argumento de Willison es que reescribirla cuesta poco, pero queda por ver qué tan frecuente es en la práctica.

La tercera: nadie ha medido aún cuánto tiempo toma realmente. Las anécdotas hablan de “pocas horas”, pero no hay muestra suficiente para saber si es la norma o el caso afortunado.

Lo que es seguro es la dirección: el umbral de conveniencia ha bajado, y seguirá bajando. Para quien tiene un dispositivo que quisiera controlar mejor, vale la pena intentarlo.