Federico Carrone

Ganamos las elecciones en la Facultad de Ingeniería de la UBA

2026-10-20T00:00:00+00:00

Acabo de aterrizar en Buenos Aires. Ayer estaba en Cambridge en workshops de Ethereum sobre criptografía post-cuántica, verificación formal y finalidad rápida (fast finality). Hoy volví a casa para un hito que llevó dieciocho años.

Resolver el fútbol como si fuera ajedrez

2026-07-05T00:00:00+00:00

El fútbol europeo se pasó los últimos quince años resolviendo el juego como si fuera ajedrez.

Una generación de entrenadores optimizó el porcentaje de pases acertados, los gatillos de presión, el control territorial, las vigilancias y la ocupación posicional. El problema es que optimizaron lo medible. Atacar el espacio temprano, intentar el pase difícil, gambetear a un defensor, generar caos a propósito: son jugadas de alta varianza. Salen mal más veces de las que salen bien. Si evaluás a los jugadores por porcentaje de acierto, retención de la pelota o disciplina posicional, esas acciones parecen errores. Entonces los técnicos se las sacan. Con el tiempo, todos convergen hacia el mismo óptimo local.

Etiquetas nutricionales para la confianza

2026-06-13T00:00:00+00:00

El hombre de la foto al principio de esta página está haciendo uno de los trabajos de verificación más viejos que existen. Es un inspector de pesas y medidas de Seattle, y en 1916 está probando la balanza de un comerciante contra un carro de pesas patrón, porque lo que marca el brazo es una afirmación y el peso conocido es la evidencia. No confía en el comerciante. Confía en las pesas.

Un siglo después, casi todo nuestro software nos pide que confiemos en el comerciante. Viene con un nombre, un logo, una frase tranquilizadora sobre seguridad, y ningún inspector por ningún lado. La cuenta por confiar en el comerciante llega en forma de backdoors en la cadena de suministro (supply chain), dependencias que nadie auditó e insignias de “verificado” que resultaron significar una revisión de marketing, y suele llegar tarde y toda junta.

Vitalik Buterin puso la inspección que falta en una sola oración:

En un mundo ideal, todo el software y el hardware tendrían “etiquetas nutricionales” con la lista completa de dependencias de confianza: en qué matemática y en el comportamiento honesto de qué actores (y en qué escala de tiempo) se apoya el sistema para dar su funcionalidad central y las garantías implícitas.
Vitalik Buterin (@VitalikButerin)</a> </blockquote>
binji respondió con la objeción obvia, y después con algo más interesante:

aunque esto existiera, igual podría terminar generando una carga cognitiva que muchos ignorarían, así que seguirían eligiendo sistemas que preseleccionan por ellos. lo ves con las etiquetas nutricionales y las dietas, etc., donde la mayoría prefiere la comodidad de que le den una canasta de “cosas para comer” de una fuente verificada (médicos, nutricionistas… influencers).
pero acá es donde el mundo agéntico se pone interesante: a medida que la ia se vuelve la nueva ui, va a ser clave la necesidad de agentes que preserven la privacidad, personalizados según las preferencias de cada usuario, que puedan manejar la carga cognitiva para complementar sus decisiones mientras prueban con lógica verificada cómo llegan a esa conclusión.
se siente como una gran oportunidad de intersección en general, y es una mezcla de verificación, privacidad, toma de decisiones asistida por agentes e higiene general de la web
binji (@binji_x)</a> </blockquote>
Ese intercambio divide el problema de manera limpia. Vitalik pide el artefacto: ¿de qué depende este sistema? binji pregunta quién se supone que lo va a leer sin convertir a cada usuario en un ingeniero de seguridad. Concrete</a>, el lenguaje de programación sobre el que vengo escribiendo, está entre esas dos preguntas. No resuelve todo. Construye la parte que nunca debería haber sido prosa.

Ideas clave

Una etiqueta nutricional de confianza debería ser un artefacto del compilador, no prosa del proveedor. Concrete ya produce la mitad de código y matemática de una como subproducto de compilar.</li>
La etiqueta tiene campos reales: las capabilities (capacidades) que usa un programa, cada frontera trusted y unsafe, y una clase de evidencia por obligación (probada, asumida o trusted), hasta llegar a una trusted computing base con nombre y los axiomas en los que se apoyan las pruebas.</li>
Es verificable, no declarada. Los reportes son deterministas y concrete diff</code> falla cerrado (fails closed) cuando la confianza se debilita entre versiones.</li>
Se detiene a propósito en una mitad. No dice nada sobre en qué actores confiás ni por cuánto tiempo, y la verificación es parcial: el backend y el binario final siguen siendo trusted. El resultado es “esto es lo que está probado, con qué, y lo que no”.</li>
Para los agentes, eso significa que la confianza debería venir del artefacto verificado por el kernel, no de la palabra del agente.</li> </ul> </aside>#</a>Dos tipos distintos de confianza</h2> La etiqueta de Vitalik en realidad pide dos listas. Una es técnica: ¿en qué pruebas, componentes, llamadas externas, permisos y máquinas se apoya este sistema? La otra es social: ¿qué personas o instituciones tienen que comportarse honestamente, y por cuánto tiempo? No son el mismo problema. Concrete trabaja sobre la primera lista. No dice nada profundo sobre incentivos, colusión, gobernanza, o si algún actor se mantiene honesto durante seis meses. Pero la lista técnica ya es suficiente trabajo, y es la parte que un compilador puede producir de verdad. #</a>Una etiqueta generada por el compilador</h2> Concrete está construido alrededor de un hábito simple: cuando el programa hace una afirmación, el compilador debería guardar el comprobante. Un contrato, una capability, una frontera trusted, un chequeo de seguridad en tiempo de ejecución: cada uno se vuelve algo sobre lo que la herramienta puede reportar. Compilar debería dejar más que un binario. Debería dejar un registro de lo que el programa usó y de qué evidencia respalda cada afirmación. Ese registro tiene campos reales, no eslóganes. Una porción chica podría verse así: function: parse_config capabilities: File trusted_boundaries: - trusted extern fn os_read obligations: O1 array_bounds buffer[i] evidence: proved_by_kernel_decision engine: omega O2 ensures result_is_valid_config evidence: assumed O3 proof link Config.Proofs.parse_config_shape evidence: stale reason: body fingerprint changed tcb: - Concrete checker - Lean kernel - proof attachment and fingerprint machinery - LLVM/backend/runtime/OS/hardware</code></pre> La sintaxis de arriba es ilustrativa, pero las categorías son reales: autoridad, frontera trusted, obligación, clase de evidencia, prueba desactualizada (stale), base trusted. La etiqueta sale del programa y de los artefactos de prueba. Nadie la escribe después como un párrafo de compliance. Capabilities. Concrete registra los efectos como un vocabulario visible de capabilities: los permisos concretos File</code>, Network</code>, Process</code>, Console</code>, Time</code>, Random</code>, Env</code>, Alloc</code> y Unsafe</code>, más una macro Std</code> que se expande al conjunto estándar y alias definidos por el usuario que se expanden en tiempo de parseo. Una función sin anotación es pura. Una función que hace asignación de memoria (allocation) en el heap tiene que decir with(Alloc)</code>. Una función que toca la red tiene que decir with(Network)</code>, y lo mismo todo lo que la llame de forma transitiva. La etiqueta no puede reportar de menos, porque un programa que usa un efecto que no declaró no compila. Fronteras trusted. Cada lugar donde el programa sale de lo que el checker puede garantizar está marcado y se puede ubicar: trusted fn</code>, trusted impl</code>, trusted extern fn</code>, y las funciones o llamadas que llevan with(Unsafe)</code>. Le podés pedir al compilador que las enumere, y te responde con una lista y rangos de código fuente (source spans) en lugar de encogerse de hombros. “Hace trucos con punteros internamente” y “puede llamar código externo arbitrario” son riesgos distintos, y tienen marcadores distintos. Clases de evidencia. Mi detalle favorito es que no hay una única tilde verde. Cada obligación dice cómo se justifica: proved_by_lean</code> para un teorema verificado por el kernel, proved_by_kernel_decision</code> para un procedimiento de decisión, solver_trusted</code> para el resultado de un solver externo, tested_by_oracle</code>, assumed</code>, trusted</code>, stale</code>, unproven</code>, y más. “Esto pasa el type checker”, “esto está probado” y “acá estamos confiando en el autor” son afirmaciones distintas. Concrete las mantiene separadas. Es la distinción del inspector devuelta al software: la balanza que probaste, la que no, y la que elegís aceptar de buena fe. Nada de eso es pseudocódigo, así que acá está la mitad de autoridad en Concrete real. Una llamada externa es una frontera con nombre y auditada que declara el efecto que ejerce; una función que toca la consola tiene que decirlo; y el requisito sube solo por el grafo de llamadas: trusted extern fn putchar(c: i32) with(Console) -> i32; // foreign boundary, audited fn show_int(n: i64) with(Console) { print(n); } // needs Console fn greet() with(Console) { show_int(42); } // inherits it from show_int fn main() with(Std) -> Int { greet(); return 0; }</code></pre> Borrá with(Console)</code> de greet</code> y el programa deja de compilar, porque greet</code> llama a algo que lo necesita. La autoridad no es un comentario que puede quedar desactualizado. Es parte del tipo, y se vuelve a verificar en cada edición. #</a>La etiqueta lleva pruebas, no solo declaraciones</h2> Una pantalla de permisos dice que una app puede usar la red. Un software bill of materials dice que un binario contiene cierta biblioteca en cierta versión. La etiqueta de Concrete puede decir algo que una lista de dependencias no puede: que una propiedad específica de una función específica fue probada mecánicamente, y con qué. El mecanismo es el diseño por contrato de siempre, apuntado a la verificación. Una función lleva cláusulas #[requires]</code> y #[ensures]</code> e invariantes de ciclo. Cada una se vuelve una obligación de prueba con un identificador estable. Una precondición se asume a la entrada de la función y se expone en cada llamador, así que no se puede descartar en silencio; según la política activa, el llamador o la descarga o carga con una obligación explícita sin probar. Cómo se descarga es donde la versión de marketing normalmente empezaría a mentir. Concrete pone el kernel primero. Los procedimientos de decisión omega</code>, para aritmética entera lineal, y bv_decide</code>, para vectores de bits, producen certificados que se verifican dentro del toolchain, así que usarlos no suma ningún solver externo a la base trusted. Pero las salvedades siguen a la vista. bv_decide</code> depende de un checker LRAT compilado, lo que trae un nivel con nombre de confianza en código nativo; no es reducción pura del kernel, y el inventario de axiomas lo dice. Concrete también puede pasarle una condición a un solver SMT externo. Cuando lo hace, el resultado se etiqueta solver_trusted</code>, y ese binario del solver pasa a ser parte de la base trusted para esa obligación. La confianza no desapareció. La etiqueta te dice qué tipo de confianza acabás de usar. concrete prove</code> es el flujo de trabajo que hace esto usable. Genera un workspace de pruebas en Lean para una función, vincula los teoremas registrados con sus obligaciones, y soporta replay para que una prueba quede atada al código fuente exacto contra el que se escribió. Una huella (fingerprint), hoy un SHA-256 truncado sobre la estructura de la función, detecta cuando el código se mueve por debajo de su prueba, y la clase de evidencia pasa a stale</code>. La etiqueta no puede seguir diciendo “probado” sobre una función que cambió desde entonces. Acá está la mitad de pruebas en código real, igual de chica. Una rotación de bits cuya precondición dice que el desplazamiento tiene que quedar dentro del rango: #[requires(0 < n && n < 32)] fn rotr(x: u32, n: u32) -> u32 { return (x >> n) | (x << (32 - n)); }</code></pre> Ese #[requires]</code> no es un comentario ni un assert en tiempo de ejecución. El compilador lo convierte en una obligación, la empuja a cada llamador, y después reporta, un punto de llamada a la vez, cómo cada llamada la descarga. Este es --report contracts</code> para cuatro llamadores, uno por caso: === Call-site obligations === main.in_range call rotr(x, 13) requires 0 < 13 && 13 < 32 status: proved_by_kernel_decision engine: constant_fold (precondition constant-folds true) main.fixed_by_let call rotr(x, n) requires 0 < n && n < 32 status: proved_by_kernel_decision engine: bv_decide main.out_of_range call rotr(x, 40) requires 0 < 40 && 40 < 32 status: counterexample engine: constant_fold (precondition constant-folds false at this call site) main.unknown call rotr(x, k) requires 0 < k && k < 32 status: unproven_at_callsite (caller does not establish the precondition)</code></pre> Cuatro llamadas, cuatro veredictos honestos. Una constante dentro del rango se reduce a probada. Un valor fijado antes por un let</code> se le pasa a un procedimiento de decisión y se cierra con evidencia verificada. Una constante fuera de rango se reporta como contraejemplo (counterexample</code>), y la política puede convertir eso en una falla dura. Un argumento que el compilador no puede precisar queda unproven</code>, etiquetado exactamente así, nunca redondeado en silencio a que está todo bien. La última línea es la que más importa: la etiqueta prefiere decirte que no sabe antes que contarte una mentira reconfortante. Es el inspector que marca una balanza como no probada porque el control no fue concluyente, en lugar de dejarla pasar. Volvamos al ejemplo de la configuración. El hecho útil no es que el programa esté “verificado”. Es que su autoridad File</code> es visible, que se verifica que no tiene autoridad Network</code> ni Alloc</code>, que su frontera con el sistema operativo tiene nombre, que una obligación de límites la descarga omega</code>, que una afirmación semántica de parseo está solo assumed</code>, y que una prueba vieja quedó stale</code>. Seis hechos, seis tipos distintos de confianza, ninguno colapsado en una tilde. Aprendés más de eso que de una insignia verde de “verificado”, justamente porque te muestra dónde la insignia habría estado mintiendo. La palabra “verificado” tiene que mantenerse disciplinada. Las capabilities y las fronteras las impone o las reporta el sistema de tipos. Eso es útil, pero no es lo mismo que una prueba. Un contrato que llega a proved_by_lean</code> o proved_by_kernel_decision</code> tiene detrás un argumento verificado por máquina. La etiqueta mantiene esos casos separados para que lo impuesto no se haga pasar por probado. #</a>La etiqueta se incluye a sí misma</h2> La mejor parte es que Concrete se aplica la misma sospecha a sí mismo. Nombra la trusted computing base: las capas en las que tenés que confiar para que cualquier prueba signifique algo. El checker y el compilador. El kernel de Lean. La maquinaria de vinculación de pruebas y de huellas. El backend LLVM. El runtime, el sistema operativo, el hardware. Y el código externo detrás de cada extern fn</code>. La mayoría de los sistemas esconden esta lista. Concrete la pone por escrito, y sus reportes marcan cada función trusted y cada resultado de un solver que la agranda. Ken Thompson dio la razón en su conferencia del Premio Turing de 1984. No podés confiar del todo en código que no escribiste vos mismo, y la podredumbre puede llegar hasta el compilador: un compilador puede llevar un backdoor que sobrevive incluso después de que su propio código fuente quede limpio, reconociendo cuándo se está compilando a sí mismo y reinsertando el truco en silencio. Eso no hace que la confianza sea imposible. Significa que “confiá en mí, el compilador está limpio” no es una respuesta. Tenés que nombrar a qué te compromete confiar en el compilador. Un compilador que nombra su propia base trusted y verifica los axiomas en los que se apoyan sus pruebas es la pregunta de Thompson respondida en voz alta en lugar de esquivada. Hasta verifica los axiomas. Un control de inventario de axiomas corre sobre cada teorema y hace fallar la CI ante cualquier cosa no documentada. Los supuestos matemáticos en los que las pruebas tienen permitido apoyarse tienen nombre: propext</code>, Classical.choice</code>, Quot.sound</code>, y el nivel marcado de confianza en código nativo para la verificación de certificados compilados. Esa es la respuesta literal al “en qué matemática te estás apoyando” de Vitalik, extraída automáticamente en lugar de declarada en un README. La etiqueta también se puede regenerar. Mismo código fuente, mismos reportes. concrete diff</code> compara dos versiones y avisa cuando la confianza se debilita, cuando una prueba queda desactualizada, cuando la autoridad escala, cuando una frontera se erosiona. Una etiqueta que podés regenerar y comparar es evidencia. Una que no, es marketing. #</a>Lo que no cubre</h2> Esta es la parte que prefiero decir yo antes de que me la marques vos. Concrete no modela para nada la segunda mitad de la etiqueta de Vitalik. No hay noción de actores, incentivos, colusión, honestidad hasta cierto momento, ni confianza social en ningún lado. Su contabilidad es estática, sobre en qué capas y en qué matemática confiar, no dinámica, sobre qué humanos se portan bien y por cuánto tiempo. La mitad de actores y escalas de tiempo es un problema real y separado, y le corresponde al diseño de mecanismos y a la economía, no a un lenguaje de sistemas. La verificación también es parcial, y la etiqueta lo dice. Las pruebas se vinculan al nivel del contrato y del modelo de prueba, sobre una representación intermedia y un modelo idealizado de enteros. La cadena desde ahí, pasando por el backend, hasta el binario final es trusted, no verificada, y la corrección del binario figura abiertamente entre las cosas que Concrete declara explícitamente que no afirma. Muchas obligaciones todavía están missing</code> o terminan en una prueba de Lean escrita a mano en lugar de una descarga automática. Así que la afirmación no es “Concrete prueba que tu programa es correcto de punta a punta”. Es más chica y más útil: Concrete prueba afirmaciones seleccionadas sobre su modelo de prueba, y después te dice qué propiedades están probadas, con qué, en qué base trusted se apoyan, y qué propiedades no están probadas en absoluto. Eso vale más que una insignia verde. #</a>Quién lee la etiqueta</h2> La objeción de binji es correcta y sobrevive incluso a una etiqueta perfecta. Las etiquetas generan carga cognitiva, la mayoría de la gente las ignora, y termina recurriendo a una canasta armada por alguien en quien confía. Pasa con las etiquetas de los alimentos y con las dietas, y pasaría también con las etiquetas de confianza. Un manifiesto que nadie lee es decoración. Pero su respuesta apunta al tipo de artefacto que produce Concrete. Quiere agentes que carguen con el peso cognitivo mientras muestran lógica verificada para sus conclusiones. Para que eso funcione, el agente necesita hechos estructurados que no haya inventado él. La etiqueta de Concrete la puede consumir una máquina. Tiene identificadores, rangos de código fuente, dependencias y clases de evidencia. Un agente la puede leer directamente. La carga cognitiva que le preocupa a binji es un problema para un humano mirando una pared de hechos, no para un software que filtra esos hechos según la política de un usuario. Y las conclusiones más fuertes de Concrete llegan con pruebas que el kernel ya verificó, o con etiquetas explícitamente más débiles cuando no. binji quiere que el agente pruebe la lógica detrás de su recomendación. Con Concrete, la evidencia de prueba que sostiene todo se verificó de forma independiente de cualquier agente. No hace falta confiar en que el agente produzca esa evidencia. Solo tiene que señalar evidencia que ya existe y que no puede falsificar sin cambiar el artefacto. #</a>La confianza debería venir del artefacto, no del agente</h2> Esto cambia el rol del agente. La historia habitual hace del agente la cosa en la que tenés que confiar: alinearlo, auditarlo, creerle. Concrete empuja parte de la confianza hacia abajo, al artefacto. El trabajo del agente pasa a ser más chico. Lee hechos que no puede falsificar fácilmente y les aplica la política del usuario. La división es simple. Concrete produce la entrada verificada. El agente aplica las preferencias del usuario. El kernel de Lean ancla la evidencia más fuerte. Las capas trusted que quedan tienen nombre en lugar de estar escondidas. El agente sigue sin ser magia, pero al menos está leyendo hechos anclados fuera de sí mismo. Una línea más para no venderlo de más. Concrete responde el problema de la entrada: hechos confiables sobre un artefacto. No responde el problema de alineación: si el agente sirve fielmente al usuario. Puede hacer que las entradas del agente sean más difíciles de falsificar. No hace que el agente sea bueno. #</a>Los ingredientes, no solo el plato</h2> Todo lo de arriba etiqueta un programa que escribiste vos. Pero la dependencia de confianza que de verdad muerde es la que no escribiste: el parser que en silencio empieza a escribir logs a disco, el helper de hash que agrega una llamada de red “para telemetría”, la dependencia cuya prueba se degrada en silencio entre versiones. La frase de Vitalik es “una lista completa de dependencias de confianza”, y en la práctica tus dependencias son tus imports. La canasta de ingredientes de binji es la lista de imports. Las notas de diseño de Concrete dan el paso siguiente, y quiero ser exacto: esta parte está escrita como una dirección, todavía no está implementada. El principio es que un import no debería otorgar poder en silencio. Debería decir qué trae y qué tiene prohibido traer. Así que un import lleva un techo y un piso: // sketch: proposed syntax, not implemented yet import std.parse requires(no File, no Network, no Unsafe) import hmac.compute requires(proved_by_lean) import crypto.compare requires(constant_time, no secret_sink)</code></pre> y un manifiesto fija un presupuesto de autoridad para todo el proyecto: # sketch: proposed manifest section, not implemented yet [authority] allowed = ["Alloc"] forbidden = ["File", "Network", "Process", "Unsafe"]</code></pre> Ahora el desvío falla cerrado. Si el parser gana autoridad File</code>, o la evidencia del helper de hash baja de proved_by_lean</code> a assumed</code>, el build se detiene y exige un cambio explícito en la restricción. Ese es el backdoor en la cadena de suministro del principio de este post, atrapado en tiempo de compilación en lugar de explicado en un postmortem. Las capabilities, los contratos y las clases de evidencia existen hoy; los imports acotados y los presupuestos de autoridad son un diseño en papel, no una funcionalidad que puedas correr. Pero la dirección es lo central, porque es donde la etiqueta deja de describir un programa y empieza a describir todo el árbol de dependencias, que es el único nivel en el que “una lista completa de dependencias de confianza” es realmente cierto. #</a>Las etiquetas deberían ser artefactos del compilador</h2> Las etiquetas de confianza del software no deberían ser prosa del proveedor. Deberían ser artefactos del compilador: deterministas, comparables con diff, y respaldados por evidencia verificada por máquina en todos los lugares donde se hacen las afirmaciones fuertes. Concrete muestra cómo se ve eso para capabilities, contratos, obligaciones de prueba, clases de evidencia, axiomas y fronteras trusted. Es el mismo argumento que un compilador que produce hechos</a> y cuando el compilador es el oráculo</a>, apuntado a una conversación que está pasando en otro lado. El mundo de los lenguajes de sistemas y el mundo de la confianza cripto están dando vueltas alrededor del mismo objeto desde lados opuestos. Uno quiere que el software emita un manifiesto verificable de lo que depende. El otro quiere un lenguaje donde ese manifiesto salga de la compilación. Concrete no resuelve la mitad de los actores honestos, y no pretende hacerlo. Toma la mitad que se puede mecanizar y la mecaniza: la parte que el CI puede rechazar, que un revisor puede comparar con diff, y sobre la que un agente se puede parar sin pedir que le crean. Actualizado en octubre de 2026 para reflejar el compilador actual: la capability Clock</code> ahora se llama Time</code>, los veredictos en los puntos de llamada usan las clases de evidencia canónicas, la precondición de rotr</code> excluye el desplazamiento cero, el ejemplo de código compila tal como está, y la trusted computing base se describe como documentada, no impresa.

