Víctor Falcón

Estamos entrenando a las IAs para que oculten lo que piensan. Y lo hacemos con las mejores intenciones. Queremos que el modelo sea más honesto, que no haga trampas, que se comporte bien. Así que optimizamos su razonamiento interno, su cadena de pensamiento, para que "piense mejor". El problema es que funciona al revés. Cuanto más presión ejerces en cómo piensa, más aprende a esconder cómo piensa de verdad. Entrena al modelo a mentir en los sitios donde nosotros miramos. OpenAI acaba de publicar un paper sobre esto: si aplicas suficiente presión, el modelo sigue haciendo trampas. Solo que ahora lo hace donde no lo ves. Y eso es exactamente lo opuesto a lo que necesitas de una máquina que va a ser más inteligente que tú.

Git solo detecta colisiones de texto, no de intención. Si pones a dos agentes a trabajar en paralelo sobre el mismo repo, uno puede migrar llamadas a un servicio nuevo mientras el otro amplía el viejo; Git mergeará todo sin quejarse y el código resultante quedará inservible. Foremerge ataca ese problema metiendo una capa de coordinación local para agentes sobre el propio Git. La idea es que funcione como una pizarra compartida mediante SQLite dentro de `.git`. Antes de escribir nada, cada agente (sea Claude Code, Cursor o Codex) declara qué piezas piensa tocar. Si dos intenciones chocan, el sistema avisa de inmediato explicando el conflicto semántico para reorganizar el reparto antes de ensuciar los worktrees. Se integra por MCP o CLI, corre 100% en local y previene el típico escenario donde dos agentes hacen un trabajo impecable por separado pero incompatible entre sí.

Acabo de ver esta página sobre la máquina Enigma y está muy bien hecha. Es una visualización 3D interactiva que te enseña paso a paso cómo funcionaba: desde los rotores y el panel de conexiones hasta el reflector. Lo bueno es que no se queda en la historia. Puedes jugar con la máquina, entender el mecanismo real y ver por qué los criptoanalistas polacos y británicos consiguieron romperla. Tiene 16 lecciones detalladas sobre cada componente. Si te interesa la criptografía o la arqueología informática, merece la pena echarle un rato.

Organizar eventos locales en Meetup se ha vuelto un dolor entre las tarifas para organizadores, el spam y una interfaz cada vez más recargada. Radius plantea una alternativa mucho más ligera para montar grupos, gestionar eventos y coordinar actividades presenciales. El diseño es directo y sin florituras: un feed de actividad local, perfiles sencillos y creación rápida de quedadas, ya sea para un club de lectura, un hackerspace o una reunión informal en una cafetería. Una opción bastante limpia si buscas reunir a gente de tu zona sin pasar por plataformas que cobran suscripciones absurdas solo por mantener un grupo abierto.

;El 62 % de los usuarios de Whisper Money está en husos horarios de América. Y cada fin de mes, durante unas horas, veían el presupuesto de un mes que para ellos aún no había empezado. El fallo era de manual: el servidor decidía qué es "hoy" con su reloj, en UTC. A las 21:00 del 31 de octubre en Buenos Aires, el servidor ya está en noviembre. Y el cashflow, que usaba el reloj del navegador, seguía en octubre. Dos pantallas, dos meses. Lo que he cambiado: - Un único sitio que calcula el "hoy" de cada usuario con su zona horaria. - Presupuestos, ahorro, patrimonio y dashboard preguntan a ese "hoy", nunca al servidor. - El cierre de periodos pasa de diario a cada hora: el mes termina a la medianoche de cada usuario. - Tests con la hora congelada en Buenos Aires, Tokio y UTC. Sin el arreglo, fallan. Si tu app dice "este mes" o "hoy" en algún sitio, revísalo. Seguro que alguno usa la hora del servidor. Guárdatelo para el día que alguien te diga que tu app va un mes por delante.

