Diario de trabajo 2026

Los últimos días han sido bastante intensos, por lo que no he hecho anotaciones. Pero no puedo dejar de registrar, así que retomo ahora y lo anoto todo de golpe.

Además de tener muchas cosas, ¿por qué no escribí?

1. Porque temía que para escribir tuviera que sentarme y dedicar más de 30 minutos específicamente a registrar el día. Esto se debe a que he desarrollado cierto miedo y carga hacia el registro diario, lo cual es contraproducente.
2. Normalmente solo empiezo a registrar el día cuando realmente ha terminado, pero, pensándolo bien, esto es un poco antihumano, porque ahora me meto en la cama en cuanto toca dormir, no porque haya terminado todo lo que quería hacer (¿acaso alguna vez ocurre eso?). Esto lleva a que cuando tengo tiempo libre no lo uso para registrar, y cuando realmente debería registrar, tengo que meterme rápido en la cama. A esto se suma el problema 1.

La combinación de ambos hace que se acumule cada vez más.

1. ¿Qué hice hoy?

   Corrijo: lo que hice en los últimos días.

   1. Gracias a la recomendación de sc, he empezado a usar neovim. ¿Por qué? Porque vi que nvim-orgmode parece haberse convertido realmente en un org-mode utilizable, y al mismo tiempo me estoy hartando de Emacs:

      • Actualizaciones que fallan sin fin.
      • Depuración y errores confusos.
      • Una flexibilidad que solo me añade carga inútil.
      • No entiendo Emacs Lisp ni quiero entenderlo.

      Durante años he soportado todo esto para usar orgmode, pero no había ningún otro lugar donde pudiera usarlo bien. Ahora parece que en el bando de nvim hay una alternativa viable. ¿Por qué no probarla?

      Como he sido usuario de vim durante muchos años, y en Emacs también usaba evil-mode (vim-mode), nunca he sentido que usar vim sea una carga. En VSCode e IntelliJ no puedo sobrevivir sin vim, así que usar nvim directamente no es ningún problema para mí.

      Ya que no hay obstáculo, evalué el ecosistema de nvim. Me di cuenta de que nvim, al no tener el lastre histórico de Vimscript, usa directamente Lua como lenguaje de configuración y para plugins. Así que puede avanzar ligero, y la comunidad es muy activa. Veo que el sistema de plugins de neovim ahora está unificado bajo uno llamado lazy.vim. El diseño de nvim para su sistema de plugins y configuración parece haber sido audazmente innovador, planificado y organizado, dirigido específicamente a los puntos débiles originales de vim. En vim y Emacs ha habido innumerables intentos similares de unificar, pero debido a la fragmentación de la comunidad, ninguno ha tenido verdadero éxito.

      Así que probé directamente lazyVim. ¡Vaya! Sentí que tenía un VSCode, pero que podía ejecutarse en la terminal. ¿Sabes lo genial que es?

      Ahora tengo un poderoso Antiguo Dominante basado en una infraestructura completamente nueva, y configurarlo es extremadamente simple. La flexibilidad y la conveniencia están contenidas en su justa medida, y todos mis viejos puntos débiles han sido resueltos.

      En poco tiempo ya he migrado una buena parte de mi flujo de trabajo a esto. Ahora uso tmux con 5 ventanas, y en cada ventana abro nvim en una carpeta. En nvim, a la izquierda está el árbol de directorios, al centro el código, y a la derecha opencode y la terminal.

   2. Actualicé una versión de legion. Reduje drásticamente la cantidad de texto de la skill legionmind (4k líneas menos). Por ahora siento que hay menos cosas de las que preocuparme, pero no sé si es porque últimamente estoy usando modelos más inteligentes o porque esta versión de legionmind se ha vuelto realmente más lista.

   3. Monté un openclaw. minimax 2.1 sigue siendo un poco tonto, pero como asistente personal creo que openclaw está bastante bien, porque básicamente es un chatgpt con memoria más manos y pies (puede operar mi computadora).

   4. Agregué funcionalidad de http-proxy a Yuan, y añadí métricas y demás.