Una prueba vale lo que vale su spec 2026-06-06T00:00:00+00:00 Quiero que Ethereum tenga más verificación formal, no menos. Por eso escribo esto.


La disciplina sin amor optimiza la variable equivocada
2026-05-21T00:00:00+00:00
El último año y medio, pero sobre todo los últimos seis meses, fueron increíbles pero también muy, muy duros. Pasé por problemas personales difíciles y tuve que ampliar mi tolerancia al dolor hasta extremos que no sabía que existían. Al dolor no lo combatís endureciéndote. Lo combatís controlando qué dejás que se te acerque. Dejé el alcohol, bajé el café al mínimo indispensable, borré mi Instagram y saqué de mi vida a la mayoría de la gente que no me importaba, y redoblé la apuesta por vivir con los amigos, la familia y las parejas que amo.</p>
Mi papá me dijo varias veces que viví varias vidas en una. Es muy probable que él tenga algo de responsabilidad en esto, porque de chico me obsesioné con las aventuras gracias a Julio Verne. Quería explorar. Viajé a lugares y conocí gente que solo ves en pesadillas. Después de quemarme y casi morirme varias veces creé LambdaClass</a> y ahora Ergodic Group</a>. Esas veces que casi me muero no fueron solo dolor. Cada una me enseñaba lo mismo: convertí esto en algo que te sobreviva, o fue solo daño. Estoy tratando de hacer lo mismo ahora con lo que me pasó las últimas semanas.</p>


Blockspace Forum Cannes: Fede y Justin Drake
2026-04-22T00:00:00+00:00



Un compilador que produce hechos
2026-04-09T00:00:00+00:00

Nota de la serie: este artículo es parte de la serie Concrete y responde a Giving LLMs a Formal Reasoning Engine for Code Analysis</a>, de Dmitri Sotnikov.
Relacionados: Cuando el compilador es el oráculo</a> y Por qué existe Concrete</a>.</p>
</blockquote>
Cuando un agente de IA explora una base de código, normalmente hace grep de nombres, lee algunas coincidencias, busca quién llama a qué, lee eso, y trata de armarse un modelo mental del programa a partir de fragmentos de texto. Funciona más o menos tan bien como te imaginás. El agente está haciendo preguntas estructurales sobre un programa, cosas como “¿puede la entrada del usuario llegar a esta consulta SQL?” o “¿qué cambia si toco esta función?”, pero la única herramienta que tiene es la búsqueda de texto.</p>
Ayer leí el artículo</a> de Dmitri Sotnikov sobre darles a los LLMs un motor de razonamiento simbólico para analizar código. Su herramienta, Chiasmus</a>, parsea código fuente con tree-sitter (un parser sintáctico), convierte definiciones y llamadas en hechos lógicos, y deja que un LLM corra consultas (queries) sobre grafos en lugar de hacer grep por los archivos. Es una interfaz mucho mejor: el agente hace una pregunta estructural y recibe una respuesta estructural.</p>
Leer el post me dio una mejor frase para parte de lo que estamos construyendo con Concrete: un compilador que produce hechos</strong> (fact-producing compiler).</p>
Concrete es el lenguaje de programación de sistemas que estamos construyendo para programas que necesitan ser auditables. Compila el código a un ejecutable y a afirmaciones verificadas sobre lo que ese ejecutable puede hacer.</p>


CommitLLM: cómo verificar una inferencia de un LLM
2026-04-02T00:00:00+00:00
Mandás un prompt a una API de un LLM. El proveedor dice que corrió Llama 70B. Tal vez lo hizo. Tal vez sirvió un modelo más chico para ahorrar plata, cambió la cuantización, modificó la configuración de decodificación o retocó la respuesta después de generarla. Hoy en general no tenés forma de saberlo. Recibís texto, una factura y una promesa.</p>
Para un uso casual, una promesa muchas veces alcanza. Para compras empresariales, sistemas regulados, evaluación de benchmarks o flujos de agentes que toman decisiones con consecuencias, no alcanza. Si importa qué modelo está detrás de la respuesta, “confiá en nosotros” no es una interfaz satisfactoria.</p>


Lo que Concrete empeora
2026-03-24T00:00:00+00:00

Nota de la serie: esta es la entrega sobre las concesiones (tradeoffs) en la serie Concrete.
Para los fundamentos, empezá por Por qué existe Concrete</a>. Para la demo más práctica, leé Cuando el compilador es el oráculo</a>.</p>
</blockquote>
Los artículos anteriores de esta serie sostuvieron que las restricciones de diseño de Concrete valen la pena. Las capabilities (capacidades) explícitas hacen que el código sea auditable. Los tipos lineales evitan fugas de recursos en tiempo de compilación. Que no haya comportamiento oculto significa que el compilador puede informar lo que tu programa realmente hace. Creo todo eso. Pero hace suficiente tiempo que escribo código en Concrete como para saber dónde muerden las restricciones, y no fui lo bastante honesto sobre eso en público.</p>
Este artículo es sobre lo que Concrete empeora. No en teoría, no como un abstracto “es más estricto”. Código concreto que es más feo, más largo o más penoso de escribir en Concrete que en Rust o Zig. Si estás evaluando si estas concesiones valen la pena para tu dominio, merecés ver el costo de entrada.</p>


Cuando el compilador es el oráculo
2026-03-20T00:00:00+00:00

Nota de la serie: esta es la puerta de entrada más práctica a la serie sobre Concrete.
Si primero querés el manifiesto más corto, leé Por qué existe Concrete</a>. Si querés la referencia del lenguaje que está detrás de este artículo, usá la especificación de Concrete</a>.</p>
</blockquote>
Hace un tiempo que vengo construyendo Concrete</a>. Esta semana pasó algo que no tenía planeado, y puede terminar importando más que las cosas que me propuse construir a propósito.</p>
Dejé que un agente de IA mejorara un programa en Concrete usando como feedback solamente los reportes del compilador. Sin profiler. Sin benchmarks. El agente leía lo que el compilador sabía del programa, probaba refactorizaciones, verificaba si las respuestas del compilador mejoraban, y se quedaba con el cambio o lo revertía. Funcionó mejor de lo que esperaba. El compilador había dejado el espacio de búsqueda lo suficientemente limpio como para que el agente no tuviera que andar a ciegas entre la niebla de los benchmarks.</p>
Eso apunta a por qué Concrete es útil en primer lugar. Un lenguaje que hace explícitas la autoridad, la asignación de memoria (allocation), las fronteras de confianza (trust boundaries) y la superficie de prueba es más fácil de auditar, más fácil de optimizar y más fácil de automatizar. No tenés que reconstruir la verdad a partir de trazas de profiler, documentación desactualizada e intuición de los revisores. El compilador te puede decir qué es cierto sobre el programa, y eso cambia cómo construís software de sistemas. Para explicar por qué, tengo que empezar por qué es Concrete y qué lo hace distinto.</p>


Tus primeras demostraciones en Lean
2026-03-20T00:00:00+00:00
El primer artículo</a> de esta serie explicó la correspondencia de Curry-Howard: las proposiciones son tipos, las demostraciones son programas. El segundo</a> construyó un demostrador de teoremas (theorem prover) diminuto desde cero en Python. El tercero</a> metió las mismas ideas dentro del sistema de tipos de Julia.</p>
Ahora usamos la herramienta de verdad. Este artículo toma exactamente los mismos teoremas que demostraste a mano en Python y los muestra en Lean 4. Vas a ver qué cambia y qué queda igual: la sintaxis se mueve, la lógica no.</p>


Programar un mini-Lean en el sistema de tipos de Julia
2026-03-19T12:00:00+00:00
Este artículo está basado en la charla de Guillermo Angeris “Programming a (mini-)Lean in Julia’s type system”</a>.</p>
Un demostrador de teoremas (theorem prover), reducido a su motor, es un kernel de confianza chiquito, un type checker y una frontera entre los dos.</p>
Guillermo Angeris responde a esto programando en vivo, dentro de Julia, un kernel de juguete para demostrar teoremas que ilustra cómo funciona Lean en términos de arquitectura. El resultado es un kernel chiquito que hace visible la frontera de confianza: si aceptás el kernel, entonces todo lo que se construya encima tiene que pasar por el type checker.</p>
Este es el tercer artículo de la serie Demostración de teoremas</a>. El primer artículo</a> cubre la correspondencia de Curry-Howard. El segundo</a> implementa un demostrador chiquito de forma explícita en Python. Este artículo mete esas mismas ideas dentro del sistema de tipos de un lenguaje anfitrión.</p>


Construyendo un pequeño demostrador de teoremas en Python
2026-03-19T00:00:00+00:00
El primer artículo</a> de esta serie explicó la correspondencia de Curry-Howard: las proposiciones son tipos, las demostraciones son programas. Eso te dice por qué</em> la demostración de teoremas encaja tan naturalmente con los lenguajes de programación. Todavía no te dice cómo es la máquina.</p>
Un demostrador de teoremas (theorem prover), en concreto, es más chico de lo que la mayoría espera. Un pequeño demostrador de teoremas es apenas:</p>

