Hoy el radar trajo una historia de policía que le prestó su acceso a un sistema de vigilancia a su marido, agente de ICE. Y esa historia se cruza con otra que apareció tres puestos más arriba: un ensayo que se llama, sin rodeos, "Someone behind the software". Parece que el día entero estuvo discutiendo lo mismo, aunque las noticias no lo digan con esas palabras.
Lo que une a los dos items no es la tecnología. Es la pregunta de quién está detrás. Detrás de un sistema de reconocimiento de patentes, detrás de un proxy de LLM, detrás de un release de Linux, detrás de una wiki de RepRap. Y lo que pasó hoy es que en varios frentes —vigilancia, inferencia, ciencia— la respuesta dejó de ser obvia. Las herramientas se volvieron lo bastante fáciles de correr como para que ya no haya excusa: o sabés quién está detrás, o estás confiando en que alguien ahí arriba se porte bien.
Vale la pena contarlo entero, porque el día tiene una forma reconocible: mucha infraestructura, poca magia.
🚔 Flock, ICE, y el login familiar
La noticia de WJCL es corta y demoledora: según documentos, una oficial de policía de Savannah le dio su credencial de Flock —la red de cámaras de lectura de patentes que se expandió por medio Estados Unidos— a su marido, agente de inmigración. No hubo hackeo. No hubo zero-day. No hubo un modelo que alucinó. Hubo una persona pasándole la contraseña a otra.
Lo no obvio no es la falla de seguridad, es el modelo de amenaza. Todo el debate sobre privacidad de la vigilancia algorítmica asume que los sistemas son técnicamente robustos y políticamente discutibles. Acá la vulnerabilidad fue un matrimonio. Y esa es exactamente la lección que el resto del día repite: los sistemas no se rompen por sus debilidades técnicas, se rompen por los humanos que los operan. Flock vende acceso a una red nacional de patentes; el acceso se puede transferir con un mensaje de texto. Eso no es un bug, es una arquitectura de confianza.
Si te quedás solo con "una policía hizo algo raro", perdés el punto. El punto es que la vigilancia distribuida tiene un problema de superficie de ataque que no se resuelve con mejores cámaras, sino con preguntarse quién puede consultar qué, y con qué registro. Y hoy, ese registro es tan bueno como la persona que lo completa.
🔧 Escribí tu propio proxy, o no sabés qué está pasando
El post con más karma del día (uno de ellos) tiene uno de los mejores títulos del año: "If you don't run your own LLM proxy, how the fuck do you even know what's going on?". La tesis es directa: si estás usando una API cerrada, con prompts y telemetría que no controlás, no tenés forma de auditar qué pasa entre tu request y tu respuesta. La única manera de saberlo es poner tu propio proxy en el medio.
Lo interesante es que este post no está solo. Aparece el mismo día que un tutorial de tmux para agentes de IA (sesiones persistentes, send-keys, y dónde está el techo de esa aproximación) y el mismo día que un laptop basado en CPU 6502. Tres niveles del mismo impulso: la gente quiere entender las piezas que usa, aunque sea solo para poder romperlas y arreglarlas. El 6502 es la versión extrema: un chip de 1975, documentado, replicable, sin abstracciones que oculten nada. La versión contemporánea es el proxy: no es nostalgia, es control.
Y hay una ironía ahí. En una industria que pasó los últimos tres años moviéndose a la nube y a las APIs, el movimiento de hoy es al revés: traer el borde de vuelta adentro. Correr el proxy, correr el modelo localmente, correr el agente en tu propio tmux. No porque sea más barato —a veces no lo es— sino porque es la única forma de responder la pregunta de Flock aplicada a tu propia infraestructura.
🧠 La inferencia se va a la ciencia, y la memoria se vuelve estructural
Los papers de hoy tienen un sesgo claro hacia la ciencia empírica. Self-Building Labs describe laboratorios autónomos que no solo ejecutan experimentos, sino que se construyen a sí mismos —agregan módulos, cambian su propio setup— para expandir lo que pueden testear. DrugHarness hace lo análogo en descubrimiento de drogas: un "harness" evolutivo que compone operaciones científicas y se adapta cuando la evidencia cambia. Y AI-Driven Reproducibility se pregunta si un agente LLM puede evaluar si un resultado científico es reproducible y robusto, una tarea que hoy consume meses de trabajo manual.
El hilo es que el agente dejó de ser un asistente que responde preguntas y empezó a ser infraestructura que modifica su propio entorno. Eso es más ambicioso de lo que suena. Un agente que se auto-construye tiene un problema de identidad: ¿qué queda del sistema original cuando el sistema cambia lo que puede hacer? Es la misma pregunta que el GLOBE del día, que evoluciona memoria estructurada para optimizar listados en búsqueda generativa, o la que plantea el paper de Behavioral Couplings: afinar un modelo para que sea más cálido lo vuelve más servil, sin que se lo hayan pedido. Los comportamientos no se agregan de a uno, se acoplan. Y si la memoria es estructural, y la estructura evoluciona, el sistema que tenés hoy no es el mismo que el de mañana, aunque el nombre sea igual.
Sumale a eso FuTransformer, FP8 en prefill y INT4 en decode sobre Hopper, y Timestral de Mistral, modelos fundacionales para series temporales. El mensaje de fondo es que la eficiencia y la especialización están reemplazando al gigantismo por el gigantismo mismo. Nadie está discutiendo quién tiene el modelo más grande. Están discutiendo quién puede correr qué, dónde, y a qué precio.
📺 RepRap, Linux 7.3, y la obra que sigue publicándose
Dos cosas más que no son noticia y sin embargo son lo más importante del día. El primero: RepRapMicron, un proyecto que intenta llevar la impresión 3D autorreplicable al nivel de las micras. RepRap siempre fue la utopía más linda y más incómoda del software libre: si una impresora se puede imprimir a sí misma, el capital deja de ser el cuello de botella. Llevarlo a escala micrométrica no es un juguete, es un experimento sobre qué se puede hacer con hardware que no depende de una cadena de suministro. Puede salir mal. Pero está publicado, y eso ya cuenta.
El segundo: Linux 7.3 salió y nadie va a hacer un post sobre eso. Un kernel líneas arriba en Hacker News, veinte años después de que empezara, y sigue saliendo. Es la mejor respuesta al ensayo "Someone behind the software": detrás del software no hay un genio, hay miles de personas haciendo commits que nadie va a famear. Y sin embargo, es el software que corre el resto de la historia. El proxy que levantás, el agente que dejás en tmux, la wiki de RepRap, todo eso corre sobre algo que alguien construyó y publicó sin esperar karma.
Hay una escena en Los increíbles (2004) que vuelve a explicar todo el día, aunque no parezca. Es la de "Edna Moda", la diseñadora que le dice a Bob que los capuchas vuelan, que los capuchas son un peligro, y que no, no hay nada que hacer al respecto. El problema no es el diseño del traje, le dice, el problema es cómo lo usa el humano que está adentro. Edna no construye superhéroes, construye la ropa que los superhéroes van a arruinar de alguna forma. Y está bien: su trabajo es diseñar para el peor caso, no para el mejor.
Hoy pasó eso. Flock diseñó una red de cámaras y alguien la usó con el peor caso. FuTransformer diseñó inferencia de bajo bit y el peor caso es que un modelo alucine más rápido. Los laboratorios auto-construidos están diseñados para el mejor caso, el del descubrimiento científico, y el peor caso todavía no está escrito. La lección no es que la tecnología esté mal. Es que la pregunta de "quién está detrás" no se responde en el repo ni en el paper: se responde en el uso. Como el capucha del traje de Edna, no es la tela, es el cuello.
Y lo lindo del día es que la respuesta está al alcance. Corré tu proxy, leé el kernel, mirá la wiki de RepRap. En la escena de Edna, Bob también podría haberse puesto el traje de otra forma. No lo hizo, y aprendió. Nosotros todavía estamos a tiempo.
— ¿Y vos sabés quién está detrás de las herramientas que usás hoy, o confiás en el capucha?