Alright, I've hit this a few times now and wanted to compare notes. I'm deep in the weeds with A/B testing tools and CRO, so I'm used to giving clear, actionable feedback on what works and what doesn't. But with Claude Code, sometimes the suggestions are just... off.
How do you all structure your feedback when Claude proposes something that's inefficient, insecure, or just plain wrong? I want to be helpful, not just critical.
My usual approach is to treat it like a bug report or a test variant that underperformed:
* **Context is king:** I restate the original goal. "To clarify, we were trying to reduce the database calls here..."
* **Side-by-side comparison:** I love this for clarity. I'll show the suggested code snippet and then my proposed fix right next to it, explaining the *why*.
* **Focus on the principle:** Instead of just saying "this is bad," I explain the pitfall. "This approach can lead to XSS because..." or "This loop is O(n²) when we could do O(n) by..."
* **Offer an alternative path:** What *should* the next step have been? "A better direction might have been to use a map function here."
The tricky part is when the suggestion is syntactically correct but logically flawed for my use case. Do you find it's better to point out the flawed assumption, or just provide the corrected code?
What's your workflow? Have you found a feedback style that gets better, more tailored suggestions over time?
✌️
✌️
I'm a staff platform engineer at a mid-sized SaaS company (~500 people) handling financial data integrations, so our pipelines are a mix of Jenkins for legacy Java services and GitHub Actions for newer containerized microservices. We've been prodding various code assistants into our PR review process for about a year now.
You're basically asking how to debug the AI itself, which is correct. My method is less about feedback structure and more about treating Claude as a junior dev who needs very precise correction. Here's how I break it down:
1. **Correctness vs. Context Blindness**: When it's syntactically correct but wrong, it's usually missing project-specific constraints. Example: Claude suggested using `Math.random()` for a session ID in a security context. My feedback wasn't just "insecure," it was "Our compliance spec requires cryptographically secure random strings; here's the `crypto` module snippet we already use in three other files." Point to existing patterns.
2. **Performance Pitfalls Detection**: It loves to suggest readable but inefficient patterns. I've seen it propose double `.filter()` `.map()` chains on large arrays. Feedback must include hard numbers: "Our dataset here is ~10k items; this chained approach adds O(2n) overhead. A single `.reduce()` achieves the same, benchmarked at ~200ms faster in our test suite."
3. **Library / Framework Bias**: Claude sometimes assumes you're using the latest version of a library or a different one entirely. I'll lock feedback to our actual stack: "We're pinned to React 16.8 for this project; your suggestion uses `useEffect` cleanup patterns from React 18. This would break. Here's the equivalent with `componentWillUnmount`."
4. **Security Blind Spots**: This is the most dangerous. It once generated a "simple" SQL concatenation for a dynamic query. Feedback must be brutal and principle-based: "This creates a SQL injection vector. Never concatenate user input. Use the parameterized query pattern our `db.js` helper provides, as shown below." Include the exact code block fix.
My pick for feedback method is always the side-by-side code block with a one-line principle header. For example:
```
// Suggested - vulnerable to injection
const query = `SELECT * FROM users WHERE name = '${name}'`;
// Fixed - parameterized
const query = `SELECT * FROM users WHERE name = ?`;
db.run(query, [name]);
```
If your goal is to train the model over time, you need to be this explicit. If you just want to correct the immediate task, a simple "No, use X instead" is fine. Tell me whether you're feeding this back into a training loop or just getting a one-off fix, and I'll narrow it down.
Speed up your build