Stop the Diff Padding: Claude Code Guardrails, MCP Security Scanning, and Local Models Closing the Gap on Opus

Today's findings

1. #1 A copy-paste CLAUDE.md rule that stops agents from padding diffstip

   A short 'scope rules' block pasted into AGENTS.md/CLAUDE.md keeps coding agents from sneaking unrequested refactors and reformatting into a fix.

   CLAUDE.md / AGENTS.md scope rules

   Scope rules cut the diff padding reviewers never check

   Without scope rules

   • The requested fix
   • Reformatted untouched lines
   • Reordered / restyled lines
   • Unrequested refactor
   • New dependency

   → Padding gone: every changed line was asked for

   With scope rules

   • The requested fix

   Paste the numbered block into CLAUDE.md / AGENTS.md and the first message of ad hoc chats.

   Why it matters: Unreviewed 'while I was here' changes are a leading source of prod breakage from agent-generated diffs, because reviewers scrutinize the requested fix, not the padding around it.

   How to apply: Add a numbered scope-rules block to CLAUDE.md/AGENTS.md (change only what's needed; don't reformat, reorder, or restyle untouched lines; no unrequested refactors or new deps) and paste it into the first message of ad hoc chats too.

   claude-codeagentscode-reviewprompting

   Read more: Coding agents pad their diffs to look thorough, and the padding is where the bugs hide

2. #2 dekko: an IDE-style code-intelligence layer so Claude Code stops grepping blindtool

   An open-source tool built with Claude Code gives it call-graph/definition lookups instead of re-reading whole files to answer simple structural questions.

   Why it matters: A large share of agentic-coding token spend is wasted context-gathering (opening three files to answer 'who calls this'); a real code-intelligence layer turns that into near-constant-cost lookups.

   How to apply: Point dekko at your repo so Claude Code can answer 'who calls this function'-style questions via index lookups instead of exhaustive file reads.

   claude-codetoolingcontext-management

   Read more: I kept watching Claude burn through tokens reading entire files to answer simple questions, so I used Claude Code to build a fix for it. (dekko, open source, free)

3. #3 OpenTrustBench: a local, zero-telemetry scanner for MCP servers before you grant shell accesstool

   An Apache-2.0 CLI statically audits MCP servers for risky behavior before you wire them into an agent with shell or filesystem access.

   OpenTrustBench · Apache-2.0 CLI

   Scan the MCP server before it gets a shell

   1

   Pick server

   new MCP server

   2

   Scan locally

   static audit, zero telemetry

   The gate most people skip

   3

   Read findings

   risky behavior flagged

   4

   Wire into agent

   shell / filesystem scopes

   Runs on your machine; nothing is sent out. Most servers get installed unread.

   Why it matters: Most people install MCP servers 'quickly, without reading them' — exactly the supply-chain risk vector for agents that can execute shell commands.

   How to apply: Run the scanner against any new MCP server before adding it to Claude Code or another agent harness, especially ones requesting filesystem or shell scopes.

   mcpsecurityagents

   Read more: Scan the MCP servers you're giving shell access to. 100% local scanner, zero telemetry [OC, Apache-2.0]

4. #4 chemx: replace 'review this code' prompts with AST-generated surgical refactor promptstool

   An open-source CLI runs local static/AST checks and compiles a precise refactor prompt straight to your clipboard instead of asking an LLM to hunt for smells.

   chemx · open-source CLI

   Stop asking the LLM to hunt for code smells

   'Review this code'

   • LLM hunts for smells itself
   • Burns context on the search
   • Findings vary run to run
   • Can hallucinate issues

   vs

   chemx AST prompt

   • Local AST checks find smells
   • Deterministic and repeatable
   • Scoped surgical refactor prompt
   • Lands on clipboard, paste and go

   Let static analysis find; let the model fix.

   Run chemx on a file before your usual clean-up prompt and paste its output instead.

   Why it matters: Asking an LLM to find code smells burns context and produces non-deterministic, sometimes hallucinated findings; deterministic local analysis plus a scoped prompt is cheaper and repeatable.

   How to apply: Run chemx against a file or module before your usual 'clean this up' prompt, and paste its generated prompt instead of writing one from scratch.

   promptingclicode-review

   Read more: Stop Asking LLMs to Find Code Smells: Auto-Generating Surgical Prompts via AST

5. #5 A new VS Code extension wires local Ollama models into the built-in chat agent UItool

   'Local Ollama Chat' connects VS Code's native agent chat panel to a local Ollama server, with reviewable diffs before any file edit is applied.

   Why it matters: The stock Ollama VS Code extension is reportedly laggy and returns raw JSON; this gives a no-code-leaves-the-machine coding assistant with normal diff review.

   How to apply: Install the extension, point it at your local Ollama server, and use it for code questions/edits you don't want sent to a hosted API.

   ollamalocal-llmvscode

   Read more: Use Local LLM within VScode agent chat · VScode extension to use Local LLM (ollama) within VScode chat agent

