🎉 Oficialmente ya puedo presentar @eventos_wiki La idea es crear, entre toda la comunidad, un único lugar con todos los eventos sobre tecnología. ¿Falta algún evento? Puedes solicitarlo con una issue en el repo de GitHub. ¡PRs son bienvenidas! eventos.wiki/

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.

Para los que se estén preguntando en qué se diferencia Jev y para qué puede ser útil: Jev no es otro LLM, sino un modelo que toma decisiones tipadas y acotadas (Choice / Score / Noul) y devuelve probabilidad + confianza, con el flujo de control en tu código y a coste muy bajo. Los casos de utilidad deben cumplir tres cosas: 1/ Hay ground truth: decisiones ya tomadas por humanos (tickets ya clasificados, informes revisados) o criterios escritos (guías editoriales), para poder medir acuerdo y calibrar umbrales. No es requisito, pero es lo que da calidad. 2/ Es acotado y repetitivo, de alto volumen: colas y cuellos de botella, no cualquier caso. 3/ El error tiene consecuencia: la confianza te permite enrutar a un humano en vez de fallar en silencio. Les dejo algunos ejemplos en los que haremos pruebas en las próximas semanas/meses. En @calisteniapp : 1/ Búsqueda por intención (vibe search). Traducir lo que escribe el usuario en lenguaje normal, como "rutina de 15 min de espalda sin material", a filtros concretos (duración, zona, material, nivel) con su confianza, para complementar la búsqueda semántica. 2/ Moderación del feed. Ahora que tenemos una parte de comunidad, esto se vuelve imprescindible. 3/ Análisis inteligente del progreso. Ya estamos haciendo pruebas internas con LLMs para leer historial y feedback y afinar cuándo avanzar, repetir o consolidar. Todavía no está en el producto, pero ampliaremos las pruebas a modelos como Jev. 4/ Análisis de riesgo combinado: abandono, constancia, lesión. Señales que nos ayuden a acompañar a quien está a punto de dejarlo o de hacerse daño. Algunos ejemplos para @_archeproject : 1/ Guardrails sobre la salida del agente: verificar que los borradores/artículos respetan voz y tono, glosario y estructura, y que no inventan. 2/ Harness engineering: routing de modelo y clasificación de trazas para decidir cuándo usar el modelo caro. 3/ Detección de contradicciones/duplicados en la KB. Correr un Score con niveles fusionar / dejar sin enlazar / revisar curador. Detectar duplicados y contradicciones entre entradas para tener una KB coherente. Son solo algunos de los casos aplicables; veremos en cuáles marca la diferencia y en cuáles no.

todo normal en mi iphone, salvo que no es mi iphone. ayer, en una tarde, con deepdeek v4.1 flash y un par de prompts completé la pieza que me faltaba en mi setup de desarrollo remoto. hace unas semanas conté que trabajo contra un mac studio en la oficina, accesible por ssh desde cualquier dispositivo con herdr. todo funcionaba igual que en local, menos para hacer qa e iterar ui. para proyectos web era fácil: bind del puerto remoto a localhost y a correr. para desarrollo móvil, no tanto. hasta ayer ;) aprovechando baguette (es la ostia), monté una pequeña app que me da acceso remoto a toda la granja de emuladores que tengo corriendo en el studio. ahora puedo tener varios proyectos ejecutándose contra distintos emuladores y probarlos en tiempo real desde mi propio móvil o desde cualquier navegador. a kilómetros de mi estación de trabajo. esto merece un: what a time to be alive :)

tuve tanto lío estas semanas que olvidé hace público el repo. aquí lo dejo para el que le quiera echar un ojo github.com/Inakitajes/petalo…

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.

😱 Menudo final de año nos espera de eventos tech. ¿Has revisado nuestro calendario? Ya hemos terminado de cargarlos todos y no sabemos cuáles elegir 😅 Lo mejor será que pases a verlos, te dejo enlace aquí: eventos.wiki/calendar

los agentes sufren ansiedad de contexto. modelar tus procesos alrededor de esta restricción, te hace tener mejores resultados. hice una prueba: misma review, mismos modelos. - A: la auditoría en un único prompt - B: separando clean code, security y bugs en contextos independientes. el split costó ~30% más y tardó prácticamente lo mismo. pero encontró bastantes más problemas relevantes. con los modelos actuales: contexto más cohesionado y acotado (no necesariamente corto) >>> agentes intentando hacerlo todo.

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.

quizás debería rebautizarla como ultimate-token-burner (utb-cli). - paralelización de steps, done. - multi-model step, done. más rápido y mejores resultados, pero quemando a saco. merece la pena? denme una semanas para seguir testeando. en breve se viene videotutorial.

codexbar está guapo, pero con tanto supply-chain attack, no me gusta estar metiendo más opensource de la cuenta en el pc. así que me hice un mini CLI con Fable 5 (antes de que lo quitaran) para controlar el usage de codex + claude. poco código, casi zero deps y al grano. la tienen en mi github si les interesa :)