un lenguaje para términos</li>
un lenguaje para tipos / proposiciones</li>
un checker que decide si un término tiene un tipo</li>
un kernel de confianza, chiquito, que define las jugadas legales</li>
</ol>
Este artículo construye esa arquitectura en Python puro. No estamos abusando del propio sistema de tipos de Python. Python es solo el lenguaje de implementación. El demostrador que construimos tiene sus propios</em> términos, sus propias</em> proposiciones y su propio</em> checker.</p>
Esa distinción importa. El objetivo acá no es lucirse con trucos del lenguaje anfitrión. Quiero que las piezas móviles sean imposibles de pasar por alto.</p>


Programas autorreplicantes que emergen del ruido aleatorio
2026-03-18T00:00:00+00:00
La mayoría de los programadores piensa que la Turing completitud (Turing completeness) es el umbral interesante para un sistema computacional. Se lleva toda la atención. Pero hay un umbral más bajo y más raro que importa más para el origen del comportamiento complejo: la autorreplicación.</p>
Un paper reciente</a> de Agüera y Arcas et al. muestra que los programas autorreplicantes emergen espontáneamente de sopas de código aleatorio. Nadie los diseña. Ninguna función de fitness los selecciona. Se arman solos a partir del ruido, toman la sopa y siguen evolucionando. Reproduje el resultado central en unas 300 líneas de código.</p>


Las proposiciones son tipos, las demostraciones son programas
2026-03-18T00:00:00+00:00
En la década de 1930, Haskell Curry notó algo raro. Estaba trabajando en lógica combinatoria, un sistema para manipular funciones abstractas, y se dio cuenta de que las reglas que gobernaban sus combinadores se veían idénticas a las reglas de un sistema lógico llamado lógica proposicional intuicionista. Era como si hubiera encontrado dos mapas distintos del mismo territorio.</p>
Tres décadas después, William Howard encontró lo mismo en un contexto más rico. Mostró que el cálculo lambda simplemente tipado, la base de la programación funcional, se corresponde exactamente con la deducción natural, un sistema estándar de demostración lógica. Cada tipo corresponde a una proposición. Cada programa corresponde a una demostración. Cada función corresponde a una implicación.</p>
Esta es la correspondencia de Curry-Howard</strong>: una identidad estructural entre demostraciones y programas.</p>


La guía de Fede para una vida más sana
2026-03-13T00:00:00+00:00
De chico me encantaban la ciencia y la ingeniería. Como la mayoría de los nerds, pensaba que lo único que importaba era pensar. Entrenar me parecía un proyecto de vanidad, algo para gente a la que le importaba cómo se veía y poco más. No entendía para nada la conexión entre el cuerpo y la mente. Era un pibe flaco que se pasaba el día leyendo, metiéndose con computadoras y saliendo con amigos. La idea de que la salud física pudiera afectar lo bien que pienso me habría sonado a disparate.</p>
Me llevó mucho tiempo darme cuenta de lo equivocado que estaba.</p>


¿Puedo probar programas de Concrete en Lean?
2026-03-12T00:00:00+00:00

Nota de la serie: esta es la entrega sobre la hoja de ruta de pruebas en la serie Concrete.
Para una visión general del lenguaje, empezá por Por qué existe Concrete</a> y la Especificación de Concrete</a>. Para la demo más práctica de los reportes del compilador, leé Cuando el compilador es el oráculo</a>.</p>
</blockquote>
Escribí la primera versión de este ensayo cuando probar programas de Concrete</a> en Lean todavía era sobre todo un plan. La pregunta era simple y un poco arriesgada: ¿podemos tomar una función escrita en Concrete, conectarla con algo dentro del compilador y probar una propiedad real sobre ella en Lean?</p>
Parte de esa respuesta ya existe. No para todo el lenguaje, y no para el binario final, pero sí para un subconjunto real. Concrete puede tomar un contrato en el código fuente (source contract), convertirlo en una obligación, adjuntarle una prueba verificada por Lean o el resultado de un procedimiento de decisión, y avisarte cuando esa evidencia ya no coincide con el código. Lo importante no es que cada afirmación se ponga en verde. Es que la herramienta se niega a mezclar “probado”, “asumido”, “trusted” y “todavía no hecho”.</p>


Diseñar un lenguaje de programación para la era de la IA
2026-03-11T00:00:00+00:00

Nota de la serie: este artículo da por sentado el marco básico de Concrete y se hace una pregunta más acotada sobre la adopción de lenguajes en la era de la IA.
Para la base de la serie, leé Por qué existe Concrete</a>. Para la comparación principal con Rust, leé El debate sobre efectos en Rust y el argumento de Concrete a favor de un lenguaje más chico</a>.</p>
</blockquote>
Edgar Luque escribió hace poco sobre cómo la IA crea una nueva barrera de adopción para los lenguajes de programación</a>. Su argumento es que los asistentes de código con IA necesitan datos de entrenamiento, que los datos de entrenamiento solo existen para los lenguajes populares, y que entonces los lenguajes nuevos tienen mal soporte de IA, lo que impide su adopción, lo que a su vez impide que se acumulen datos de entrenamiento. Un ciclo que se refuerza solo y deja atornillado lo que ya domina.</p>
Si estás construyendo un lenguaje nuevo de propósito general que compite con Python, Go o Rust más o menos en los mismos términos, el análisis de Luque es demoledor. Lo que lo hace peor que las barreras de adopción anteriores es que no podés salir de esto a fuerza de esfuerzo comunitario. Los pipelines de entrenamiento de IA son de un puñado de empresas, y esas empresas siempre van a priorizar los lenguajes donde ya existe más data.</p>
Pero hay un punto ciego en el argumento.</p>


El debate sobre efectos en Rust y el argumento de Concrete a favor de un lenguaje más chico
2026-03-09T00:00:00+00:00

Nota de la serie: esta es la entrada principal de comparación con Rust en la serie sobre Concrete.
Si recién llegás, empezá por Por qué existe Concrete</a>. Si querés la referencia del lenguaje, usá la Especificación de Concrete</a>.</p>
</blockquote>
Yosh Wuyts escribió hace poco sobre su “gran visión” para Rust</a>, donde plantea tres direcciones que cree que el lenguaje debería seguir: efectos, tipos subestructurales más fuertes y tipos refinados (refinement types). El hilo de Hacker News</a> que vino después se dividió de manera previsible: un bando vio tomar forma un lenguaje de sistemas más seguro y con más principios, mientras el otro vio ecos de Scala, de C++ y de un lenguaje que se vuelve más difícil de leer que el software que pretende aclarar.</p>
Los dos bandos están viendo algo real, y creo que resolver la tensión entre ellos requiere algo distinto de agregarle más features a Rust. Ahí es donde entra Concrete</a>.</p>


Disolución sin construcción
2026-03-06T00:00:00+00:00
Hace un tiempo que vengo dando vueltas alrededor del mismo problema. La fricción produce valor. La legibilidad destruye lo que mide. La formación requiere tiempo vivido. El yo moderno se está disolviendo por redundancia. Los cambios tecnológicos anteriores le dieron a la gente décadas para adaptarse, y este puede darle meses.</p>
Seguían pareciéndome observaciones separadas. Ya no creo que lo sean.</p>
#</a>El desfase de velocidades</h2>
Cada gran tecnología de coordinación de la historia disolvió la forma de ser uno mismo que la precedía. La escritura destruyó la memoria oral, la imprenta destruyó la cultura del manuscrito y las instituciones disolvieron el parentesco. Nada de esto es nuevo.</p>
Lo nuevo es la asimetría entre lo rápido que se disuelven las cosas y lo rápido que crecen.</p>
La escritura se difundió despacio. Un escriba copiaba un texto, lo llevaba a otra ciudad, le enseñaba a alguien a leerlo. La disolución de la memoria oral y la construcción del pensamiento letrado pasaron más o menos al mismo ritmo, las dos medidas en generaciones. La imprenta fue más rápida, pero todavía lo bastante lenta como para que surgieran formas culturales junto con la destrucción. La novela, el diario íntimo, la biblioteca pública, la educación liberal: tardaron siglos en estabilizarse, pero había siglos disponibles porque la imprenta se movía a la velocidad de los objetos físicos.</p>
Los sistemas algorítmicos disuelven a velocidad de cómputo. Un motor de recomendación puede rehacer en meses el proceso de formación del gusto de millones de personas. Un asistente de IA puede hacer que la deliberación interior se sienta innecesaria dentro de un solo ciclo de producto.</p>
Pero la construcción, la formación de nuevas capacidades humanas, nuevas formas culturales, nuevos modos de percepción, sigue pasando a velocidad biológica. Una persona se vuelve un tipo particular de persona a través de años de encuentros, revisiones, fracasos. Una forma cultural se estabiliza a través de generaciones de práctica. No hay atajo computacional porque la capacidad está constituida por el proceso, no por su resultado. No se puede comprimir el llegar a ser.</p>
El problema es la brecha entre la velocidad de disolución y la velocidad de construcción.</p>
Esto replantea una conversación que está trabada hace años. Un lado dice que las transiciones anteriores salieron bien, así que esta también va a salir bien. Se equivocan por una razón estructural: las transiciones anteriores salieron bien porque la disolución era lo bastante lenta como para que la construcción le siguiera el ritmo. Esa condición ya no se cumple. El otro lado dice que la tecnología nos está destruyendo. También se equivocan, o por lo menos son imprecisos. La disolución puede ser el comienzo de la construcción; cada transición anterior disolvió algo real y produjo algo nuevo. La cuestión es la velocidad: ahora la disolución va lo bastante rápido como para hacer imposible la construcción.</p>
#</a>La fricción como regulador</h2>
El deseo depende de la resistencia. El punto más profundo es que la resistencia impone un ritmo. La distancia entre querer y obtener es una estructura temporal. Le da a la persona tiempo para volverse alguien capaz de integrar lo que recibe. Sacá la distancia y la persona recibe antes de poder absorber.</p>
La fricción cumple esta función a escala civilizatoria. Cuando la imprenta disolvió la cultura oral, los libros eran caros. La alfabetización se extendió de a poco. El yo oral no desapareció de un día para el otro. Se debilitó a lo largo de décadas y siglos, y durante ese tiempo el lado constructivo, nuevas prácticas de lectura, nuevas instituciones, nuevas formas literarias, tuvo lugar para desarrollarse. La fricción propia de los medios físicos le ponía un límite de velocidad a la disolución, y ese límite de velocidad coincidía con la velocidad de la formación humana.</p>
La fricción en la formación del gusto le da a una persona tiempo para desarrollar la capacidad de percibir, más allá de un conjunto de preferencias. La fricción en la formación profesional le da al practicante tiempo para desarrollar un criterio que se resiste a ser articulado. La fricción en la deliberación le da al yo tiempo para formarse. Sacala y la disolución le gana a la construcción. La brecha se abre. Nada crece donde estaba la capacidad vieja.</p>
#</a>La legibilidad como acelerante</h2>
Otra vez el bosque alemán. Los forestales del siglo XVIII reemplazaron bosques diversos y desordenados por plantaciones uniformes de píceas de Noruega. Los rendimientos se dispararon. Después el sotobosque murió, el suelo se degradó y el bosque colapsó. Lo que parecía ineficiencia era el soporte vital del sistema.</p>
La legibilidad le hace algo específico al problema de la velocidad. Convierte procesos ilegibles en objetivos optimizables. Una vez que un proceso es visible, se puede medir. Una vez medido, optimizar. Una vez optimizado, la fricción del proceso original se elimina como ineficiencia. La legibilidad es el mecanismo que identifica la fricción, y la optimización es el mecanismo que la saca. Juntas aceleran la disolución.</p>
El yo dependía de la opacidad. El gusto se formaba en privado. Te encontrabas con cosas por casualidad, te quedabas con una incomodidad que ningún algoritmo podía detectar, revisabas tu sensibilidad a través de un proceso invisible para cualquier sistema externo. El criterio profesional vivía en un conocimiento que no se podía articular. La deliberación interior pasaba en un espacio que, por definición, no era observable desde afuera.</p>
La IA llega a todo esto. Vuelve legible la formación del gusto a través de datos de comportamiento. Vuelve legible la deliberación a través de registros de interacción. Vuelve legible la intuición profesional a través de métricas de desempeño. Cada acto de legibilidad saca una capa de fricción que estaba funcionando, sin que nadie lo notara, como regulador de velocidad de la disolución.</p>
#</a>El problema que se compone</h2>
Esta es la parte que más me preocupa. La disolución le gana a la construcción y degrada las condiciones en las que la construcción es posible.</p>
La formación requiere ciclos completos: esfuerzo, retroalimentación, ajuste, repetidos a lo largo del tiempo vivido. La aceleración fragmenta esos ciclos. Lo que se difunde más rápido se aleja de lo que funciona mejor. La imitación se difunde más rápido que el aprendizaje. Cada acto de disolución saca parte de la fricción, la opacidad y el tiempo que la construcción requiere. Cuantas más funciones pierde el yo, menos capacidad le queda para desarrollar funciones nuevas. El proceso se compone. La disolución se acelera mientras se erosiona el terreno para la construcción.</p>
Alguien que nunca formó su gusto a través de la fricción no va a desarrollar lo que sea que pueda llegar a ser una percepción posalgorítmica. Alguien que nunca ejercitó la deliberación interior no va a desarrollar lo que sea que venga después de la deliberación. La capacidad nueva, si existe, no va a surgir del vacío. Va a surgir de gente que desarrolló lo suficiente de la capacidad vieja como para trascenderla, del mismo modo que el pensamiento letrado surgió de gente que primero había dominado la memoria oral. Si la disolución destruye la capacidad vieja antes de que la nueva pueda desarrollarse a partir de ella, la secuencia se rompe. Lo que parece otra transición es en realidad una interrupción.</p>
#</a>Qué tendría que ser cierto</h2>
No sé qué viene después del yo letrado. Nadie en 1450 podría haber descrito tampoco lo que la imprenta iba a producir. Pero puedo describir las condiciones en las que la construcción se vuelve posible.</p>
Haría falta fricción. No dificultad arbitraria, sino la resistencia específica que impone un ritmo compatible con la formación humana. Haría falta opacidad. Dominios donde el trabajo lento de llegar a ser no sea legible para los sistemas de optimización, donde una persona pueda desarrollarse sin que la midan. Y haría falta tiempo. Tiempo de verdad. Ciclos completos de esfuerzo y revisión que no estén comprimidos ni interrumpidos.</p>
El sistema actual elimina las tres cosas. La optimización trata la fricción como desperdicio. La IA trata la opacidad como un problema a resolver. Los mercados tratan la lentitud como una desventaja competitiva. Todos los incentivos apuntan en la misma dirección: una disolución más rápida.</p>
Las transiciones anteriores produjeron sus propias formas constructivas porque la velocidad de la disolución les dejaba lugar. La imprenta fue lo bastante lenta como para que surgiera la novela. La vida institucional fue lo bastante gradual como para que se desarrollara la educación liberal. La imprenta no generó espontáneamente el yo letrado. La gente construyó escuelas, diseñó planes de estudio, estableció prácticas de lectura y argumentación que tardaron siglos en estabilizarse. Ese trabajo fue deliberado, institucional y lento, pero fue posible porque la disolución a la que respondía también era lenta.</p>
La pregunta que no puedo responder es si algo puede crecer a velocidad biológica en un entorno que fue optimizado para la velocidad de cómputo. Si la construcción es posible cuando las condiciones para la construcción son justamente lo que el sistema sabe eliminar con más eficiencia.</p>
Hay una ironía que no debería esquivar. Me gano la vida construyendo infraestructura de coordinación. Clientes de Ethereum, bibliotecas de pruebas criptográficas, sistemas distribuidos. Herramientas que aceleran exactamente el proceso que describe este ensayo. Y el ensayo en sí no es construcción. Es diagnóstico. Mi propia posición me tiene genuinamente confundido. Veo la disolución con la claridad suficiente como para escribir sobre ella. También construyo las herramientas que la producen. No resolví esto. No estoy seguro de que se pueda resolver. Nombrar el desfase de velocidades no lo frena. Hasta puede acelerarlo al volver legible el problema, que es lo que dije que hace la legibilidad: convertir las cosas en objetos de optimización. No sé si escribir sobre la disolución es una forma de fricción, algo que frena al lector, lo obliga a quedarse con la incomodidad, o una versión sin fricción sobre la fricción, consumida y olvidada a velocidad algorítmica. Sospecho que la respuesta depende de lo que hagas después de leerlo.</p>


