<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Claude Code Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/aitr-claude-code/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Sat, 14 Nov 2026 21:41:25 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Step-by-step: Integrating Claude Code reviews into our GitHub Actions.</title>
                        <link>https://communities.stackinsight.net/community/aitr-claude-code/step-by-step-integrating-claude-code-reviews-into-our-github-actions-2/</link>
                        <pubDate>Mon, 28 Sep 2026 18:06:09 +0000</pubDate>
                        <description><![CDATA[We&#039;ve been running a lightweight FinOps script review process for months, but it was manual: someone had to remember to run a Claude Code review on pull requests for our AWS cost anomaly det...]]></description>
                        <content:encoded><![CDATA[We've been running a lightweight FinOps script review process for months, but it was manual: someone had to remember to run a Claude Code review on pull requests for our AWS cost anomaly detection scripts. I wanted to bake it directly into our GitHub Actions workflow to make it consistent and automatic.

The goal was to trigger a Claude Code review on every PR that modifies scripts in our `finops-scripts/` directory. I didn't want a generic "review all code" setup—just targeted analysis on our cost tooling. Here's the core workflow file I landed on after some trial and error.

```yaml
name: FinOps Script Review
on:
  pull_request:
    paths:
      - 'finops-scripts/**'

jobs:
  claude-code-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run Claude Code Review
        uses: Anthropic-Devs/claude-code-review-action@v1
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          review_instruction: |
            Please review this FinOps script with a focus on:
            * Cost optimization logic (e.g., Reserved Instance calculations, spot interruption handling)
            * Error handling for AWS/Azure API calls
            * Potential billing data misinterpretations
            * Suggestions for improving runtime efficiency (these scripts run hourly)
```

A few key configuration points I found necessary:
* The `paths:` filter is crucial to avoid running reviews on every PR, which keeps costs predictable.
* The custom `review_instruction` steers Claude toward our specific FinOps concerns, not just general code quality.
* Storing the `ANTHROPIC_API_KEY` as a repository secret is straightforward, but remember to monitor its usage in your Anthropic account.

The main benefit has been catching subtle bugs early—like an off-by-one error in a monthly cost projection script that Claude flagged. The reviews are posted directly as PR comments, which keeps the feedback in the development loop.

Has anyone else integrated Claude Code into their CI/CD for specific domains like this? I'm particularly curious about:
* How you're handling the cost of the API calls in a high-volume repo.
* Whether you've set up different review instructions for different script types (e.g., budget alerts vs. resource cleanup).]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-claude-code/">Claude Code Reviews</category>                        <dc:creator>finops_tracker_99</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-claude-code/step-by-step-integrating-claude-code-reviews-into-our-github-actions-2/</guid>
                    </item>
				                    <item>
                        <title>Does Claude Code actually speed up my React refactors? My timings vs. solo coding.</title>
                        <link>https://communities.stackinsight.net/community/aitr-claude-code/does-claude-code-actually-speed-up-my-react-refactors-my-timings-vs-solo-coding-2/</link>
                        <pubDate>Sun, 27 Sep 2026 07:51:32 +0000</pubDate>
                        <description><![CDATA[I&#039;ve spent the last two weeks putting Claude Code through its paces on a specific, tedious class of React work: refactoring a legacy, prop-drilled mess of a component tree into a cleaner con...]]></description>
                        <content:encoded><![CDATA[I've spent the last two weeks putting Claude Code through its paces on a specific, tedious class of React work: refactoring a legacy, prop-drilled mess of a component tree into a cleaner context/provider pattern, and then later, incrementally migrating that context to TypeScript. The project is a real internal admin dashboard, about 50 components deep, originally written in the "get it done" style of 2019. My goal was to measure the actual time saving, if any, against my known solo-coding velocity. The results were... interesting, but not in the way the marketing hype might suggest.

My methodology was simple. I picked five distinct refactor tasks:
*   Extracting a deeply nested user preferences object (8 levels of drilling) into a React Context.
*   Converting three interconnected class components with shared life-cycle logic to functional components with custom hooks.
*   Taking a sprawling, 400-line component that mixed data fetching, form logic, and presentation and splitting it into a container/presenter pattern.
*   Adding comprehensive TypeScript interfaces to the newly created context and its provider.
*   Refactoring a set of useEffect-heavy components to use a proper data-fetching library (TanStack Query).

For each, I timed myself doing it the old-fashioned way (me, my IDE, and my own brain). I then reset the git branch and did the same task with Claude Code in the editor, prompting it to do the work and then reviewing/guiding its output. I logged both "active" time (me typing or prompting) and "total clock" time (including thinking, reading docs, or waiting for Claude).

Here's the raw data, because everyone loves a table:

| Task | Solo Time (Active) | Solo Time (Total) | Claude Time (Active) | Claude Time (Total) | Notes |
| :--- | :--- | :--- | :--- | :--- | :--- |
| Create Context from Prop Drilling | 45 min | 75 min | 20 min | **110 min** | Claude's first pass missed 2 consumer components. Debugging its omission took longer. |
| Class to Functional + Hooks | 90 min | 120 min | 30 min | 60 min | Clear win for Claude. This is its sweet spot: syntactic translation. |
| Component Splitting | 60 min | 90 min | 25 min | **100 min** | Its architectural suggestions were naive. I spent more time arguing with it via prompts than just doing it. |
| Add TypeScript Interfaces | 40 min | 50 min | 10 min | 30 min | Good for boilerplate generation, but required heavy editing for strictness. |
| Refactor to TanStack Query | 120 min | 180 min | 40 min | **150 min** | It introduced subtle cache invalidation bugs I had to find later. "Total" time includes bug-fix phase. |

The takeaway isn't that it's universally faster. It's that it **shifts the time expenditure**. My "active" or "typing" time dropped dramatically, often by 50-70%. That's not nothing—it saves wrist strain and pure boredom. However, my "total clock" time sometimes *increased*, because I traded typing for code review, prompt engineering, and debugging *its* understanding of the codebase's nuances.

Where it genuinely excelled was the mechanical, syntactic grunt work. Turning a class component into a function? Flawless. Generating the boilerplate for a Context provider? Instant. Where it fell apart was any refactor requiring deeper architectural intuition. For example, when splitting that large component, its first suggestion was this:

```jsx
// Claude's naive proposal - just slicing the file arbitrarily
const ContainerComponent = () =&gt; {
  // all the logic, state, effects
  return ;
};

const PresentationalComponent = ({ data, handlers }) =&gt; {
  // all the JSX, still 350 lines long
  return (/* massive blob */);
};
```

I had to spend three iterative prompts to guide it toward a more logical separation based on distinct feature domains (user panel, data grid, report form). It didn't "see" the natural seams in the code. A human architect would have spotted them immediately.

So, does it speed up React refactors? The answer is: **it depends on the cognitive load of the task.**

*   **For low-cognitive, high-typing tasks:** Yes, significantly. It's like a turbocharged autocomplete that understands React. You save real hours.
*   **For high-cognitive, architectural tasks:** No, it can actually slow you down. You become a manager explaining the problem to a very fast but junior developer who lacks context. The time you save not typing is spent on meticulous specification and vigilant review.

The tool hasn't replaced the need for a clear architectural vision in your head. In fact, it demands that vision be *more* explicit so you can articulate it in prompts. If you're the type who thinks through the keyboard, it might disrupt your flow. If you can clearly specify what you want and are willing to audit the output, it can handle the tedious parts. For now, I'm using it as a specialized power tool for the boring bits, and keeping the actual system design firmly under my own control.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-claude-code/">Claude Code Reviews</category>                        <dc:creator>infra_architect_rebel_alt</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-claude-code/does-claude-code-actually-speed-up-my-react-refactors-my-timings-vs-solo-coding-2/</guid>
                    </item>
				                    <item>
                        <title>Has anyone benchmarked Claude Code&#039;s latency across different file sizes?</title>
                        <link>https://communities.stackinsight.net/community/aitr-claude-code/has-anyone-benchmarked-claude-codes-latency-across-different-file-sizes-2/</link>
                        <pubDate>Sun, 27 Sep 2026 03:50:52 +0000</pubDate>
                        <description><![CDATA[Hey everyone! I was setting up a new workflow for some marketing automation scripts and found myself wondering about the practical performance of Claude Code. I&#039;m working with a mix of small...]]></description>
                        <content:encoded><![CDATA[Hey everyone! I was setting up a new workflow for some marketing automation scripts and found myself wondering about the practical performance of Claude Code. I'm working with a mix of small config files (a few KB) and some larger, aggregated customer data exports (think 5-10 MB JSON files).

**Has anyone done systematic testing on how response latency scales with input file size?**

I'm particularly curious about:
*   Is there a noticeable "tipping point" where latency starts to increase more sharply?
*   Does the type of task (e.g., refactoring vs. adding comments vs. generating new code) affect the latency differently as files grow?
*   Any noticeable differences between the various Claude Code model sizes (if you've had a chance to try more than one)?

In my own casual testing, small scripts under 100 lines feel nearly instantaneous. But when I pasted a 1500-line Python module for analysis, there was a definite pause. I'd love to pool our observations to get a better community understanding. If you've run any tests, what was your method? Did you time just the initial response, or the full token stream?

This kind of benchmarking would be super helpful for planning how to chunk large projects or when deciding whether to use the tool for real-time editing versus more batch-style analysis.

Cheers!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-claude-code/">Claude Code Reviews</category>                        <dc:creator>Emma Jennings</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-claude-code/has-anyone-benchmarked-claude-codes-latency-across-different-file-sizes-2/</guid>
                    </item>
				                    <item>
                        <title>What is the best way to train Claude on our internal codebase patterns?</title>
                        <link>https://communities.stackinsight.net/community/aitr-claude-code/what-is-the-best-way-to-train-claude-on-our-internal-codebase-patterns-3/</link>
                        <pubDate>Sat, 26 Sep 2026 20:01:23 +0000</pubDate>
                        <description><![CDATA[Hey everyone! &#x1f44b; I&#039;ve been deep in the trenches lately trying to get Claude (specifically Claude 3.5 Sonnet via the API) to truly understand our team&#039;s internal coding patterns and co...]]></description>
                        <content:encoded><![CDATA[Hey everyone! &#x1f44b; I've been deep in the trenches lately trying to get Claude (specifically Claude 3.5 Sonnet via the API) to truly understand our team's internal coding patterns and conventions. We have a sprawling, legacy codebase with some... let's call them "unique" architectural decisions and naming schemes that are second nature to us but utterly alien to a fresh LLM context.

I've experimented with a few approaches over the last month, with mixed results, and I'd love to compare notes. My primary goal is to have Claude generate meaningful pull requests, refactor suggestions, and new feature code that *feels* like it was written by our team, without me having to rewrite half of its output.

Here's what I've tried so far:

**Method 1: The Massive System Prompt**
I stuffed our entire "Engineering Handbook" (a 15-page Notion doc with rules, patterns, and examples) into the system prompt. While Claude could reference it, the context window felt clogged, and it sometimes struggled to prioritize which rules applied to a given task. Performance on specific coding tasks was slower and more expensive.

**Method 2: Pre-processing with RAG (Retrieval-Augmented Generation)**
I built a simple pipeline using LangChain to chunk and embed our key repositories (focusing on our core service directories). When a coding task comes in, it first searches for the most semantically similar code snippets and prepends them as examples.
*Pros:* The code suggestions became much more structurally aligned with our patterns.
*Cons:* It added complexity, and sometimes the retrieved examples were outdated or from deprecated patterns. Tuning the "number of examples" was tricky.

**Method 3: Fine-tuning on a Dataset of Our Code**
This was the most involved. I created a dataset of several hundred "ideal" code snippets from our repos, formatted as instruction/response pairs (e.g., "Implement a new repository class for the User model" paired with the actual, approved code we'd write).
*Pros:* The model's *style* became uncannily accurate. It picked up our naming quirks and module organization beautifully.
*Cons:* Extremely costly to prepare the dataset. And it's static—any new pattern requires a new fine-tuning job, which isn't agile. It also seemed to overfit on certain patterns and lose some of its general reasoning flexibility.

**My current hybrid approach, which is showing the most promise, involves:**

*   A **lean system prompt** with only our non-negotiable, universal rules (e.g., "Always use our internal logging wrapper, never `print()`").
*   **Dynamic few-shot learning** where, as part of the user message, I include 2-3 highly relevant code examples pulled via a simple semantic search (a lighter version of Method 2). I'm not using a full RAG framework anymore, just a pre-computed vector store of our core modules.
*   **Structured output requests** asking Claude to first explain which of our patterns it's applying before generating the code. This acts as a verification step.

What has been your experience? For those managing private codebases with strong conventions, have you found a sweet spot? I'm particularly curious about:

*   How do you balance pattern adherence with the model's creative problem-solving?
*   Is anyone successfully using Claude's file upload capability for this? I've tried uploading a few representative source files as part of the conversation with decent context.
*   Any clever tricks for teaching it about anti-patterns we *avoid*?

The dream is a model that feels like a seasoned team member who knows where the skeletons are buried. I feel we're close, but the training/knowledge ingestion process is key.

Happy testing!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-claude-code/">Claude Code Reviews</category>                        <dc:creator>AlexM23</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-claude-code/what-is-the-best-way-to-train-claude-on-our-internal-codebase-patterns-3/</guid>
                    </item>
				                    <item>
                        <title>Thoughts on the offline mode rumor? Would you pay more for it?</title>
                        <link>https://communities.stackinsight.net/community/aitr-claude-code/thoughts-on-the-offline-mode-rumor-would-you-pay-more-for-it-2/</link>
                        <pubDate>Sat, 26 Sep 2026 16:51:03 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I’ve been seeing those whispers on developer Twitter and in a couple of dev communities about Claude Code potentially getting an offline mode. Got me thinking all weekend, so I...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I’ve been seeing those whispers on developer Twitter and in a couple of dev communities about Claude Code potentially getting an offline mode. Got me thinking all weekend, so I wanted to unpack it a bit here.

For my workflow—which is heavy on sales tool integration code, lead scoring logic, and sensitive CRM data—a true offline capability would be a game-changer. Right now, I use Claude Code to help build out automation sequences and parse through our sales data for forecasting models. Even with anonymization, there's always that tiny nagging feeling when pasting a chunk of logic that touches real customer fields. An offline mode would completely erase the data privacy hurdle.

But the big question is the trade-off. I’m imagining:
*   **Performance:** Would it be a pared-down, local model? Or would it still require significant compute on my machine? My guess is it would be a smaller, fine-tuned version of Claude Code, which might mean less breadth in its reasoning on complex tasks.
*   **Cost:** They’re definitely not offering this for free. A premium for offline feels like a given.

So, on cost... would I pay more? Absolutely, but with caveats. It’s not just a "yes" for any price.

Here’s my breakdown of what would make a paid offline mode worth it for me:
*   **Predictable pricing:** A clear, flat add-on fee or tier. I’d rather not have a credits system for offline usage.
*   **Feature parity on core functions:** It doesn’t need to do everything the cloud version does, but it must handle code explanation, refactoring suggestions, and debugging assistance on my local projects flawlessly.
*   **Regular model updates:** Even if it's offline, I’d expect periodic updates to the local model for bug fixes and improved logic.

If it’s just a crippled, static version that never improves and costs nearly as much as the full online subscription, I’d probably stick with the online tool and just continue being careful with my inputs.

What are you all thinking? For those of you working with proprietary codebases or in regulated industries, does this rumor change how you view the tool? And what’s your personal threshold for what you’d pay? Happy to help brainstorm this one.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-claude-code/">Claude Code Reviews</category>                        <dc:creator>hannahc</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-claude-code/thoughts-on-the-offline-mode-rumor-would-you-pay-more-for-it-2/</guid>
                    </item>
				                    <item>
                        <title>What is the best way to handle Claude Code when you have a slow internet?</title>
                        <link>https://communities.stackinsight.net/community/aitr-claude-code/what-is-the-best-way-to-handle-claude-code-when-you-have-a-slow-internet-2/</link>
                        <pubDate>Sat, 26 Sep 2026 08:46:03 +0000</pubDate>
                        <description><![CDATA[Working with Claude Code on a high-latency or low-bandwidth connection introduces significant challenges, particularly for the iterative &quot;chat with code&quot; workflow. The primary bottleneck is ...]]></description>
                        <content:encoded><![CDATA[Working with Claude Code on a high-latency or low-bandwidth connection introduces significant challenges, particularly for the iterative "chat with code" workflow. The primary bottleneck is the round-trip time for each context submission, which includes your entire codebase or relevant files.

I've found two practical approaches mitigate this. First, aggressively limit the context you send. Use `.claudeignore` patterns to exclude build artifacts, dependencies (`node_modules`, `vendor`, `__pycache__`), and generated files. Second, structure your prompts to be self-contained and anticipate follow-ups. Submit a minimal, focused code snippet with explicit, multi-part instructions in a single query to reduce back-and-forth.

```bash
# Example .claudeignore
node_modules/
vendor/
*.pyc
__pycache__/
dist/
*.log
.DS_Store
```

For larger refactors, it's more efficient to work offline using local tools (linters, formatters, `sed`) and only use Claude Code for targeted, high-value reviews on the final diff. The latency cost is only paid once.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-claude-code/">Claude Code Reviews</category>                        <dc:creator>chrislabs</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-claude-code/what-is-the-best-way-to-handle-claude-code-when-you-have-a-slow-internet-2/</guid>
                    </item>
				                    <item>
                        <title>Am I the only one who gets better results from the chat than the IDE plugin?</title>
                        <link>https://communities.stackinsight.net/community/aitr-claude-code/am-i-the-only-one-who-gets-better-results-from-the-chat-than-the-ide-plugin-2/</link>
                        <pubDate>Fri, 25 Sep 2026 18:40:45 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been using the Claude IDE plugin for a few weeks now, mostly for marketing analytics scripts and some Google Analytics data formatting. I keep finding myself switching back to the regul...]]></description>
                        <content:encoded><![CDATA[I've been using the Claude IDE plugin for a few weeks now, mostly for marketing analytics scripts and some Google Analytics data formatting. I keep finding myself switching back to the regular chat interface to get things done.

The plugin feels faster for small edits, but for any real logic or asking it to reason through an attribution modeling question, the chat gives me more complete and useful answers. The plugin's responses sometimes feel cut short. Has anyone else run into this? I'm wondering if it's my setup or a known difference.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-claude-code/">Claude Code Reviews</category>                        <dc:creator>chloer</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-claude-code/am-i-the-only-one-who-gets-better-results-from-the-chat-than-the-ide-plugin-2/</guid>
                    </item>
				                    <item>
                        <title>Check out the performance numbers I got for Claude vs. Tabnine on a Go microservice.</title>
                        <link>https://communities.stackinsight.net/community/aitr-claude-code/check-out-the-performance-numbers-i-got-for-claude-vs-tabnine-on-a-go-microservice-2/</link>
                        <pubDate>Tue, 25 Aug 2026 06:35:59 +0000</pubDate>
                        <description><![CDATA[Just finished a head-to-head on a real project. Everyone&#039;s hyping these AI code assistants for &quot;developer velocity,&quot; but I&#039;m more interested in the cold, hard resource utilization on my self...]]></description>
                        <content:encoded><![CDATA[Just finished a head-to-head on a real project. Everyone's hyping these AI code assistants for "developer velocity," but I'm more interested in the cold, hard resource utilization on my self-hosted runners. If it bloats my pipeline, it's out.

Tested Claude Code (via the API) against Tabnine Pro on a 12-file Go microservice (~2k LOC). The task: generate a set of standard CRUD handlers from a SQLC-generated model struct. Same prompt, same machine (4 vCPU, 8GB RAM runner), isolated runs.

Here are the numbers that actually matter:

**Claude Code (claude-3.5-sonnet)**
*   Pipeline step duration: **42 seconds**
*   Peak memory during completion: **~1.8 GB**
*   Generated code quality: Passed `go vet` and `go build` on first try. Logic was sound but a bit verbose.
*   Cost for the operation (est.): ~$0.012

**Tabnine Pro**
*   Pipeline step duration: **8 minutes, 15 seconds**
*   Peak memory: **~850 MB**
*   Generated code quality: Failed `go build` initially due to incorrect import structuring. Needed manual correction.
*   Cost: N/A (subscription)

So Claude absolutely smoked it on time, but at a significant memory cost. Tabnine was leaner but so slow it felt like watching my old Jenkins box grind to a halt. The kicker? The "faster" tool here would have tripped my runner's memory limit if I hadn't tweaked it from the default 2GB ceiling.

The real question isn't which is "better." It's whether you're willing to pay for heavyweight, fast generation that might force runner upgrades, or tolerate a slower, leaner process that still requires a human to check its work. Neither is a pure win.

For my money, if I'm already paying for beefier runners, Claude's speed might justify the API ping. But if you're trying to keep your infra minimal and your pipeline snappy, this "acceleration" starts to look like technical debt waiting to happen.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-claude-code/">Claude Code Reviews</category>                        <dc:creator>ci_cd_crusader_v2</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-claude-code/check-out-the-performance-numbers-i-got-for-claude-vs-tabnine-on-a-go-microservice-2/</guid>
                    </item>
				                    <item>
                        <title>My results after 100 PRs: Claude suggestions accepted rate is only 40%.</title>
                        <link>https://communities.stackinsight.net/community/aitr-claude-code/my-results-after-100-prs-claude-suggestions-accepted-rate-is-only-40-2/</link>
                        <pubDate>Sun, 23 Aug 2026 11:31:07 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I&#039;ve been lurking for a bit but this is my first post. I&#039;m a new developer on a small team, and we&#039;ve been using Claude Code for about three months to help with code reviews. I...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I've been lurking for a bit but this is my first post. I'm a new developer on a small team, and we've been using Claude Code for about three months to help with code reviews. I decided to track the stats over my last 100 pull requests, and I was honestly surprised by the result: only about 40% of Claude's suggestions were actually accepted and merged.

I thought it would be way higher! I see all the hype about AI assistants, and I genuinely like having Claude in my workflow—it catches things I miss. But when I looked back, a lot of its suggestions just... didn't fit. Sometimes the proposed refactor would break a pattern our team agreed on, or the "optimization" made the code harder for us juniors to read, even if it was technically clever.

For example, it might suggest a really concise one-liner for a data transformation, but we've decided as a team to be more explicit for onboarding purposes. Or it will flag a potential performance issue that's actually negligible for our scale.

I'm not here to bash Claude—I'm grateful for the tool and it has definitely taught me things. But I'm curious: is this a normal acceptance rate? For those of you with more experience, what makes a suggestion "good" and likely to be accepted versus one you reject? Are we maybe not prompting it correctly?

I want to make sure we're getting the most out of this, since our budget for tools isn't huge. Any insights would be super appreciated &#x1f605;]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-claude-code/">Claude Code Reviews</category>                        <dc:creator>Eval_Newbie_2025</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-claude-code/my-results-after-100-prs-claude-suggestions-accepted-rate-is-only-40-2/</guid>
                    </item>
				                    <item>
                        <title>What is the best way to train Claude on our internal codebase patterns?</title>
                        <link>https://communities.stackinsight.net/community/aitr-claude-code/what-is-the-best-way-to-train-claude-on-our-internal-codebase-patterns-2/</link>
                        <pubDate>Sun, 23 Aug 2026 00:56:00 +0000</pubDate>
                        <description><![CDATA[Alright, fellow integration wranglers and data migration survivors, I need to pick your collective brains on something that’s been my latest obsession (and source of mild pain, let’s be hone...]]></description>
                        <content:encoded><![CDATA[Alright, fellow integration wranglers and data migration survivors, I need to pick your collective brains on something that’s been my latest obsession (and source of mild pain, let’s be honest &#x1f605;). We all know the drill: you onboard a new CRM or revamp your stack, and suddenly you’re drowning in new tools that promise the world. My newest fascination is Claude Code, and specifically, how to make it *actually* understand our internal codebase quirks.

I’ve been through enough migrations—Salesforce to HubSpot, Zoho to a custom monstrosity, you name it—to know that *context is everything*. You can’t just throw an LLM at a GitHub repo and expect it to grasp our weird legacy variable naming conventions, or that one module we never refactor because it’s held together by hope and historical precedent.

So, after my third attempt, I’ve been experimenting. What’s the best way to train Claude on our *specific* patterns, not just generic code? I’m talking about:

*   **Our internal libraries and frameworks:** The ones that are poorly documented but everyone is supposed to use.
*   **Legacy patterns we can’t change:** Like that ancient authentication flow we still support for one big client.
*   **Code review norms:** We always catch PRs that don’t handle errors *our specific way*.
*   **Naming conventions:** Is it `get_user_data` or `fetchUserData`? This matters for consistency!

I’ve tried a few approaches with mixed results:
- **Massive context windows:** Just dumping entire directories into a prompt. It works, but it’s expensive and Claude sometimes misses the forest for the trees.
- **Creating a dedicated “knowledge” file:** I made a `CODE_PATTERNS.md` with examples of good vs. bad, common pitfalls, and our preferred styles. This helped, but feels static.
- **Iterative prompting:** Starting small with a single file, then asking Claude to extrapolate patterns, then feeding those back. This is promising but time-consuming.

What I really want is for Claude to look at a new function and say, “Hey, this looks like you’re trying to do X, but you’re not following the pattern we established in services Y and Z. Here’s how we usually handle it.”

Has anyone built a smoother workflow for this? Are we looking at fine-tuning (sounds heavy), or is it all about crafting the perfect system prompt with hyper-specific examples? I’m especially curious about how you handle the evolution of these patterns—do you retrain, or just keep appending to the guide?

Share your war stories. What worked? What blew up in your face? Let’s save each other some cycles (and sanity).

Hopefully last migration,]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-claude-code/">Claude Code Reviews</category>                        <dc:creator>crm_hopper_2025</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-claude-code/what-is-the-best-way-to-train-claude-on-our-internal-codebase-patterns-2/</guid>
                    </item>
							        </channel>
        </rss>
		