Developer Standards Platform
A 30-person polyglot team had no shared standards. Every engineer had their own interpretation of structure, documentation, and review. Onboarding was slow and deployments carried environment-specific surprises that traced back to no common baseline.
The fix started with input gathering, structured sessions across the team between October and December 2024, collecting how people actually worked before prescribing how they should. The result is a 10-section language-agnostic guidebook. Sections 1-7 cover principles that apply to any engineering team: coding conventions, documentation, testing, deployment, troubleshooting, dependency management, and security. Those seven are public at guidebook.atlancis.com. The remaining three sections contain internal operational context that has no reason to leave the network.
A guidebook on a website changes nothing if engineers only read it during onboarding. The enforcement layer puts the standards in the editor. When a developer saves a file in VSCode or PhpStorm, an extension backend sends the code through a LangChain pipeline. ChromaDB retrieves the relevant guidebook sections, they get assembled with the code into a structured prompt, Claude returns violations as JSON keyed to line numbers and rule IDs, and the extension renders them as native inline squiggles.
The pipeline started as a single RAG chain on the raw Anthropic SDK. When validation needed multiple review stages, that hit a ceiling. The switch to LangChain LCEL gave reliable chaining without managing the stages manually. Claude runs in closed-book mode. It can only flag violations for rules explicitly present in the retrieved chunk. Nothing inferred, nothing invented.
Pipeline
Prompt schema
The prompt enforces closed-book execution. A rule not present in the retrieved guidebook chunk cannot generate a violation.
<system>
You are an uncompromising code quality compiler. Your sole task
is to inspect incoming code for direct violations of the provided
Developer Guidebook sections.
CRITICAL INJUNCTIONS:
1. Only flag violations for rules explicitly defined inside
<guidebook_context>.
2. If the code does not violate any stated rule, return an empty
array. Do NOT invent standard language guidelines or personal
preferences.
3. Output strictly valid JSON matching the specified schema.
</system>
<guidebook_context>
{guidebook_context}
</guidebook_context>
<source_code>
{source_code}
</source_code>
<output_instructions>
Return a JSON object. If zero rules are broken, return
{"violations": []}.
{
"violations": [
{
"line_number": int,
"rule_id": "string (e.g., GUIDEBOOK_SEC_1.1_CODE FORMATTING)",
"severity": "warn" | "error" | "info",
"description": "Direct citation of the rule broken",
"suggested_fix": "Code snippet or precise modification step"
}
]
}
</output_instructions> Key decisions
| Decision | Chosen | Why |
|---|---|---|
| Documentation engine | MkDocs + Material | Static HTML through Nginx with gzip. No CMS, no database, rebuild on a shell script. |
| Public/private split | Sections 1–7 public | Principles in 1–7 apply anywhere. The rest is internal operational context. |
| AI orchestration | LangChain LCEL | Single RAG loop worked until validation needed multiple stages. LCEL gave deterministic chaining without manual stage management. |
| Vector store | ChromaDB | Embedded, no infrastructure overhead. The guidebook corpus does not need a distributed store. |
| Output format | Structured JSON via Pydantic | IDE extension maps violation objects directly to line numbers. No regex. |
| IDE targets | VSCode + PhpStorm | The two editors the team uses. |