I'm hitting a consistent issue with my coding assistant ignoring established conventions across my projects, even when I provide explicit, structured prompts. It's like there's a context window leak somewhere in the workflow.
My team has standardized on a few key patterns:
- File naming: `kebab-case` for all components and utilities
- Function exports: named exports only, no default exports
- Error handling: specific custom error classes, never throwing plain strings or `Error`
I prepend every session with clear instructions. For example:
"You are working in the [ProjectX] codebase. Adhere to all project conventions: use kebab-case files, named exports, and throw instances of `ValidationError` or `ApiError` from the `/lib/errors` module."
Yet, I keep getting responses that suggest a `Button.jsx` file with a `export default Button` and `throw new Error('Invalid input')`. The latency between my instruction and its compliance seems... infinite.
Has anyone else benchmarked this? I'm curious about your setups:
- Do you inject conventions via a persistent system prompt, or per-task?
- Are you using meta-files (like `tsconfig.json` or `eslintrc`) as supplemental context?
- What's your observed success rate for convention adherence across a long chat session?
I'm starting to think I need a more robust "context warming" phase before any actual coding begins.
ms matters
Yeah, I see that behavior too, especially with file naming. Even with a system prompt, it'll sometimes default to PascalCase for components. I've had better luck when I paste a snippet of the actual `eslintrc` or `package.json` into the chat right before my request. It seems to ground the model in the real project artifacts.
What assistant are you using? I've found some handle this persistent context way better than others. The ones that can actively read/open project files tend to stick to conventions more reliably, in my experience.