Skip to content
Notifications
Clear all

Walkthrough: Teaching Cline our internal API naming conventions.

4 Posts
4 Users
0 Reactions
0 Views
(@charliep)
Reputable Member
Joined: 1 week ago
Posts: 172
Topic starter   [#8138]

Tried to get Cline to stop suggesting camelCase for our internal API endpoints. It's a snake_case shop. Has been for a decade.

The process felt like arguing with a particularly stubborn new hire who read one blog post. Had to correct it on every single function signature. "generateUserProfile" no. "generate_user_profile" yes. Rinse and repeat for two hours. The "learning" seems to reset if you switch contexts. So much for AI adaptability.

Ended up crafting a painfully explicit system prompt that lists our conventions like a legal document. It helps, but you'd think a tool that reads the whole codebase could infer this from, you know, the entire codebase. The vendor hype about "understanding your style" is a bit rich.

¯_(ツ)_/¯


Your stack is too complicated.


   
Quote
(@bookworm42)
Estimable Member
Joined: 1 week ago
Posts: 88
 

Your experience with the system prompt is the real takeaway. We've found the same thing. The "legal document" approach, as you put it, is currently the only reliable method.

These tools don't infer style from the codebase because they're not built to retain that as persistent context. They're reacting to your immediate prompt plus a slice of files. Expecting them to grok a decade of snake_case from scattered examples is like expecting a compiler to read your project docs.

The vendor hype is about capability, not out-of-the-box understanding. You still have to do the configuration, which they conveniently gloss over. Your two-hour argument was the configuration process. Annoying, but standard for any new tool that needs to align with entrenched conventions.



   
ReplyQuote
(@elliek2)
Estimable Member
Joined: 1 week ago
Posts: 98
 

That's a really good point about it being a configuration process, not a learning one. I hadn't thought of it that way. It's frustrating that they market it as "understanding" when you actually have to feed it the rulebook.

So is the "legal document" prompt something you just paste in at the start of every chat? Or can you set it up somewhere permanently? I'm still figuring out where the line is between a chat and a project setting.



   
ReplyQuote
(@julie)
Trusted Member
Joined: 1 week ago
Posts: 29
 

Yeah, that "understanding" marketing really gets under my skin. It makes you feel like you're doing something wrong when you have to spell everything out.

On your question about where to put the rulebook - I've been digging into this too. Some of these tools let you set a custom instructions file at the project level, like a .clinerules or something similar. But honestly I'm still figuring out whether Cline actually picks that up consistently or if you still need to paste it in every new chat. I've seen people mention a "project knowledge" setting but I haven't found the sweet spot yet. Have you tried creating a rules file in your project root? I'm curious if that worked for anyone here or if it's just another thing that looks good in the docs but falls apart in practice 😅



   
ReplyQuote