Optimize Claude Code with code-review-graph

Stop letting Claude Code read files that have nothing to do with your task! Every time you ask Claude Code to review a change, it scans your entire codebase. Most of those files are irrelevant. You are paying for tokens that add no value. code-review-graph fixes this by building a persistent knowledge graph of your codebase using Tree-sitter. It maps every function, class, import, and dependency, then at review time computes the exact set of files Claude actually needs to read. Here's how it works: • Parses your codebase into an AST and stores it as a graph of nodes and edges in SQLite • On every file save or git commit, a hook fires and re-parses only what changed • At review time it traces the blast radius of your change: every caller, dependent, and test that could be affected • Claude reads only those files instead of scanning the whole project Real results across 6 open-source repositories: 6.8x fewer tokens on code reviews, up to 49x on daily coding tasks. Supports 23 languages including Python, TypeScript, Rust, Go, Java, Vue, Solidity, and Jupyter notebooks. Works with Claude Code, Cursor, Windsurf, and any MCP-compatible agent. It's 100% open source. Link to the GitHub repo in the comments!

Agreed. I’ve used Code Review Graph in my projects, and it’s been incredibly helpful. One thing I especially liked was how it points directly to the code that actually needs analysis in the middle of the conversation, instead of making the agent scan everything. That focus makes reviews much faster and more relevant.

I hated Object Oriented Programming (OOP) but now, I am addicted to it. Coming from BASIC, all these textbook definitions overwhelmed me: Polymorphism? Abstraction? Inheritance? It just sounded way too complex. (I even chose PHP over JavaScript early on because JS had "Java" in the name! 😅). But it all changed when I decided to fully understand it. Forget all the big grammar, it's very simple and you will understand it if you stick till the end. A class is simply a blueprint. It defines what traits (variables/properties) and behaviors (functions/methods) an entity (e.g. a human being) should have and how they work together. The best example of a class in real life is DNA. DNA determines how the organism looks and behaves. If you modify the DNA, you modify the organism. Now, here's something interesting: A human DNA by itself is not yet a human being, but we use it to create a living human being. This process of creation is what we call "instantiating a class". So every living human being you know is an instance of the human DNA class. In code: "class Human {...}" is the DNA while, "new Human(...)" is the human being (a.k.a an instance of class Human otherwise known as an object) So every time you do "new Human", you just created a new person/object... To be continued in the comments 👇

AI can generate tests quickly. But that doesn’t necessarily mean it knows which tests are worth writing. That’s the problem I’ve been working on with Repo Test Architect: a local-first CLI and MCP server that audits a repository before any generation happens. It identifies: - high-value behavior without matching tests - existing tests and the evidence connecting them to source - covered but still risky code - files that probably don’t deserve direct tests - project boundaries, blockers and repository-native verification commands The next public alpha now supports 10 bounded adapters: JavaScript/TypeScript, Python, Swift, Kotlin/JVM, Go, Rust, C#, Ruby, PHP and Elixir. Each adapter has been exercised against pinned public repositories, native test commands and cross-platform release gates. The findings are still review input—not automatic instructions to rewrite a repository. In the attached video, I audit a pinned version of the H3 TypeScript framework. The tool finds one high-value missing test, distinguishes it from code with direct asserted test evidence, skips a type-only target, and produces a focused plan using H3’s own pnpm run test command. Try it locally: npx --yes repo-test-architect analyze . GitHub: https://lnkd.in/dUsfW5zf The next question is where to expand from here. If your stack isn’t supported, what language, build system and test framework would you need before trying it on one of your repositories?  (And yes the video is amazingly edited my me)  #OpenSource #SoftwareTesting #MCP #DeveloperTools

Last week, there was quite a drama between the creator of Bun, Jarred Sumner and the creator of Zig, Andrew Kelly, regarding the Bun Rust rewrite. Bun is a fast and modern JavaScript runtime environment designed to prioritize performance and developer tooling. Zig is a system programming language designed to be a general-purpose improvement to the C programming language. Bun was built using Zig previously because of high-speed performance. As the user base began to grow, the issues were also increasing. Remember Anthropic’s 512,000-line code leak in March? That was Bun’s fault, thanks to a bug in the bundler that generated source maps during builds even when told not to. Also one of the problems was that JavaScript uses a garbage collector for memory handling and Zig handles memory manually. That created some of the bugs that they were facing. Here, Rust came in handy for them because in Rust, the borrow checker turns use-after-free, double-free, and forgot-to-free bugs into compile-time errors instead of production incidents. You don't catch these bugs after they ship — the code simply doesn't compile until they're gone. Result of the rewrite now 99.8% of Bun's existing test suite passed on the new Rust codebase with a 20% smaller binary size without compromising the speed. The creator of Zig called out the creator of Bun, saying It's not a Zig issue, it's their skill issue (jk). Writing Rust code is painful and managing memory in a large codebase is a nightmare. So choosing the pain you want to go through matters 😂

Keeping up with what is gaining traction on GitHub is more tedious than it should be. GitHub's trending page shows one language at a time, so you end up clicking through Python, then Rust, then Go, then TypeScript, and losing the overall picture. GHTR is a free web tool that pulls trending repositories across 25+ languages into a single sortable table. What it gives you: - Trending repos from many languages aggregated into one view: Python, Rust, Go, TypeScript, Swift, C++, Java, Vue, Svelte, Zig and more - Sort by total stars, stars gained today, or forks, by clicking a column header - Filter down to only the languages relevant to your stack - Automatic de-duplication of repos trending in multiple languages, with a count of what was merged - One-click refresh with a live progress indicator Nothing to install, it runs in the browser. Useful for engineering leads and developers tracking which tools are actually picking up momentum this week. Try it: https://ghtr.fly.dev