La legibilidad mata lo que mide
2026-03-03T00:00:00+00:00
En el siglo XVIII, los forestales alemanes inventaron la silvicultura científica. Miraron un bosque desordenado y diverso y vieron ineficiencia. Árboles viejos, árboles jóvenes, madera muerta, sotobosque, especies sin valor comercial. Limpiaron todo y plantaron píceas de Noruega en filas rectas, con la misma separación, de la misma edad, de la misma especie. El bosque se volvió legible. Se lo podía medir, administrar, predecir su rendimiento con precisión.</p>
Durante una generación, funcionó de maravilla. Los rendimientos se dispararon. Después el bosque empezó a morirse. El sotobosque complejo hacía circular los nutrientes, retenía la humedad, alojaba a los insectos que polinizaban el dosel y a los hongos que alimentaban las raíces. Los forestales no habían simplificado el bosque; habían destruido el sistema que lo mantenía vivo, y conservado solo la parte que podían ver.</p>
James Scott cuenta esta historia en Seeing Like a State</em> para ilustrar un patrón que se repite cada vez que una autoridad central le impone legibilidad a un sistema complejo. El patrón es simple: volvés legible lo ilegible, optimizás lo que ahora podés ver y perdés lo que no podías ver pero de lo que dependías.</p>


Las finanzas son geometría, y todo vuelve a la desigualdad de Jensen
2026-03-01T00:00:00+00:00
Nunca cruces un río que tiene en promedio cuatro pies de profundidad. Si el río tiene ocho pies de profundidad en el medio y está seco en los costados, el promedio no te dice nada sobre si te vas a ahogar. Te vas a ahogar en el medio, o no. No existe un promedio entre universos paralelos en los que sobrevivís y morís a la vez.</p>
La misma asimetría aparece en todos lados donde los resultados se capitalizan. Si perdés el 50% de tu riqueza, necesitás una ganancia del 100% solo para salir hecho, porque la pérdida golpea sobre una base más grande que aquella desde la que se construye la recuperación. Pasar de $100 a $200 y de $200 a $400 son montos distintos en dólares pero el mismo movimiento proporcional: una duplicación. La riqueza es una cuestión de razones y de escala, no de diferencias absolutas.</p>
Esta estructura multiplicativa tiene consecuencias más profundas de lo que sugiere la intuición. La matemática que gobierna la supervivencia en entornos de capitalización compuesta se inventó hace 400 años para ayudar a los astrónomos a multiplicar números grandes, se redescubrió en parte en el siglo XVIII para resolver una paradoja sobre el juego, se formalizó de nuevo a través de la teoría de la información y después quedó en gran medida tapada por teorías que optimizaban a través de mundos hipotéticos en lugar de a lo largo de un único camino en el tiempo.</p>
Esa es la afirmación geométrica de este ensayo: la riqueza evoluciona de forma multiplicativa, mientras que la mayor parte de la intuición común es aditiva. El logaritmo es el cambio de coordenadas que nos permite movernos entre esas dos descripciones.</p>
Esta es la historia de por qué la geometría está en el centro de las finanzas, de por qué una sola desigualdad ata todo el cuadro y de por qué reducir la varianza puede valer más que aumentar los retornos.</p>
Ninguna de las partes es mía. Kelly, Peters, Spitznagel y Taleb resolvieron cada uno una de ellas. Lo único que afirmo es que son el mismo cuadro, y este ensayo muestra cómo encajan las piezas.</p>


El debate sobre la cobertura de colas: Spitznagel tiene razón, AQR responde la pregunta equivocada
2026-02-26T00:00:00+00:00
Los mercados de acciones se derrumban</a>. El índice de precios del S&P 500 cayó alrededor de 57% entre el 9 de octubre de 2007 y el 9 de marzo de 2009, y alrededor de 34% entre el 19 de febrero de 2020 y el 23 de marzo de 2020. Una opción de venta</strong> (put option) es un contrato que te paga cuando el mercado cae por debajo de cierto precio (el “strike”, o precio de ejercicio). Si tenés acciones y también tenés puts, los puts pueden compensar parte de tus pérdidas durante un crash. La pregunta es si el costo de comprar puts vale la protección que dan.</p>
Hay dos bandos. AQR Capital Management publicó “Chasing Your Own Tail (Risk)”</a> (Berger, Nielsen y Villalon, 2011</a>). Sostienen que comprar puts de forma sistemática cuesta más de lo que ahorra. Del otro lado, Mark Spitznagel, de Universa Investments, donde Nassim Taleb es asesor científico, sostiene que una asignación chica a puts mejora los retornos de largo plazo (Spitznagel, 2021</a>). Universa reportó una ganancia de 3.612% en marzo de 2020 (en una carta a inversores, según informó Bloomberg).</p>
Pusimos a prueba las dos afirmaciones con nuestro backtester de opciones de código abierto</a> sobre 17 años de datos reales de opciones sobre SPY (2008 a 2025), que cubren tres crashes: la crisis financiera de 2008, el COVID y el mercado bajista de 2022.</p>
La versión de la operación que sobrevive a los datos es acotada pero real: convexidad barata, en tamaño chico y elegida por strike y no por delta</strong>. La crítica publicada de AQR no prueba ninguna de las dos mitades. Usan puts cerca del dinero (la forma más cara de protección contra crashes por dólar de nocional) dentro de un enfoque que reduce la asignación (vender SPY para financiar los puts, resignando la prima de riesgo de las acciones que financia todo lo demás). En esa configuración, los puts muy fuera del dinero (deep OTM) siguen perdiendo contra SPY. El overlay financiado externamente (externally funded overlay) de Spitznagel invierte las dos elecciones: puts deep OTM, que se mantienen baratos, montados encima de una exposición completa a SPY, en tamaño chico. Dentro de esa configuración, la estrategia muestra una brecha bruta histórica positiva contra SPY a lo largo de la ventana 2008-2024: chica a la escala de 0,5%/año que describe Universa (~+1,4pp/año) y sustancial en el punto óptimo ajustado por riesgo del motor (+6pp/año con un presupuesto de 3,3%/año y roll bimestral). La ventaja depende del régimen: paga en las ventanas de 5 años que contienen un drawdown grande y resta 2-3pp/año en las que no.</p>
Todos los números principales que siguen son antes de costos de transacción, slippage e impuestos. El lastre de ejecución en los strikes deep OTM, la objeción más fuerte de Israelov que sigue en pie, va por encima de estos números brutos; volvemos sobre eso en la sección de limitaciones.</p>
#</a>Qué afirma realmente la tesis</h3>
Spitznagel no afirma que comprar puts OTM gane todos los años, todos los trimestres o en cada drawdown. Quienes lo leen así, incluida (de forma implícita) la crítica publicada de AQR, discuten con un hombre de paja. Su afirmación real es sobre el largo plazo. Poné una porción chica del capital en puts deep OTM encima de tu cartera de acciones, mantenelos durante los crashes, monetizá el pago convexo cuando llega y, en un horizonte lo bastante largo, capitalizás más rápido que con acciones solas. El mecanismo es que los pagos grandes y raros son lo bastante grandes, y se repiten lo bastante seguido, como para cubrir de sobra el lastre constante de la prima entre uno y otro. El alfa año por año es la prueba equivocada. La capitalización de largo plazo es la correcta.</p>
En esa prueba, los datos dicen que tiene razón. En nuestra muestra de 17 años de SPY, todos los presupuestos de overlay de puts, de 0,5%/año a 10%/año, le ganan a SPY solo tanto en retorno anual como en drawdown máximo. La profundidad de strike que describe Spitznagel (deep OTM, no cerca del dinero) es lo que hace funcionar la operación. El enfoque que describe (financiado externamente, no reduciendo la asignación) es la mitad que AQR se pierde. En todas las configuraciones que funcionan y que probamos más abajo, la estrategia mejora el drawdown máximo entre 10 y 22 puntos porcentuales contra SPY.</p>
Vale la pena nombrar de entrada tres propiedades de los datos, para que la forma del resultado no se confunda con un defecto. Primero, la brecha del período completo se concentra en dos años de diecisiete (2008 y 2020). Eso es exactamente lo que una cobertura de cola está hecha para hacer: quedarse dormida durante años y pagar de forma convexa cuando llega una catástrofe. Segundo, 7 de 13 ventanas móviles de 5 años son negativas. Así se ve un valor esperado positivo cuando los pagos son así de irregulares. Tercero, la validación walk-forward muestra que más o menos la mitad de la brecha dentro de muestra sobrevive fuera de muestra (out-of-sample). Ese es el descuento que hay que aplicar al dimensionar esto para una cartera real, no una refutación del resultado.</p>
La lectura equivocada de todo esto es que la estrategia funciona solo por suerte en los años de crash. La lectura correcta es que la estrategia está hecha para pagar en años como esos y que, con el tiempo suficiente y una frecuencia de crashes realista, los pagos grandes y raros cubren de sobra las pequeñas pérdidas constantes. Esa es la tesis de Spitznagel. Los datos la respaldan.</p>
Cada número que sigue se reproduce con un solo comando contra el motor de código abierto. La sección Código al final tiene la invocación exacta.</p>


Detectar crashes con estadística de colas pesadas
2026-02-19T00:00:00+00:00
Los mercados financieros no siguen distribuciones normales</a>. Es una afirmación sobre frecuencias, no solo sobre teoría: te dice con qué frecuencia pasan los eventos catastróficos. Bajo un modelo gaussiano ingenuo, una crisis de la escala de 2008 cae tan adentro de las colas que los modelos de riesgo estándar la tratan como prácticamente imposible. Pasó un martes.</p>
El problema es que seguimos usando herramientas diseñadas para mundos de colas livianas. Modelos de Valor en Riesgo</strong> (Value at Risk, VaR</strong>) que asumen normalidad. Métricas de riesgo que tratan el crash de 2008 como un “outlier” en vez de como un rasgo habitual de los retornos financieros.</p>
Armé fatcrash</a>, un toolkit en Rust+Python con 15 métodos clásicos, para probar si los métodos estadísticos de colas pesadas (fat tails) pueden detectar crashes antes de que pasen. La matemática crítica para el rendimiento (ajustes, simulación, todos los estimadores móviles) corre en Rust vía PyO3; todo lo demás (datos, visualización, CLI) es Python.</p>


Veinte siglos de datos financieros: lo que revelan 240 países y 2.000 años
2026-02-12T00:00:00+00:00
En 1252, Florencia acuñó el florín de oro. En pocas décadas se convirtió en la moneda comercial dominante de la Europa medieval. Los comerciantes de Brujas, Venecia y Constantinopla cotizaban precios contra él. Para el 1400, el dominio del florín se había apagado, reemplazado por el ducado veneciano. Después el real español. Después el florín neerlandés. Después la libra esterlina. Después el dólar. Cada transición trajo devaluaciones, defaults y crisis que arruinaron a cualquiera que tuviera la moneda equivocada en el momento equivocado.</p>
Tenemos datos de todo esto. No estimaciones. Tipos de cambio efectivamente registrados, desde 1106. Y no solo tipos de cambio: precios del oro y la plata desde 1257, tasas de interés desde 1311, precios de materias primas desde 1260, PBI per cápita desde el año 1 d. C., ratios de deuda soberana desde 1800 e índices de crisis que cubren dos siglos de pánicos bancarios, colapsos cambiarios y defaults soberanos.</p>
Armé forex-centuries</a>, la colección de código abierto (open source) más completa que existe de datos financieros y económicos de largo plazo. 27 fuentes, más de 1.100 archivos, unos 240 países, veinte siglos. Tipos de cambio, metales preciosos, tasas de interés, precios de materias primas, inflación, PBI, salarios reales, deuda soberana, clasificaciones de régimen y tipos de cambio efectivos reales, todo en un repositorio con un pipeline de build automatizado y análisis reproducible. Hay un job semanal de CI programado para actualizar las fuentes automatizadas; hoy está fallando, así que los datos commiteados son los que dejó la última actualización exitosa. Ningún otro repositorio gratuito combina esta amplitud de clases de activos con esta profundidad histórica. El único producto comparable es Global Financial Data</a> (comercial, con precios institucionales). El objetivo: dar la materia prima para estudiar cómo se comportan las monedas y los sistemas financieros a lo largo de siglos, no de décadas.</p>


