The problem is not another model
Two developers can use the same AI coding assistant on the same repository and still give it different context. One session has opened the relevant files. Another has found an architecture note. A third has not seen the schema change that explains the failing code. The model may be identical; the evidence supplied to it is not.
SocratiCode addresses that context layer. It indexes source code, combines exact and semantic search, builds file and symbol relationships, and can include material such as API specifications, database schemas, and architecture documents. The assistant remains the interface. SocratiCode gives it a more consistent way to find the relevant parts of the system.
What “shared context” means
A shared index is one searchable representation of a repository that several authorised users can query. It does not mean a shared editor session or a live copy of every developer’s uncommitted files.
For the open-source setup, teammates keep their own source checkouts but point SocratiCode at the same external Qdrant collection. A stable projectId identifies that collection. One designated checkout writes updates; reader checkouts query it.
Writer checkout → embeddings + metadata → shared Qdrant index
↑
Reader checkout A → SocratiCode search ───────┤
Reader checkout B → SocratiCode search ───────┘
That design makes ownership explicit. It also avoids several machines racing to rewrite the same collection.
The open-source operating pattern
Commit a stable identity at the repository root before creating the shared index:
{
"projectId": "team-service"
}
Every SocratiCode process that uses the collection must have the same Qdrant endpoint, embedding provider, model, dimensions, and indexed-representation settings. Supply any Qdrant API key through private host configuration, not through the committed project file.
Choose one checkout as the writer. It runs the first codebase_index and keeps the collection current through the watcher or deliberate codebase_update calls. Reader processes should set:
SOCRATICODE_WATCHER=off
SOCRATICODE_AUTO_RESUME=off
Readers should also work from the same source revision before treating a result as current code. A shared index cannot make two different checkouts equivalent.
What changes for the team
The useful change is repeatability. A question about authentication, an API boundary, or the callers of a function can start from the same indexed project identity instead of from whatever each person happened to open in one chat.
That does not remove engineering judgement. Search results still need to be opened and read. Graphs show recorded relationships; they do not prove runtime behaviour. Tests, configuration, deployment state, and the actual source remain authoritative.
Open source or Cloud beta
The open-source route is appropriate when the team is willing to operate Qdrant, control the writer process, align configuration, and coordinate source revisions. It is available to run directly and its operating assumptions are visible.
SocratiCode Cloud is a private beta. It is the route to discuss when the team wants a managed service rather than owning this operating pattern. Availability, deployment shape, and required controls are confirmed during onboarding. The beta label matters: do not treat a public description of a planned Cloud capability as proof that it is available in a particular environment.
Questions to settle before adoption
- Which repository identity will remain stable across developer checkouts and CI?
- Who owns the writer process and verifies that indexing completed?
- Which source revision does the shared index represent?
- Where do source chunks, embeddings, index metadata, prompts, and tool results travel?
- Which assistant hosts and user groups may query the index?
- Does the team want to operate this path, or evaluate the managed beta?
For repositories that form one larger system, continue with cross-repository context. For data handling, review source-code boundaries before indexing sensitive code.