Implementación de IA en STR Network: de la tecnología a la gestión

«La IA no es un problema técnico, es un problema de gestión.» Eso es lo que dice Sunny en su entrevista con Business Weekly nº 1963.

Suena a eslogan de presentación de consultora, pero en STR Network (薩泰爾娛樂) describe un orden de ingeniería. Mientras la mayoría de las empresas siguen comparando si ChatGPT, Cursor o n8n es más potente, esta cofundadora ya ha dado la vuelta a la pregunta: primero hay que definir qué se va a gestionar dentro de la empresa; solo entonces tienen sentido las herramientas.

Este artículo es un inventario de los sistemas internos que STR Network ejecuta sobre Zeabur. Pero el orden de la historia — y por qué el ritmo de ingeniería de STR Network no encaja con la imagen al uso de «startup que corre rápido» — empieza por cómo se organizan a sí mismos.

At a glance

I. Cómo STR Network aterriza la IA y otras herramientas nuevas

STR Network es una productora taiwanesa que nació de la comedia satírica; entre sus programas está The Night Night Show with Brian Tseng. El ADN central de la compañía es el contenido — planificación, guion, producción, representación de artistas — y el departamento técnico, en sentido estricto, lo forma una sola persona: el ingeniero Feng.

Desde la perspectiva de Zeabur, mirando cómo STR Network adopta y aplica herramientas, su ritmo es más rápido que el de productoras de tamaño parecido. No porque tengan muchos recursos de ingeniería, sino porque el reparto de roles interno está muy claro:

La cofundadora Sunny se encarga del brief. Define qué tiene que gestionar la empresa, quién puede ver qué, cómo se reparten los permisos y con qué marco recibir las herramientas nuevas cuando entran. Estas decisiones se condensan en un brief que pasa al ejecutor.

Después del brief que entrega Sunny, Feng aterriza esos requisitos en un sistema que funciona. El inventario de procesos y la implementación de ingeniería no son una carrera de relevos: son dos personas sentadas a la misma mesa hablando. Sobre el documento de requisitos que escribe Sunny, Feng, mientras construye, vuelve a preguntar cosas como «¿este campo realmente necesita este nivel de permisos?», y lo sincroniza con Sunny en el weekly brief.

Es esta estructura — decisión de Sunny + implementación de Feng — la que hace que cada herramienta nueva, cada sistema nuevo, pase por un filtro antes de entrar en la empresa. En lugar de cargar a un solo ingeniero con gobernanza, diseño y obra al mismo tiempo. Esto es lo que se conoce como «estructura de gobernanza»: en STR Network lleva años en marcha, y la verdadera razón por la que tantas empresas medianas se ven sepultadas por las herramientas en la era de la IA es justamente la falta de esa estructura.

Pongamos un escenario concreto: cada función tiene que reservar entre 20 y 200 entradas de prensa y relaciones públicas para invitados del consejo, medios, partners de negocio, contactos de representación, y un asistente para cada interlocutor importante. A lo largo del año, los contratos que hay que firmar, los partes de retribución que hay que seguir, los informes de venta de entradas que hay que cuadrar, han cruzado hace tiempo el volumen que aguanta una Google Sheet.

Todo el mundo sabe que hay que diseñar procesos y construir sistemas. Antes incluso de la era de la IA, STR Network ya estaba resolviendo este problema de manera sistemática. Para una empresa sin departamento técnico, la siguiente pregunta no es nunca «¿qué herramienta de IA usamos?», sino «¿qué tenemos que gestionar exactamente?». Cuando ChatGPT apareció en 2022, e incluso antes, en la era de GPT-3, STR Network ya llevaba mucho tiempo pensando en eso.

II. Los tres niveles de la «deuda de gestión» en STR Network

Sunny usa la expresión «deuda de gestión» en su entrevista con Business Weekly nº 1963, y es también la cita con la que abre este artículo. En su entrevista con Zeabur la desgrana en tres niveles concretos.

Primer nivel: la definición de gestión va por delante del diseño del sistema.

«Una vez que sale la definición de gestión, todo eso que llamamos diseño de sistemas y conceptos puede empezar a crecer.»