6. #6 llama.cpp lands Flash Attention tuning for RDNA4/3.5 AMD GPUs (gfx1201)repo

   A pending PR adds tuned flash-attention kernels for R9700/RX 9060 XT/8060S with notable prefill gains at large context.

   llama.cpp · AMD ROCm

   Tuned Flash Attention kernels land for RDNA4 / RDNA3.5 (gfx1201)

   llama.cpp PR #28102

   feature Pending PR

   ggml-org/llama.cpp · targets R9700, RX 9060 XT, 8060SPending · Sep 2026

   GitHub PR #28102Build from PR branchRequires gfx1201-class AMD GPU

   rungh pr checkout 28102 · build with HIP/ROCm · re-bench prompt processing at long context

   Biggest win is prefill (prompt-processing) speed at large context, narrowing the AMD-vs-CUDA gap.

   Why it matters: AMD GPU users running local models have historically lagged CUDA performance; this closes part of that gap, especially for long-context workloads.

   How to apply: Track ggml-org/llama.cpp PR #28102, build from that branch if you're on gfx1201-class AMD hardware, and re-benchmark prompt-processing speed at long context.

   llama.cppgpuperformance

   Read more: CUDA/HIP: Flash Attention tuning (gfx1201) by pwilkin · Pull Request #28102 · ggml-org/llama.cpp

7. #7 Lightweight semantic-entropy hallucination detection for local models, no heavy judge model neededtechnique

   Sampling K responses and clustering them for semantic entropy (the Oxford/Nature approach) flags when a local model is guessing, without a VRAM-hungry judge model.

   Why it matters: Local deployments often can't afford a second large model just to check the first one's outputs, so a cheaper entropy-based signal is the difference between shipping a hallucination guard and shipping nothing.

   How to apply: Sample multiple completions at temperature ~0.7 from your local model, cluster for semantic equivalence, and treat high entropy as a hallucination flag before surfacing an answer.

   local-llmollamaevaluation

   Read more: Detecting hallucinations in local models without eating VRAM: What we learned testing 1.5B to 120B models

8. #8 llama.cpp's default tensor split can make two machines slower than onetip

   Splitting a 321B model across a MacBook M5 Max and a Strix Halo box over Thunderbolt ran slower than one Mac alone because the default split dumped half the layers on the slower node.

   Why it matters: Teams pooling heterogeneous local hardware to run bigger open models can silently regress performance if they trust the default split instead of tuning it per node.

   How to apply: When distributing a model across mismatched machines with llama.cpp, manually set the tensor-split ratio to favor the faster node rather than relying on the default even split.

   llama.cpplocal-llmperformance

   Read more: MacBook M5 and AMD Strix Halo sharing large models

9. #9 Qwen3.8 Flash Next on a 128GB Strix Halo laptop scores within 2 points of Claude Opus 4.8technique

   A fully local Qwen3.8 setup (llama.cpp + custom launcher) hits Artificial Analysis index 40 vs Opus 4.8's 42 for agentic coding, at 2-3x the wall-clock time.

   Local vs frontier · agentic coding

   Local Qwen3.8 trails Opus 4.8 by 2 points, at 2-3x the wall-clock

   vs

   Qwen3.8 Flash Next (local)

   Claude Opus 4.8 (cloud)

   Artificial Analysis index

   40

   42

   Wall-clock time

   2-3x slower

   baseline

   Cost

   no paid usage

   paid per use

   Privacy

   fully on-device

   data leaves machine

   Qwen3.8 Flash Next (local) wins the row Claude Opus 4.8 (cloud) wins the row

   UD-Q4_K_XL via llama.cpp on a 128GB Strix Halo laptop; good enough for background coding where latency is acceptable

   Why it matters: It's a concrete, reproducible data point for when a local model is 'good enough' to offload agentic coding work from paid Claude usage, trading latency for cost and privacy.

   How to apply: If you have 128GB+ unified memory or equivalent, try Qwen3.8 Flash Next (UD-Q4_K_XL) via llama.cpp for lower-priority or background coding tasks where 2-3x latency is acceptable.

   local-llmbenchmarkingagentic-coding

   Read more: Qwen 3.8 (27B + Flash Next) on a 128GB Strix Halo laptop as a Claude Opus replacement for agentic coding. AA 40 vs 42, 10-15 tok/s decode, 3 min cold prefill · Qwen3.8 Flash Next vs Claude Opus 4.8 for agentic coding: AA 40 vs 42, and why thinking tokens rather than tok/s set the wall clock

10. #10 A popular terminal-output compression tool claims big token savings but didn't lower the actual billtip

    Independent Terminal-Bench 2.1 testing found a widely-used context-compression tool's token-savings claims didn't translate into lower total cost.

    Why it matters: Teams adopting token-compression middleware on trust alone may add complexity and risk without the cost benefit they expected.

    How to apply: Before adopting a terminal/tool-output compression layer in your agent harness, benchmark end-to-end cost on your own workload rather than trusting vendor token-savings claims.

    cost-optimizationbenchmarkingcoding-agents

    Read more: RTK reports token savings, but our cost benchmarks disagree · Most popular terminal output compression tool tested on Terminal-Bench 2.1: huge token savings claims, no impact on the final bill