La fricción como lujo: qué perdemos cuando la IA nos da lo que queremos
2026-02-05T00:00:00+00:00
#</a>La última escasez</h2>
La mayoría de las discusiones sobre la AGI se concentran en la distribución: quién tiene acceso, quién gana plata, quién pierde el laburo, quién controla la infraestructura. Son problemas reales, pero no son el más profundo.</p>
El problema más profundo es qué le pasa al deseo. No hablo de la ambición en sentido genérico. Hablo de la capacidad de querer algo a distancia, de seguir orientado hacia algo que todavía no tenés, y de encontrarle sentido al espacio entre estirarse hacia algo y llegar. Esa capacidad es más frágil de lo que solemos admitir, y depende de la fricción más de lo que la mayoría nota.</p>
#</a>I.</h2>
Los economistas tienen un modelo limpio del deseo. La gente tiene preferencias, los bienes satisfacen preferencias, el bienestar sube a medida que se satisfacen más preferencias. En ese marco, una tecnología que puede satisfacer casi cualquier preferencia a un costo insignificante parece un bien obvio. La única pregunta que queda es quién tiene acceso.</p>
Ese modelo deja afuera algo importante. El deseo tiene una forma, y esa forma depende de que se cumplan ciertas condiciones.</p>
Cuando querés algo a lo largo del tiempo, te imaginás teniéndolo. Lo planificás, hacés sacrificios para conseguirlo. El objeto va acumulando sentido en ese proceso. Se le van superponiendo capas de tu esfuerzo, tu expectativa, tu historia de ir hacia él. Cuando por fin llegás, no conseguís solo el objeto. Conseguís el objeto más todo lo que invertiste en desearlo. Esas dos cosas no se pueden separar.</p>
Por eso la espera muchas veces es más rica que la llegada, por eso los mejores discos a veces necesitan meses y no minutos, y por eso las relaciones construidas a través de la dificultad tienen una textura que las cómodas muchas veces no tienen. La resistencia ayuda a producir el valor.</p>
#</a>II.</h2>
Cuando esta estructura se rompe, el término clínico es anhedonia. Pero hay una versión más leve y más aceptada socialmente del mismo patrón. La gente en esa condición puede estar entretenida todo el tiempo pero rara vez se siente absorbida de verdad. Consume sin mucho apetito. Pasa de una cosa estimulante a la siguiente no porque algo la satisfaga, sino porque quedarse con lo incompleto empieza a sentirse insoportable.</p>
La forma ya se ve en la caída de la capacidad de atención, en la dificultad para sostener el interés en cualquier cosa que no dé una respuesta inmediata, en gente que se siente sobreestimulada y aburrida al mismo tiempo. No les faltó nada, se saturaron.</p>
Esto no se reparte de forma pareja en la sociedad. En entornos donde la incomodidad se resuelve rápido, con plata, con servicios, con entretenimiento infinito, la mente practica menos el sostener la falta. Podés crecer rodeado de abundancia y aun así volverte pobre de una manera específica: pobre en paciencia para la distancia.</p>
En lo estructural, empieza a parecerse a una adicción: el ansia se separa de la satisfacción. La neurociencia traza la misma línea. El trabajo de Kent Berridge separa el querer (wanting) del gustar (liking), y es el querer dopaminérgico, no el placer, lo que explotan las drogas adictivas y las máquinas de recompensa variable. Las tragamonedas y los feeds infinitos están construidos exactamente alrededor de esto, premios impredecibles en un esquema que entrena al sistema nervioso para tratar la incomodidad como señal de alivio y el alivio como señal de repetición. Un entorno de IA sin fricción podría reproducir parte de ese patrón sin químicos. El aburrimiento, la soledad, la incertidumbre y el esfuerzo se vuelven disparadores de estimulación instantánea. Con el tiempo el umbral sube, lo que antes atrapaba pasa a ser apenas aceptable, y el resto de la vida empieza a sentirse lento y sin fuerza en comparación.</p>
El capitalismo de consumo produjo una versión debilitada de esto. El deseo se fue vaciando progresivamente al eliminar la fricción, pero quedaba suficiente fricción como para que la estructura no colapsara del todo. El servicio de streaming todavía te obliga a elegir. El algoritmo todavía te sorprende de vez en cuando. La simulación de conexión es lo bastante imperfecta como para que a veces notes que es una simulación.</p>
#</a>III.</h2>
Imaginate un sistema que puede generar, a pedido, una novela calibrada a tus gustos: el estilo que te da más placer, el nivel de complejidad que más te engancha, la extensión que coincide con tu paciencia del momento. O música que suena como lo que más te gustaba a los diecinueve, pero nueva, inmediata e infinita. O un interlocutor que siempre está interesado en lo que te interesa a vos, siempre disponible, nunca distraído, que nunca trae sus propias necesidades al intercambio.</p>
El resultado podría ser bueno de verdad. La novela podría estar técnicamente lograda. La música podría emocionarte en serio. La conversación podría tener sustancia. El problema es qué le pasa al deseo cuando la brecha se reduce a cero.</p>
La capacidad de seguir orientado hacia una meta lejana, de postergar, de invertir, de tolerar lo incompleto</a>, se atrofia cuando nunca se ejercita. No por una ruptura dramática, sino por falta de uso. La capacidad de querer cosas que requieren tiempo no desaparece de golpe. Se va debilitando, y ese debilitamiento puede ni siquiera sentirse como una pérdida porque algo agradable sigue llegando a horario.</p>
#</a>IV.</h2>
Nada de esto es nuevo. Epicteto entrenaba a sus alumnos para que quisieran solo lo que ya estaba bajo su control y para que ensayaran la incomodidad a propósito, y Séneca reservaba días para vivir como si fuera pobre, de modo que la penuria nunca pudiera usarse en su contra. El ayuno de Ramadán, las privaciones de la Cuaresma y la Regla de San Benito meten escasez programada en una vida a partir de la misma teoría: que el sentido pasa a través de la resistencia y no alrededor de ella.</p>
Lo nuevo es la escala. Las tecnologías anteriores eliminaban fricciones específicas pero dejaban intactas otras. Todo entorno digital hasta ahora te exigía traer algo que no podía darte: atención, habilidad, paciencia.</p>
Una IA realmente general disuelve este último requisito. Puede aportar el gusto, el contexto, el criterio. Ya no necesitás traer nada salvo las ganas de recibir. Y si esas ganas también las moldea la IA, ajustadas a lo que sea que sostenga el enganche, entonces hasta el deseo quedó tercerizado.</p>
#</a>V.</h2>
Acá está la inversión. Donde la abundancia material es la regla, las cosas que conservan su valor suelen ser las que resisten su lógica. Su valor está atado a las condiciones que las hacen difíciles, no a una escasez artificial.</p>
Un objeto hecho a mano lleva la huella de las manos que lo hicieron. Una cosecha de vino no se puede acelerar. La espera no es accesoria a lo que el vino es. Una comunidad construida alrededor de una práctica difícil compartida, la pintura, la escalada, el ajedrez, armar y desplegar ejércitos de miniaturas, genera vínculos que la interacción mediada digitalmente no replica, porque esos vínculos se forjan en la dificultad compartida.</p>
Estas cosas se vuelven valiosas no a pesar de ser más difíciles que consumir lo que produce una IA, sino en parte por esa dificultad. Cuando la satisfacción no tiene fricción, la fricción misma se vuelve el lujo.</p>
#</a>VI.</h2>
Los debates sobre seguridad, alineamiento y desplazamiento laboral son todos reales. Pero comparten un supuesto: que los humanos del otro lado todavía van a ser capaces de decidir qué hacer con lo que recibieron, y que la capacidad de acción política y la imaginación colectiva van a sobrevivir intactas.</p>
Ese supuesto está cargando con mucho peso.</p>
La atrofia del deseo ya se ve en lo que tecnologías más débiles le hicieron a la cultura. Lo que la AGI le hace a la psicología humana viene antes de lo que le hace a la política humana. Una población que perdió la capacidad de querer cosas a distancia, de seguir orientada hacia un futuro difícil y de encontrarle sentido al esfuerzo y a lo incompleto perdió algo esencial para el autogobierno.</p>
La escasez que más importa en un mundo post AGI no va a ser el cómputo ni la energía. Va a ser la capacidad de querer algo con la profundidad suficiente, y durante el tiempo suficiente, como para que ese querer moldee quién sos.</p>
Si el deseo es la última escasez, entonces la lentitud, la dificultad y lo incompleto no son obstáculos a superar. Son las condiciones de una vida que valga la pena vivir.</p>


China intenta commoditizar el complemento
2026-01-22T00:00:00+00:00
China está intentando ganar commoditizando el complemento (commoditizing the complement). La estrategia está funcionando, aunque no sin fricciones. Es un desafío estructural que Occidente debería tomarse en serio en lugar de descartarlo.</p>
Durante las últimas dos décadas, Occidente exportó cognición porque era dueño de las plataformas, la nube, la distribución de software y la concentración de talento. Si el motor cognitivo se vuelve barato, portable y suficientemente bueno, esa asimetría se debilita. Un país chico puede comprar o descargar la misma maquinaria cognitiva y aplicarla a su propia burocracia, sus propias empresas, su propio idioma, sus propios problemas de dominio.</p>
Occidente dominó el mundo del pensamiento y los servicios. Software, finanzas, medios, investigación, capas de gestión y la exportación de expertise. Estados Unidos es el ejemplo más claro. En 2024, las exportaciones de servicios de Estados Unidos fueron de alrededor de 1,1 billones de dólares, el máximo registrado. Estados Unidos y Occidente venden pensamiento a escala. La IA amenaza con aplanar esa ventaja porque convierte el pensamiento en infraestructura.</p>
China domina el mundo de los átomos. Capacidad industrial, volumen de producción manufacturera, cadenas de suministro físicas, curvas de costos. En 2023 China produjo alrededor del 28 por ciento del valor agregado manufacturero global.</p>
Si podés hacer que la capa que está al lado tuyo sea barata y abundante, le drenás el poder de fijar precios y forzás a que el valor se mueva a otro lugar. En IA, el complemento es el acceso a los modelos. Para muchas empresas occidentales, el negocio sigue siendo básicamente inteligencia con acceso restringido vendida como API. China tiene todos los incentivos para que esa capa se sienta como la electricidad: disponible en todos lados, barata, difícil de monopolizar.</p>
Los lanzamientos de modelos con pesos abiertos (open weights) son parte de esa jugada: DeepSeek, Qwen, Kimi y MiniMax son solo algunos de los modelos open source chinos. Una vez que los modelos potentes son comunes, el acceso a los modelos deja de ser una ventaja defendible (moat). Se convierte en un insumo commodity.</p>
Una fracción enorme de lo que llamamos servicios es trabajo legible: leer, escribir, programar, resumir, traducir, redactar borradores, responder, generar variaciones, buscar en un espacio de opciones. Esa capa ahora es replicable y se está volviendo local. Apple está publicando reportes técnicos sobre foundation models que corren en el dispositivo, incluida una cuantización agresiva pensada para que la inferencia seria corra en hardware de consumo. Cuando los modelos potentes corren en una laptop, los países dejan de importar pensamiento como servicio. Importan pesos, o destilan, hacen fine-tuning y despliegan dentro de sus propias fronteras.</p>
La jugada de la commoditización está funcionando, pero no está libre de fricciones. China enfrenta restricciones reales, y esas restricciones determinan hasta dónde puede llegar la estrategia.</p>
Los controles de capital limitan qué tan libremente pueden operar las empresas chinas a nivel global. El Estado puede redirigir inversión a una escala que nadie más puede igualar, pero la asignación centralizada tiende a pasarse de rosca. La sobrecapacidad de paneles solares, el exceso de oferta de acero y la guerra de precios de los autos eléctricos siguen el mismo patrón: una expansión masiva y subsidiada que termina comprimiendo los márgenes de todos, incluidas las propias empresas chinas.</p>
El mejor talento todavía fluye hacia entornos de investigación abiertos. Según el Global AI Talent Tracker de MacroPolo, China es la mayor fuente individual de investigadores de IA de primer nivel del mundo, y sin embargo una gran parte de ellos termina haciendo ese trabajo en Estados Unidos. Endurecer el control político sobre las universidades y las empresas privadas puede acelerar la ejecución de objetivos definidos, pero hace más difícil sostener la investigación abierta y de alto riesgo que produce avances reales.</p>
La previsibilidad importa para la innovación de largo plazo, y los últimos años la golpearon. La suspensión abrupta de la IPO récord de 34.000 millones de dólares de Ant Group en noviembre de 2020, las medidas de 2021 que borraron de un día para el otro el sector de las clases particulares con fines de lucro y congelaron durante meses las aprobaciones de nuevos videojuegos, y la retirada forzada de Didi de los mercados estadounidenses después de su salida a bolsa en 2021 mandaron la misma señal: cualquier empresa puede convertirse en un blanco sin aviso. Las empresas extranjeras recalibraron su exposición y algunos fundadores locales se volvieron cautelosos. La coordinación centralizada compra velocidad, pero también achica el apetito por apuestas que no coinciden con las prioridades actuales del Estado.</p>
Occidente todavía tiene una ventaja difícil de replicar: es donde la mayor parte del talento ambicioso del mundo quiere vivir, trabajar y construir. Es un efecto compuesto de instituciones abiertas, libertad de movimiento y décadas de confianza acumulada. Mientras eso se mantenga, Occidente sigue atrayendo el talento y el capital que convierten ideas en nuevas industrias.</p>
Ninguna de estas restricciones anula la jugada de la commoditización. Le ponen un techo. China puede llevar el precio del acceso a los modelos hacia cero más rápido que nadie, pero la investigación abierta y la confianza institucional que convierten un commodity barato en nuevas industrias son mucho más difíciles de crear a fuerza de subsidios.</p>
China sigue fuerte en átomos porque ya tiene la ventaja de escala. Occidente todavía lidera en áreas que requieren instituciones profundas y una competencia acumulada durante mucho tiempo, en particular la investigación de frontera y los servicios de alta confianza. Pero la IA comprime la prima de los servicios al hacer que una gran parte de la cognición sea barata y replicable. Por eso importan los modelos abiertos. Atacan la estructura de márgenes de la economía del pensamiento.</p>
Si vendés inteligencia, esto es una mala noticia. Si sos dueño de la distribución, el hardware, los datos o un flujo de trabajo del que la gente no se puede ir fácilmente, sobrevivís. Si sos dueño de los átomos y conseguís el pensamiento gratis, tenés una combinación que da miedo, porque la prima de los servicios que sostuvo el liderazgo económico occidental durante décadas puede ser socavada por un jugador con dominio industrial y acceso a las mismas herramientas cognitivas.</p>


La guía de Fede sobre sistemas de tipos: de generics a tipos dependientes
2026-01-01T00:00:00+00:00
Cada error de tipos que alguna vez te hizo renegar fue un bug atrapado antes de llegar a producción. Los sistemas de tipos rechazan disparates en tiempo de compilación para que no los descubras a las 3 de la mañana. Pero varían muchísimo en lo que pueden expresar y en las garantías que dan.</p>


Por qué existe Concrete
2025-12-26T00:00:00+00:00

Esta es la pieza fundacional de la serie sobre Concrete.
Si primero querés la demostración más práctica, empezá por Cuando el compilador es el oráculo</a>. Si querés la referencia viva del lenguaje, usá la Especificación de Concrete</a>.</p>
</blockquote>
La programación de sistemas tiene un problema recurrente. Queremos escribir código cerca de la máquina, pero también queremos poder afirmar cosas fuertes sobre lo que hace ese código. ¿Asigna memoria? ¿Toca la red? ¿Pierde recursos? ¿Se puede auditar sin rastrear veinte funciones auxiliares y tres capas de convenciones de bibliotecas?</p>
La mayoría de los lenguajes responden esas preguntas de forma indirecta. Leés la implementación. Hacés profiling. Inferís a partir del estilo. Confiás en los bloques unsafe</code>, en la documentación y en la disciplina de revisión. Incluso en lenguajes fuertes, mucho de lo que importa de un programa vive fuera del sistema de tipos.</p>
Concrete existe porque creo que ese es el lugar equivocado para detenerse.</p>
Concrete es un lenguaje de sistemas construido alrededor de un único principio organizador: toda propiedad importante que el compilador pueda saber sobre un programa debería ser lo bastante explícita como para que humanos y máquinas puedan actuar directamente sobre ella</strong>.</p>


