Otra de las piezas importantes es saber cómo llevar esos modelos a producción.
Y aquí quién tiene mucha experiencia de ello son Jorge Castro y Joaquin Cabezas.
En el curso hay un vídeo con ellos comentando sus experiencias llevando todo esto a producción. 🎩
Lo complicado es saber qué modelo escoger para cada tarea.
Y no sólo por términos de inteligencia del modelo, si no por saber si va a poder ejecutarse en nuestras máquinas.
Por ello acabamos de publicar un curso en Codely Pro centrándonos en ello.
Por privacidad y seguridad, los modelos en local son hoy en día más importante que nunca.
Tanto si lo usas para hacerte pequeñas aplicaciones para que te hagan el día a día más fácil. como si lo que quieres es tener un asistente con OpenClaw.
El Outbox y el Inbox pattern son 2 patrones de programación muy interesantes.
📤 El Outbox Pattern se encarga de que un mensaje siempre sea entregado.
📥 El Inbox Pattern se encarga que un mensaje siempre sea leído.
Hemos publicado un curso en Codely Pro Standard de ello. 😊
Y sí, sí que lo tiene. Nos comentó como gracias a ello podían escalar su frontend mucho mejor.
Y a nosotros si nos das la mano te cogemos el brazo, así que le hicimos el lío para grabar un curso de ello.
Ya disponible, Tailwind CSS: Arquitectura y buenas prácticas.
Hace un tiempo, en una conferencia, nos cruzamos con Paco Castelló, Tech Lead Front End Developer en S2 Grupo.
Hablando con él nos comentó algo MUY interesante: Estaban aplicando arquitectura CSS en su frontend con Tailwind.
Nos quedamos en plan: ¿Arquitectura + Tailwind? ¿Eso tiene sentido?
Claude Code lo ha petado. Tiene un éxito brutal para programar ya a día de hoy. Anthropic acaba de lanzar Claude Cowork llevando el mismo nivel de autonomía a personas no técnicas.
Vídeo con demo de uso real y 5 ejemplos de uso: youtu.be/bMlKWBzG81Q
Podemos estar de acuerdo en que depender de donaciones no sea la mejor solución, pero si ayuda a mitigar un poco la situación y dar más tiempo para conseguir adaptarse… pues como mínimo es un granito de arena que mientras tanto aporta 😊.
Lo hacemos en directo para evidenciar que sólo cuesta 2 clicks y 5 minutos. Con lo que si no sólo aportamos el granito de arena de la donación directa, si no que también conseguimos animar a que otras personas promuevan iniciativas similares en sus empresas… 🎉 🌈
Descubrimos que @GitHub lo pone tremendamente fácil. Analiza las dependencias de tus proyectos, mira qué mantenedores tienen, te permite filtrar y ordenar por distintos criterios… e incluso permite hacer una donación a múltiples personas en una sola transacción: github.com/sponsors/exp...
Así que, más allá del dolor/pena que dé… **¿qué granito de arena podemos aportar?**
Pues en el último directo del Café con Codely empezamos con algo muy concreto: Donar 250 $ cada mes a 5 mantenedores de las dependencias que usamos en todos nuestros repositorios.
Además, no sólo apostamos desde el lado de producir Open Source, si no que también, como todas las empresas, usamos un montón de software open source en nuestro día a día. Por esto, ver cómo cada vez el modelo es más insostenible para muchos nos duele especialmente.
En Codely apostamos por el Open Source desde el inicio. En nuestra organización de GitHub puedes ver no sólo repositorios de ejemplos para aprender, si no utilidades que aportan valor en sí mismas.
Tailwind despide al 75% de su plantilla por la IA.
Hasta ahora: Visitabas la documentación, descubrías productos de pago, un % acababa comprando. Ahora: 60% de caída de tráfico → Modelo insostenible.
Creemos tiene que ver con el Open Source en general. Qué hemos hecho 👇
Todo esto lo explicamos en el curso que acabamos de publicar sobre estos patrones. Ya disponible para Codely Pro. 😊
Por otro lado, añadir "por si acaso" estos sistemas que acabamos de explicar, puede causar diversos problemas. Hemos añadido nuevos niveles de indirección, movido cargas a otro sistema (del Rabbit a la BD), añadido nuevos procesos para consumir de estas tablas… Sobreingeniería de libro.
Estos 2 patrones son muy poderosos ya que nos desacoplan del sistema de mensajería (también nos pueden permitir desacoplarnos de servicios de envío de email, notificaciones…). Además, el patrón inbox nos puede ayudar a evitar consumir mensajes duplicados.
Luego tendremos un proceso que leerá de esa tabla y ejecutará el suscriptor pertinente.
Si aplicamos el inbox pattern, lo que haremos es una vez consumido el mensaje guardarlo en una tabla de nuestra base de datos. De esta forma, si se encolan muchos, lo que se llena es nuestra base de datos en lugar de el Rabbit.
En un suscriptor podemos escuchar el evento de usuario registrado para enviarle un email de bienvenida.
Pero algo que puede pasar es que el servicio de envío de email esté caído y que por culpa de eso perdamos ese evento o que se sature la cola y se acabe cayendo el Rabbit por ello.
Luego tendremos otro proceso que leerá de esa tabla y publicará en el Rabbit. De esta forma nos aseguramos de que siempre funcionen bien los casos de uso.
📤 El Inbox pattern
El inbox pattern es el patrón que se encarga de que un mensaje siempre sea leído.
Obviamente las 2 primeras no nos gustan, así que podemos optar por la 3a. Eso implica que en lugar de publicar en el RabbitMQ en ese momento, haremos un insert del evento en una tabla nuestra.
Pero algo que puede pasar, es que el Rabbit se caiga. En ese momento podemos elegir:
💥 Hacer rollback del caso del insert de usuario y devolver un error 500.
🥺 Asumir que hemos perdido el evento.
📤 Aplicar el patrón outbox.
📤 El Outbox pattern
El outbox pattern es el patrón que se encarga de que un mensaje siempre sea entregado.
Una vez un usuario se ha registrado (insert en base de datos) queremos publicar el evento de usuario registrado (en RabbitMQ, por ejemplo).
📬 Los patrones Inbox y Outbox pueden ser sobreingeniería
Los patrones inbox y outbox son dos patrones que nos aseguran que un mensaje se ha entregado o enviado. Para analizarlos vamos a imaginar el caso de uso de registrar un usuario:
Además, relacionado, Git. Para gente que no sabe programar es muy complicado. Quizás empezamos a ver una alternativa (o wrapper) más sencillo.
Sin duda cuesta de imaginar qué es lo que pasará. Llegas a decirnos en el 2020 todo esto y nos reímos de lo imposible que parecía.
Aunque si tiene que haber una gran revolución, seguramente sea algo que potencie el Vibe coding. Ahora mismo el Vibe coding está limitado. Si no sabes programar hay un punto donde los agentes dejan de funcionar bien. Quizás el código se vuelve transparente y pasamos del Vibe Coding al Vibe Building
Un punto donde los agentes de programación flaquean ahora es que son muy generalistas. Los subagentes aún no están maduros. Así que tiene sentido que veamos más agentes más especializados trabajando entre ellos para poder hacer mejores tareas.
🍍 2026: El año de… ¿la coordinación indirecta de agentes? Vibe Coding++
No sabemos qué va a pasar este año que viene, pero sí que sabemos que viendo el ritmo al que vamos, va a ser un año con más revoluciones incluso que este mismo 2025.
Además salieron nuevos editores de Google, Amazon… para programar. Infinitos nuevos modelos cada uno más poderoso que el anterior.
Desde este año ya no se entiende programar si no se utiliza IA.