La IA programa mal. Pero no es un tema de ego: es un tema de ecosistema. Partimos de una base que aún no estaba bien cimentada. Las ideas estaban, pero no se habían interiorizado. Y tiene solución. Te cuento más aquí: adrianferrera.dev/es/blog/ai…

De vuelta por #CommitConf este 2026 ☺️

Algo grande se está cocinando en #CommitConf. 🚀 Este año nos hemos propuesto romper moldes con un proyecto que cambiará la forma de vivir los eventos, ¡y no solo en el sector tecnológico! 💥La cuenta atrás ha comenzado.

Después de gastar billones de tokens, creo que ya puedo sacar una conclusión bastante clara: La gente está optimizando el coste equivocado. He probado decenas de modelos, editores y agentes: Codex, Claude Code, Cursor, OpenCode, Codex Cloud, múltiples providers y configuraciones. Llevo desde gpt-3.5 usando IA para programar. Al principio como asistente y desde diciembre del año pasado, no escribo código manualmente: programo exclusivamente con IA. Además lo he hecho en proyectos reales. En productos en producción con millones de usuarios, como Calisteniapp. Me costó todo este tiempo darme cuenta de qué es lo realmente importante a la hora de elegir modelos y tools. La mayoría mira únicamente el precio por millón de tokens, o el uso que tiene incluido en la suscripción de turno, y la calidad del resultado. Tienden a usar el mejor modelo calidad/precio que se pueden permitir. Pero esta métrica, aislada, no significa nada. Porque el verdadero coste no son los tokens. Es el efecto compuesto: - el número de iteraciones, - el tiempo humano, - la carga mental, - la pérdida de flow, - y el coste de revisar trabajo mediocre. Con modelos baratos tipo Kimi K2.6, para una misma tarea, normalmente necesito 1 o 2 iteraciones más que con GPT-5.5 o modelos sota. Sí, el modelo barato cuesta 2-3 veces menos por token. Pero si necesito: - más prompts, - más revisiones, - más contexto, - más correcciones, - y más tiempo pensando… Entonces el modelo "barato" termina siendo más caro. Porque no estás pagando solo tokens. Estás pagando tiempo humano y carga cognitiva. Y el tiempo humano de un programador senior no vale precisamente poco. Tomemos un baseline conservador: 40 céntimos por minuto. Si un modelo mediocre me hace perder 10 minutos extra revisando, iterando o corrigiendo, ya he gastado 4€ invisibles. Ese es el coste oculto de usar modelos "calidad/precio". Y esto se vuelve todavía más evidente usando modos xhigh o max. Mucha gente piensa: no compensa, consume demasiados tokens. En mi experiencia, la mayoría de las veces ocurre exactamente lo contrario. Los modos de razonamiento profundo suelen ser más baratos en coste total real porque: - resuelven mejor, - hacen menos errores, - necesitan menos iteraciones, - y llegan mucho más cerca del one-shot. A veces gastas más tokens. Pero menos tiempo humano. Y eso es lo importante. Pero hay otro factor más que la gente subestima y que casi nadie mide: La velocidad de inferencia. Hay tareas donde no necesitas el modelo más inteligente del planeta. Por ejemplo: - commits, - pushes, - tareas mecánicas, - scripting simple, - operaciones repetitivas. Pero ahí tampoco compensa necesariamente usar modelos lentos y baratos. Compensa usar modelos suficientemente inteligentes… pero absurdamente rápidos. Modelos como GLM 4.7 o GPT OSS 120B en providers optimizados pueden trabajar a cientos o incluso miles de tokens por segundo. ¿Resultado? Tareas que antes tardaban 2 minutos pasan a tardar 10 segundos. Y otra vez: el ahorro no está en tokens. Está en no romper el flow. Dos minutos esperando un commit automático son dos minutos donde tu cerebro sale del contexto. Son dos minutos de tu tiempo que cuestan mucho más que esos tokens. Te sugiero cambiar el chip: - No optimizar €/millón de tokens. - Sino optimizar coste total cognitivo y operativo. Si te interesa saber qué modelos y configuraciones uso, en mi perfil tienes un repo abierto con todo. Si piensas diferente, me gustaría conocer tu opinión.

- planeas con gpt-5.5 xhigh - /implement usa glm-4.7 para lanzar un worktree para cada tarea no te casas con nadie, pagas por lo que usas. amo @opencode