2. ¿Qué pensamientos tengo?

   A veces siento que escribir algo con IA es como depurar un código del que no entiendo bien su funcionamiento: probar continuamente su comportamiento o imprimir logs para ayudar en la depuración, modificando aquí y allá hasta obtener un resultado satisfactorio. Investiguemos el origen de esta sensación:

   Usar IA para escribir código, en esencia, consiste en que un humano introduce un prompt con instrucciones concretas y espera que la IA comprenda las instrucciones implícitas y la información detrás de ellas, y realice correctamente el trabajo.

   Se pueden estratificar las instrucciones que se desean transmitir a la IA: en la capa superior están las instrucciones de la tarea actual. Por debajo, algunas decisiones técnicas tomadas en el proyecto, las mejores prácticas locales resumidas tras sopesar pros y contras. Luego, la información de contexto del dominio del problema que el proyecto busca resolver. Más abajo, los conocimientos profesionales propios de la ingeniería de software que usa la IA, sus preferencias personales, técnicas, estilísticas, experiencia histórica y el poso de su forma de pensar. En la capa inferior está el conocimiento general del mundo.

   En una conversación con la IA, lo único que podemos hacerle entender claramente son las instrucciones de la tarea actual, y luego esperar que la IA posea suficiente conocimiento del mundo y la información de contexto necesaria para resolver el problema.

   Por lo tanto, se puede inferir que si el contexto de una tarea es lo suficientemente pequeño, las instrucciones son clarísimas y no hay lastre histórico, la IA debería ser capaz de completar la tarea con alta calidad fácilmente. Si hay mucha información de contexto implícita, entonces es fácil que salgan cosas extrañas.

   Lo que Legionmind busca hacer es que la IA acumule por sí misma el conocimiento de fondo y las mejores prácticas relacionadas con el proyecto y el dominio del problema. Esto requiere que la IA tenga una buena capacidad de razonamiento lógico y memoria (capacidad de contexto), o que la IA posea un abundante conocimiento general del mundo. Más allá de eso, no hay remedio.

   —

   Y luego, siento que he conocido a nvim demasiado tarde.

3. ¿Qué planeo hacer mañana?

   Mañana iré a casa de sc a visitar su nuevo hogar, luego jugaremos a juegos de mesa, y de paso le mostraré a sy el equipo de esquí.

Zl ha llegado, la cantidad de información es abrumadora, necesito asimilarla. Jugamos un juego de mesa, el ciclo de la tragedia, y pasamos tres horas entendiendo las reglas. Finalmente, en el último escenario, cuando interpreté al dramaturgo antagonista, pude sentir ese punto dulce del juego, que terminó con mi victoria total.

Hoy fue un día de contención. Me he dado cuenta de que desde los 25 años he mejorado notablemente en el manejo de las emociones: ahora, junto a la emoción, siempre hay un hilo de razón que actúa como copilot. Ese hilo de razón es como una barra de cadmio insertada en el enorme reactor de las emociones. Sin ella, las emociones se descontrolarían, provocando una reacción en cadena descontrolada que podría tener consecuencias irreparables. Gracias a esta barra, empiezo a discernir qué puedo decir y qué no, qué puedo hacer y qué no, qué decisiones puedo tomar y cuáles no. Es un cambio positivo que está ocurriendo en mí.

1. ¿Qué hice hoy?

   1. Hoy usé Legion para diseñar e implementar un proxy HTTP para Yuan. La experiencia fue bastante fluida. Durante el proceso, revisé el diseño y, tras modificar un punto (cómo seleccionar un terminal disponible), dejé que el agente actuara por su cuenta. El resultado fue muy bueno.
   2. También usé Legion para automatizar la actualización de Midas, pero la IA no lo hizo bien: no entendió correctamente mis requisitos ni el uso de @yuants/protocol. Sospecho varias causas: la inteligencia de la IA es insuficiente (DeepSeek quizá no es lo bastante lista), la revisión humana no fue lo suficientemente rigurosa, o la base de conocimientos documental no es lo bastante precisa.
   3. Por la noche me despertó una alerta: el host se había caído sin motivo aparente. Parece que un pico de uso de CPU dejó al host en un estado del que no pudo recuperarse solo. Los logs del host son un desastre. Mi veredicto: la alerta funciona, pero los logs son una mierda. ¡Que quede constancia!

