Workflow: onboarding to a new codebase

You just joined a project. Or you're returning to one after months away. Or you inherited it from a contractor whose CONTRIBUTING.md is a single sentence and a winking emoji.

Without project context, the first session with an AI assistant looks like a polite version of "what does this project do?" answered by reading thirty files. With cix, it looks like a structured briefing that takes one query.

What it normally takes

A new contributor's first day usually involves:

Skimming the README to identify the stack.
Opening a few files at random to see what the code looks like.
Searching for "where does the app start" — usually wrong on the first guess.
Trying to figure out the testing convention by reading two existing tests.
Asking a senior engineer where the bodies are buried.
Realizing four hours later that there's a subdirectory you didn't know about.

This work is necessary. It is also massively repeatable. Every contributor does it for every project they touch. AI assistants do it for every session.

What it looks like with cix

The first turn returns:

The project's primary language, framework, and ORM.
A list of entry points — where the application actually starts running.
A summary of HTTP routes, with samples.
The major directories, ranked by where the substance lives.
A list of database tables with column information.
A list of the most-imported and most-referenced symbols (the load-bearing parts of the system).
A note on what wasn't parsed and why.

This is not a generated essay. It is structured data, built from the actual code, with locations attached. The assistant uses it to ground every subsequent question.

A walkthrough

You're added to an existing repo. You open it in your editor and start a session with your AI assistant. Your first prompt is something like:

Help me understand this project. I'll be adding a new endpoint for exporting orders.

Without cix, the assistant reads the README, the package.json, the main entry file, the routes folder, and three or four representative files. It makes some inferences. It might miss key conventions. The session burns ten minutes and a few thousand tokens before any real work happens.

With cix, the assistant runs orientation first. In a single response, it has:

The framework (say, Laravel).
The entry points (the API and admin route files).
The existing route table (so it knows exporting endpoints would naturally land in the API tree).
The schema (so it knows the orders table exists, with columns id, customer_id, status, total, placed_at).
The pattern conventions (controllers in app/Http/Controllers, requests in app/Http/Requests).

The assistant's first message back to you is grounded. It can ask the right follow-up questions — "should this be CSV or JSON?" — instead of "what's the framework?"

The session that started with an orientation query produces useful work in the first three turns. The session without it spends those three turns on discovery.

What you get out of it personally

Faster ramp-up on inherited projects. The first session is productive, not a tour.
Less context-switching cost when returning to old projects. You don't have to re-discover what you already knew.
Better behavior in the assistant from the start. Grounded first turns lead to grounded later turns.

What the team gets out of it

Consistent onboarding. Every developer's first session looks the same: orient, then work. There is no "ramp-up tax" that varies by individual.
Less load on senior engineers. The questions juniors used to ask seniors ("where are routes registered?", "what's the test convention?") are answerable by the index.
A shared mental model of the project. When everyone's assistant orients the same way, conversations about the project happen against the same facts.

The boundary

Orientation is about structure, not intent. It can tell you where the routes are; it cannot tell you why this team chose to split admin and public APIs three years ago. It can tell you the schema; it cannot tell you why the orders table has both total and total_cents (somebody is going to clean that up someday).

For the why, you still want the senior engineer or the design doc. For the what — orientation handles it.

Project orientation feature — the underlying capability this workflow relies on.
For solo developers — onboarding to your own old projects counts too.
Workflow: feature add — the natural next step after orientation.