Case study: Apache Airflow

Airflow is one of the most demanding projects in the 25-repo benchmark. It is a Python monorepo with:

A FastAPI core API (the public REST surface).
A separate FastAPI execution API (used by workers).
A React/TypeScript UI bundled in.
One hundred-plus provider packages, each with its own configuration, migrations, and routes.
Seventy-four indexed database tables.
Two hundred-plus indexed HTTP routes.
A multi-process runtime (scheduler, DAG processor, triggerer, API server, workers).

It is the kind of project where naive AI-assisted exploration burns hundreds of file reads before producing any useful output. We ran cix against it to see how the system behaves at the upper end of complexity.

Result: 13/15 on the standard rubric, with all five dimensions answerable from cix queries alone — no fallback to file reading required.

What cix saw

A single orientation query, run cold against the current state of the repo, returned:

Stack: Python with FastAPI, Alembic for migrations, SQLAlchemy ORM. Frontend is React/TypeScript bundled into the API server.
Five entry points, all correctly classified as runtime bootstrap, with file/line locations.
209 HTTP routes across three families: public REST, UI-specific endpoints, and the short-lived JWT-scoped execution API.
74 database tables spanning the core scheduler set, the asset/dataset graph, the FAB role/user tables, and the edge-worker tables.
The architecture story: layered service-based monolith with explicit process boundaries — scheduler reads serialized DAGs only, workers communicate with the metadata DB only via the Execution API, providers are independent distributions with their own packaging.

This is the answer that, without an index, would take an experienced engineer twenty to forty file reads to assemble.

What cix surfaced that grep wouldn't

The execution API as a separate FastAPI app. Airflow mounts two FastAPI apps side-by-side: the core public API and the execution API used by workers. The orientation step recognized both as runtime entry points and classified them correctly, including the architectural reason for the split.

The provider plugin surface. Each provider package has its own configuration, migrations, and routes. cix surfaced the full provider directory structure as part of the top-directories view, with the major providers visible at a glance.

Asset/dataset graph schema. Airflow's data-aware scheduling layer introduces a constellation of tables — asset_active, asset_partition_dag_run, asset_trigger, asset_watcher, dataset*, dag_schedule_*_reference, task_*_reference. The schema view returned all of them with column information.

Multi-tree migration awareness. Migrations live in three places: core, FAB provider, and edge3 provider. The schema view consolidated all three into a single response.

Where cix was honest about its limits

Schema confidence flagged as partial. The system explicitly said "schema confidence: partial; some columns missing" and pointed at specific tables (dag, dag_run, a few others) where the migration parser had picked up a mutation rather than a creation. The recommended fallback — query the ORM model directly for a column-complete view — was suggested by name.

Test-fixture routes leaked through. A handful of test-only HTTP routes (mock setups in provider test files) appeared in the route list alongside production routes. cix has no native "test fixture" classifier today. This is a known limitation.

Suspicious-credential heuristic produced one noisy positive. A password= literal in a known-default Airflow utility was flagged as a hardcoded credential. It isn't, in this case — it's a public default — but the heuristic correctly errs on the side of flagging.

13 CSS files reported as unsupported. No CSS parser today. The system flagged the unsupported files explicitly with a recommendation to grep them if needed.

The honesty of these signals is what made the benchmark score meaningful. cix did not claim to fully understand Airflow. It claimed to understand the parts it could parse, listed the parts it couldn't, and let the user act accordingly.

What this means for an Airflow contributor

If you're a developer working on Airflow with cix in the loop:

The first turn of any session orients the assistant correctly. No more "what framework is this" guesses.
Adding an endpoint to the core API is grounded — the assistant can see the existing 209 routes, the entity schemas, and the request-response patterns.
Modifying a model is grounded — the schema view tells the assistant what columns exist, and impact analysis tells it what migrations and tests reference them.
Provider work is grounded — each provider is identifiable as its own distribution, with its own conventions.

The combination is meaningful. Airflow is large enough that even experienced contributors lose context regularly; an indexed assistant that can answer structural questions in a single query is a real productivity gain.

Methodology

Run mode: cix-only. No fallback to file reading or grep.
State: clean repo, fresh index built from main branch.
Time to fully indexed: a few minutes (large repo).
Tools used: orientation, route listing, schema view, entry-point listing, file outline, dependency analysis, file listing.
Score: 13/15 — the deductions came from partial schema column coverage on a handful of tables and the test-fixture noise in the route list.

What this case shows

Scale is not the problem. A well-structured large project remains tractable for cix.
Multi-component systems benefit most. The complexity in Airflow comes from the interaction of components — scheduler, DAG processor, API, workers. The orientation step compresses that into something understandable in seconds.
Honest partial coverage is workable. A schema view that's 90% complete with explicit gaps is dramatically more useful than one that's 100% confident and 10% wrong.

25-repo benchmark — full benchmark including this project.
Schema awareness — the feature most-used in this case.
Project orientation — the entry point for any large-codebase workflow.