Workflow: adding a feature

Most AI-assisted coding is feature work. Add an endpoint. Add a model field. Add a UI component that lists the new thing. Add the test that covers it. This is bread-and-butter work, and it's where the difference between a context-aware assistant and a context-free one shows up most clearly.

This page walks through what feature development looks like with cix in the loop.

The shape of the work

Adding a feature in a real codebase usually involves:

Understanding the existing structure for similar things.
Checking what helpers, components, or models already exist.
Writing the new pieces.
Connecting them — registering the route, importing the component, hooking up the test.
Verifying that nothing else broke.

Without an index, an assistant typically does steps 1 and 2 by reading files (often the wrong ones) and step 5 hardly at all. With cix, each step has a structured query backing it.

A concrete example

Take a real request: "Add a CSV export endpoint for orders, accessible to admins."

Step 1: Orient

The assistant runs the orientation query. It learns:

The project is Laravel + Vue.
API routes are registered in routes/api.php.
The admin namespace is under routes/admin.php.
The orders table has columns id, customer_id, status, total, placed_at.
Existing controllers live in app/Http/Controllers.

This is one query. Without it, the assistant would need to read the routes file, the configuration, several controllers, and a migration to assemble the same picture.

Step 2: Search for existing parts

The assistant queries: "is there an existing CSV export utility?" The index returns a hit — app/Services/CsvExporter.php — that already handles streaming responses for large datasets. The assistant uses it instead of writing a new one.

Step 3: Search for related controllers

The assistant queries: "is there an OrdersController already?" There is. The new endpoint will be a method on that controller, not a new file.

Step 4: Validate placement

Before writing anything new, the assistant validates that any new files will land in the right place. The convention check confirms: requests go in app/Http/Requests, the test goes in tests/Feature. No new file is created until the path passes the check.

Step 5: Write the code

The assistant adds:

A new method on OrdersController that uses the existing CsvExporter.
A request class for input validation.
A route registration in the admin namespace.
A feature test.

Each new file has a known-good location. Each piece of code reuses an existing utility instead of inventing one.

Step 6: Verify

After writing, the assistant runs an impact check on the controller it modified. It confirms no test or other handler relied on the old method shape. Nothing downstream broke.

The whole sequence took roughly six structured queries and a handful of edits. Without cix, the same work would have involved reading twenty files and would still have left questions unanswered.

Why this shape works

Each step is small, structured, and verifiable. The assistant is not making big inferential leaps. It is asking targeted questions, getting structured answers, and using them to decide the next action.

This matters for two reasons:

Quality. Each decision is grounded in real project state. The assistant is not guessing about whether a helper exists, where files belong, or what the schema looks like. It knows.

Cost. Each query is cheap. Reading twenty files is not. The structured-query workflow uses dramatically fewer tokens for the same result. Multiplied across a team, this is real money.

What the developer experiences

You still drive the conversation. The assistant just stops asking you questions whose answers it should have looked up — and stops making decisions whose consequences it should have checked.

The session feels like working with a more careful collaborator. Less "I'll write something and we'll see," more "let me check what's there first."

Where the workflow falls down

When the index is stale. If you made changes outside the assistant and haven't re-indexed, the queries return outdated answers. The system does try to keep the index fresh automatically, but a manual refresh is occasionally needed.
When the project uses something the parser doesn't know. A custom routing layer, an exotic ORM, a templating language without a tree-sitter — the queries return fewer results, and the assistant has to fall back to reading.
When you're the one introducing the convention. If your project has no established pattern for the kind of feature you're adding, the assistant has nothing to anchor to. You'll need to make a judgment call and tell it.

Find before you build — the core feature this workflow leans on.
Convention enforcement — what stops new files from landing in the wrong place.
Workflow: refactoring — the next-most-common workflow.