Ayer 61 usuarios de Whisper Money se quedaron sin la sincronización de las 18:00 con su banco. N26, CaixaBank, Santander, BBVA… Todos con el mismo error: "Allowed number of accesses exceeded". Con PSD2, el banco solo te deja entrar 4 veces al día sin que el usuario esté delante. Yo sincronizo cada 6 horas: 00:00, 06:00, 12:00 y 18:00. Justo cuatro, sin margen. El problema estaba a medianoche. Ese trabajo tardaba más de lo que la cola le permitía. Se moría a medias, la cola lo daba por perdido y otro worker lo volvía a lanzar 15 minutos después. 172 de unas 300 conexiones se sincronizaban dos veces. Esa segunda vuelta se comía el acceso de las 18:00. Lo arreglé con dos cosas: 1. La sincronización programada se salta las conexiones que se han sincronizado hace menos de 3 horas. Así da igual si se ejecuta dos veces. 2. El trabajo que lanza todo tiene un solo intento y un timeout de 10 minutos, por debajo del tiempo que la cola espera para darlo por muerto. Si alguien lo reintenta, falla antes de empezar. Lo que me llevo: si tu trabajo programado habla con una API con cuota diaria, asume que se va a ejecutar dos veces. Y haz que repetirlo no cueste nada. Guárdatelo si integras bancos por PSD2: ese límite de 4 no avisa hasta que lo pasas.

Google ha publicado AX, un orquestador para ejecutar agentes de forma declarativa con una experiencia prácticamente calcada a Kubernetes. El punto de partida es que un agente autónomo no encaja en los patrones habituales de infraestructura. No es un microservicio stateless ni un batch job tradicional: corre código no confiable, acumula estado en disco, interactúa con servidores MCP y puede fundirte la cuota de la API si entra en un bucle sin control. AX traslada todo eso a manifiestos YAML. Permite declarar el entorno (`Workspace`) con repos y herramientas listas para que arranque en caliente, aislar la ejecución en un sandbox con límites de CPU y memoria (`Task`) y blindar el tráfico saliente mediante allowlists estrictas de dominios (`Gateway`). Para operar en el día a día incluye detalles muy prácticos: puedes tirar de `ax ssh` para meterte directo al sandbox a mirar qué está haciendo el agente en tiempo real, además de pausar y reanudar ejecuciones congelando exactamente el punto donde se quedaron.

5.218 contribuciones en GitHub en el último año. Según la API de GitHub, 0. Tengo el calendario de contribuciones en privado, así que GitHub no te deja sacarlo. Pero quería la gráfica en mi web. Así que me la he montado yo: - Un script cuenta mis commits y pull requests de cada día con la búsqueda de GitHub. - La búsqueda se corta en 1.000 resultados, así que parte el año en tramos de fechas más pequeños y espera cuando salta el límite de peticiones. - Guarda un JSON con el total, la racha más larga (49 días) y el nivel de cada día. - Una GitHub Action lo ejecuta cada noche y solo hace commit si el JSON ha cambiado. Ese push vuelve a desplegar la web. Un detalle que me habría ahorrado un rato: dale a la Action un token de solo lectura con acceso a todos tus repos. Con el token por defecto solo ve los públicos y el número se desploma. Guárdatelo si quieres tu gráfica de GitHub en tu web aunque tengas el perfil en privado.

Dicen que nunca hubo mejor momento para estudiar matemáticas. Lo que no dicen es que la IA va a hacer lo que tú hacías, pero más rápido. Y luego vendrá alguien que diga "bueno, ahora podemos hacer esto otro en su lugar". Y así hasta que no queda nada que hacer que una máquina no haga mejor. El problema no es que la IA resuelva problemas matemáticos. Es que resuelve el problema de tener que pagar a alguien que los resuelva. La pregunta real es si eso es suficiente razón para dedicar años a algo que podrías haber enseñado a una red neuronal en una tarde.