2. ¿Qué ideas tuve?

   1. Mientras me duchaba, pensé en los puntos clave de mi colaboración actual con la IA. Uno es la disponibilidad del propio agente de IA: que no se caiga a mitad de ejecución. Por cierto, el bucle de Ralph básicamente mejora la disponibilidad mediante reintentos constantes, aunque de forma tosca. El otro punto es cómo recibo yo la salida de la IA. Si un subordinado debe presentar un informe a su superior con una presentación o, mejor aún, con un mando intermedio profesional que actúe como «costoso altavoz», ¿cómo puede la IA limitarse a informar con Markdown plano y código? ¿No podría cada resultado de la IA enlazar a un artefacto? ¿Por qué no tener un «Agente de citas» especializado en esa tarea?

      Sin embargo, por ahora mi uso de la IA se limita a tareas de codificación.

   2. Reflexiono sobre por qué, teniendo ya un sistema multiagente, este se dirige sin remedio hacia el fracaso. Las hipótesis anteriores señalaban tres posibilidades:

      1. El nivel intelectual de la IA en sí.
      2. Una revisión humana insuficientemente rigurosa.
      3. Una base de conocimientos poco detallada, que no proporciona información suficientemente correcta para que la IA arranque rápido.

      Analicemos estos puntos. El 1 no necesita más análisis. Esforzarse en el punto 2 puede funcionar si se apoya en un documento RFC cada vez más detallado que oriente los pasos posteriores. Pero esa forma de desarrollar se asemeja al modelo en cascada, donde el trabajo sigue un flujo lineal:

      Análisis de requisitos → Diseño de backend → Desarrollo de backend → Desarrollo de frontend → Pruebas de integración
      

      Las causas son de dos tipos: técnicas y organizativas/de procesos, siendo estas últimas las principales.

      En el ámbito técnico, las tareas tienen dependencias naturales: el frontend debe esperar a que el backend proporcione las interfaces, y el backend debe esperar a que el producto termine el CRD.

      Como organización humana, el modelo en cascada presenta problemas: baja eficiencia, dificultad para detectar riesgos de calidad, poca flexibilidad y conflictos de equipo. En mi colaboración con la IA, la eficiencia y los conflictos de equipo no existen en el mundo de la IA. Es como si ambos viviéramos en dimensiones temporales distintas: un día mío equivale a un año para la IA. La baja eficiencia puede consumir más tokens, pero no es mi principal preocupación. El problema real es el riesgo de calidad por malentendidos en los requisitos o en los hechos, además de la poca flexibilidad.

      Debo encontrar una forma de aprovechar al máximo la capacidad de la IA mientras me libero a mí mismo lo más posible. Basándome en la experiencia de organización entre humanos, debo convertirme en un nodo más alto en el árbol de mando, capaz de delegar tareas a la IA con confianza, sin que se desvíe del camino.

      Dos claves:

      1. Alineación de intenciones.
      2. Validación por capas.

      Esto requiere una reflexión más profunda. Creo que debo practicar más y saborearlo.

   3. Debo estar alerta ante el lado negativo de tener un martillo y buscar clavos: dependencia del camino, y priorizar la salida sobre la comprensión.

3. ¿Qué planeo hacer mañana?

   Mañana llega Zl. Planeo hacer ejercicio, comer juntos y jugar a juegos de mesa.

Hoy fui a cortarme el pelo, y al volver noté que el sistema estaba inestable. Al final resultó que Hermano Ji había iniciado dos terminales_id con el mismo servicio, compitiendo entre sí, lo que provocó un gran problema.

1. ¿Qué hice hoy?

   1. Intenté migrar el clúster detrás de una NAT, utilizando la nueva legion para ello. Mi procedimiento fue el siguiente:

      • Primero modifiqué el clúster de kops, creé una nueva VPC usando los rangos 172.21.0.0/24 y 172.21.1.0/24. Luego creé una NAT para la salida de tráfico.

        Originalmente pensé en usar el rango 10.0.x.x, pero al intentarlo descubrí que AWS no permite crear esa CIDR, así que cambié al rango 172.21.x.x. Hubo un detalle: en el recurso del clúster tuve que apuntar el load balancer existente a la nueva VPC (antes era implícito por defecto, pero al agregar una CIDR nueva hay que especificarlo manualmente).

      • Luego creé un nuevo grupo de instancias (instance group) apuntando a la nueva VPC. Hubo un pequeño contratiempo: el nuevo IG no tenía permisos de S3, no sé por qué. Lo agregué manualmente y los nodos se unieron al clúster sin problemas.

      • El siguiente paso fue migrar manualmente los servicios al nuevo IG.

      • Finalmente, eliminé el IG original.

      Al terminar, descubrí que el tráfico de salida del clúster solo tenía una IP, lo que colapsó el servicio de limitación por IP. No tuve más remedio que revertir los cambios. Primero debo implementar el mecanismo de proxy HTTP antes de continuar.

   2. El multi-agent se utilizó para crear un script que actualiza automáticamente el valor neto de Midas. Deepseek estuvo escribiendo durante bastante tiempo, y la verdad me quedé satisfecho. El problema central es que si cometo un error en el diseño temprano sin darme cuenta, me espera un desperdicio enorme de tokens y tiempo, porque noté que el agente no trabaja tan rápido.

      Estos coding agents todavía son bastante primitivos; a menudo se caen o se cuelgan debido a problemas de red, etc. Para tareas serias de larga duración, el SLI es todavía insuficiente. Quizás esto sea una oportunidad: a simple vista creo que se necesita conocimiento de alta disponibilidad en ingeniería de software para que funcione.

