← All benchmarks
May 2026
Angular · ThingsBoard
Modern Angular patterns that plain search misses. ThingsBoard is a large Angular codebase with lazy routing, nested routes, functional DI via inject(), and ResolveFn patterns. This benchmark tests whether an agent can follow how Angular actually wires screens, services, routes, and dependencies — not just search for class names.
View on GitHub ↗Benchmark setup
Results summary
Claude Sonnet 4.6
1.75 / 25 (7%) → 21.00 / 25 (84%) +19.25 pts (+77 pp)
Tessra improved the model by grounding answers in Angular's actual wiring: lazy route spreads, functional inject() calls, ResolveFn dependencies, and route-to-component resolution.
Claude Haiku 4.5
0.00 / 5 (case 05 only) → 3.375 / 5 +3.375 (+68 pp on case 05)
Results per case
| Case | Question | Without Tessra | With Tessra | Δ |
|---|---|---|---|---|
| 01 | Which classes depend on CalculatedFieldFormService via inject()? | 0.00 / 5 | 5.00 / 5 | +5.00 |
| 02 | How does AlarmRulesComponent inject its dependencies? | 0.00 / 5 | 4.375 / 5 | +4.375 |
| 03 | Which component renders the /dashboards route? | 0.875 / 5 | 4.125 / 5 | +3.25 |
| 04 | Where should a sibling route to /profiles/deviceProfiles be added? | 0.875 / 5 | 4.125 / 5 | +3.25 |
| 05 | Which callers use AlarmRulesService — constructor or inject()? | 0.00 / 5 | 3.375 / 5 | +3.375 |
Key findings
Functional caller inside ResolveFn — hard to catch with grep
Case 05 asks which callers use AlarmRulesService. The hardest caller is inside an anonymous function used as a ResolveFn — not in a constructor and not as a standalone inject() call. A plain search for AlarmRulesService finds the obvious references, but it is unlikely to classify this usage correctly without Angular context. With Tessra, the agent identified AlarmRulesTableConfigResolver, the injected method, and classified it correctly as functional DI.
// 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 Spread routes required a two-step routing plan
Case 04 asks where to add a sibling route to /profiles/deviceProfiles. Without context, the model inferred that creating a new module was enough. With Tessra reading ProfilesRoutingModule, it found the spread-route pattern and produced the complete plan: create the route module and register the spread in 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 ]
Route-to-component tracing across lazy modules
Several cases require following Angular routing across files rather than searching for a single component. Tessra helped the agent trace route definitions, lazy modules, resolver dependencies, and the final component that renders a screen.
Known limitations
This benchmark measures architectural navigation on the ThingsBoard Angular frontend. Cases are designed around Angular 17+ patterns such as inject(), lazy routing, nested routes, and ResolveFn. Results may differ on Angular versions below 15 or on projects that still use mostly NgModule-heavy patterns. LLM outputs are non-deterministic, so scores may vary across runs.
Try it yourself
See what Tessra surfaces in your repo.
Index an Angular, Django, or Flutter repo and try local context for 7 days.