El ejemplo concreto que pone es un concepto interno al que llaman «libro contable» (帳本): un mismo proyecto de espectáculo puede tener dos o tres libros contables, cada uno con permisos distintos, y todos vuelven al final al mismo proyecto. Si el sistema es capaz de hacerlo es una cuestión de ingeniería; el requisito previo para hacerlo es que la dirección haya definido antes reglas como «el salario es dato personal, no se hace público» o «las comidas del rodaje las puede declarar cualquier asistente». En términos de ingeniería, se trata de definir bien los permisos sobre los datos.

Sin el primer paso, no hay manera de dar el segundo.

Segundo nivel: cada pequeño cambio tiene su coste de comunicación.

«Añadir una etiqueta, añadir un estado, añadir un rol de usuario, añadir una de esas cosas que se usan — su coste es alto; su coste de comunicación es alto.»

Añadir una columna en una hoja de cálculo sobre la marcha es gratis. Una vez que la operación está dentro de un sistema, cada cambio de campo arrastra horas de ingeniería, rediseño de permisos, mantenimiento posterior y formación de los roles afectados. Desplegar esa cadena entera y calcularla con honestidad — tiempo y recursos humanos — es lo que STR Network tiene que terminar antes de decidir «hacerlo o no hacerlo». No al revés: no dejar que el ingeniero empiece y luego recoger los pedazos en la conversación.

Tercer nivel: si la persona se va, nadie hereda el sistema.

Sunny es prudente con la idea de migrar el sistema (en concreto, el proyecto INVITI de invitaciones que Jerry arrancó, descrito más abajo) desde Google Sheet a una aplicación web propia. Lo dice directamente, y de paso suelta una broma negra (¿en una productora de comedia todo el mundo se ríe?):

«Si yo me muero mañana en un accidente de coche, vale, no pasa nada. Pero si Feng se va, todo esto (los demás) no lo conocen — no hay nadie que pueda recoger el mantenimiento. La verdad es que ese problema, hasta hoy, sigue sin resolverse.»

Sistematizar el proceso también crea una dependencia nueva, y esa dependencia recae en el único ingeniero. La «deuda de gestión» en este nivel significa: hasta que no resuelvas la dependencia de «todo el sistema solo lo entiende una persona», cada sistema nuevo es pedir más deuda.

Sumados los tres niveles, esa es la verdadera lectura de «deuda de gestión» en STR Network: no es una cuestión de qué herramienta usar, sino de poner sobre la mesa, definir y seguir con claridad qué hay que gestionar dentro de la organización, quién gestiona qué y quién puede ver qué — y solo entonces decidir si conviene convertirlo en sistema. Más aún en una época en la que «escribir cualquier cosa» se ha vuelto demasiado fácil.

III. La «deuda técnica» es lo que más le preocupa a Sunny del vibe coding

STR Network no rechaza en absoluto las herramientas de IA — al contrario: ya han pasado una ronda de automatización, conectan un RAG con Gemini Embedding, y Sunny escribe ella misma un framework de Skills con Claude Code. Su preocupación va por otro lado: el nuevo problema de gestión de IA. Lo dijo claro hacia el final de la entrevista:

«STR Network está bien, las operaciones y el modelo de negocio son estables. Pero muchas empresas que están arrancando, con la ansiedad reciente por la IA, comparten esa mentalidad de sprint: querer construir un montón de cosas encima del producto original. Lo que me parece más doloroso es que la gente puede acabar haciendo cien cosas parecidas que en el fondo son trabajo duplicado. Promover el vibe coding sin reservas, en realidad, va a generar un problema de eficiencia mayor — más deuda técnica, y la deuda de mantenimiento que viene detrás.»

«Si simplemente le dices a ChatGPT o a Cursor que necesitas un sistema, lo único que te van a dar es algo malísimo», comenta Feng en su entrevista con Global Views.

Deuda técnica y deuda de mantenimiento son los dos riesgos que Sunny señala por su nombre. Al día siguiente de la entrevista (2 de abril), publicó en Facebook un texto público titulado How to Read the Vibes, donde desarrolla la preocupación con más detalle:

