🎉 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/

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í 👇

🙌 ¡Se abre el Call for Volunteers de #CommitConf 2026! Buscamos personas que quieran vivir el evento desde dentro, conocer a la comunidad tech y formar parte del equipo durante esta nueva edición.⏳ Inscripciones abiertas hasta el 30 de abril.

Necesito una biopsia molecular avanzada para saber qué tratamiento aún puede funcionar. He creado un crowdfunding para poder hacerla. Cualquier ayuda (donar o compartir) suma 💙 Maxima transparencia👇 gofund.me/7d669b4bf

Si usas @obsdmd @opencode, esto te encantará:

La mayoría de empresas NO necesitan otro chatbot. Necesitan un entorno: - abierto, - multi-modelo, - multi-agente, - conectado a sus herramientas, - y construido sobre su propio conocimiento. Eso es Arche. Open source. Gratis. Te cuento por qué importa: (1/6)

Sorteamos 1 entrada gratis a la #JSConfES 🎉 Ya están las entradas agotadas, así que es tu última oportunidad para conseguir asistir 😊 Cómo participar: 1️⃣ RT de este post 2️⃣ Follow a @CodelyTV 3️⃣ Follow a @midudev (organizador) 4️⃣ Estar en el directo del Café con Codely de este viernes 6 de marzo (empieza a las 9h CET)

Archē is live! An open-source, AI native operating system for your company. One goal: Bring the best tools together and create shared context for more efficient day to day operations. It is built around @opencode and adds a layer of sugar. Custom tools, a shared versioned knowledge base, multi user remote workspace, and centralized configuration. Best part. One click deploy on a cheap VPS. Up and running in minutes with its templating engine. If you like it, try it and share. Still early stage. PRs welcome. Cc: @p3rd0mo @ixJosemi

Arche está casi listooo! No inventamos nada nuevo, solo unimos las mejores herramientas en un solo pack abierto, interoperable y sencillo de poner a funcionar. Les dejo algunas novedades aprovechando un loom que le envié a un amigo :)

La revolución de la IA nos da un x10 en productividad. Pero no sale gratis. Quizás lo más duro de la transformación que estamos viviendo en el trabajo es que no todo el mundo está preparado física y anímicamente. Una de las cosas que más drena de energía a un founder/c-level es la toma constante de decisiones y el context switching. Estar a mil cosas en paralelo. No parar de decidir. Decisiones determinantes, todo el rato. El ser humano no es multitarea. Lo que hacemos es multiplexar tiempo: unos minutos para esto, otros para lo otro. Intercalamos tareas. Y eso tiene un coste enorme: esfuerzo cognitivo, fatiga de decisión, burnout mental. No todo el mundo puede (ni quiere) ocupar estos roles. Empieza a ser evidente que, cuanto más rápida es la IA, más claro queda que el cuello de botella seremos nosotros. No podemos cambiar de contexto tantas veces y seguir tomando buenas decisiones al mismo tiempo. Lo comenté en la última reunión trimestral con el equipo: el verdadero objetivo de este x10 en productividad debería ser darnos más espacio para pensar mejor. No ir como caballos desbocados haciendo más, pero peor. Ni sacrificar salud por velocidad. Productividad no es hacer más. Es decidir mejor.

Amén.