← Todos los benchmarks
May 2026
Angular · ThingsBoard
Patrones modernos de Angular que la búsqueda simple pierde. ThingsBoard es un codebase Angular grande con lazy routing, rutas anidadas, DI funcional vía inject() y patrones ResolveFn. Este benchmark prueba si un agente puede seguir cómo Angular conecta pantallas, servicios, rutas y dependencias — no solo buscar nombres de clases.
Ver en GitHub ↗Configuración del benchmark
Resumen de resultados
Claude Sonnet 4.6
1.75 / 25 (7%) → 21.00 / 25 (84%) +19.25 pts (+77 pp)
Tessra mejoró al modelo al anclar las respuestas en el wiring real de Angular: spreads de lazy routes, llamadas inject() funcionales, dependencias en ResolveFn y resolución de ruta a componente.
Claude Haiku 4.5
0.00 / 5 (case 05 only) → 3.375 / 5 +3.375 (+68 pp on case 05)
Resultados por caso
| Caso | Pregunta | Sin Tessra | Con Tessra | Δ |
|---|---|---|---|---|
| 01 | ¿Qué clases dependen de CalculatedFieldFormService vía inject()? | 0.00 / 5 | 5.00 / 5 | +5.00 |
| 02 | ¿Cómo inyecta sus dependencias AlarmRulesComponent? | 0.00 / 5 | 4.375 / 5 | +4.375 |
| 03 | ¿Qué componente renderiza la ruta /dashboards? | 0.875 / 5 | 4.125 / 5 | +3.25 |
| 04 | ¿Dónde se debe agregar una ruta hermana de /profiles/deviceProfiles? | 0.875 / 5 | 4.125 / 5 | +3.25 |
| 05 | ¿Qué callers usan AlarmRulesService — constructor o inject()? | 0.00 / 5 | 3.375 / 5 | +3.375 |
Hallazgos clave
Caller funcional dentro de ResolveFn — difícil de capturar con grep
El Caso 05 pregunta qué callers usan AlarmRulesService. El caller más difícil está dentro de una función anónima usada como ResolveFn — no en un constructor ni como una llamada inject() aislada. Una búsqueda simple de AlarmRulesService encuentra referencias obvias, pero es poco probable que clasifique correctamente este uso sin contexto Angular. Con Tessra, el agente identificó AlarmRulesTableConfigResolver, el método inyectado y lo clasificó correctamente como DI funcional.
// alarm-routing.module.ts
export const AlarmRulesTableConfigResolver: ResolveFn<AlarmRulesTableConfig> =
(route, state, alarmRulesService = inject(AlarmRulesService)) => { ... }
// ↑ not a constructor or class-level inject() — difficult to identify correctly with grep alone Las rutas con spread requerían un plan en dos pasos
El Caso 04 pregunta dónde agregar una ruta hermana de /profiles/deviceProfiles. Sin contexto, el modelo infirió que crear un nuevo módulo era suficiente. Con Tessra leyendo ProfilesRoutingModule, encontró el patrón de rutas con spread y dio el plan completo: crear el módulo de ruta y registrar el spread en profiles-routing.module.ts.
// profiles-routing.module.ts children: [ ...deviceProfilesRoutes, // from device-profile-routing.module.ts ...assetProfilesRoutes, // from asset-profile-routing.module.ts // ← new route module spread goes here ]
Trazado de ruta a componente entre lazy modules
Varios casos requieren seguir rutas Angular entre archivos, no buscar un solo componente. Tessra ayudó al agente a trazar definiciones de rutas, lazy modules, dependencias de resolvers y el componente final que renderiza la pantalla.
Limitaciones conocidas
Este benchmark mide navegación arquitectónica en el frontend Angular de ThingsBoard. Los casos están diseñados alrededor de patrones Angular 17+ como inject(), lazy routing, rutas anidadas y ResolveFn. Los resultados pueden variar en versiones de Angular anteriores a 15 o en proyectos que aún usan principalmente patrones pesados de NgModule. Los outputs de LLM no son determinísticos, por lo que los scores pueden variar entre ejecuciones.
Pruébalo tú
Mira qué expone Tessra en tu repo.
Indexa un repo Angular, Django o Flutter y prueba el contexto local durante 7 días.