«Lo que me importa no ha sido nunca insistir en lo poderosos que se vuelven los individuos. Me da curiosidad lo que podemos dejar de hacer. Al mismo tiempo, mi miedo más profundo es que, después de construir mucho, eso se convierta en más “construcciones ilegales” — deuda técnica y deuda de gestión a la vez. Cuando reparar agota y construir es cómodo, perdemos la fe en cómo se diseñan marcos que duren.»

«Construcciones ilegales» — esa es su imagen para describir el resultado del vibe coding fuera de control. Y un giro inmediato después:

«Pero que no se me malinterprete: no rechazo construir. Justamente para poder construir sin miedo es para lo que hace falta el marco de gestión.»

Su respuesta es escribir una Dev Diagnosis Skill, ya publicada como Claude Code Skill en GitHub. El README abre con «Antes de ponerte a trabajar, identifica el valor», y un poco después una frase afilada: «producir basura con mucha eficiencia sigue siendo basura.»

Esta Skill descompone el tratamiento de un requisito que llega en cuatro fases: diagnóstico → elegir solución → gestión por niveles → aterrizaje. Sunny explica en el post de Facebook la evolución del Skill:

«El año pasado, en STR Network, hice un diagrama de clasificación de cuestiones que cruzaba “alcance de impacto × continuidad × complejidad” para sacar tres niveles que nos ayudaran a decidir cómo supervisar. El problema es que “alcance de impacto × continuidad × complejidad” es ya en sí demasiado abstracto. Pensaba siempre en las técnicas del “diagnóstico”: el paciente puede describir sensaciones, pero la sabiduría del médico está en cómo conectar el síntoma con el nombre de la enfermedad, y de ahí a la solución.»

Dicho de otra forma: está reescribiendo el propio marco de gestión. No quiere que el usuario aprenda el vocabulario de «alcance de impacto × continuidad × complejidad», sino que describa directamente los síntomas y que el Skill traduzca esos síntomas al modo de desarrollo que toca aplicar.

Un Skill no es una herramienta: es la versión escrita en markdown de la gobernanza de la empresa. La síntesis de Sunny: «Lo que me importa es que dentro de un equipo haya consenso sobre los criterios básicos. Cuando esa sincronización de base es más alta, entonces sí se pueden amplificar las perspectivas que aporta la experiencia distinta de cada persona.»

Como respuesta a «construir sin miedo», más deuda técnica y la consiguiente deuda de mantenimiento, lo importante es revisar desde el origen — con arquitectura y con conciencia — la necesidad real de cada sistema nuevo.

IV. Algunos sistemas que corren sobre Zeabur

A continuación, los productos y sistemas que STR Network ejecuta en Zeabur. Una parte corre sobre el clúster compartido de Zeabur (que desde el 23 de febrero de 2026 ya no acepta proyectos nuevos), y otra parte está conectada vía BYOS a su propia máquina en GCP.

1. INVITI, el sistema de invitaciones a invitados

INVITI no empezó como código. Empezó con un mes de inventario que hizo Jerry, asistente del CEO, harto de gestionar invitaciones de prensa y relaciones públicas.

Como ya hemos comentado, cada función de STR Network reserva entre 20 y 200 entradas de cortesía según el tamaño del evento — para invitados del consejo, listas de prensa, partners de negocio del equipo comercial, contactos de medios de representación. Detrás de cada entrada hay una persona, y detrás de esa persona, su asistente. El volumen de datos supera enseguida lo que aguanta una sola Google Sheet.

Sunny y Feng cuentan en la entrevista lo que hizo Jerry: «Al principio dedicó alrededor de un mes a inventariar él mismo todo el flujo de invitaciones de prensa que había estado recorriendo.» Eso significa convertir el flujo completo en un documento de «tabla de correspondencia de roles»: quién invita a quién, qué rol ve qué campo, cómo se clasifican las distintas categorías de entrada, qué hay que hacer en cada paso. Ese documento no es un diagrama de arquitectura; es el flujo real, tal y como sucede en el mundo físico.

