Josemi

mi parte friki ama las tuis, pero es innegable que una gui comunica más y mejor. llevo unos días trabajando en goatty.xyz, un cliente nativo para herdr-core, sin hooks ni dependencias adicionales. ya disponible para mac, por si quieres darle un try!

tenemos nueva versión de convoy.inaki.cc: - harness agnostic (oc, claude code, codex (exp)). - ahora tus agentes usan convoy: headless mode + skills. el valor: - pipelines ad-hoc para trabajos grandes monitorizados por tu harness de diario. - poder solicitar reviews desde la propia sesión a convoy (contexto limpio, modelos contrarios, etc). llevo probando un par de días y de momento muy muy top

No todas las tareas necesitan un custom harness. En este vídeo explico cómo decido qué flujo utilizar según dos variables: - Alcance: ¿qué tan grande es el cambio? - Incertidumbre: ¿qué tan claro tengo lo que quiero construir? Todo empieza en un worktree como unidad de trabajo. A partir de ahí: - Cambio pequeño → agente directo (opencode). - Decisión de producto → spec. - Spec acotada → apply en la misma sesión. - Tarea grande + incertidumbre → Pipeline Implement + iteración (opencode). - Tarea grande + objetivo claro → Pipeline Full Cycle. - Resultado terminado → Pipeline Ship para auditar, corregir y preparar la PR. La idea detrás de Convoy no es usar más agentes. Es aplicar el nivel de estructura y automatización que necesita cada tarea haciendo frente a la limitación de contexto y alcance que tienes las sesiones individuales.

Asúmelo: has perdido el control del código. Intentar recuperarlo es la batalla equivocada. Creo que los programadores tenemos que empezar a aceptar que nuestro trabajo ya no es escribir código. El rol tiene que evolucionar. Y hacerlo de manera que sigamos siendo relevantes. Que sigamos aportando valor. No se trata de cuánto código leemos o escribimos nosotros mismos. En las últimas semanas me he propuesto construir un flujo de trabajo alrededor de esta idea. El agente ya escribe código más rápido y mejor. Pero "mejor" es relativo. Tenemos que volverlo absoluto. La idea fundamental es fácil de entender, pero difícil de ejecutar: construir un sistema en el que pueda delegar prácticamente todo el ciclo de desarrollo y seguir teniendo garantías sobre el resultado. Especificación → implementación → revisión adversaria → tests → seguridad → mantenibilidad → scoring → QA. Mi trabajo es definir las invariantes correctas contra las que ejecutar todo esto de forma desatendida. Con Convoy, una feature puede estar 1-2 horas recorriendo el pipeline completo sin que yo toque nada. Cuando termina, solo me queda hacer QA de usuario final, no discutir si en la línea 18 debería usar un bucle while o for. Todavía no confío al 100% en esto para producción, y probablemente tampoco sea el flujo definitivo. Pero si algo tengo claro es que cada semana necesito bajar menos al código. Y creo que hacia ahí va nuestro trabajo. Menos control sobre cada línea de código y más control sobre el sistema que lo produce: - Sandboxing + guardrails - Spec driven design. - Scoring. - Automation. En el vídeo explico cómo estoy intentando llegar hasta ahí y qué estoy aprendiendo por el camino.

seguimos exprimiendo kimi k3 para tareas de diseño, nuevo landing para convoy.inaki.cc

1/ Llevo unos días probando un patrón de agentes que me parece bastante más interesante que el típico: modelo caro planifica + modelo barato implementa. Mucha gente lo está entendiendo mal. 2/ La idea no es que el modelo SOTA haga un plan al principio y desaparezca. Eso, al menos en mis pruebas, consume prácticamente lo mismo y muchas veces no mejora los resultados (mira mis posts de hace unos meses). 3/ El trabajo difícil no suele estar en el plan general. Está en los detalles que aparecen durante la implementación. Ahí es donde un modelo realmente bueno aporta valor. 4/ En lugar de tener un pipeline lineal: - SOTA → Plan - Cheap → Implementa - SOTA → Revisa La clave está en que el modelo caro pase a ser un advisor integrado dentro del loop del agente ejecutor. 5/ El ejecutor sigue siendo el modelo barato. Hace prácticamente todo el trabajo. Pero puede pedir ayuda al advisor cuando realmente la necesita. 6/ Lo hace en checkpoints durante el ciclo agéntico: - Antes de empezar a modificar código, para validar el enfoque. - Cuando entra en un bucle intentando resolver el mismo problema. - Cuando detecta una decisión compleja donde merece la pena gastar más tokens. - Al terminar cada step del pipeline. 7/ La clave es que el modelo caro no gestiona el contexto completo de la implementación. Solo ventanas pequeñas y acotadas. Además se limita la longitud de la respuesta (ahorro de output tokens), solución concreta y concisa. Eso reduce muchísimo el coste manteniendo gran parte de la calidad. 8/ Es parecido a tener un ingeniero senior que no programa toda la feature. Solo aparece cuando alguien se atasca o cuando hay una decisión importante que tomar. 9/ Acabo de implementarlo en Convoy. Todavía estoy validándolo en proyectos reales, así que no puedo decir todavía si el impacto es tan grande como parece. Pero las primeras pruebas son bastante prometedoras. 10/ Si termina funcionando como espero, creo que este tipo de arquitectura tiene bastante más recorrido que seguir aumentando el tamaño del modelo para absolutamente todas las llamadas. No siempre hace falta un SOTA. Lo importante es saber exactamente cuándo utilizarlo. Si te animas a probarlo, recuerda que es open-source, lo tienes en mi github :)

epa, +75 stars en github. para la mayoría será poco, pero es lo más lejos que he llegado en open source jaja. btw, rebrand completado: archer es ahora convoy! seguimos testeando Kimi K3. No es la web más fina. Pero para ser one-shot y buscando algo meramente funcional, es top.

una de las formas más sencillas de tener tu segundo cerebro de ia: local, seguro e ilimitado. @_archeproject + @ollama soporta: - base de conocimiento local. - flows (automatizaciones recurrentes) - connectors (mcps e integraciones)