Arquitectura, seguridad y sistemas distribuidos · Ingeniería asistida por agentes
Ocho años construyendo software. Los últimos, sistemas distribuidos orientados a eventos: microservicios que se hablan por colas, integraciones firmadas entre plataformas y la infraestructura que los sostiene en producción.
Trabajo desde el criterio, no desde la herramienta. Las preguntas que me ordenan el diseño son siempre las mismas: qué garantiza que esto es correcto, qué pasa cuando falla y quién puede acceder a qué.
Hace más de un año que construyo con agentes de código. El trabajo se corrió de escribir a definir el criterio de aceptación y las restricciones que el resultado tiene que atravesar.
Lo que llevo a un equipo no es un lenguaje. Es criterio sobre estas cinco cosas.
Arquitectura y diseño
Separo por razones operativas, no por moda. Cada límite del sistema tiene que poder justificarse con algo que pasa en producción.
Ver los 6 puntosOcultar
Extender la herramienta que el negocio ya usa antes que levantar un sistema paralelo. Casi todo lo que construí en los últimos años es eso: un módulo, un canal o un servicio que se enchufa a una plataforma existente por sus contratos públicos, sin pedirle al equipo que cambie de herramienta.
Servicios con contextos de build independientes, cuando hay un motivo de disponibilidad concreto: redesplegar la interfaz no puede reiniciar el ingestor de eventos, que tiene que seguir recibiendo.
Orientación a eventos sobre un broker de mensajes: cola, audit log, dead-letter queue, y el enrutamiento de dominio separado del ingreso.
Puertos y adaptadores donde importa. En el prototipo de pagos, cambiar la pasarela simulada por la real toca un solo archivo: ni el dominio ni la interfaz se enteran.
Contrato primero: el sobre, los enums y los códigos de resultado definidos antes que el código que los usa.
Separación de plano de control y plano de datos, cache-aside, BFF y fachada — aplicados donde resuelven algo, no como catálogo.
Seguridad
No como una capa que se agrega al final, sino como la propiedad que decide la forma del sistema.
Ver los 7 puntosOcultar
Criptografía verificada en los dos extremos: firma RSA-SHA256 de 2048 bits con serialización canónica sobre un sobre de pagos. Alterar un byte de la firma hace fallar la operación con el código de error del contrato.
Verificación de firma Ed25519 en los webhooks entrantes, antes de que el evento toque la cola.
Aislamiento de ejecución no confiable: contenedor efímero por turno, usuario sin privilegios, límites de memoria, CPU y procesos, y únicamente el espacio de trabajo montado.
Superficies de autenticación separadas: secreto entre servicios comparado en tiempo constante, y credenciales de usuario de vida corta emitidas por el plano de control.
Autorización por módulo sobre un catálogo de permisos explícito, con roles sembrados de forma idempotente.
Defensa en profundidad en el borde: un único contenedor con puertos al host, backends sin exposición pública y rutas internas rechazadas en el proxy.
Auditoría de superficie expuesta de un servidor: puertos escuchando en todas las interfaces, registros de autenticación y llaves autorizadas, con un plan de endurecimiento — acceso solo por llave, firewall y secretos fuera del código.
Fiabilidad y operación
Diseñar para el día en que algo falla, porque va a fallar. Lo que importa es si se puede ver, rastrear y reprocesar.
Ver los 6 puntosOcultar
Idempotencia y reintentos con backoff en toda integración que cruza un límite de red.
Dead-letter queues y audit log: un evento que falla se puede encontrar, entender y reprocesar.
Healthchecks en los contenedores, logs estructurados, métricas y monitoreo activo.
Los trabajos programados van a un motor de workflows, no a un cron colgado del servidor. Cada ejecución queda registrada con su entrada, su salida y su error, y se puede reintentar sin entrar por SSH. Un cron que falla a las tres de la mañana no deja rastro de por qué falló.
Despliegue en contenedores detrás de un proxy inverso con TLS. Lo interno no sale a internet.
Las zonas horarias como decisión de diseño y no como valor por defecto: un sistema que razona en hora del comercio le cierra el día cuando el comercio cierra.
Metodología y equipo
El código es la mitad del trabajo. La otra mitad es que alguien más pueda entenderlo, extenderlo y confiar en él.
Ver los 4 puntosOcultar
Tests como especificación ejecutable, escritos para definir el comportamiento y no como trámite posterior.
Documentación de arquitectura como contrato del repositorio: un golden path escrito para que todo módulo nuevo se construya igual que los anteriores.
Siete años enseñando Algoritmos y Programación a nivel universitario. Explicar un sistema a quien no lo conoce es la mitad del trabajo de un ingeniero senior.
Entregas predecibles con equipos distribuidos y en husos horarios distintos: decisiones escritas donde se puedan encontrar después, y avance que no dependa de que alguien esté conectado a la misma hora que yo.
Ingeniería con agentes
Hace más de un año que no escribo código a mano. Especifico, restrinjo y verifico.
Hace más de un año que no escribo código a mano. Especifico, restrinjo y verifico.
Reemplacé la lectura de diffs línea por línea por restricciones verificables. El trabajo se corrió de escribir código a definir el criterio de aceptación, y eso tiene dos disciplinas con nombre propio.
Test-Driven Development, que es de siempre: el test se escribe antes y define el comportamiento, así que funciona como criterio de aceptación y no como verificación posterior. Y Spec-Driven Development, que nació de esto mismo: la especificación versionada es la fuente de verdad y el código es lo que se genera contra ella. Este sitio funciona así — el contenido vive en un archivo, y la página y el PDF son salida.
El circuito que tiene que atravesar lo que produce un agente: tests automatizados como criterio de aceptación, análisis estático de seguridad, mutation testing —mutar el código y comprobar que los tests efectivamente fallan— y límites de complejidad y de dependencias. Si algo de eso no pasa, no se despliega.
Revisar dejó de ser leer. Es diseñar ese circuito antes de que el resultado exista. Eso no es una herramienta que se aprende: es una decisión de arquitectura.
“My current strategy is to not read any of the code written by my agents. […] What I do instead is to surround the agents with extreme constraints.”
En el módulo constructor de agentes de la plataforma de apps, la frontera de seguridad no son las restricciones de herramientas del agente: es un gate de publicación del lado del servidor —análisis estático de seguridad en estado prístino más la suite de tests— que el código tiene que atravesar para llegar a desplegarse. La decisión está razonada y escrita en el código, no implícita en la configuración.
Una capa de capacidades propia
Alrededor de cincuenta procedimientos versionados sobre las APIs que uso a diario, tipados y con alcance acotado, en lugar de depender de funcionalidades genéricas. Lo relevante no es la cantidad: es que tienen gobierno. Credenciales por dominio con mínimo privilegio, estándares propios que se le imponen al agente, y ciclo de vida real — lo que se reemplaza queda marcado como obsoleto con un puntero a su sucesor, no se borra.
Un contrato reconstruido
Los manuales de integración de una pasarela de pagos se publican como PDFs escaneados, sin texto extraíble. El nombre del archivo delataba al proveedor real, que sí documenta en texto. Desde ahí: contrato reconstruido, firma criptográfica verificada en los dos extremos y tests que la ejercitan. Todo eso —protocolo, criptografía, app, backend simulado y despliegue— en menos de una tarde. La velocidad la ponen los agentes; qué había que construir y qué tenía que resistir, no.
menos de 4 horas
Portafolio
Cinco sistemas. En los dos primeros está casi todo lo que sé hacer.
Otimify · 2026
Plataforma de apps sobre un ecosistema SaaS
Extender un CRM de terceros con módulos propios, con su propio sistema de permisos, sin poder tocar su código.
Ciclo de vida de un evento · si falla → dead-letter queueVer detalleOcultar detalle
El problema
Un CRM SaaS que la operación ya usa, que hay que extender con funcionalidad propia. No se puede modificar su código, hay que integrarse por sus contratos públicos, y el ingreso de eventos del CRM no se puede caer cada vez que se publica una funcionalidad nueva.
Decisiones
Cinco servicios con contextos de build independientes. Redesplegar la interfaz no recompila ni reinicia el ingestor de webhooks, que tiene que seguir recibiendo eventos del CRM sin interrupción. Ese es el motivo de la separación, y está documentado como tal.
Pipeline de eventos completo: ingreso con firma Ed25519 verificada, cola, audit log, motor de reenvío configurable a destinos externos, enrutamiento de dominio y, si algo falla, dead-letter queue. El plano de control del reenvío está separado del plano de datos.
Un único contenedor con puertos al host, con TLS automático, oficiando de borde. El resto de los servicios solo expone puertos en la red interna, y las rutas destinadas a comunicación entre servicios se rechazan en el borde aunque alguien las conozca.
Inicio de sesión único dentro del iframe del CRM, con un token independiente de la cuenta —la cuenta viaja por cabecera— y autorización por módulo sobre un catálogo de permisos explícito, complementando el sistema de usuarios del propio CRM.
Un golden path documentado: cómo se agrega un módulo nuevo, qué convenciones son innegociables y qué componentes hay que reutilizar en vez de reinventar.
El módulo que más me gusta: el constructor de agentes
Ejecuta un agente de código en un contenedor efímero por turno —usuario sin privilegios, límites de memoria, CPU y procesos, y solo el espacio de trabajo montado— para que se lo pueda instruir en lenguaje natural y construya y despliegue otros agentes ya integrados al ecosistema del CRM. Dos superficies de autenticación separadas: secreto entre servicios comparado en tiempo constante, y credenciales de usuario de vida corta emitidas por el plano de control. La frontera de seguridad real es el gate de publicación, no las restricciones de herramientas del agente.
Resultado
La plataforma sostiene módulos independientes, cada uno con sus propios permisos, sobre la estructura de usuarios del CRM. Publicar una funcionalidad nueva no interrumpe la ingesta de eventos.
Java 17
Spring Boot
PostgreSQL
RabbitMQ
React
Python
FastAPI
n8n
Docker
Caddy
Se describen decisiones y patrones. Los detalles de la operación del cliente quedan fuera.
Proyecto propio · 2026
Portal contra una pasarela de pagos real
Un prototipo que habla el protocolo real de una pasarela de pagos, reconstruido desde documentación escaneada.
Recorrido de una operación firmada · un byte alterado → la operación fallahandy-poc.fluxing.appVer detalleOcultar detalle
El problema
Los manuales de integración de la pasarela se publican como PDFs escaneados, sin texto extraíble. Construir un prototipo creíble exigía primero reconstruir el contrato, y no inventar modelos que se parecieran.
Decisiones
El nombre del archivo del manual delataba al proveedor real de la pasarela, que sí publica documentación en texto. Con eso el prototipo dejó de usar modelos inventados y pasó a hablar el protocolo real: sobre firmado, serialización canónica, códigos de resultado, estados de transacción y la normativa de inclusión financiera que aplica.
Firma y verificación RSA-SHA256 de 2048 bits en los dos extremos. Alterar un solo byte de la firma devuelve el código de error que define el contrato: la criptografía es real aunque la pasarela sea simulada.
Puertos y adaptadores: apuntar al ambiente de homologación real toca un único archivo de configuración, más cargar el certificado emitido por el proveedor. Ni el dominio ni la interfaz se enteran. Ese es el argumento de la arquitectura.
Feed de ventas en tiempo real por WebSocket, y los centavos del monto disparan cada camino de error de la pasarela — para poder mostrar los fallos en vivo, durante una demostración, sin tocar código.
Resultado
Desplegado y navegable. Un solo contenedor sirve la API simulada y la aplicación. Los datos son sintéticos y generados con semilla fija: el prototipo es reproducible.
Flutter
Node.js
WebSocket
RSA-SHA256
Docker
Prototipo con fines de demostración técnica. No procesa cobros reales ni está afiliado a ninguna empresa.
Fluxing LLC · producto propio
Plataforma de automatización comercial
Servidor de autenticación y licenciamiento de la aplicación de escritorio: credenciales firmadas, hashing con bcrypt, sesión del lado del servidor para el panel de administración y auditoría de cada intento de acceso. Alrededor, los servicios de sincronización y orquestación del producto.
Un canal de mensajería instantánea construido desde cero sobre la librería Baileys y dado de alta como proveedor nativo del CRM: sostiene la sesión, reconecta, envía y recibe por la API de la plataforma, y publica cada mensaje en el broker para que los microservicios asíncronos lo procesen. Tres lenguajes conversando por colas, con webhooks firmados, idempotencia y reintentos con backoff.
Node.js
Fastify
Baileys
Java 17
Spring Boot
RabbitMQ
PostgreSQL
GoHighLevel
Roche · 2022–2024
Datos y lenguaje natural sobre el data warehouse
Librería Python publicada en PyPI para consumir distintos data warehouses corporativos desde un solo cliente. Un chatbot que traduce preguntas en lenguaje natural a SQL ejecutable contra esos almacenes y responde con los resultados. Procesos ETL, tableros analíticos e ingeniería inversa de APIs públicas para integrar datos externos.
Diseño y construcción de la plataforma de apps propias que extiende el CRM sobre el que corre la operación: pipeline de eventos, inicio de sesión único, permisos por módulo y el constructor de agentes. En paralelo, la gestión del proyecto y la priorización con los clientes.
Producto propio de automatización comercial. Arquitectura, backend, autenticación y licenciamiento, infraestructura y despliegue. Aplicaciones móviles en React Native para iOS y Android.
Diseño, construcción y operación de microservicios orientados a eventos en Java 17, comunicados por un broker de mensajes y colaborando con servicios en Node.js y Python. Integración de plataformas SaaS —GoHighLevel entre ellas— mediante APIs y webhooks firmados definidos con contrato primero, con foco en resiliencia —reintentos con backoff, idempotencia—, observabilidad y seguridad. Desarrollo de un proveedor de mensajería instantánea propio, dado de alta como canal nativo del CRM, que sostiene la sesión, envía y recibe por la API de la plataforma y publica cada mensaje en el broker para que los servicios asíncronos lo procesen. Agentes en producción para ventas y agendamiento.
Procesos ETL y modelado sobre SQL Server y Amazon Redshift, con servicios corriendo en EC2. Librería Python publicada en PyPI para unificar el acceso a los data warehouses de la compañía. Scraping e ingeniería inversa de APIs públicas para integrar datos externos, chatbot de lenguaje natural a SQL, aplicaciones internas con AppSheet y tableros analíticos en Tableau.
Desarrollo de un cliente propio contra la API REST de Moodle para automatizar lo que la plataforma no exponía: altas de cursos y usuarios, matriculaciones y sincronización con los sistemas de la universidad. Frontends a medida en React sobre el campus, y plugins propios en PHP extendiendo el código fuente de Moodle. Acá empecé a trabajar con Google Apps Script y el ecosistema de Google Workspace para automatizar procesos de gestión. Modelado y consultas sobre MariaDB y PostgreSQL, con reportes a medida para las áreas administrativas. Despliegue, configuración y mantenimiento del campus.
SM
mar 2018 — ago 2018
Administrador de sitio web
Secretaría de Modernización de la Nación
CABA, Argentina
Frontend del sitio institucional, administración de servidor LAMP y de la base de datos del sistema de concursos públicos.