A continuación, Feng tarda mes y medio en montar la base de datos junto con el frontend. Sobre el papel que Zeabur juega en este sistema — el de empujar la internalización — su descripción es directa:

«Lo que más nos ayuda Zeabur en esto es el despliegue con un clic de Postgres. Antes de eso, casi no teníamos opciones de despliegue de datos fuera de BigQuery o lo que está sobre Google, y poder levantar Postgres con un clic en Zeabur me facilita muchísimo las pruebas en local. Eso ha rebajado un montón el coste de no tener que subir a la nube para probar.»

2. Sistema de operaciones — la plataforma interna donde se recogen todas las cifras y procesos de la empresa

«Todo esto está desplegado sobre Zeabur», dice Feng en la entrevista, y lo repite cuatro veces. Se refiere a la plataforma interna — el sistema de operaciones de STR Network: gestiona reembolsos, partes de retribución, informes de venta de entradas, la lista de proyectos. «Las cifras de la empresa se recogen ahí, todas concentradas en este sitio web.»

La arquitectura técnica es, en realidad, una aplicación web completa: capa de aplicación con Django + Celery, capa de datos con PostgreSQL, Redis para los workers y los procesos en segundo plano, django-celery-beat para las tareas programadas, y Nginx como proxy inverso. Feng comenta que en su momento «no se orientó deliberadamente hacia microservicios, pero echando la vista atrás ya tenían la forma embrionaria» — servicios separados, cada uno ejecutándose por su cuenta, aislados entre sí. Dicho esto, todavía hay distancia respecto a unos microservicios en sentido estricto, con bases de datos independientes y despliegue independiente (Pan, ingeniero de backend de Zeabur, compartió en SITCON 2025 la definición y la implementación de microservicios). STR Network sigue iterando el sistema, y la siguiente etapa es ir aislando los servicios de manera incremental — además de reducir el riesgo de acoplamiento, para mejorar también la eficiencia de desarrollo:

«Lo ideal sería que este servicio estuviera desplegado en este host, y aquel otro servicio en otro host.»

Sin embargo, lo verdaderamente difícil del sistema de operaciones no es la composición técnica, son los permisos.

Sunny menciona que el equipo detrás de un gran espectáculo es, por naturaleza, una colaboración subcontratada. La mayoría de las personas que aparecen en el evento real no son empleados de plantilla, y hay que separar con rigor qué libros contables, qué proyectos y qué datos salariales puede ver cada persona. El sistema lo resuelve con RBAC, pero Sunny lo había dejado claro en la entrevista anterior: «Una vez que sale la definición de gestión, todo eso que llamamos diseño de sistemas y conceptos puede empezar a crecer.»

El concepto de «libro contable» que STR Network diseñó en su gestión de proyectos — un proyecto puede tener dos o tres libros contables, cada uno con permisos diferentes, y todos vuelven al mismo proyecto — es, en esencia, el Principio de Mínimo Privilegio (PoLP) del campo de la seguridad de la información: cada rol solo ve el libro que necesita para hacer su trabajo, ni uno más.

El propósito de este mecanismo es que también las personas subcontratadas puedan entrar al sistema sin contratiempos y dejar el terreno preparado para la plantilla: «Es nuestra herramienta interna, pero no puede usarse solo internamente. Si solo la usa gente interna, choca con un cuello de botella, sigue limitada por la capacidad del equipo interno», añade Sunny.

Eso por fuera. La misma lógica de gestión, llevada hacia dentro, plantea otra pregunta: un libro contable, dentro de la empresa, ¿de verdad necesitan consultarlo todos los miembros? La respuesta es obvia, pero cuando entran en juego responsabilidades internas más finas, aterrizarlo es un reto más avanzado.

Permisos desde fuera hacia dentro, aislamiento desde el usuario hasta la capa de arquitectura: la trama de las dos cosas es exactamente el problema de gestión que toda empresa se encuentra a continuación cuando adopta IA. STR Network resolvió el tramo inicial de esa adopción y ahora, a través de las actualizaciones del propio sistema, empuja en sentido inverso la iteración de su marco de gestión.