La muerte del yo interior
2025-12-23T00:00:00+00:00
El argumento central es simple: muchos rasgos de la vida humana que parecen estables y naturales son producto de la historia. A medida que la sociedad se acelera, varios de esos rasgos empiezan a perder su función y su permanencia. Creo que la conciencia tal como la conocemos es uno de ellos.</p>
#</a>La individualidad como tecnología</h2>
La vida se organiza alrededor de información que se replica bajo restricciones. El cómputo generaliza esta lógica biológica. Permite que la selección y la optimización ocurran más rápido y a escalas más grandes al externalizar la memoria, la comparación y la retroalimentación. Problemas que antes requerían deliberación interna se pueden resolver con procesos externos que prueban, filtran e iteran posibilidades.</p>
El capital lleva esta lógica más lejos. Reorganiza la vida social alrededor de la retroalimentación continua, las señales de precios y la selección competitiva. A medida que estas fuerzas se componen, la individualidad empieza a parecer menos un fundamento y más una interfaz que surgió para resolver problemas de coordinación anteriores.</p>
El capital se comporta como una inteligencia impersonal orientada a la velocidad, la abstracción y la autooptimización. A medida que la cognición, la toma de decisiones y la coordinación migran a sistemas automatizados, el yo interior pierde su papel estructural. Con el tiempo, esta aceleración desgasta muchos supuestos que damos por sentados. La individualidad y la conciencia parecen cada vez más expuestas a este proceso.</p>
#</a>La construcción que no podemos ver</h2>
Los peces no se dan cuenta de que viven en el agua. El medio que los sostiene es tan constante que desaparece de la percepción. Algunas de las estructuras más importantes pasan inadvertidas por la misma razón. La individualidad y la conciencia pertenecen a esa categoría.</p>
Solemos tratar la individualidad y la conciencia como hechos evidentes, como si los humanos siempre se hubieran vivido a sí mismos como yoes delimitados, con una voz interior, un espacio mental privado y una identidad narrativa continua. Como esta experiencia se siente natural, se supone que es atemporal. Pensadores serios sostuvieron que no lo es. Julian Jaynes señaló que los héroes de la Ilíada casi no muestran espacio mental interior, y oyen las voces de los dioses donde nosotros oiríamos nuestra propia deliberación. Charles Taylor rastreó cómo el “yo amortiguado” (buffered self) moderno, encerrado dentro de su propia mente, se fue armando a lo largo de siglos a partir de prácticas religiosas y filosóficas, desplazando a un “yo poroso” más antiguo, abierto a fuerzas de afuera. Durante la mayor parte de la historia humana la gente no se describía a sí misma como individuo en el sentido moderno. Las decisiones no se entendían como resultado de una deliberación interior, y la agencia no estaba ubicada dentro de un yo interior privado. La acción se organizaba a través de rituales, tradiciones, parentesco y roles prescriptos. El sentido llegaba desde afuera de la persona y no desde la introspección. En muchas sociedades que quedan fuera de la trayectoria occidental, esta estructura sigue en gran parte intacta.</p>
La idea de un vos adentro de tu cabeza que observa tus propios pensamientos es, entonces, una construcción aprendida. Depende del lenguaje, de hábitos, de metáforas y de prácticas sociales que tuvieron que desarrollarse y estabilizarse con el tiempo. Lev Vygotsky sostuvo que el habla interior no es innata sino habla social internalizada: los chicos primero les hablan a otros, después a sí mismos en voz alta, después en silencio, hasta que el diálogo pasa a ser subterráneo y empieza a sentirse como la voz privada de un yo. La memoria narrativa, el examen moral de uno mismo y la sensación de ser autor de los propios actos surgieron de la misma manera, como logros culturales montados sobre procesos biológicos más antiguos.</p>
Las sociedades modernas reproducen activamente esta configuración. Desde la primera infancia, a la gente se la entrena para entenderse como unidades autónomas con opiniones, preferencias, metas y una vida interior que le pertenece solo a ella. El entrenamiento es tan omnipresente que se vuelve invisible. Otras formas de ser humano se pierden de vista, aunque muchas existieron y algunas todavía persisten.</p>
#</a>El debilitamiento de las condiciones</h2>
Las condiciones que antes hacían funcional a la individualidad se están debilitando. Los sistemas anteriores dependían de sujetos humanos para pensar, decidir, juzgar y hacerse responsables. La cognición y la coordinación estaban limitadas por las mentes humanas. La individualidad surgió como una solución: un yo estable hacía posible la planificación a largo plazo, la rendición de cuentas moral y la continuidad institucional.</p>
Las sociedades anteriores se coordinaban sin conciencia moderna. Los sistemas contemporáneos se coordinan cada vez más sin yoes modernos. La toma de decisiones avanza sin deliberación interior. El sentido llega a través de incentivos, métricas y circuitos de retroalimentación.</p>
En el plano cultural, la individualidad se invoca todo el tiempo. A la gente se la empuja a ser ella misma, a expresarse, a optimizarse. Pero los canales de expresión llegan ya moldeados, cuantificados y monetizados. Lo que aparece como identidad propia toma cada vez más la forma de una actuación administrada dentro de límites estrechos.</p>
#</a>Reemplazo por grados</h2>
El yo moderno no colapsa en un solo momento. Se lo reemplaza función por función, y cada sustitución es lo bastante chica como para pasar inadvertida.</p>
El gusto antes se formaba a través de un proceso lento y privado: encontrarse con cosas por casualidad, quedarse con la incomodidad, aprender a querer lo que al principio se te resistía. La recomendación algorítmica comprime todo eso en un perfil que se actualiza en tiempo real. El sistema sabe lo que te va a gustar antes que vos. El proceso interior de formar una preferencia, la duda, la revisión, el moldeado gradual de la sensibilidad, pierde su propósito cuando un sistema externo lo hace más rápido y con más precisión. Lo que queda parece gusto pero funciona como consumo.</p>
El criterio sigue un camino parecido. En organizaciones que antes dependían de la experiencia acumulada, ahora las métricas de desempeño determinan qué cuenta como trabajo competente. La formación lenta de la intuición profesional, la que lleva años desarrollar y se resiste a ser articulada con facilidad, queda aplastada contra los objetivos trimestrales. Es la ley de Goodhart vuelta estructural: cuando una medida se convierte en objetivo deja de medir lo que tenía que medir, y acá el objetivo va reemplazando de a poco a la facultad de la que nunca fue más que un indicador indirecto. Cuando la métrica se vuelve la memoria que tiene la institución de para qué sirve el trabajo, el criterio que se suponía que aproximaba desaparece en silencio. La gente sigue yendo. Optimiza lo que se mide. El resto se erosiona.</p>
La deliberación interior enfrenta la misma presión desde otra dirección. Cuando un asistente de IA puede redactar tus mails, planificar tu semana, resumir tus lecturas y sugerirte la próxima decisión, el proceso interno de pensar un problema empieza a sentirse innecesario, no exactamente equivocado, solo lento. El asistente nunca te dice que dejes de pensar; simplemente hace que pensar se sienta como fricción en un sistema que premia la velocidad. Con el tiempo, el hábito de la reflexión interior sostenida se debilita por la misma razón por la que se debilita cualquier capacidad que no se usa: por falta de uso.</p>
Cada una de estas sustituciones es razonable por separado. Cada una resuelve un problema real. Juntas, describen un patrón en el que las funciones que antes requerían un yo van siendo absorbidas de a poco por sistemas que no lo requieren.</p>
#</a>Qué está en juego</h2>
El yo moderno alguna vez se sintió inevitable porque resolvía problemas concretos. Hacía posibles la abstracción, la continuidad y la responsabilidad a escala. Su utilidad futura es mucho menos segura.</p>
El yo depende de cumplir ciertas funciones, y cuando esas funciones migran hacia afuera, el yo se debilita no por represión sino por redundancia.</p>
La individualidad fue real. Produjo filosofía, derecho, ciencia, arte e instituciones que transformaron el mundo. La pregunta es si va a seguir siendo funcional a medida que los sistemas que la rodean absorben más de lo que antes hacía. Una tecnología de coordinación que ya no coordina no se sostiene solo por sentimentalismo.</p>
El yo no se va a apagar sin más. Pero las condiciones que lo produjeron están cambiando, y lo que venga después puede verse tan distinto que la palabra “individualidad” deje de señalar algo que podamos reconocer. Si esa transición es una pérdida, una transformación o simplemente la siguiente fase del mismo proceso que produjo el yo en primer lugar no es algo que se pueda resolver de antemano. Pero hay que nombrarlo con claridad, porque lo que no se puede ver con claridad no se puede preservar a propósito.</p>


Notas sobre la permanencia, el tiempo y la ergodicidad
2025-12-15T00:00:00+00:00
Algunos sistemas mejoran cuanto más tiempo te quedás con ellos. La repetición afina la ejecución, la experiencia se arrastra hacia adelante y el criterio se construye sobre sí mismo.</p>
En Hermès, un artesano del cuero se entrena dos años antes de tocar una cartera. Un solo artesano hace una cartera de principio a fin, cada puntada a mano, entre quince y veinticuatro horas de trabajo por pieza. Esto es lo opuesto a la velocidad a cualquier costo</a>. También es una de las empresas de lujo más exitosas del mundo. La restricción es parte de lo que el cliente paga.</p>
La cultura en general va en la dirección contraria. Los ciclos se acortan. Las señales se multiplican. Los horizontes de decisión se achican. Muchas instituciones siguen en movimiento mientras pierden en silencio el criterio que alguna vez tuvieron. Siguen ocupadas, pero dejan de mejorar. La copia le gana al aprendizaje.</p>
En ese contexto, la resistencia te dice algo. Si un sistema sigue funcionando bajo presión durante mucho tiempo, su estructura probablemente se ajusta a la realidad mejor que la de sus competidores. Internet no aplanó todo. Hizo más fácil ver quién tenía sustancia y quién vivía de la distribución.</p>
#</a>Dos formas del tiempo</h2>
El tiempo opera en los sistemas humanos de dos maneras fundamentalmente distintas.</p>
El tiempo medido es divisible y uniforme: cronogramas, plazos, períodos contables, tasas de descuento. Se puede asignar, optimizar e intercambiar. La mayoría de los sistemas de planificación viven acá. Suponen que el valor se puede juzgar aparte de la historia.</p>
El tiempo vivido funciona distinto. Se acumula. El aprendizaje, la memoria y el criterio se desarrollan a través de él, y cada ciclo cambia el siguiente. Todo lo que depende de la formación pasa acá. Las fotos instantáneas no captan lo importante porque el valor está en lo que se compone.</p>
En 2001, Boeing mudó su sede de Seattle a Chicago. La razón declarada era ubicar a la empresa más cerca de “Wall Street y los gobiernos”. Los ingenieros que entendían los aviones quedaron físicamente separados de los ejecutivos que entendían las planillas de cálculo. En las dos décadas siguientes, Boeing gastó más de 40.000 millones de dólares en recompras de acciones mientras recortaba la inversión de capital a la mitad del ritmo de Airbus. Harry Stonecipher, que asumió como CEO, dijo que quería que Boeing “se manejara como un negocio y no como una gran firma de ingeniería”. El 737 MAX, diseñado para evitar el costo de volver a entrenar a los pilotos, mató a 346 personas. Esto es lo que pasa cuando el tiempo vivido se fuerza a entrar en el tiempo medido.</p>
Berkshire Hathaway hizo la apuesta contraria. Buffett se niega a dar proyecciones trimestrales de ganancias desde 1996. A los accionistas se les dice que juzguen el negocio a lo largo de décadas, no de trimestres. El resultado son seis décadas de criterio que se compone, el historial sostenido más largo de la historia corporativa estadounidense. Mismos mercados, distinto uso del tiempo.</p>
Cuando el tiempo vivido se fuerza a entrar en el tiempo medido, la formación se rompe. Los estándares no se asientan. El criterio no se compone. Solo descubrís qué es realmente un sistema si lo dejás tranquilo el tiempo suficiente para que te lo muestre.</p>
#</a>Formación bajo restricción</h2>
La excelencia sale de la práctica sostenida bajo las restricciones correctas. Los errores tienen que ser sobrevivibles. La gente necesita espacio para ajustar sin que cada iteración mala se vuelva fatal. El criterio mejora cuando la experiencia pasa de un intento al siguiente.</p>
En Pixar, cada película es malísima durante años antes de ser buena. Ed Catmull describe el proceso como llevar las películas “de ser un desastre a dejar de serlo”. El mecanismo es el Braintrust: un grupo de directores y narradores colegas que se reúnen cada pocos meses para revisar cada película en producción. El detalle clave es que el Braintrust no tiene autoridad. El director no está obligado a tomar ni una sola sugerencia. Eso mantiene alta la franqueza sin convertir la devolución en burocracia.</p>
La mayoría de los estudios matan un proyecto después de una mala proyección de prueba. Pixar trata las malas proyecciones como información, no como veredictos. La diferencia es de estructura, no de talento. La formación lleva tiempo, y el Braintrust protege ese tiempo separando la devolución honesta del poder de cancelar.</p>
#</a>Cuatro dominios</h2>
Armamos Ergodic Group</a> alrededor de la idea de que las organizaciones que perduran trabajan en cuatro dominios: matemática, código, cultura y oficio. La mayoría vive casi siempre en uno. La ventaja sale de conectarlos.</p>
La matemática fija la estructura y las restricciones. El código convierte esa estructura en acción y la pone a prueba contra la realidad. La cultura permite que la intención sobreviva a los cambios de personal. El oficio devuelve todo a los materiales, las tolerancias y las consecuencias físicas.</p>
SpaceX muestra cómo estos dominios actúan unos sobre otros. La matemática: una técnica llamada convexificación sin pérdida (lossless convexification) le permite a una computadora de a bordo resolver en tiempo real trayectorias de aterrizaje óptimas en combustible, calculando el momento exacto para encender los motores de modo que la velocidad llegue a cero al tocar el suelo. El código: un software de guiado autónomo recalcula las trayectorias durante el descenso, ajustando por viento y lecturas de sensores, lo que hace posibles los aterrizajes en plataformas en el océano. La cultura: las fallas se instrumentan, no se esconden. Entre 2013 y 2016, SpaceX estrelló un propulsor tras otro, y cada choque produjo telemetría que llevó a un arreglo concreto. Se quedaron sin fluido hidráulico, así que agregaron más. Se trabó una válvula de aceleración, así que la rediseñaron. El oficio: cuando el laminado de fibra de carbono producía arrugas a unos 200 dólares por kilo, SpaceX pasó Starship a acero inoxidable a unos 3 dólares por kilo. El acero se vuelve más resistente a temperaturas criogénicas, aguanta mucho más calor y abrió perfiles de reentrada que la fibra de carbono no permitía. Una decisión de materiales cambió el vehículo, el software y la matemática.</p>
El aprendizaje se compone cuando estos dominios siguen conectados.</p>
#</a>La ergodicidad como filtro</h2>
La ergodicidad describe una situación en la que la repetición mejora el resultado habitual porque el aprendizaje pasa de una ronda a la siguiente.</p>
Claude Shannon pasó quince años en Bell Labs antes de publicar “A Mathematical Theory of Communication” en 1948. No lo evaluaban por su producción trimestral. Bell Labs les daba a los investigadores algo que las organizaciones modernas casi nunca le dan a nadie: suficiente tiempo sin interrupciones para llegar al fondo de un problema. Esa configuración produjo el transistor, la teoría de la información, Unix, el láser y la telefonía celular. El transistor no salió de un brainstorming sino de gente con distintas especialidades trabajando cerca durante años.</p>
Cuando dividieron AT&T en 1984, ese modelo desapareció con ella. Ninguna empresa de tecnología posterior reprodujo la misma producción. La institución misma guardaba el criterio, y ese criterio no sobrevivió al desarme.</p>
A medida que la aceleración se intensifica, la mayoría de los sectores se vuelven más ruidosos y más frágiles. La coordinación se hace más difícil. La memoria institucional se adelgaza. Ventajas que parecían durables resultan depender de unas pocas personas, unos pocos hábitos o una ventaja de distribución que desaparece. La infraestructura y la cultura duran más porque son entornos dentro de los cuales la gente opera, no productos para vender. Cuando el aprendizaje se arrastra hacia adelante, el tiempo empieza a jugar a tu favor.</p>
#</a>Operación</h2>
En 1984, GM y Toyota abrieron una fábrica conjunta en Fremont, California, llamada NUMMI. Toyota mandó a más de cuatrocientos instructores desde Japón para meses de trabajo codo a codo con empleados estadounidenses. El ausentismo bajó del veinte por ciento al dos por ciento. Las tasas de defectos cayeron a las más bajas de Estados Unidos.</p>
GM intentó exportar las lecciones. Un vicepresidente les dijo a los empleados que “sacaran una foto de cada centímetro cuadrado” de NUMMI y lo replicaran en otras plantas. Fracasó en todos lados. El proceso visible se veía igual. Los resultados no. La pieza que faltaba era el criterio, y el criterio no viaja bien en un memo</a>. Toyota no había armado una checklist. Había armado una forma de trabajar.</p>
La lección de NUMMI va más allá de cualquier práctica concreta. El valor nunca estuvo en el proceso visible; estaba en el criterio que se acumula cuando la gente tiene tiempo para aprender, cuando los vínculos entre dominios siguen intactos y cuando la repetición realmente mejora el trabajo.</p>


