How it works
A foundation for building with AI.
cix brings project knowledge, working rules and tools with defined jobs into one environment. Your AI has a way to understand the code, investigate a change, record your decisions and check what it builds.
You work with it in the cix app, using the AI you choose. The foundation supplies the method and the records behind the work; the model brings its reasoning and coding ability. You set the direction and decide what goes ahead.
Ground the work
Start with the project you actually have.
A request rarely describes everything a change touches. The AI needs to find the existing behaviour, see where it is used, and understand the conventions the project already follows.
cix’s code tools help it look up definitions and their uses. Research gives those findings a durable home, alongside constraints, unanswered questions and approaches that did not work.
That gives the design something to build on: what can be reused, what needs changing, and what still needs an answer.
Each tool has a job. Its output feeds the work.
The method connects exploration, decisions, implementation and evidence. Each part holds a different kind of information, so an idea, an agreed requirement and a passing check do not get treated as the same thing.
Idea Builder makes the idea inspectable.
Map a flow, a structure or a set of requirements as cards. See branches and missing outcomes, then decide what to keep, cut or leave for later. The chart gives exploration a shape you can question before committing to the work. Ask for a database diagram and cix draws your project’s tables and columns, from what it already knows about your code or from a read-only query you run in your own database tool.
Research separates findings from guesses.
Keep observations, sources, hypotheses, unanswered questions and dead ends together. Investigate the existing code and its constraints. The design can refer to that evidence, and a later conversation can pick up the investigation without relying only on a chat summary.
Design settles what the change must do.
Define behaviour, boundaries, failure cases and how success will be checked. Record the decisions and unresolved questions. This is where a vague request becomes something specific enough to build—and where you can change direction before implementation.
The plan makes the work traceable.
Break the design into ordered steps, with dependencies and checks. Keep progress, blockers and follow-ups with the work. A completed step can point to what was changed and the evidence used to check it.
Building and checking use that foundation.
The AI works from the agreed scope and project conventions, using the code and execution tools available to your chosen engine. Checks compare the result with the requirements. Failures and unverified cases remain part of the record, rather than being hidden behind “done”.
The amount of investigation and planning should fit the change. Existing evidence can be reused; a new uncertainty needs an answer. The point is to give each piece of work the support it needs.
A real example from building cix
An off switch has to work before the first report.
The request was a Settings control for problem reports. The useful detail was where that choice had to take effect: reporting ran when the app started, so displaying a switch was only part of the change.
What the investigation established
Reporting ran whenever someone was signed in, with no setting to turn it off. That put both Settings and the reporting startup path in the scope of the feature.
What the work recorded
The design chose on by default, with an off switch. The plan included saving that choice. The implementation reads it at startup, before reports are sent.
The connection matters: the visible control, the saved value and the startup behaviour all have to agree.
What the checks covered
- No setting saved yet
- Reports on · passed
- Settings file damaged
- Reports off · passed
- Saving the choice fails
- Previous value kept · passed
The saved record shows which behaviours were checked. These results cover the cases listed, not every possible failure.
Paraphrased from this feature’s research, design, plan and test records in cix. This is an explanation of the work, not a recording of it being built inside the app.
A foundation you can return to
Keep the reasoning with the result.
When you return to a feature, the important questions are still there: why was this approach chosen, what has been finished, what failed, and what remains uncertain? Saved records give you and the AI a place to look for those answers.
That is the consistency cix is designed to provide: a shared method, project rules and inspectable work. Models still differ in their reasoning, behaviour and available capabilities.
Saved research, designs, plans and Idea Builder are included on paid plans. What each AI can read or update differs today. See what each AI choice gets.
What you stay in charge of
The choices
Keep, cut or later on each idea card, and the decisions in a design, are yours.
What runs
Commands and file edits wait for your OK, unless you turn on full access.
Which AI
Pick the AI for each conversation. What each AI choice gets