3. Bot de Slack de administración interna con RAG

Este sistema acababa de desplegarse el día anterior a la entrevista.

Dentro de STR Network hay un canal de Slack llamado #help-administración, donde los compañeros preguntan: contraseña del Wi-Fi, contraseñas de las cuentas de empresa, reservas de sala de reuniones, qué número de autobús llega a la oficina. Antes era un bot escrito con Apps Script que hacía coincidencia por palabra clave, con una Google Sheet como base de datos por detrás: si las columnas no encajaban, no había respuesta, y la misma pregunta podía disparar incluso dos o tres respuestas duplicadas.

Feng lo movió todo a Zeabur: la Gemini Embedding 2 API (lanzada el 10 de marzo de 2026) para los vectores semánticos, la plantilla de PG Vector (que Zeabur abre con un clic) para almacenar los vectores, y Python con FastAPI como backend. Sobre el momento de lanzarlo, su explicación refleja el ritmo de ingeniería de STR Network:

«No tiene mucho que ver con el modelo. Resulta que el 10 de marzo se publicó la Gemini Embedding 2 API y se quedó en mi lista de pendientes. Esto ya funcionaba; simplemente, antes se disparaba con palabras clave, sin componente LLM por dentro.»

No es que se lance algo en cuanto sale un modelo: es que la necesidad llevaba tiempo en la lista de pendientes y la herramienta nueva acabó moviéndola hacia arriba en la prioridad. Sobre el papel de Zeabur, Feng lo describe así: «Con Zeabur lo importante es que el despliegue se vuelve fácil. Antes lo corríamos sobre Apps Script, como si fuera el backend de LINE. Ahora es básicamente empaquetar FastAPI y ejecutarlo sobre Zeabur.»

El RAG tiene además un mecanismo de auto-iteración: cuando el sistema no encuentra respuesta, vuelve atrás para ver por qué no la ha encontrado, hace un juicio semántico e incorpora el caso a la base de datos. Feng insiste en que solo después de que esto lleve un tiempo corriendo «se va volviendo cada vez más inteligente».

V. ¿Cómo se ejecutan estos sistemas sobre Zeabur?

Si juntamos los requisitos de los sistemas anteriores, el papel de Zeabur en STR Network queda claro: Zeabur no reemplaza al equipo de mantenimiento, reimagina cómo debería verse «desplegar un sistema y mantenerlo corriendo de forma estable». Potencia a las personas que ya están en el equipo — con el apoyo de Zeabur Agent — para que hagan lo que antes habría requerido un equipo entero de operaciones.

En STR Network, el equipo técnico es Feng él solo — y por eso él solo es capaz de mantener a flote varios sistemas en producción sin necesidad de entrar al detalle de en qué tipo de host corre cada uno, ni de contratar a una persona dedicada para «poner las cosas en producción», otra para «que el sistema se mantenga estable y no caiga de madrugada», y otra para «cuidar de las copias de seguridad y el rendimiento de la base de datos». En lugar de eso, gestiona la operación a través de tres funciones de Zeabur:

• Plantillas de despliegue con un clic: INVITI arranca con Postgres, el bot de administración con RAG arranca con PG Vector, y la aplicación de trabajo se apoya en Postgres y Redis. Feng describe cómo esto reduce la diferencia de coste entre «probar en local» y «probar en la nube». Para un ingeniero que sostiene full-stack en solitario, eso determina directamente la velocidad de iteración y de prueba de ideas nuevas.
• Gestión de nubes híbridas: parte de la producción crítica corre sobre su propio servidor de GCP. El despliegue, la monitorización y los logs pasan por la interfaz de Zeabur, mientras que otra parte de los recursos está desplegada en otros recursos contratados a través de Zeabur. Los recursos de servidor son híbridos (de hecho, STR Network tiene incluso una máquina Mac on-premise, y está considerando conectarla a Zeabur para gestionarla), y la interfaz de operación es la misma.
• Capa de abstracción unificada: solo el sistema de operaciones tiene seis servicios (Django, Celery, Redis, Postgres, Nginx, django-celery-beat); a eso se suman INVITI, el bot RAG de administración y los demás sistemas críticos que corren sobre GCP. Todo el estado de salud de los servicios se ve en la misma interfaz de Zeabur, con una gestión visual unificada.