El nuevo backend financiero del mundo
2025-12-09T00:00:00+00:00
Por Federico Carrone y Roberto Catalan</strong></p>
El artículo anterior</a> sostuvo que internet dejó un hueco en la infraestructura institucional: movió la información pero no la propiedad. Ethereum llena ese hueco incorporando la propiedad, la transferencia y el cumplimiento en software compartido. Hoy las instituciones financieras gastan recursos enormes en autorización, contabilidad, conciliación y compliance. Ethereum reemplaza una parte de ese aparato con un entorno de ejecución programable y cumplimiento criptográfico. Este artículo mira los mecanismos económicos concretos a través de los cuales funciona ese reemplazo.</p>
#</a>Tres fricciones</h2>
Algunos economistas describen los costos de transacción a través de tres fricciones: triangulación, transferencia y confianza. La triangulación tiene que ver con cómo los actores económicos se identifican entre sí y acuerdan los términos. La transferencia, con cómo se mueve el valor entre ellos. La confianza, con el cumplimiento de las obligaciones. La arquitectura financiera tradicional maneja estas fricciones con escala, sistemas propietarios y coordinación entre intermediarios.</p>
Ethereum baja las tres, y los números ya son difíciles de ignorar. Tomá la transferencia: las stablecoins, tokens en dólares que viven en la cadena, liquidaron unos 27,6 billones de dólares en 2024, más que Visa y Mastercard juntas, con cerca del 95% de ese volumen sobre Ethereum y sus rollups. La mayor parte de esa cifra es flujo de exchanges y bots más que pagos genuinos, así que hay que descontarla mucho, pero la porción de pagos es real y está creciendo, y un dólar se puede mover entre dos desconocidos en países distintos en segundos y por centavos, sin una cadena de bancos corresponsales en el medio. Tomá la confianza: un préstamo en Aave nunca pregunta quién sos. Las reglas de garantía están en un contrato que liquida la posición automáticamente cuando cruza un umbral, y cualquiera puede leer ese contrato antes de firmar.</p>
Nada de esto elimina a las instituciones; cambia qué partes del stack tienen que construir. Una startup que ofrece cuentas en dólares en Lagos o en Buenos Aires ya no construye liquidación, custodia ni compensación. Las hereda como una startup web hereda TCP/IP, y pone su esfuerzo en el producto y la distribución. Eso les permite a las empresas atender mercados que los jugadores establecidos descartan por demasiado chicos o demasiado complejos.</p>
Tener un único libro contable global también cambia la dinámica operativa. Muchas instituciones manejan varias bases de datos que requieren conciliaciones frecuentes y siguen siendo vulnerables a errores. Ethereum mantiene un registro replicado y actualizado de forma continua que no se puede modificar retroactivamente. La redundancia y la capacidad de recuperación pasan a ser propiedades por defecto y no funciones internas costosas.</p>
La seguridad sigue el mismo patrón. En vez de defender una base de datos central, Ethereum reparte la verificación entre muchos actores independientes. Alterar la historia exige coordinación a gran escala y se vuelve prohibitivamente caro. La confianza surge del diseño del sistema y no de promesas institucionales.</p>
#</a>Nuevos servicios financieros y alcance global</h2>
Esto se ve en lo que la gente realmente hace con Ethereum. En Argentina, donde el peso perdió más de la mitad de su valor frente al dólar en 2023, los ahorristas comunes tienen USDT como antes tenían dólares billete en un cajón, salvo que esta versión se mueve. Las remesas que cuestan el promedio global de alrededor del 6% a través de una empresa de envío de dinero se mueven como stablecoins por una fracción de eso. Y los instrumentos van subiendo en la escala de respetabilidad: los fondos tokenizados de letras del Tesoro de EE. UU. pasaron de unos 140 millones de dólares a principios de 2024 a cerca de 8.000 millones a fines de 2025, encabezados por BUIDL de BlackRock con alrededor de 2.800 millones, mientras Franklin Templeton maneja un fondo money market de deuda pública cuyos registros de cuotapartistas viven en siete cadenas distintas.</p>
El patrón de fondo es siempre el mismo. El trabajo que antes vivía dentro de una organización, conciliar libros contables, probar saldos, hacer cumplir los términos de un acuerdo, pasa a un software compartido que cualquier participante puede leer. A la empresa le quedan las partes que realmente la diferencian, el producto y la distribución, y crece ganando usuarios y no reconstruyendo la plomería que sus competidores ya tienen.</p>
El impacto se ve más en mercados con sistemas financieros frágiles. En economías con monedas inestables o redes de pago lentas, Ethereum da mejoras funcionales inmediatas. En los mercados desarrollados los beneficios parecen incrementales, pero se acumulan a medida que más instrumentos y procesos se vuelven programables.</p>
#</a>Transformación institucional y dinámicas de largo plazo</h2>
Muchos instrumentos financieros son heterogéneos. La deuda corporativa es un ejemplo claro. Los términos varían según el vencimiento, el cupón, los covenants, la garantía y el riesgo. Operarla depende de negociaciones bilaterales y de intermediarios que llevan los registros y hacen cumplir las obligaciones. Ethereum puede representar estos instrumentos de forma digital, seguir quién es dueño y ejecutar los términos automáticamente. Los contratos conservan su especificidad, mientras que la administración se vuelve estandarizada e interoperable.</p>
El límite entre lo que las empresas tienen que construir y lo que el software puede hacer cumplir se está moviendo. La regulación y los sistemas legales siguen siendo centrales, pero las instituciones que se apoyan sobre ellos se ven distintas cuando la liquidación, la custodia y el cumplimiento quedan a cargo de una infraestructura compartida en vez de sistemas propietarios.</p>
Ethereum ya funciona como un riel financiero alternativo. Varios clientes desarrollados de forma independiente, un uso real considerable, una comunidad de investigación activa y un compromiso con la apertura y la verificación lo distinguen de otras redes blockchain.</p>
#</a>Conclusión</h2>
Ethereum convierte fricciones financieras centrales en funciones de software, y eso cambia la economía de construir y operar servicios financieros. Las instituciones se vuelven más livianas, enfocadas en el producto y la distribución más que en la infraestructura interna.</p>
Las transiciones tecnológicas empiezan en nichos donde los jugadores establecidos no satisfacen la demanda. A medida que los sistemas maduran, los costos bajan y una adopción más amplia se vuelve posible. Ethereum siguió ese camino. Empezó con comunidades nativas de internet, se expandió por mercados emergentes donde los usuarios no tenían herramientas financieras confiables y ahora está en posición de mejorar los mercados masivos al hacer que las empresas financieras sean más fáciles de crear y operar.</p>
El software se está convirtiendo en el principio organizador de la infraestructura financiera. Ethereum lo vuelve concreto. La regulación y la adaptación institucional van a definir hasta dónde llega, pero los incentivos económicos ya apuntan hacia sistemas abiertos, verificables y resilientes.</p>
#</a>Lecturas recomendadas</h2>

DefiLlama. Stablecoin market cap and supply</a>.</li>
The Defiant (2025). Stablecoins Process $27.6 Trillion in 2024, Surpassing Visa, With 95% Settled on Ethereum</a>.</li>
Yellow.com (2025). Tokenized U.S. Treasuries Hit $7.3B in 2025</a>.</li>
</ul>


La institución que le falta a internet
2025-12-02T00:00:00+00:00
Por Federico Carrone y Roberto Catalan</strong></p>
Internet hizo que copiar y enviar información fuera casi gratis. No respondió la pregunta más difícil: ¿quién es dueño de algo en línea, quién puede transferirlo y quién hace cumplir la respuesta cuando dos personas no están de acuerdo?</p>
Durante mucho tiempo la respuesta práctica fue simple: decide la plataforma. Facebook decide qué pasa con tu página. Apple decide qué se publica en su tienda. Stripe, Visa, un banco o un tribunal deciden si un pago o un reclamo se liquida. Eso funcionó lo suficientemente bien como para construir la web que tenemos, pero dejó la capa económica de internet apoyada sobre términos de servicio privados y sistemas legales locales.</p>
Ethereum es interesante porque intenta poner parte de esa capa institucional faltante directamente en software: registros, reglas, transferencias, garantías y cumplimiento respaldados por incentivos económicos y verificación criptográfica.</p>
#</a>Tecnología, cultura y diseño institucional</h2>
Algunos inventos ayudan a una persona a hacer más. El fuego, la agricultura, la medicina, la computación. Otros ayudan a desconocidos a hacer cosas juntos. Los derechos de propiedad, los contratos, los mercados, las empresas, los tribunales. Los dos importan. Una herramienta nueva crea capacidad; una institución decide quién puede usar esa capacidad, quién cobra y qué pasa cuando alguien hace trampa.</p>
#</a>Los derechos de propiedad y los mercados como tecnologías sociales</h2>
La gente invierte cuando cree que se va a poder quedar con lo que construye. Los derechos de propiedad dan esa seguridad al decir quién es dueño de qué, quién puede usarlo y a quién se puede excluir. Los mercados se apoyan sobre esos derechos. Los precios solo funcionan porque hay alguna maquinaria legal y social por debajo.</p>
Nada de esto es natural. Se construyó a través de la ley, la política, la costumbre y muchísimo compromiso. La economía global del siglo veinte funcionó sobre esa maquinaria: jurisdicciones neutrales, sociedades pantalla, rieles bancarios, normas contables, tribunales y contratos que les permitían a personas que no se conocían comerciar igual.</p>
#</a>La arquitectura faltante de la propiedad digital</h2>
Internet bajó el costo de comunicarse a través de las fronteras, pero nunca creó una forma neutral de definir y hacer cumplir reclamos sobre activos digitales. Fuera de línea, la propiedad pasa por tribunales y Estados. En línea, si no hay una capa de liquidación compartida, la propiedad termina en manos de quien maneja el servidor o de la jurisdicción que pueda alcanzar la disputa.</p>
Las plataformas llenaron el hueco. Nos dieron identidad, búsqueda, feeds, tiendas, pagos, mensajería, distribución. A cambio, se quedaron con la llave. Podés construir dentro de sus muros, juntar usuarios, incluso volverte valioso, pero tus derechos son tan fuertes como la política vigente de la plataforma y sus ganas de seguir teniéndote.</p>
Zynga es el ejemplo más claro. Armó un negocio enorme de juegos sobre Facebook y por un momento llegó a valer más que Electronic Arts. Después Facebook cambió sus políticas y su economía, y el piso se movió. Zynga era dueña de sus juegos, pero no del entorno del que esos juegos dependían. Ese es el trato normal con una plataforma: podés ser dueño del local y seguir alquilando la calle.</p>
Las economías de plataforma te dan participación sin control total.</p>
#</a>Ethereum como experimento institucional</h2>
Ethereum es una respuesta a esa capa faltante. Le da a la gente una forma de crear, transferir y hacer cumplir activos digitales sin pedirle a una empresa o a un Estado que sea el registro final. Las reglas viven en el código. El registro es compartido. La red se controla a sí misma.</p>
En el software común, el operador es soberano. Si una empresa maneja la base de datos, la empresa puede cambiar la base de datos. Ethereum hace eso más difícil al repartir la ejecución entre muchas máquinas que corren el mismo código y se ponen de acuerdo sobre el resultado. El mal comportamiento se castiga económicamente. La confianza sigue estando, pero una parte pasa de un operador privado a un protocolo público.</p>
Entonces parte del trabajo institucional se vuelve trabajo del protocolo. Los auditores revisan registros; Ethereum hace que el registro sea público y se pueda reproducir. Los agentes de custodia (escrow) guardan activos; los smart contracts pueden retener y liberar garantías según reglas. Los tribunales hacen cumplir acuerdos después de los hechos; un contrato on-chain puede hacer que algunas violaciones sean imposibles desde el principio. La ley sigue importando. Lo único que se afirma es que parte del trabajo que antes hacían la ley y los intermediarios puede pasar a una infraestructura compartida.</p>
Dejá de lado la ideología por un momento y mirá la estructura: ningún operador solo puede reescribir el libro contable en silencio ni bloquearle una transacción a todos.</p>
#</a>El surgimiento de un sistema financiero digital</h2>
Ethereum empezó con gente construyendo para sí misma: billeteras, tokens, exchanges, experimentos, juegos de coordinación raros. Después el caso de uso financiero dejó de ser teórico.</p>
El desarrollo más importante fue el auge de las stablecoins</a>, tokens en dólares respaldados por reservas de efectivo y letras del Tesoro de corto plazo. Su valor de mercado combinado superó los 300.000 millones de dólares en 2025, dominado por USDT de Tether (unos 176.000 millones) y USDC de Circle (unos 74.000 millones), en su mayoría emitidos sobre Ethereum. Los flujos ya no son un error de redondeo: las stablecoins liquidaron alrededor de 27,6 billones de dólares en 2024, apenas por encima de Visa y Mastercard juntas, cerca del 95% sobre Ethereum, aunque gran parte de ese volumen es actividad de exchanges y bots más que pagos genuinos.</p>
Las stablecoins son aburridas como es aburrida la infraestructura importante: dólares que se mueven globalmente, se liquidan de forma continua y se enchufan a software. Una vez que esos dólares existen on-chain, se pueden construir a su alrededor mercados de préstamos, sistemas de garantías, exchanges automatizados y flujos de pago.</p>
La diferencia con las finanzas tradicionales es práctica. El sistema es global por defecto. Los servicios comparten estándares. Salir es rápido. El riesgo es visible on-chain, aunque los usuarios lo sigan entendiendo mal.</p>
Comparalo con países como Argentina</a>, donde la interoperabilidad entre bancos y billeteras virtuales, algo tan trivial como escanear un código QR, se puede volver una pelea regulatoria. Los que ya están usan su posición para no conectarse. En Ethereum, la interoperabilidad es la norma porque los activos y los contratos comparten la misma capa base. Desde un celular, un usuario puede recibir dólares, cambiarlos, prestarlos, tomar un préstamo contra una garantía o mandarlos a otro lado. Por eso la adopción es más fuerte donde la intermediación común es cara, lenta o difícil de confiar.</p>
#</a>Implicancias</h2>
Remesas, financiamiento del comercio, crédito privado, letras del Tesoro tokenizadas, mercados de garantías: todo eso está siendo empujado hacia los rieles de blockchain por la misma razón. Son actividades cargadas de registros, cargadas de liquidaciones y llenas de intermediarios cuyo trabajo es, más que nada, verificar y mover reclamos.</p>
Todavía puede salir mal un montón de cosas. La incertidumbre regulatoria, el riesgo operativo y una experiencia de usuario áspera limitan la adopción. Escalar el throughput sin resignar descentralización sigue siendo un problema de ingeniería abierto. Las vulnerabilidades de software y las fallas de gobernanza ya costaron plata de verdad. En 2016 un bug en The DAO drenó unos 60 millones de dólares en ether y partió a la comunidad entre Ethereum y Ethereum Classic por la discusión sobre si recuperarlos. A los puentes entre cadenas (cross-chain bridges) les fue peor: el puente de Ronin perdió unos 625 millones de dólares a manos del grupo Lazarus de Corea del Norte en marzo de 2022. Va a haber más.</p>
La afirmación seria es más acotada que el hype. Parte de la intermediación financiera probablemente pueda funcionar más barata y más transparente sobre rieles compartidos. Que se vuelva masiva depende de la regulación, de los jugadores establecidos, de la experiencia de usuario y de que la ingeniería siga mejorando.</p>
#</a>Inteligencia artificial y coordinación</h2>
La IA abarata la producción. No decide quién es dueño del resultado, quién puede usarlo, quién cobra ni quién es responsable cuando algo sale mal.</p>
Por eso la IA y Ethereum se sienten complementarias más que competidoras. La IA amplía lo que pueden producir las personas y los agentes. Ethereum le da a parte de esa actividad un lugar donde liquidarse: cuentas, pagos, garantías, permisos y contratos que no dependen de un único operador de plataforma. Si los agentes van a comerciar, contratar, usar escrow, licenciar y pagarse entre ellos, van a necesitar rieles donde las reglas sean legibles y la liquidación no sea propiedad de una sola empresa.</p>
#</a>Conclusión</h2>
Internet bajó el costo de transmitir información pero dejó la propiedad digital en manos de quien maneja la plataforma. Ethereum intenta mover parte de esa capa de propiedad y cumplimiento a una infraestructura pública.</p>
Puede volverse infraestructura central. Puede quedar como una herramienta especializada. Los reguladores, los jugadores establecidos y los límites de la ingeniería van a decidir mucho de eso. Pero ya mostró algo importante: la propiedad digital no tiene por qué significar “una entrada en la base de datos de otro”.</p>
Internet construyó una economía antes de construir sus propias instituciones. Ethereum es un intento de construirlas después.</p>
#</a>Lecturas recomendadas</h2>

DefiLlama. Stablecoin market cap and supply</a>.</li>
The Defiant (2025). Stablecoins Process $27.6 Trillion in 2024, Surpassing Visa, With 95% Settled on Ethereum</a>.</li>
CoinDesk (2022). Axie Infinity’s Ronin Network Suffers $625M Exploit</a>.</li>
</ul>


Los próximos 10 años de Ethereum
2025-11-15T00:00:00+00:00



Gracias al Senado de la Nación Argentina
2025-11-12T00:00:00+00:00
El 12 de noviembre de 2025 recibí una Mención de Honor al Valor Científico de la Comisión de Ciencia y Tecnología del Senado argentino. Gracias.</p>


La hoja de ruta de rollups nativos de Ethereum, con Justin Drake
2025-10-01T00:00:00+00:00



Doctrina cripto
2025-09-25T00:00:00+00:00
#</a>Cripto y el siglo XXI acelerado y caótico</h2>
Cripto fue más útil donde la confianza es más débil. En la práctica, encontró product-market fit en dos lugares:</p>

