El sprint de la app de la Meguilá, Purim 2026
Cómo los shlujim del grupo AI for Shlichus dieron forma a una app sincronizada de la Meguilá en unos diez días antes de Purim 2026, y las lecciones de ese sprint y de un lector de Ester que falló el día de Purim.
En esta página
Esta página es historia: lo que pasó en los diez días previos a Purim 2026, cuando un shliaj publicó una app de la Meguilá y el grupo la convirtió en un proyecto compartido. La app tal como es hoy está en megillah.app.
Cronología
Las fechas son las del chat. Purim 5786 comenzó en la noche del 2 de marzo de 2026.
| Fecha | Qué pasó |
|---|---|
| 20 feb | Un shliaj publica megillah.app, creada con Claude. El primer tiempo de lectura predeterminado es de 35 minutos; los miembros dicen que es largo. |
| 21 feb | El código se hace público en GitHub. Se agregan traducciones en seis idiomas, un botón de pausa de sonido, un ajuste de agitar para hacer sonar la matraca (gragger) y un enlace a Chabad.org. |
| 22 feb | Antes del amanecer, un miembro publica «Shluchim Vibe Coding Sprint: Purim is in 10 days» con una lista de ideas: traducciones, reconocimiento de voz, una versión para niños, sesiones con QR, efectos de sonido, resaltado de palabras, lectura sincronizada en la sinagoga. El modo en vivo sale ese mismo día y se publica una página de novedades. |
| 22 feb | El administrador del grupo abre un grupo aparte, AIFS Builders, para vibe coding y construcción de agentes, tras una encuesta, y pide que las conversaciones sobre la app de la Meguilá se mudaran allí. |
| 22 a 23 feb | Los miembros objetan el inglés JPS de 1917 de Sefaria por arcaico. Los shlujim que prueban en sus sinagogas informan de desfase entre teléfonos. |
| 25 feb | Se aclara el inicio de sesión del transmisor: abre /live e ingresa el ID de la sesión y la contraseña. |
| 25 a 26 feb | Una gran actualización: vista versículo por versículo por defecto, desplazamiento automático centrado, tipografía predeterminada más pequeña, transliteración y traducción de las brajot, ajustes de traducción en la barra superior, valores predeterminados fijados por el transmisor, un botón de «dejar de seguir». El inglés pasa a Metzudah, y luego a la traducción de Kehot una vez que Kehot da el visto bueno. |
| 2 mar | Se agregan ilustraciones de TorahApp.org. COLlive publica «700 Shluchim Built a Megillah App in 10 Days». |
| 2 a 3 mar | Purim. Los Batei Jabad la usan en la sinagoga. |
| 3 a 5 mar | Análisis y comentarios; un lector de Ester paralelo comparte un franco análisis posterior (abajo). |
Solicitudes de funciones, concedidas y rechazadas
| Solicitud | Resultado |
|---|---|
| Varios idiomas | Entregado (seis al principio, diez al final de la temporada) |
| Transliteración | Entregado para los versículos que se leen en voz alta y los hijos de Amán |
| Controles de pausa, tipografía y tamaño | Entregado |
| Efectos de sonido de Amán y agitar para la matraca | Entregado (hoy el sitio usa tocar a Amán) |
| Transmisión en vivo a todos los teléfonos de la sinagoga | Entregado |
| Imágenes | Entregado como capa opcional |
| Desplazamiento automático por reconocimiento de voz | Rechazado: «la tecnología aún no está lo bastante madura», demasiado retraso |
| Activar automáticamente No molestar | No es posible desde un sitio web; haría falta una app nativa |
| Ajustes que coincidan entre el transmisor y los seguidores | Prometido como arreglo durante el sprint; los valores predeterminados del transmisor ahora pasan a quienes se unen después |
El otro lector de la Meguilá: un análisis posterior
En esas mismas semanas un miembro lanzó un lector de Ester rico en imágenes en learningtanach.org. Funcionó en la noche de Purim. El día de Purim, después de una ronda de arreglos, falló. El constructor publicó un análisis posterior abierto el 4 y 5 de marzo de 2026. En sus palabras, «siguió agregando piezas con herramientas de IA», y cada adición volvía el código más frágil hasta que hubo «seis sistemas de temporización distintos contradiciéndose entre sí». Ofreció reembolsos a quienes habían pagado por funciones premium y reconstruyó el lector desde cero. El sitio aun así atrajo a unos 7.000 visitantes en dos días, y solo las imágenes llevaron más de 100 horas.
Lecciones que sacó el grupo
Provienen del análisis posterior y de la revisión que le siguió.
- Congela lo que funciona antes del gran día. Si a la gente ya le gusta la versión 1, no publiques un montón de arreglos la noche anterior. El lector de learningtanach.org falló después de los arreglos, no antes.
- Conserva versiones a las que puedas volver. Consejo de un miembro después de Purim: numera tus versiones (1.0, 1.1) para poder deshacer una mala actualización en minutos.
- Cada edición de la IA solo ve el código que tiene delante. Muchos parches pequeños de IA pueden parecer correctos cada uno y aun así dejar toda la app incoherente. Cuando empiece a tambalearse, pide a la IA que revise todo el diseño, o empieza de cero.
- La IA no reemplaza el proceso completo de software. Probar en teléfonos reales en una sinagoga real, un plan y alguien que lea el código siguen importando.
- Publica donde cuenta, y luego detente. La app de la Meguilá funcionó porque era corta, de un solo uso y no necesitaba cuentas. En octubre de 2026 un constructor señaló que las apps de larga duración que los shlujim usan todo el año son mucho más difíciles; el sprint de la Meguilá no es prueba de que un grupo pueda mantener de la misma manera un sistema completo de Beit Jabad.
- Planifica para un solo encargado. Casi todas las fusiones pasaron por una sola persona. Acuerden de antemano quién puede hacerse cargo si esa persona está ocupada en Purim.
Por qué se recuerda
El sprint le mostró a unos cientos de shlujim, la mayoría sin ser programadores, que una herramienta gratuita para su sinagoga podía pasar de la idea a Purim en diez días cuando se mantiene dentro de las reglas del vibe coding: sin inicios de sesión, sin pagos, sin base de datos de personas. Un participante contó la reacción después de Purim: «La gente me decía que Jabad son genios y líderes. A la gente le encantó».
También marcó el patrón que el grupo de constructores sigue usando: publicar una versión que funcione, recibir pedidos del chat y entregar cambios en cuestión de horas.