He publicado el repo con las personalizaciones de @opencode que más han cambiado mi flujo de trabajo diario. github.com/Inakitajes/openco… Básicamente incluye 2 plugins, 5 comandos y mi setup local con OpenCode + Worktrunk + Ghostty. Plugins 1. Un plugin TUI que cambia el título de cada pestaña/ventana según el estado de OpenCode: 🟡 trabajando 🟢 idle / terminado 🔴 requiere atención / error 2. Un plugin server que manda notificaciones locales en macOS cuando una sesión termina o necesita intervención. Comandos Los comandos no tienen demasiada magia. Son atajos para no escribir siempre el mismo prompt/flujo: /clean-code Auditoría read-only de arquitectura, mantenibilidad, SRP, SOLID y code smells. /audit Auditoría de seguridad read-only sobre la PR actual o el repo completo. /branch Cuando ya tengo un plan claro, crea un worktree aislado con Worktrunk y abre una sesión limpia de OpenCode allí con el plan como prompt inicial. /push Revisa el diff, ejecuta checks/tests relevantes, crea un commit convencional y hace push. /ship Prepara una rama para review: checks, commit si hace falta, push, PR en GitHub y revisión del estado de CI. La idea no es automatizarlo todo de forma mágica, sino quitar fricción a las acciones que repito muchas veces al día. Mi stack ahora mismo: - OpenCode como cockpit de agentes, comandos y plugins. - Worktrunk para ramas/worktrees aislados. - Ghostty como terminal principal. Es pequeño, local y bastante opinado, pero me está ahorrando muchísimo cambio de contexto. Espero que te sirva.

Here we go! @commitconf

En la última semana Codex ha pasado de tener 5 millones de instalaciones semanales a más de 85. Esto ha sido porque mucha gente ha migrado de Claude Code allí por tener los límites más altos. Seguramente este sea uno de los motivos por los cuáles Anthropic acaba de hacer un acuerdo con SpaceX para poder usas sus servidores. Gracias a este acuerdo: - Doblan el uso en la ventana de tiempo de 5h. - Quitan el límite de horas punta. - Aumentan los rate limits para los modelos Opus. Que haya esta competencia nos beneficia a los usuarios.

Llevo meses apostando contra la mayoría. Parece que empiezo a no estar tan loco. La idea central es simple, pero incómoda: Nadie quiere usar tu app. Ni tu SaaS. Ni tu herramienta. La gente solo quiere resolver su problema y seguir con su vida. Pero seguimos construyendo software como si el objetivo fuera que lo usen. La semana pasada di una charla a 150 personas sobre esto. La mayoría está pensando el futuro del software completamente mal. El discurso dominante es: habrá más software. Más apps. Más herramientas. Más sistemas personalizados. Cada persona con su propio CRM, su propio stack, su propio “todo”. La misma cajita de siempre, pero multiplicada por mil. Eso no es el futuro. Eso es pensar en velas más grandes cuando lo que viene es la bombilla. Porque nadie quiere apps. Nadie se levanta pensando: “ojalá hoy pueda usar 5 herramientas nuevas” La gente quiere: - entrenar sin complicarse - llevar su negocio sin fricción - resolver cosas rápido y ya El software es solo el medio. Nunca fue el fin. Y aquí está el cambio de verdad: No es que vaya a haber más software. Es que el software como producto deja de tener sentido. Hasta ahora: Abres una app → navegas → te adaptas → ejecutas Te adaptas tú a la herramienta. Pero lo que viene es lo contrario: Dices lo que quieres → obtienes lo que necesitas Un diseño emergente: sin menús, sin flujos, sin cajitas predefinidas. “Quiero empezar calistenia” → plan generado → explicación → seguimiento → adaptación El software ya no se usa. El software responde. No existe antes de que lo necesites. Aparece en el momento. Pensar que esto acaba en “más apps” es caer en tres sesgos: - Cierre funcional: imaginamos el futuro como una versión mejorada de lo actual - Continuidad: creemos que el cambio será gradual - Extrapolación lineal: proyectamos el presente en vez de cambiar el modelo (velas más grandes, caballos más rápidos…) Pero el cambio no es evolutivo. Es de paradigma. lo relevante? Si el software se genera… el software deja de ser la ventaja. Quedan tres capas: - Infraestructura (alguien tiene que hacer que todo funcione) - Datos (que nutran los llms) - Interfaz (sensorial y generativa) Y fuera de eso, lo único defensible es: - entender problemas - tener distribución - generar confianza Porque al final: nadie quiere tu app, quiere el resultado. Y eso no cambia. Lo que sí cambia es dónde está el valor. Mientras el software se comoditiza, la diferenciación se mueve a: - marca - comunidad - autoridad La gente no quiere “una solución”. Quiere TU solución. Y aquí viene la pregunta incómoda que dejé en la charla: Si mañana tu app desaparece... ¿qué queda? Si la respuesta es “nada”, no tienes producto. Tienes una cajita, un envoltorio. Te has quedado con el medio en lugar de con el fin.

Tenemos web 🌐 helpmiriam.com Ahí está todo documentado públicamente: el perfil molecular, la ciencia detrás del caso, el equipo de cuatro países, la cronología semana a semana. Para quien se acaba de unir: tengo cáncer de mama metastásico con una biología tan rara que las guías clínicas no tienen respuesta para él. Hace unas semanas decidí investigar mi propio caso con IA. Un hilo. Un equipo espontáneo. Y ahora esto. No sé lo que viene. Pero voy con más información que nunca y con el mejor equipo posible. Si eres oncólogo/a, investigador/a o simplemente quieres entender qué está pasando está todo ahí 👇