Investigadas y descartadas

Un agente de GUI en JavaScript dentro de la página que lee el DOM en vivo como texto (sin capturas de pantalla) y actúa como el usuario real: se le apunta a cualquier endpoint compatible con OpenAI y se le da una instrucción en lenguaje natural.

Por qué valía la pena revisarla: Encaje muy limpio en el papel: convertir un panel de administración existente en React en una interfaz de lenguaje natural para un equipo de operaciones no técnico, solo texto hacia el modelo, MIT, ~22k★. Queríamos que funcionara.

Por qué la descartamos: Ya operamos una vía de administración en lenguaje natural validada: un panel “Send to AI” que enruta por un puente en el servidor, con un contrato de acciones estructuradas y filtrado de entradas. page-agent maneja el DOM en bruto y envía formularios directamente, lo que esquiva esas salvaguardas del servidor justo en las acciones de escritura, pago y borrado que más las necesitan. Sumaría una segunda vía de control, menos segura, para una capacidad que en buena parte ya tenemos. Su propia documentación dice que la seguridad basada en prompts no es una garantía firme, así que en nuestro caso sería estrictamente más riesgo a cambio de poco alcance nuevo.

Una herramienta multiagente de pruebas de penetración con IA que ejecuta su aplicación de forma dinámica, encuentra y valida vulnerabilidades con pruebas de concepto funcionales en el OWASP Top 10+ (IDOR, evasión de autenticación, JWT, SSRF, lógica de negocio), con su propio LLM y apta para CI.

Por qué valía la pena revisarla: La candidata realmente más valiosa que revisamos: el control de acceso roto y el aislamiento por inquilino son justo de lo que depende una propuesta empresarial centrada en la privacidad, y admite modelos autoalojados o en Bedrock, de modo que los datos del cliente no tienen por qué salir de nuestro control. ~37k★, Apache-2.0.

Por qué la descartamos: No es un rechazo por calidad, sino por alojamiento y costo. Descarga un sandbox de Docker + Kali de varios gigabytes y factura por consumo aprox. USD 5–50 por escaneo, así que necesita un nodo dedicado más robusto, no la máquina puente de 16 GB siempre encendida que ejecuta nuestro código de integración en producción. El host que habíamos designado para esto estaba fuera de línea al momento de la evaluación. Lo responsable fue preparar un runbook con tope, de escaneo rápido y solo sobre nuestras propias aplicaciones, y esperar a lanzarlo hasta que el nodo adecuado vuelva, en lugar de improvisar un escaneo pesado facturado por consumo en el hardware equivocado.

Un asistente de reuniones centrado en la privacidad y 100 % local (Rust/Tauri + Next.js): transcripción local con Whisper/Parakeet con identificación de hablantes, y resúmenes con el modelo local o alojado que usted elija. Núcleo MIT, ~19k★.

Por qué valía la pena revisarla: Se parece de forma casi inquietante a un producto centrado en la privacidad, autoalojable, con LLM propio y con núcleo gratuito y versión empresarial de pago, lo que lo vuelve una sólida arquitectura de referencia para cualquiera que construya en ese terreno, no solo una herramienta de reuniones.

Por qué la descartamos: La instalación en sí resuelve un problema que nadie en el equipo tiene: no necesitábamos otra aplicación de reuniones en la máquina siempre encendida. El valor real estaba en la arquitectura: cómo abstrae a los proveedores y cómo empaqueta para su distribución una aplicación local primero y con LLM propio. Capturamos esos patrones como referencia y seguimos adelante. Estudiarla valió más que desplegarla.

Un framework de evaluación pequeño: se define una suite como un directorio de archivos YAML, se ejecuta con varias configuraciones de modelo, se califican las ejecuciones contra verificaciones y se sirve o se genera un reporte HTML estático.

Por qué valía la pena revisarla: El vocabulario es el mejor que hemos visto que alguien aplique a este problema (evaluación, tarea, configuración, ejecución, ejecutor, calificador, verificación, verificador), cada uno con una sola función. También es genuinamente nativo para agentes: `uvx smevals docs` imprime el README para que un agente de programación aprenda la herramienta y luego le arme una suite. Pequeño, MIT, sin infraestructura.

Por qué la descartamos: Esto ya lo ejecutamos, una capa más a fondo: 36 pruebas (18 integradas, 18 personalizadas) con 8 validadores de datos, un juez LLM para respuestas abiertas, un flujo de propuesta→aprobación, resultados en Supabase que alimentan la clasificación pública y una lente tests-eye sobre todo el conjunto. Adoptar smevals significaría un segundo sistema de evaluación junto a uno más maduro, sin camino de regreso a ese historial ni a esa interfaz: dispersión, no valor. Lo que SÍ tomamos fue su mejor idea: una “configuración” que varía el prompt de sistema y los parámetros, no solo el modelo, de modo que un bake-off de prompt contra prompt sea una ejecución ordinaria y no un script a la medida. Ese eje ya está en nuestro propio ejecutor. Tomar prestada la abstracción fue la adopción correcta; instalar la herramienta no lo fue.

Dos skills de diseño MIT, bien valoradas, para agentes de programación: una orientada al rediseño y la auditoría, con detección de “slop” en CI, y otra orientada a proyectos nuevos y páginas de marketing, con un sistema de gusto ajustable.

Por qué valía la pena revisarla: Ambas son realmente buenas en lo suyo, y una capa de diseño para un agente de programación con IA es una necesidad real cuando se publica mucha interfaz.

Por qué la descartamos: Ya operamos una pila de skills de diseño madura y canónica (un sistema de UI/UX propio, lineamientos de diseño por proyecto y una skill oficial de frontend-design). Instalar globalmente un cuarto y un quinto asistente de diseño significaría disparadores que se traslapan y chocan: justo la dispersión de skills que hace que un agente elija la herramienta equivocada. La cantidad correcta de skills de diseño globales para nosotros eran las que ya teníamos, no más.

Un modelo de pesos abiertos (open-weight) para programación agéntica con una ventana de contexto muy grande (1M de tokens), presentado como un retador económico para el enrutamiento del carril de programación.

Por qué valía la pena revisarla: Un modelo de programación barato y de contexto largo es una necesidad real para una suite de benchmarks; un retador nuevo en el carril de programación siempre vale una corrida.

Por qué la descartamos: Dos obstáculos, verificados y no supuestos. Primero, en realidad no era enrutable como se presentaba: no aparecía en la lista de modelos en vivo de nuestro proveedor de enrutamiento al momento de la evaluación, así que el paso de “agregarlo como retador del benchmark” no tenía endpoint al cual apuntar. Segundo, es un modelo alojado de origen chino, y nuestra regla de soberanía de datos le impide tocar cualquier dato de inquilinos, sin importar cómo califique en los benchmarks. Un modelo que no se puede enrutar y al que no se pueden confiar datos de clientes todavía no es un candidato; autoalojar los pesos es el único camino, y esa es una decisión distinta y más grande.