Por qué simular una economía
Hay una diferencia entre entender un concepto y ver cómo se comporta. Puedo leer que un sistema exhibe homeostasis, que sus partes están interconectadas, que produce emergencia. Pero eso sigue siendo abstracto hasta que lo pongo a correr: agentes que trabajan, un mercado que ajusta condiciones, un gobierno que recauda y redistribuye, y la riqueza que fluye de maneras que nadie programó explícitamente.
Eso fue lo que construí en teoria-sistemas: un modelo de simulación de una economía mínima, escrito en Python, cuyo propósito no era predecir nada real sino explorar si los conceptos teóricos se vuelven visibles cuando los materializas en código.
El problema que me interesaba
La teoría de sistemas lleva décadas intentando darle un lenguaje unificado a fenómenos muy distintos: ecosistemas, organismos, mercados, ciudades, redes neuronales. El argumento central es que ciertos patrones de comportamiento —retroalimentación, jerarquía, adaptabilidad, entropía— aparecen en todos esos dominios independientemente de cuál sea el sustrato.
Eso es una afirmación fuerte. Y la forma honesta de ponerla a prueba no es escribir un ensayo sobre ella, sino construir el sistema y ver si los patrones aparecen solos.
El dominio económico tiene una ventaja: es suficientemente familiar como para que los resultados sean interpretables, pero suficientemente complejo como para que los comportamientos emergentes no sean triviales. Si puedo ver redistribución de riqueza, cooperación espontánea y ajuste de roles surgiendo de reglas simples, entonces la teoría de sistemas está haciendo su trabajo.
Lo que el modelo incorporó
El código tiene tres clases principales: Agent, Market y Government. Cada una modela una entidad con sus propias reglas de comportamiento.
Los agentes trabajan, consumen y adaptan su rol según su nivel de riqueza —cuando acumulan suficiente, se convierten en empleadores; cuando pierden, vuelven a ser empleados. Eso no es una regla programada sobre clases sociales: es una condición de umbral que produce estratificación como efecto secundario.
El mercado implementa homeostasis a través del método adjust_conditions: cuando el sistema se aleja de ciertos límites, actúa para corregirlo. El gobierno impone impuestos y redistribuye, intentando reducir la entropía del sistema, aunque sin garantizar que lo logre.
Las funciones de utilidad y ganancia son no lineales —raíz cuadrada y logaritmo— porque la realidad económica no es lineal. Un agente que pasa de cero a cien unidades de riqueza no experimenta lo mismo que uno que pasa de mil a mil cien.
Lo que la simulación enseña sobre los sistemas
Hay algo que solo se aprende corriendo el código: la diferencia entre diseñar comportamiento y diseñar reglas que producen comportamiento.
Yo no programé que los agentes cooperen. Programé que bajo ciertas condiciones de mercado, cooperar les da mejores resultados que competir individualmente. La cooperación emergió como estrategia racional dentro de las reglas del sistema. Eso es precisamente lo que la teoría de sistemas llama emergencia: propiedades del todo que no están presentes en ninguna parte.
También emergió algo menos esperado: la redistribución de riqueza no estabiliza el sistema de manera permanente. El gobierno puede inyectar recursos y ajustar condiciones, pero la dinámica no lineal implica que el equilibrio es temporal, no estructural. El sistema vuelve a separarse. Eso no lo diseñé; apareció.
La visualización en 3D fue deliberada: quería ver simultáneamente la riqueza de empleadores, la de empleados y la "satisfacción" del sistema —definida como el producto de riqueza y cooperación— a lo largo del tiempo. Ver las tres dimensiones juntas hace visible algo que los números sueltos no muestran: que maximizar una dimensión frecuentemente deprime las otras.
Simular como método filosófico
Esto no es un proyecto de economía. No tiene datos reales, no predice ningún mercado, no tiene aplicación inmediata. Es un ejercicio epistemológico: ¿qué sucede cuando traduzco una teoría a un sistema ejecutable?
Lo que sucede es que las inconsistencias se vuelven visibles. Si una teoría tiene huecos, el programa falla o produce resultados absurdos. Si una abstracción es vaga, no puedo implementarla sin elegir una interpretación concreta. Programar obliga a precisar lo que el lenguaje natural permite dejar difuso.
En ese sentido, construir este modelo fue más una práctica filosófica que de ingeniería. La pregunta no era cómo hacer que funcione, sino qué significa que funcione: ¿qué dice sobre la teoría el hecho de que los patrones aparezcan, o de que no aparezcan?
Este repo marcó el inicio de una serie de exploraciones computacionales sobre sistemas complejos —caos, información, juegos, autómatas. En todos ellos, el movimiento es el mismo: tomar un concepto teórico, darle cuerpo en Python, y ver qué dice el comportamiento sobre la idea.