Skip to content

Examples

Situations you will recognise.

Six things that happen to a codebase during AI-assisted work, and what Little Owl actually prints when they do.

“Your component reached 2,000 lines”

Three assistant passes each added a section to the same file. No single diff looked alarming.

little-owl check --details
🟡 complexity  <CheckoutPage> is 2,014 lines
   src/app/checkout/page.tsx:18

   The CheckoutPage component is 2,014 lines, past the 800-line budget.
   Components this size usually mix data fetching, state and presentation.

   → Extract the sub-sections into their own components, and move data
     logic into hooks.

Note. Components get their own budget, separate from plain functions, because they are legitimately longer.

“Your feature bypasses the architecture boundary”

A UI file started importing the database client directly, skipping the service layer entirely.

little-owl architecture
🔴 architecture  ui imports infrastructure directly
   src/components/Orders.tsx:4

   src/components/Orders.tsx imports src/lib/db/client.ts, skipping the
   application layer. The structure detected in this project is
   ui -> application -> infrastructure.

   found:    ui -> infrastructure
   expected: ui -> application -> infrastructure

   → Route the call through application instead of importing
     infrastructure from here.

Note. If Little Owl inferred your layers rather than reading them from config, it says so in the output.

“A dependency is no longer used”

A refactor removed the last import of a package, but the package stayed in package.json.

little-owl dependencies
14 declared   11 imported

ℹ Declared but never imported (may be used via config or at runtime)

  date-fns
  lodash

3 packages (type definitions, linters, build tooling) do their job
without being imported and are not counted above.

Note. Build tooling is filtered out automatically. What is left is short enough to actually check.

“A change affects 17 modules”

You are about to edit a shared auth helper and want to know what it reaches before you start.

little-owl impact src/lib/auth/session.ts
Potentially affected

  HIGH  (6 files)
    src/app/login/page.tsx
    src/components/panel/AdminGate.tsx
    ... and 4 more

  MEDIUM  (11 files)

Routes
  /login    src/app/login/page.tsx
  /panel    src/app/(app)/panel/layout.tsx

Risk: high    Confidence: medium
Some dynamic imports could not be resolved, so more files may be
affected than listed.

Note. Risk is about reach, not correctness. A trivial change to a widely-imported module is still a wide change.

“Your codebase accumulated new complexity”

Nothing broke. The scores just moved, and you want to know exactly what moved them.

little-owl review
12 files changed (uncommitted changes vs HEAD)
+486 -73 lines   across 3 areas

✗ DEGRADED

Architecture     91 →  84 ↓
Complexity       84 →  71 ↓
Overall          89 →  83 ↓

Since the baseline: +1 circular dependency, +2 skipped-layer imports,
+3 over-complex functions

Note. Every point of movement resolves to a count. There is no score you cannot explain.

“An assistant duplicated an existing helper”

The helper already existed two directories away. The assistant could not see it, so it wrote another one.

little-owl check
🟡 maintainability  formatCurrency() is implemented in 3 places
   src/lib/format.ts

   3 files each define and export their own `formatCurrency`. When the
   same helper exists more than once, a fix applied to one copy silently
   leaves the others behind.

   src/lib/format.ts
   src/components/cart/price.ts
   src/features/billing/money.ts

   → Keep one implementation of `formatCurrency` and import it, or give
     the variants names that say how they differ.

Note. This describes a structural pattern. It says nothing about who or what wrote the code — and Little Owl never claims to know.

Found something it got wrong?

False positives are the thing that kills a tool like this. There is an issue template specifically for them, and they are treated as bugs.

How false positives are handled