# Microframeworks en la Consola del administrador > La consola del administrador de Asana era una maraña de lógica personalizada, hasta que el equipo creó marcos declarativos que hicieron posible la migración asistida por IA. Lee cómo lograron hacer el lanzamiento un mes antes de lo previsto. Source: https://asana.com/es/inside-asana/microframeworks-admin-console ## Micromarcos en la Consola del administrador Cada implementación de Asana tiene una consola del administrador. Es donde los administradores de TI configuran cómo su empresa usa Asana, por ejemplo, ajustando los requisitos de contraseña, los roles y los permisos, si se pueden adjuntar archivos desde Dropbox y quién puede ver un proyecto nuevo de forma predeterminada. A medida que Asana creció, la consola del administrador acumuló años de lógica personalizada y soluciones puntuales, lo que hizo que los controles administrativos fueran cada vez más costosos de crear y mantener. Tomemos un ajuste administrativo: la privacidad predeterminada para los proyectos nuevos. Un administrador elige si un proyecto nuevo comienza siendo visible para toda la organización, visible para su equipo o privado para los miembros invitados. Es fácil de describir, pero hay mucha complejidad oculta: - ¿Esta función está incluida en el plan del cliente? - ¿Solían pagar por ella, dejaron de hacerlo y se quedaron con un ajuste que ya no pueden cambiar? - ¿Es un cliente de HIPAA o FedRAMP, donde solo los roles con permisos elevados pueden editarlo? - ¿Alguna otra configuración hace que una opción no esté disponible? - ¿Debería mostrarse un banner informativo para describir las limitaciones actuales? Cualquier equipo que quisiera agregar un control del administrador tenía que hacer todo eso correctamente. La mayoría decidió que no valía la pena y, con el tiempo, la brecha entre lo que Asana podía hacer y lo que un administrador podía controlar se amplió. Esto se ilustra en el hecho de que algunos controles solo se pueden configurar a nivel de toda la empresa, lo que dificulta que los administradores de TI apliquen el control solo a un subconjunto de sus usuarios. Aquí hay un fragmento del cuadro de diálogo de configuración de privacidad del proyecto, que se usa para determinar si debe estar deshabilitado y si se debe mostrar un banner: Hay mucha lógica que analizar allí: licencias de funciones, gobernanza, anulaciones debido a la estructura de implementación y roles de usuario, especialmente para los revisores. Para ser meticuloso, tendrías que reconstruir la matriz de pruebas en tu mente para determinar si es correcta. Y eso es solo el cuadro de diálogo. La decisión sobre si la fila aparece en la página de ajustes se tomó en otro lugar y, además, de manera inconsistente: Tres filas, tres mecanismos y el control de acceso no siempre está en el mismo archivo. Entonces, para responder a la pregunta “¿Qué ajustes ve realmente este cliente?”, no solo tenías que leer cada fila, sino que también tenías que revisar cada componente. Esa pregunta surge con bastante frecuencia: Atención al Cliente tratando de explicar por qué un ajuste desapareció para un cliente, un gerente de producto que quiere una respuesta directa sobre si un nuevo control es un cambio rápido o uno de dos semanas, un empleado nuevo tratando de encontrar el único lugar que decide lo que un usuario específico puede ver. En términos generales, había cuatro aspectos que hacían que trabajar en la consola del administrador fuera costoso: - **Costoso de revisar.** La lógica estaba donde el autor la colocaba, por lo que una solicitud de cambio podía introducir un comportamiento especial sin que fuera evidente para un revisor, y la corrección no era algo que se pudiera verificar fácilmente con solo leer. - **La falta de estandarización ocultaba los errores.** Teníamos errores de larga data que eran difíciles de detectar. Muchos se debían a la desviación entre las especificaciones del producto y la implementación, causada por una gran cantidad de implementaciones personalizadas. Los equipos tomaban decisiones arbitrarias, lo que hacía que cada control tuviera sus propias peculiaridades. - **Cambios costosos.** Para hacer un cambio para el usuario final, había que encontrar todos los lugares donde se codificaba una regla, y rara vez había un único punto de definición. - **Costoso de probar.** La configuración de las pruebas requería un profundo conocimiento de los estados del backend, y las pruebas manuales exhaustivas de las implementaciones finales eran inviables debido a la cantidad de dimensiones que interactuaban. ## Presentamos los marcos Creamos un marco declarativo para los controles administrativos que sirviera como fuente única de referencias en la base de código. Ahora, un control indica qué es: Cada campo aquí se asigna a una rama del cuadro de diálogo anterior: requiredAdminRole es la verificación de HIPAA/superadministrador, upsellBehavior son las dos ramas de venta adicional y churnBehavior es el caso de los clientes que se dan de baja, lo que les permite restaurar la configuración predeterminada y nada más. Como parte de esto, el marco expone hooks que los ingenieros usan para derivar el estado calculado del control. Echa un vistazo a cómo se ve ahora el mismo cuadro de diálogo de privacidad del proyecto: La cadena de condicionales del banner se redujo a un componente compartido impulsado por un hook centralizado. El marco se encarga de la lógica combinatoria de todos los diferentes escenarios, y los SME responsables de mantenerlo, que conocen a fondo el producto de administración, pueden realizar cambios radicales con total confianza. Ahora usamos un tipado estricto para guiar a los implementadores a completar la información obligatoria necesaria para mostrar correctamente su configuración en todos los escenarios posibles. Es fundamental que no tengan que comprender las complejidades de esos escenarios ni cómo interactúan entre sí. Se puede acceder a estos ajustes a través de las filas en la interfaz de usuario de la consola del administrador. La visibilidad de esas filas recibió el mismo tratamiento, y aquí es donde entra en juego el segundo marco. Una fila en el registro de ajustes no describe sus propias reglas de visibilidad, sino que las vincula a los controles que la representan: La matriz de controles es el valor agregado. Contiene el mismo objeto ProjectDefaultPrivacy que el cuadro de diálogo entrega a useAdminConsoleControl, y el registro lo ejecuta a través de la misma fuente de referencias, por lo que la página y el cuadro de diálogo no pueden estar en desacuerdo. Antes se calculaba por separado, por lo que las discrepancias podían dar lugar a dos tipos de errores: una fila que es visible pero abre un cuadro de diálogo que no se puede usar, y una configuración por la que un cliente paga pero a la que no se puede acceder desde ninguna fila. Al centralizarlo, se eliminó esta categoría de errores. Las pruebas que adoptaron los marcos centralizados mejoraron considerablemente la experiencia de los revisores de solicitudes de extracción. Por ejemplo, consideremos las pruebas de visibilidad de filas, que responden a la pregunta “¿Qué ajustes ve realmente este cliente?” pregunta de antes. En lugar de código de prueba, un escenario es simplemente información: un perfil, un estado de dominio y las páginas en las que se muestra. Y una fila simplemente enumera en qué escenarios con nombre debe aparecer: No hay que escribir ninguna llamada de renderización ni ninguna aserción. Un conjunto de pruebas dinámico lee el catálogo y verifica cada fila con cada escenario en el que se menciona. El catálogo es ahora el único lugar que indica lo que ve un cliente, verificado por una máquina. Ya no es necesario depender de un revisor de código diligente o del autor para identificar y redactar correctamente sus propios casos de prueba. ## En el mundo de la IA Comenzamos este trabajo a finales de 2025 porque anticipamos la necesidad de permitir que los ingenieros que no son expertos en la materia desarrollen con confianza en la consola del administrador. En ese momento, el objetivo no era optimizar el rendimiento de los LLM, pero resulta que estandarizar y simplificar la experiencia para los ingenieros hace lo mismo para los agentes de IA. Antes de crear estos marcos, aplicamos la IA a este problema de migración, lo que técnicamente funcionó. El problema era que ni el agente ni el revisor podían determinar si las pruebas eran realmente correctas, lo que generaba una falsa sensación de seguridad y brechas silenciosas. La IA no soluciona la falta de estructura, simplemente genera más código, más rápido, sobre cualquier estructura que ya exista. [Google presentó un caso similar para el sistema de tipos de Go en el desarrollo asistido por IA](https://developers.googleblog.com/why-go-is-an-ideal-language-for-ai-assisted-software-engineering/): los tipos estáticos actúan como una red de seguridad automatizada, ya que los LLM son propensos a “alucinar” propiedades y a generar tipos incompatibles entre archivos. TypeScript no es tan estricto a nivel estático como Go, pero un marco puede ofrecer la misma garantía sobre él: definir el tipo del control una sola vez a nivel del marco, y cada implementación debe ajustarse a él en el punto de uso. Una vez que los marcos estuvieron listos, comenzamos a prepararnos para delegar y paralelizar. Usé nuestra nueva herramienta de desarrollo basado en especificaciones [link placeholder: eng blog post on spec driven development: [Blog de Ingeniería de Asana - Desarrollo basado en especificaciones: las partes buenas](/inside-asana/spec-driven-development)] para crear una habilidad que hiciera el trabajo de principio a fin. Codifica toda la conversión: define el control, llama al hook, reemplaza los banners, actualiza los fragmentos, agrega las nuevas pruebas declarativas, además de una lista de verificación que se actualiza automáticamente y un registro de casos extremos de conversiones anteriores. En todas las aproximadamente 150 migraciones, el 91 % no necesitó ninguna revisión después de la evaluación. Poner en marcha un agente para que redacte una solicitud de cambios no requiere mucho esfuerzo, y revisar dicha solicitud tampoco. Dado que todo se declara de una manera predecible, los revisores no necesitan ser expertos en administración para verificar si la implementación coincide con las especificaciones del producto. Es fundamental destacar que esto amplía el grupo de revisores elegibles a un conjunto mucho más amplio de ingenieros, lo que acelera el ritmo más allá de simplemente tener un embudo más amplio en la parte superior para crear solicitudes de cambios. No somos los únicos que estamos replanteando las revisiones para esta era: [GitHub reconstruyó el propio agente de revisión de Copilot en torno a evidencias estructuradas de las solicitudes de cambios](https://github.blog/ai-and-ml/github-copilot/better-tools-made-copilot-code-review-worse-heres-how-we-actually-improved-it/) para ayudar a los revisores humanos a llegar a las preguntas correctas más rápido, lo que redujo el costo de las revisiones en aproximadamente un 20 %. La migración original de aproximadamente 150 elementos que abarcaban varios marcos se consideró un trabajo de ingeniería manual y puntual de principio a fin. Al crear primero los marcos y luego delegar la migración a los ingenieros que supervisan a los agentes, pudimos completar todo el esfuerzo más de un mes antes de lo previsto en el plan original. ## ¿Qué sigue? Crear estos marcos nunca fue un proyecto en sí mismo. Surgió por necesidad, a partir de una hoja de ruta que necesitaba paralelizarse y escalarse, con un personal limitado y cambiante a lo largo del camino, y sin requerir que todos los colaboradores fueran primero expertos en el área. Ya hemos visto que funciona más allá del equipo que lo creó: 18 de los 66 controles del marco actual fueron creados por ingenieros de 8 equipos diferentes. Ahora, estamos buscando el próximo lugar para hacer este tipo de inversión. En todo caso, los argumentos a favor son más sólidos ahora que antes de empezar: un marco declarativo bien diseñado no solo facilita la revisión, sino que determina si un agente produce algo confiable o simplemente algo rápido. También es lo que podría hacer que la revisión autónoma sea plausible: [Cloudflare creó un sistema en el que un revisor de IA aprueba el código limpio y bloquea los problemas reales por sí solo](https://blog.cloudflare.com/ai-code-review/), y eso solo funciona porque sus entradas están lo suficientemente estructuradas como para que el revisor confíe en ellas. Una buena pregunta para hacer a continuación es si los nuestros están lo suficientemente estructurados como para intentar hacer lo mismo. #### Acerca del autor Leo Zhang es ingeniero de software en el equipo de Fundamentos para Administradores, que empodera a los administradores de TI para que puedan gestionar sus organizaciones. Actualmente, está mejorando la experiencia de desarrollo de otros ingenieros de producto en la Consola del administrador al invertir en los marcos técnicos que respaldan nuestro producto. #### Reconocimientos al equipo Diseñar, implementar, probar y comunicar estos cambios ha sido un gran esfuerzo de equipo. Esto fue posible gracias a las contribuciones de otros ingenieros del equipo de Fundamentos para Administradores: Yunus Rahbar, Maryam Booshehrian, Saverio Castelli, Bronwyn Damm, Cindy Yu, Calvin Norton y Jaxsun McCarthy Huggan. Walter Li, del equipo tigre de Éxito de los Agentes, ayudó enormemente a configurar las herramientas de IA adecuadas para estas migraciones. ### **Referencias** - Lan Cheng, Emerson Murphy-Hill, Mark Canning, Ciera Jaspan, Collin Green, Andrea Knight, Nan Zhang y Elizabeth Kammer, “What Improves Developer Productivity at Google? Code Quality”, ESEC/FSE '22, noviembre de 2022. [https://doi.org/10.1145/3540250.3558940](https://doi.org/10.1145/3540250.3558940) - “Orchestrating AI Code Review at Scale”, blog de Cloudflare, abril de 2026. [https://blog.cloudflare.com/ai-code-review/](https://blog.cloudflare.com/ai-code-review/) - Napalys Klicius, “Better tools made Copilot code review worse. A continuación, te contamos cómo lo mejoramos realmente”, The GitHub Blog, julio de 2026. [https://github.blog/ai-and-ml/github-copilot/better-tools-made-copilot-code-review-worse-heres-how-we-actually-improved-it/](https://github.blog/ai-and-ml/github-copilot/better-tools-made-copilot-code-review-worse-heres-how-we-actually-improved-it/) - “Why Go is an Ideal Language for AI-Assisted Software Engineering” (Por qué Go es un lenguaje ideal para la ingeniería de software asistida por IA), Blog de Google Developers, agosto de 2026. [https://developers.googleblog.com/why-go-is-an-ideal-language-for-ai-assisted-software-engineering/](https://developers.googleblog.com/why-go-is-an-ideal-language-for-ai-assisted-software-engineering/) - [Desarrollo basado en especificaciones: lo bueno y lo que aprendimos después de tres meses](/es/inside-asana/spec-driven-development) Ingeniería #### Ingeniero/a de software del personal Después de tres meses, teníamos una idea más clara de cuándo la estructura adicional ayudaba y cuándo se interponía en el camino.Uno de nuestros ingenieros estaba preparando una m ... - [Migramos de Enzyme en 2 semanas. Debería haber tomado cinco años](/es/inside-asana/migrating-off-enzyme-2-weeks) Ingeniería Recientemente usamos la IA para finalizar años de trabajo de ingeniería en aproximadamente un sprint. A continuación, te contamos cómo y por qué cambió la forma en que pensamos so ... - [Cómo los compañeros de IA crean memoria: convertir el trabajo en conocimiento reutilizable](/es/inside-asana/ai-teammates-turn-work-into-reusable-information) Inteligencia artificial (IA) Ingeniería La mayoría de los productos de IA tratan la memoria como una característica personal: recuerdan datos sobre un usuario o una conversación. Pero la IA que colabora entre los equipo ... - [Agentes de IA diseñados para equipos: contexto compartido y transparencia en la IA empresarial](/es/inside-asana/ai-agents-built-for-teams-context-transparency) Ingeniería Inteligencia artificial (IA) La brecha en la Responsabilidad Los agentes de IA empresarial son sistemas de IA que pueden realizar acciones dentro de los flujos de trabajo compartidos entre equipos y proyectos ... - [Microframeworks in the Admin Console](/es/inside-asana/microframeworks-admin-console) Ingeniería Cada implementación de Asana tiene una consola del administrador. Es donde los administradores de TI configuran cómo su empresa usa Asana, por ejemplo, ajustando los requisitos de ... - [Ingeniería](/inside-asana/engineering-spotlight)