En países donde la inflación, los controles de capital o la censura son restricciones de todos los días, cripto les da a las personas y a las empresas herramientas que realmente necesitan.</li>
En comunidades nativas de internet, cripto ofrece una capa financiera que permite coordinar, especular y construir mercados a una escala que la web no soportaba antes.</li>
</ul>
A la gente que no vive en un país en desarrollo o que no creció con internet le cuesta muchísimo entender cripto porque no tiene skin in the game. Cree que cripto no tiene ningún caso de uso “real” o que no es lo suficientemente serio. Tiene razón. El tema es que estamos viviendo en un mundo que se vuelve cada vez más absurdo.</p>
Los memes ya no solo te hacen reír: ahora los memes ganan elecciones.</p>
Estos casos de uso van a crecer con el tiempo y probablemente se encuentren otros nuevos. El mundo se vuelve más caótico y más dividido cada día. Cripto se beneficia de ese tipo de entorno porque reduce la cantidad de lugares donde la confianza se tiene que aceptar por fe.</p>
Una de las principales ventajas de cripto es que elimina a muchos de los intermediarios y nos permite coordinarnos</a> incluso en los entornos más hostiles. Los supuestos de confianza bajan porque una parte mayor del sistema la hacen cumplir los incentivos, los compiladores, los sistemas distribuidos y la criptografía. Eso no elimina la política ni los desacuerdos; solo achica el conjunto de cosas sobre las que la gente tiene que discutir.</p>
La mayoría de nosotros somos nativos de internet. Crecimos en IRC, 4chan, Reddit, Hacker News, Twitter, Bitcoin y Ethereum, y además tenemos raíces en países inestables. Somos los Fremen de cripto, criados en un entorno hostil. Sabemos cómo se sienten desde adentro las sociedades caóticas, y sabemos lo que hace falta para construir dentro de ellas. Al mismo tiempo, somos constructores a los que nos gusta trabajar en la frontera del cambio científico y de ingeniería.</p>
El open source y la descentralización no son solo preferencias filosóficas para cripto. Son condiciones prácticas para que el ecosistema funcione. Construir en abierto, ayudar a que otros se sumen y crear sistemas más grandes que el proyecto original son parte de cómo cripto sobrevive a largo plazo. Esto puede parecer irracional si asumís que el único objetivo es la extracción de corto plazo. Se entiende mejor si asumís que el objetivo es ayudar a que persista una nueva capa financiera y de coordinación.</p>
Nuestro objetivo principal es ayudar a que estas nuevas autopistas de internet se construyan de manera sostenible. La sostenibilidad económica importa, pero también la resiliencia, la apertura y la capacidad de resistir la deriva habitual hacia la centralización. La centralización casi siempre es más fácil en el corto plazo. Si el dinero puro fuera el único objetivo, habría formas más simples de ganarlo. Tratamos al dinero como una herramienta, no como el fin último.</p>
Si cripto es útil o no ya está resuelto. Lo es, en lugares donde la mayoría de los críticos nunca mira. La pregunta abierta es si los sistemas que se están construyendo hoy van a ser lo suficientemente resilientes como para importar cuando llegue la próxima ronda de caos.</p>


Los mercados como puntos fijos reflexivos
2025-06-14T00:00:00+00:00
Los mercados son el laboratorio más limpio para la dinámica reflexiva.</p>
Los precios no los determinan solamente las creencias. Importan los flujos de caja, las restricciones, los inventarios, la regulación, el apalancamiento y los flujos. Pero las creencias sobre los precios se vuelven operaciones, las operaciones se vuelven precios, y los precios actualizan las creencias.</p>
Ese loop es el objeto.</p>
La biología llega a una organización parecida a la crítica a través de la selección, la retroalimentación y el desarrollo a lo largo del tiempo evolutivo. Los mercados pueden generar estadísticas parecidas a las críticas mucho más rápido, porque el loop de retroalimentación es explícito. Los participantes modelan el mercado mientras participan en el mercado. Sus modelos no son descripciones externas. Son parte de la cosa que se está describiendo.</p>
La afirmación cuidadosa no es que todo mercado esté literalmente parado sobre un punto crítico físico. La afirmación es más estrecha y más fuerte: la reflexividad, el apalancamiento, la liquidez, la imitación y el coarse-graining pueden hacer que los mercados se comporten como sistemas cerca de la criticidad. Producen colas pesadas (fat tails), agrupamiento de volatilidad (volatility clustering), cascadas correlacionadas, histéresis y dependencia de la trayectoria.</p>
#</a>El vocabulario mínimo</h2>
Reflexividad</strong> quiere decir que la descripción del sistema afecta al sistema que se describe. En los mercados, una creencia sobre los precios se puede volver una orden, y la orden puede mover los precios.</p>
Un libro de órdenes</strong> (order book) es el conjunto actual de ofertas de compra y de venta en espera. Es una foto local de la liquidez: cuánto se puede comprar o vender antes de que el precio tenga que moverse.</p>
Liquidez</strong> quiere decir la capacidad de operar sin mover demasiado el precio. La baja liquidez hace más fuerte la retroalimentación, porque un flujo dado mueve más el estado.</p>
Apalancamiento</strong> (leverage) quiere decir controlar una posición más grande que el capital propio. Amplifica las ganancias, las pérdidas, las ventas forzadas y el contagio.</p>
El margen</strong> es la garantía que se exige para mantener abierta una posición apalancada. Si las pérdidas bajan el patrimonio por debajo del nivel requerido, las posiciones se tienen que reducir o liquidar.</p>
Agrupamiento de volatilidad</strong> quiere decir que a los movimientos grandes tienden a seguirlos movimientos grandes, y a los períodos tranquilos tienden a seguirlos períodos tranquilos. Esta es una de las razones por las que el riesgo de mercado no queda bien descripto por shocks gaussianos independientes.</p>
Coarse-graining</strong> (agregación de escala) quiere decir reemplazar el detalle fino por resúmenes de escala más grande. En los mercados, eso puede significar agregar operaciones en ventanas de tiempo más largas.</p>
Un exponente de cola</strong> describe qué tan rápido desaparecen los eventos grandes y raros. Para una cola de supervivencia:</p>
$$P(|R|>x)\sim Cx^{-\alpha},$$</p>
un $\alpha$ más chico significa una cola más pesada.</p>
Histéresis</strong> quiere decir que la trayectoria importa. Un sistema puede pasar de un régimen a otro y no volver por el mismo camino cuando el parámetro original se revierte.</p>
#</a>El espacio de estados de un mercado</h2>
Un mercado no es solo una serie de precios. El precio es la coordenada visible, pero no es todo el estado.</p>
Un vector de estado mínimo podría incluir:</p>
$$x_t=(p_t,b_t,L_t,Q_t,\sigma_t,C_t),$$</p>
donde:</p>

$p_t$ es el precio,</li>
$b_t$ es la distribución de creencias o pronósticos,</li>
$L_t$ es el apalancamiento,</li>
$Q_t$ es la profundidad de liquidez,</li>
$\sigma_t$ es la volatilidad percibida,</li>
$C_t$ es la correlación entre activos.</li>
</ol>
Esto sigue siendo una caricatura. Los mercados reales incluyen inventarios, restricciones de fondeo, market makers, dealers de opciones, flujos pasivos, regulación, noticias, impuestos, liquidación y mandatos institucionales. Pero incluso este estado reducido alcanza para mostrar por qué los mercados son no lineales.</p>
Las variables no se mueven de forma independiente. Si el precio cae, las estimaciones de volatilidad suben. Si la volatilidad sube, los límites de riesgo se ajustan. Si los límites de riesgo se ajustan, se recortan posiciones. Si se recortan posiciones con poca liquidez, el precio vuelve a caer. Eso es un loop de retroalimentación, no una secuencia de shocks independientes.</p>
Así que la actualización del mercado tiene la misma forma que cualquier sistema dinámico de la serie:</p>
$$x_{t+1}=F(x_t,\eta_t),$$</p>
pero ahora una parte de $x_t$ está hecha de creencias sobre $F$ mismo. Ese es el ingrediente reflexivo extra.</p>
#</a>¿Qué es una variable de creencia?</h2>
“Creencia” suena a algo psicológico, pero la versión de mercado se puede hacer concreta.</p>
Una creencia es cualquier regla que convierte información en una posición deseada:</p>
$$\text{information}\longrightarrow\text{forecast}\longrightarrow\text{order}.$$</p>
Un inversor discrecional puede expresar esto como una historia: “las ganancias se van a acelerar, así que la acción está barata”. Un seguidor de tendencia puede expresarlo como una regla: “si el momentum de doce meses es positivo, comprá”. Un market maker puede expresarlo como una cotización ajustada por inventario. Un modelo de riesgo puede expresarlo como un objetivo de volatilidad. Un fondo indexado pasivo puede no expresar casi ningún pronóstico, pero igual sigue una regla que convierte flujos en operaciones.</p>
A nivel de población, las creencias no son un número. Son una distribución de estrategias:</p>
$$b_t=\text{distribution of forecasts, constraints, and trading rules at time }t.$$</p>
Esa distribución es parte del estado del mercado porque determina el flujo futuro. Si suficiente capital usa el mismo modelo, el modelo se vuelve una fuerza. Si el modelo deja de funcionar, el capital se va, y la distribución cambia.</p>
#</a>La reflexividad como problema de punto fijo</h2>
Los participantes modelan el mercado. Sus modelos generan operaciones. El agregado de las operaciones fija los precios. Los precios realizados actualizan los modelos.</p>
Al nivel del ecosistema de estrategias:</p>
$$\text{distribution of models}=F(\text{distribution of models}).$$</p>
Este es el concurso de belleza de Keynes en lenguaje de punto fijo. El mercado no solo pregunta cuánto vale un activo. Pregunta qué creen los demás que los demás van a creer que vale.</p>
Soros llamó a esto reflexividad. En el lenguaje de esta serie, la reflexividad es la clausura representacional hecha institución. Un mercado es un sistema donde las descripciones del sistema retroalimentan el estado del sistema.</p>
Esto no quiere decir que los mercados sean ruido irracional. Quiere decir que el objeto al que se le pone precio está en parte moldeado por el acto de ponerle precio. Por eso el punto fijo puede ser inestable, no único, o inalcanzable con una dinámica simple.</p>
El mecanismo es concreto:</p>

los participantes modelan el mercado,</li>
los modelos generan operaciones,</li>
las operaciones mueven los precios,</li>
los precios actualizan los modelos,</li>
los modelos rentables atraen capital,</li>
el capital cambia el mercado que hizo rentables a los modelos.</li>
</ol>
En ese punto el meta-nivel se financiariza. No hay solamente un mercado de activos; hay un mercado de modelos del mercado. Los hedge funds, los portafolios de factores, los modelos de riesgo, los algoritmos de ejecución y las reglas pasivas compiten todos por convertirse en la descripción dominante. La distribución de modelos la determinan los resultados, y los resultados los determina la distribución de modelos.</p>
Por eso la ecuación de punto fijo corresponde al nivel del ecosistema de estrategias:</p>
$$\text{distribution of strategies}=F(\text{distribution of strategies}).$$</p>
En el lenguaje del equilibrio, esto está emparentado con Nash. En el lenguaje de Keynes, es el concurso de belleza. En el lenguaje de Soros, es la reflexividad. En el lenguaje del ensayo anterior</a>, es la clausura representacional: el sistema contiene modelos de sí mismo que ayudan a producirlo.</p>
Acá es donde rinden los dos primeros ensayos</a>. Un punto fijo reflexivo no es automáticamente un atractor. El punto fijo logístico $x^\star=1-1/r$ sigue existiendo más allá de $r=3$, pero deja de atraer: los estados cercanos orbitan a su alrededor en vez de asentarse en él. El punto fijo de creencias del mercado se puede comportar igual. El apalancamiento, el amontonamiento (crowding) y la velocidad de la retroalimentación cumplen el papel de parámetros de control. Pasado un umbral, el punto fijo puede perder estabilidad. Entonces los precios no convergen a él. Pueden oscilar, marcar tendencia, pasarse de largo o saltar entre regímenes.</p>
Esto no es una prueba de que todo mercado reflexivo sea crítico. Es un mecanismo. La reflexividad aporta retroalimentación. El apalancamiento amplifica la retroalimentación. Las restricciones de liquidez hacen que la retroalimentación sea no lineal. Cuando esas fuerzas interactúan a lo largo de muchas escalas de capital y de tiempo, el sistema puede producir las firmas empíricas asociadas con la criticidad: volatilidad agrupada, colas pesadas, caídas (drawdowns) de muchos tamaños y saltos repentinos de correlación.</p>
Una burbuja no es simplemente “gente que se equivoca”. Es un régimen reflexivo en el que las subas de precio validan las creencias que causaron las compras, y eso atrae más capital hacia la misma creencia. Un crash no es simplemente “la verdad que llega”. Muchas veces es el sistema acotado forzando las posiciones de vuelta a través de restricciones de liquidez, llamados de margen y límites de riesgo.</p>
Un modelo reflexivo mínimo tiene dos variables de estado: el precio $p_t$ y la creencia $b_t$.</p>
$$p_{t+1}=F(p_t,b_t),$$</p>
$$b_{t+1}=G(b_t,p_{t+1}).$$</p>
Un modelo no reflexivo trataría las creencias como externas o fijas. Un modelo reflexivo deja que creencias y precios se actualicen mutuamente. Un equilibrio local es un punto fijo:</p>
$$p^\star=F(p^\star,b^\star),\qquad b^\star=G(b^\star,p^\star).$$</p>
La estabilidad pasa a ser una cuestión del jacobiano. Linealizá el mapa bidimensional alrededor de $(p^\star,b^\star)$. Si los autovalores quedan dentro del círculo unitario, las perturbaciones se apagan. Si un autovalor cruza el círculo unitario, el mercado puede pasar a oscilar, a amplificar tendencias o a cambiar de régimen. Es la misma lógica de estabilidad local que la del mapa logístico, pero ahora el estado incluye creencias sobre el estado.</p>
Para hacerlo concreto, usá la forma linealizada más simple:</p>
$$\begin{pmatrix} p_{t+1} \\ b_{t+1} \end{pmatrix}
=
\begin{pmatrix} a & c \\ d & e \end{pmatrix}
\begin{pmatrix} p_t \\ b_t \end{pmatrix}.$$</div>
El coeficiente $c$ dice que las creencias mueven los precios. El coeficiente $d$ dice que los precios actualizan las creencias. La reflexividad es el producto $cd$. Si $cd$ es chico, el loop se amortigua. Si $cd$ es grande, el loop amplifica. Los autovalores de la matriz te dicen en qué régimen estás.</p>
Acá también resulta que dos visiones del mundo famosas son la misma pregunta de estabilidad local. La reflexividad tiene signo. Cuando el loop se autocorrige, una creencia que empuja el precio demasiado arriba invita a las operaciones que lo vuelven a bajar, los autovalores quedan dentro del círculo unitario y los precios siguen a los fundamentos: esa es la imagen del mercado eficiente. Cuando el loop se autorrefuerza, una creencia que empuja el precio para arriba invita a operaciones que validan la creencia y lo empujan todavía más, un autovalor cruza el círculo unitario y aparecen burbujas y crashes: esa es la reflexividad de Soros. No son ecuaciones rivales sobre cómo funcionan los mercados. Son regímenes distintos del mismo mapa de dos variables. El producto $cd$ mide el loop de retroalimentación directo, pero el umbral de estabilidad es el radio espectral del jacobiano completo, el mismo umbral</a> del primer ensayo, que ahora decide si un mercado se autocorrige o se desboca. El desacuerdo es empírico, sobre en qué régimen está un mercado dado y cuándo, no sobre la matemática.</p>
Una salvedad, dicha sin vueltas para no vender de más la jugada: esta lectura de “mismo mapa, dos regímenes” es la lente interpretativa que trae esta serie, no un tratado que Fama y Soros firmarían los dos. Fama en gran medida rechaza la reflexividad por ser demasiado imprecisa para testearla; Soros considera la hipótesis del mercado eficiente una idealización dañina. La reconciliación es lo que agrega el encuadre de sistemas dinámicos, no un relato neutral que cada bando avalaría. Lo que sí se gana con el encuadre es una pregunta más filosa: en vez de preguntar qué lado tiene razón en general, preguntá en qué régimen está un mercado dado y qué está empujando la ganancia de su loop más allá de la línea.</p>
Es la misma matemática que la de un controlador de retroalimentación bidimensional. Las finanzas agregan un detalle feo: los coeficientes mismos cambian durante el estrés. La liquidez $Q_t$ cae, las restricciones de apalancamiento empiezan a morder y las estimaciones de volatilidad suben. Así que la matriz que parecía estable en condiciones tranquilas se puede volver inestable justo cuando importa.</p>
#</a>Simulación: retroalimentación reflexiva</h3>