Cómo Masha Leshchinskaya salvó su proyecto paralelo de la muerte: un sistema de reserva de dispositivos para IA

Masha Leshchinskaya, Head of QA en Surf, compartió la historia de un proyecto paralelo que sobrevivió a diferencia de cientos de otros. El sistema de reserva de dispositivos físicos lleva ya tres meses activo. Y esto no gracias a tecnologías revolucionarias o financiamiento de capital de riesgo, sino gracias a una solución simple: minimizar el costo de mantenimiento en la etapa de diseño.

Por qué los proyectos paralelos mueren

La mayoría de los proyectos paralelos duran una o dos semanas. El desarrollador se entusiasma con la idea por las noches, lanza rápidamente un MVP durante el fin de semana, lo sube a GitHub, lo comparte en redes sociales. Pero luego llega la realidad: es necesario monitorear los registros a las 2 de la mañana, corregir errores en producción, agregar funciones a solicitud de los primeros usuarios. Todo en tiempo libre, sin plazos, sin presupuesto, sin analistas. El entusiasmo cae linealmente con el tiempo, el proyecto se congela en el archivo de GitHub.

Masha se enfrentó a la misma trampa, pero actuó de manera diferente: en lugar de una arquitectura ideal con máxima flexibilidad, tomó como criterio desde el inicio el mantenimiento mínimo.

Cómo diseñar un sistema para mantenimiento mínimo

El sistema de reserva de dispositivos en Surf resuelve una tarea específica: los ingenieros de QA y probadores necesitan reservar dispositivos físicos (smartphones, tablets, IoT) para pruebas. Generalmente es una hoja de cálculo de Google con conflictos o una herramienta empresarial cara como TestRail. Masha eligió el mínimo funcional y automatizó todo lo posible:

• Liberación automática del dispositivo por timeout: el dispositivo se reserva exactamente para el intervalo asignado, luego se libera automáticamente
• Notificaciones a través de canales existentes (Slack, Telegram): sin aplicación separada
• Sincronización de BD completamente automática, sin actualizaciones manuales
• Mínimas integraciones personalizadas: APIs listos para usar (Slack, Google Calendar)
• El registro y monitoreo se autodiagnostican, las alertas solo llegan cuando hay problemas reales

Resultado: el proyecto requiere atención completa una vez por semana durante 15 minutos, no vigilancia diaria.

Cómo el proyecto paralelo se convirtió en un campo de pruebas para IA

Masha utilizó el sistema como un campo de pruebas real para experimentos con IA y LLM. Por ejemplo, un bot de NLP que entiende solicitudes en lenguaje natural («necesito un iPhone 15 por una hora de 3 a 4 de la tarde») y reserva el dispositivo por sí solo sin clics en la UI. O un agente de IA que propone dispositivos alternativos si el deseado está ocupado.

El bot de investigación clásico en un cuaderno de Jupyter se olvida. Un bot en un sistema de producción dura más: aprende de errores reales, del comportamiento real de los usuarios, no de un conjunto de datos sintético de la documentación.

Qué significa esto

Un proyecto paralelo duradero no es magia ni suerte. Es el resultado de un diseño sensato: minimiza el dolor del mantenimiento, automatiza la rutina, elige un caso de uso práctico. Y si el proyecto se convierte en un campo de pruebas real para experimentos de IA, deja de ser un hobby y se transforma en una herramienta que vale la pena mantener.