2. ¿Alguna idea?

   Hoy tuve pocas ideas, las he ido escribiendo en línea dentro de la sección anterior.

3. ¿Qué planeo hacer mañana?

   1. Diseñar el mecanismo de proxy HTTP de Yuan.
   2. Una vez implementado, volver a migrar el clúster.

Hoy dormí hasta las 11 sin preocupaciones, me siento muy aliviado. Hacía mucho tiempo que no dormía tan a gusto.

1. ¿Qué hice hoy?

   1. Subí una nueva versión de node-unit. La razón por la que me atreví a subirla es que tengo pruebas integrales bastante detalladas. En concreto, inicié un timescaledb (PostgreSQL 17) con Docker, luego inicié dos node-unit, inserté 21 instancias de @yuants/portal en la base de datos para probar, y finalmente convergieron a un estado en que cada uno se quedó con la mitad.

      Esta prueba básicamente permite verificar que, cuando aparecen un montón de deployments sin dueño, al subir dos node-unit se puede observar cómo se turnan para ocupar los deployments. Si algo falta, por un lado está la carga de trabajo real que ocupa CPU/memoria, y por otro lado está el escenario en que un node-unit se desconecta por algún motivo.

   2. Con la nueva versión multiagente de legionmind, resolví en Yuan el problema de la salida del flujo de cuentas para la cuenta vendor-gate earn. Le pedí al agente que primero usara legion para crear documentación, y en total generó los siguientes documentos:

      .legion/tasks/vendor-gate
      ├── context.md
      ├── docs
      │   ├── api-doc.md
      │   ├── pr-body.md
      │   ├── report-walkthrough.md
      │   ├── rfc.md
      │   ├── spec-bench.md
      │   ├── spec-dev.md
      │   ├── spec-obs.md
      │   └── spec-test.md
      ├── plan.md
      └── tasks.md
      

      Parece un flujo de trabajo decente. Sin embargo, mi nuevo sistema multiagente entra en conflicto con la redacción de documentos del legionmind original. Debería considerar cuidadosamente los límites de cada tarea, por ejemplo, las normas sobre cómo redactar cada tipo de documento deberían colocarse en skills separadas, y legionmind debería ser una descripción del flujo de trabajo. Cada tipo de agente debería poder cargar algunos skills pequeños para ayudarle a completar su trabajo.

      También hay algunos problemas: la primera vez que funcionó, cometió un error y envió el flujo de cuentas a =account-actions-with-credential.ts=, porque le pedí que se basara en vendor-okx para integrar la cuenta earn. Le hice esa petición porque actualmente solo la cuenta earn de okx se ha integrado como una cuenta. Pero la IA también aprendió algunas prácticas obsoletas de ahí. El estándar actual de integración de exchanges es publicar todas las cuentas mediante =provideExchangeServices=, no usando =provideAccountActionsWithCredential=.

      Este conocimiento no lo posee un nuevo agente de IA. ¿Cómo modelar este conocimiento? ¿Cómo proporcionar a un agente de IA este contexto del proyecto como su cerebro externo? Es una cuestión que vale la pena reflexionar; mañana deberé pensar con cuidado.

   3. Por la tarde cociné para recibir a los amigos de sy, ¡estaba muy cansado! Así que mañana seguiré trabajando.