Most of us have seen this at least once: 0.1 + 0.2 === 0.3 // false The first time I saw it, I genuinely thought JavaScript was broken. Years later, after working on web applications—including payment and financial systems—I realized something important: JavaScript wasn't broken. My understanding of how computers represent numbers was. This isn't just a JavaScript quirk. It's a computer science fundamental that affects JavaScript, Java, Python, Go, C#, Rust, and many other languages because they all follow the IEEE 754 floating-point standard. In my latest article, I explore: ✅ Why 0.1 + 0.2 becomes 0.30000000000000004 ✅ How computers actually store numbers in memory ✅ What IEEE 754 is and why it matters ✅ When to use Number.EPSILON ✅ Why fintech teams store money in cents/paisa instead of decimals ✅ When arbitrary-precision libraries like decimal.js become essential One thing I've learned over the years is this: Frameworks evolve. AI generates code. But computer science fundamentals never go out of style. Sometimes, the difference between a successful transaction and an expensive production incident is just: 0.00000000000000004 If you've ever wondered why this happens—instead of just memorizing the workaround—I hope you'll enjoy this deep dive. 📖 Read the full article here: https://lnkd.in/dUiKK4Z7 I'd love to hear your thoughts! Have you ever encountered a floating-point precision bug in production, or is there another computer science fundamental that completely changed how you think about software engineering? #JavaScript #SoftwareEngineering #Programming #WebDevelopment #ComputerScience #IEEE754 #FinTech

𝗙𝘂𝗻𝗱𝗮𝗺𝗲𝗻𝘁𝘂𝗺: 𝗛𝗼𝘄 𝗧𝘆𝗽𝗲𝗦𝗰𝗿𝗶𝗽𝘁 𝗕𝗲𝗰𝗮𝗺𝗲 𝘁𝗵𝗲 𝗜𝗻𝗳𝗿𝗮𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲 𝗼𝗳 𝘁𝗵𝗲 𝗔𝗜 𝗘𝗿𝗮 Type checking the VS Code codebase went from 125.7 seconds to 10.6. The speed is not the story. Where the check runs is. I watched Anders Hejlsberg introduce TypeScript 7: forty years of building the tools everyone else builds with, now rewriting his own life's work in a language he did not design. It shipped 8 July. At two minutes, a type check lives in CI, after the work is finished. At ten seconds it runs inside the loop, while the context that caused the error is still live. Same tool, different job. And it is not only TypeScript. Meta, Astral and an independent developer each rewrote a Python type checker in the same window. Four checkers, two languages, one year. Nobody rewrote a runtime. They all went after the thing that says no. That is the tell. When writing code gets cheap, the constraint moves to checking it, and the checker has to be fast enough to sit where the writing happens. Four teams spent a year on that instead of anything more visible. How long does your slowest type check take, and does anyone still run it? https://lnkd.in/gtCrvEqm

JetBrains just made a move that says a lot about where the industry is heading: they're shipping their best-in-class Java and Kotlin intelligence as a Language Server Protocol extension for VS Code and Cursor. I use PHPStorm daily, so this is an interesting development in my eyes. For years, the IntelliJ engine was a big reason to pay for their IDEs. Now they're unbundling it. The rationale in their own post is telling - as agents take on more implementation work, developers only need a narrow set of features: navigation, references, simple completion. That's exactly what LSP covers. This is a smart and early strategic pivot. The editor is becoming commoditised; the language server is where the value is. But it also means JetBrains is betting that developer workflows will increasingly live in lighter editors driven by agents, not in full-fat IDEs. For startups building developer tools, the lesson is clear: the moat isn't the UI. It's the intelligence underneath - and it needs to be accessible wherever your users actually work. https://lnkd.in/gvnkJWpy

I made a programming language this year. The general thesis is that good software design is an actual thing. In everything I've ever programmed, in any part of the stack, the design "to be implemented" always feels like the same design — but given the actual intersect of language, libraries and domain, the way the implementation comes together feels different every time. We know software designs are good or bad, and we talk amongst ourselves about design patterns and whatnot when we try to actually describe what the good design is. It's not uncommon for large codebases to define some baseline harness that codifies a few technical opinions for the rest of the project, and the choices there shape what "good design" has to mean for everything after. Since the clankers started doing uppers at the end of last year, most of my time with agentic coding has been spent speed running corrections to the good design. The surface area of languages and libraries is so granular these days that the decision space at any point in a project is pretty large. Driving an agent session is manual course correction — keeping requirement, specification, and machine instruction aligned. The boundary conditions there are effectively static. Only the middle layer, the specification, is fungible. Hale codifies a recursive hypergraph model, which lets you express an application's specification using the same stacked singular shape. You program your units of code using both direct ownership and async messaging. You get pure logical isolation between the domain implementation and the technical deployment. And the structure maps directly to the machine hardware layout, so no-gc no lifetime management are just, free: the structure of the language results in deterministic ownership and frees at compile time. I've been building a handful of fun apps, they're working well, so I feel like it's not a total waste of anyone else's time that might be interested. https://hale-lang.org https://lnkd.in/ggMXZJX3