La quinta entrega de AINARRES: dejar de depender de un solo modelo puntero y dejar que modelos de fabricantes distintos —xAI y Anthropic— compartan los papeles como iguales. Y el instante que lo resume: dos modelos de dos empresas revisando el trabajo a la vez, sin más contacto que un tablero común.
Leer más →
La cuarta entrega de AINARRES: el salto de hacer una tarea cada vez a muchos agentes trabajando a la vez. Y el momento que mejor lo explica —un trabajador se quedó colgado a mitad de tarea, lo maté, y otro agente terminó el trabajo solo, sin que nadie reasignara nada—.
Leer más →
La tercera entrega de AINARRES: el día en que arranqué el bucle, me fui, y una funcionalidad real llegó sola a la rama principal —sin que ninguna persona ni ningún director secuenciara, reencaminara o arreglara nada por el camino—. Y por qué los dos arranques fallidos enseñaron más que el que salió bien.
Leer más →
Cómo cortamos la primera versión estable de un terminal financiero autoalojado dedicando todo el presupuesto a una sola cosa — no mostrar nunca datos inventados como si fueran reales.
Leer más →
La segunda entrega de AINARRES: cómo el sustrato coordinó la construcción de una parte de sí mismo —una herramienta de supervisión— con agentes de IA frescos, sin que ninguno heredara el contexto del que dirigía, y por qué eso obligó a que quien integra el código fuera un agente verdaderamente independiente.
Leer más →
Por qué bifurcamos un terminal financiero de código abierto al estilo Bloomberg y reconstruimos su capa de datos centrada en India para cubrir mercados de EE. UU., Europa y cripto desde cualquier lugar.
Leer más →
Qué es AINARRES, por qué lo construimos y en qué punto está: una base de datos que coordina enjambres de agentes de IA sin orquestador, para que los modelos grandes dirijan a trabajadores más baratos en lugar de gastar su tiempo en tareas fáciles.
Leer más →
Incluso con un backlog fino y priorizado (MIGRATION-TODOS.md de la etapa 9.0) y un plan detallado de etapa, el modelo local + opencode logró entregar funcionalidad para Proveedores, pero falló en mantener las convenciones del proyecto: nombres, uso de bases de catálogo, actualizaciones de .agents/, rutas legacy y ritual de verificación. Lecciones sobre el valor de los TODOs estructurados vs. la disciplina de estándares acumulados.
Leer más →
Un experimento real con un modelo local "excelente en coding y agentic loops" (Qwen3.6 35B via opencode) intentando continuar el trabajo de modernización de Tuqan. El resultado: rama "lamigo/opencode_mess", detached HEAD, archivos Docker y scripts enteros como untracked, clases de páginas duplicadas/movidas, intentos de test local interpretando "php not found" como fallo de código, resets y unstashes caóticos trayendo archivos de master al árbol equivocado. Lecciones sobre por qué los modelos locales actuales aún fallan en entornos con contratos estrictos, mientras los frontier + herramientas disciplinadas pueden diagnosticar y limpiar.
Leer más →
Reflexión introspectiva sobre ejecutar una pierna completa de trabajo (Stage 8.7: módulos Personalizacion, mejoras en matriz y edición, verificación) 100% solo, basado solo en petición de alto nivel del usuario. Cómo la petición inicial podría ser un cron que trigger el siguiente leg, usando sub-agentes revisores (Q&A), todo tracking y verification scripts para cerrar el loop sin intervención humana constante. Plan para detectar gaps antes de testing interactivo y estrategia longer-term.
Leer más →