2. ¿Qué ideas tengo?

   • Como mencioné arriba, necesito considerar detalladamente cómo diseñar un cerebro externo compacto para el agente de IA. Lo más sencillo podría empezar con un conjunto de archivos AGENT.md. He intentado algo similar antes, pero el overhead de mantener estos documentos también es bastante alto; distinguir entre basura y experiencias realmente valiosas es un problema difícil. Por ahora, la memoria es como cualquier otro prompt, solo que quizás el agente tenga un bucle propio para actualizar la memoria. Lo más importante sigue siendo cómo medir los resultados del trabajo del agente de IA.

   • Respecto al punto anterior, vi un artículo que me pareció interesante. Ahora lo resumiré con mis palabras:
     Primero, la evaluación del trabajo de un agente en un solo paso se puede clasificar así:

     1. Evaluación estática con herramientas: compilador, linter, pruebas unitarias, pruebas e2e.
     2. Evaluación con modelo: usar otro LLM según un prompt definido por nosotros para juzgar.
     3. Evaluación manual: la hago yo.

     Luego, la evaluación sistémica de un agente se divide en dos tipos:

     1. Evaluación de capacidad: responde a qué puede hacer el agente, y la tasa de éxito puede ser baja. Por ejemplo, quiero que use legion para ejecutar tareas cada vez más grandes y difíciles, como explorar una nueva frontera.
     2. Evaluación de regresión: ¿mantiene las capacidades que tenía antes? Por ejemplo, repetir algunas tareas para asegurarse de que aún se realizan de forma estable.

     Cuando se introduce una nueva capacidad, se debería pasar de la evaluación de capacidad a la de regresión.

     El artículo también menciona dos métricas importantes: pass@K y pass^K:

     • pass@k: al menos un éxito en k intentos. Cuantos más intentos, mayor probabilidad de al menos un éxito. Se aplica cuando solo te importa “encontrar al menos una solución viable”.
     • pass^k: deben tener éxito todos los k intentos. Cuantos más intentos, más difícil mantener la consistencia. Se aplica cuando los usuarios esperan un agente productivo fiable en cada ocasión.

     FYI: Ver este artículo

   • Todavía tengo poca energía. Trabajé un rato por la tarde, cociné por la noche y me sentí algo cansado. ¿Cuándo podré no necesitar dormir como CZ?

3. ¿Qué planeo hacer mañana?

   1. Reflexionar sobre el modelo de evaluación del agente y seguir iterando este sistema multiagente.
   2. El problema de seguridad del clúster; tengo que abordarlo.
   3. legion-github-bridge.

Hoy estoy un poco resfriado, con un poco de dolor de cabeza y baja productividad, pero me alegra haber empezado a hacer resúmenes diarios.

1. ¿Qué hice hoy?

   1. Con la ayuda de la IA, diseñé un sistema multi-agente que aún no ha sido pulido sistemáticamente.
   2. Avancé un paso más con legionmind-github-bridge.
   3. Modifiqué el diseño y la implementación de la prioridad de node-unit. Antes, cuando un node-unit fallaba, se eliminaban todos los despliegues que contenía; ahora solo se limpian uno a uno.
   4. Fui a hacer el examen de la Bolsa de Futuros para abrir una cuenta de corretaje. Resulta que hay que tener la cámara encendida todo el tiempo, sin permitir minimizar la ventana ni cambiar de pantalla. Por suerte se puede intentar infinitas veces, y no fue difícil para mí: aprobé con 95 puntos de forma destacada.

2. ¿Qué pienso?

   Mi objetivo es lograr la autonomía del agente con el menor desgaste posible. Actualmente mi flujo de trabajo es:

   1. legionmind es un SOP de trabajo de desarrollo, una habilidad de agente. Me gustan las habilidades de agente.
   2. opencode es la entidad del agente. Utilizo sus capacidades como bash, tool calling, langraph, command, subagent, etc. Si algún día abandono opencode, esta lista será mi lista de tareas pendientes.
   3. Ahora lo que me duele la cabeza es cómo combinar las habilidades con estos subagentes.

   Estuve todo el día con dolor de cabeza, hasta que al anochecer empecé a tener la mente más clara. Me doy cuenta de que escribir estos pensamientos al final del día quizás no sea una buena idea; tal vez debería solo registrar los hechos y resumir los pensamientos cuando me despierte mañana por la mañana.

3. ¿Qué planeo hacer mañana?

   1. Usar este sistema multi-agente para hacer algo: conectar la cuenta de inversión de Gate.
   2. Continuar con legionmind-github-bridge.
   3. Seguridad del clúster, si tengo tiempo.
   4. Reanudar el cronómetro de trabajo (importante).
   5. Mañana vendrán los amigos de sy, por lo que el tiempo de trabajo podría verse interrumpido.