Por supuesto, para los equipos que ya tienen a alguien dedicado a cuidar de la capa técnica de base, Zeabur potencia a ese mismo grupo de personas para hacer el mantenimiento de forma más rápida y con menos esfuerzo, y devuelve la energía que se ahorra a las cosas que de verdad piden criterio especializado: iterar la arquitectura del producto, asegurar el cumplimiento de seguridad, planificar cómo va a crecer el sistema en el futuro.

VI. Volver a «la adopción de IA no es un problema técnico»

«La adopción de IA no es un problema técnico, es un problema de gestión.» Esta frase no significa que la IA no importe.

Significa esto: antes de la IA hace falta un inventario completo de los recursos y de los procesos (a veces, una base de datos interna acumulada durante años), un flujo de evaluación que Sunny solo escribe en el sistema después de haber pasado por él una y otra vez, y el cálculo afinado del coste de comunicación de cada pequeño cambio. Así es como STR Network maneja los dos grandes retos de la adopción de IA — la deuda de gestión y la deuda técnica:

La deuda de gestión, que es la capa de fondo, y la deuda técnica que la acompaña — todo lo que en superficie parece desorden técnico (arquitecturas demasiado mezcladas, demasiados servicios, cuanto más rápido se escribe más rápido explota) — en el fondo son la cuenta del «sistema de gestión que no se definió bien». STR Network resuelve esta raíz con dos cosas:

• La estructura de gobernanza a tres bandas «brief de Sunny × Jerry × Feng» que aparece en las secciones I y II, unida al concepto de libro contable y al modelo de permisos RBAC. Desde muy pronto, la organización delimita con claridad qué se gestiona, quién lo gestiona y quién puede verlo.
• La Dev Diagnosis Skill que Sunny ha escrito recientemente: cuando entra un requisito, se le hace un diagnóstico — si en superficie parece técnico pero por debajo es gestión sin definir, se intercepta en el acto, para evitar el «chabolismo» de reinventar la rueda una y otra vez.

Cuando la deuda de gestión de fondo está saldada y la estructura del requisito es clara, lo que queda es «mantenimiento»: lograr que el sistema arranque y se mantenga estable. De esta capa se ocupa Zeabur Agent — abrir Postgres con un clic, publicar FastAPI con un clic, mover un servicio de un host a otro, recoger el estado de todos los servicios en la misma interfaz.

Por debajo aún espera el siguiente reto: cuando el sistema crece a colaboración multi-persona, multi-host y multi-entorno, quién puede acceder a qué máquina, quién puede cambiar qué servicio, quién puede ver qué tramo de logs — esa es una necesidad de gestión que nace de lo técnico, y es el desafío que STR Network está clarificando y argumentando a continuación junto con Zeabur.

La parte de las herramientas cambia constantemente en la era de la IA — de Apps Script a FastAPI, de coincidencia por palabra clave a RAG, del clúster compartido a BYOS — pero la lógica de inventario que tienen debajo no cambia.

«La IA no es un problema técnico, es un problema de gestión.» Eso dice Sunny.

Referencias

• Ho, Pei-Shan; Chen, Ying-Ying (26-06-2025). «Por qué la pionera en IA STR Network no para de derribarlo todo y empezar de nuevo: para hacer IA, primero ordena tu “deuda de gestión”». Business Weekly, nº 1963.
• Tseng, Tzu-Hsuan (27-02-2025). «El equipo entre bastidores de The Night Night Show: cómo el uso “divino” de la IA por parte de STR Network ha hecho subir de nivel a toda la plantilla». Global Views Monthly.
• Sunny (02-04-2026). «How to Read the Vibes». Publicación pública en Facebook + repositorio de GitHub mseatingtpe/dev-diagnosis-skill.
• Yuanlin Lin (23-02-2026). «El clúster compartido deja de admitir proyectos nuevos». Changelog de Zeabur.