DEV Community: Muhammad Shoaib Syed

Lum1104 — Understand-Anything

Muhammad Shoaib Syed — Tue, 02 Jun 2026 18:07:47 +0000

Most AI coding tools operate in silos. Claude Code has its own context. Copilot has another. Cursor, Codex, Gemini CLI—each carries a separate understanding of your codebase.

Until this week, that meant switching tools meant losing context. Not anymore—at least in theory.

The new open-source project Understand-Anything claims to turn any code into a single interactive knowledge graph. Explore, search, ask questions. And it works across Claude Code, Cursor, Copilot, Codex, and Gemini CLI.

That is the promise: one graph to rule them all. A unified, queryable map of your codebase accessible from any assistant.

The promise of a shared code brain

Imagine asking Claude Code, "What calls this deprecated function?" and getting an answer that also highlights the same dependency in Copilot when you switch tools. No re-indexing. No lost context.

Or using Gemini CLI to ask plain-English questions about a gnarly algorithm, with direct links to the relevant code nodes. Then plugging into Cursor to visually navigate the call hierarchy.

A team might integrate it with Copilot in VS Code to visually trace class hierarchies. A new developer could search for all instances of an API endpoint, seeing a map of usage across the codebase via Codex integration.

The core proposition is deceptively simple: an interactive model of your code that any AI assistant can tap into. It's not just another visualisation tool. It's an attempt to solve context fragmentation.

What the project actually claims

The GitHub repository is refreshingly straightforward. Its entire description reads:

Turn any code into an interactive knowledge graph you can explore, search, and ask questions about. Works with Claude Code, Codex, Cursor, Copilot, Gemini CLI, and more.

That's it. No architectural diagrams. No deep dives into graph generation. No language compatibility matrix.

We don't know whether the graph is built via static analysis, LLM parsing, or some hybrid approach. Performance on large monorepos remains a question mark. And "and more" hints at ambition without specifying integration depth.

But the bullet points are enough to make the intent clear: a universal abstraction layer for code understanding, consumed through whichever AI assistant you prefer.

Why context fragmentation hurts

Multi-tool workflows are now the norm. You might debug in Copilot, refactor in Cursor, and generate docstrings with Claude Code. Each shift costs you the mental model you'd built in the previous tool. The assistant forgets what the other assistant knew.

A shared knowledge graph could bridge that gap. It wouldn't magically align model reasoning, but it would give each tool the same structural map of the codebase. That's a meaningful improvement over the current state, where each tool independently reconstructs its own version of your code.

The project touches a real pain point. Even if today's implementation is thin, the concept is worth watching.

Holding the scepticism

Early-stage projects deserve enthusiasm tempered with honesty. Understand-Anything currently offers a vision more than a verified solution. No examples of actual graph generation sit in the repo. No queries or visualisations demonstrate the interactive experience. Community adoption isn't measurable yet.

But this isn't unusual for projects that are just surfacing. The interesting bit isn't what the codebase does right now. It's the problem statement it pins to the wall: context switching across assistants is a tax we should stop paying.

Which chore in your multi-tool workflow would you most want unified by a knowledge graph?

Claude Opus 4.8: dynamic workflows change how you structure large-scale coding tasks

Muhammad Shoaib Syed — Mon, 01 Jun 2026 15:57:17 +0000

Anthropic shipped Claude Opus 4.8. Most of the coverage will focus on benchmark improvements and the 2.5× speed boost in fast mode.

The source confirms it builds on Opus 4.7 with improvements across benchmarks and launches with several new features. One stands out for developers working with large codebases: the 'dynamic workflows' feature in Claude Code.

What dynamic workflows enable

Claude Code now includes a 'dynamic workflows' feature that allows it to tackle very large-scale problems. The model can decompose work into coordinated subtasks — a pattern that was previously hard to automate.

Think about a monolith-to-microservices migration. You could break it into file-by-file tasks, with the model coordinating changes across hundreds of files. Or tracing dependencies through a legacy system to generate documentation.

The Anthropic release describes it as a way to handle very large-scale problems, though specific coding benchmarks are not detailed in the announcement.

What else is in Opus 4.8

The release adds several other features relevant to coding workflows:

Controllable effort on claude.ai: tailor how deeply the model engages with a task — quick linting or comprehensive architectural review.
Fast mode: 2.5× speed and 3× cheaper than previous versions, useful for iterative cycles in CI/CD pipelines.

Claude Opus 4.8 builds on Opus 4.7 with improvements across benchmarks and is described as 'a more effective collaborator', though the source does not break out code-specific benchmark scores.

Why this matters for developers

The dynamic workflows feature shifts what you can automate. Previously, models could handle isolated files or functions. Now, the model can coordinate across broader system changes. That is not just a faster model. It is a different way to structure work.

The speed and cost improvements in fast mode also make AI-assisted iteration more practical for everyday development tasks.

https://code.claude.com/docs/en/ultraplan

Which large-scale chore would you automate first?

Ultraplan Shifts AI Code Planning to a Multi-Agent Cloud Workflow

Muhammad Shoaib Syed — Mon, 01 Jun 2026 15:57:15 +0000

Anthropic just shipped Ultraplan for Claude Code. Most coverage will focus on the cloud offloading. I read it as a shift in how AI plans code.

Until now, AI coding assistants typically used a single agent to think through a task step by step. Ultraplan spins up a multi-agent system in the cloud. Multiple parallel exploration agents gather context simultaneously. A critic agent reviews and refines the plan. The result is a blueprint drafted before any code is written.

This matters because planning is often the bottleneck. A single agent can miss context or get stuck in a narrow path. Parallel exploration means broader coverage. The critic agent adds a layer of quality control. The blueprint is not just a to-do list. It is a structured execution plan you review in a browser UI, not a cluttered CLI scrollback.

Your local terminal stays free while the agents work. You can keep coding or switch tasks. When the plan is ready, you inspect it in a rich web interface. You decide what to run locally or in the cloud. That changes the developer workflow from passive waiting to active oversight.

Credit to the Anthropic team. The multi-agent pattern is not new in research, but seeing it productised for everyday coding tasks is a signal. Planning is becoming a first-class step, not an afterthought.

How much planning do you want to offload to a team of agents?

https://code.claude.com/docs/en/ultraplan

Stop Paying for Noise: Trim LLM Tokens from Both Ends of the Pipe

Muhammad Shoaib Syed — Wed, 27 May 2026 09:35:16 +0000

The Token Tax You Are Paying

Every time an LLM-powered coding agent runs cargo test or git status, it swallows reams of output. Most of that is noise—progress bars, ANSI escapes, empty lines. You pay for every token. On the other side, verbose model replies burn even more. The result is a slow, expensive loop that scales badly.

Two open-source tools attack the problem from opposite ends of the pipe. RTK strips input noise before it reaches the model. caveman forces the model to talk like, well, a caveman. Together they keep more of your token budget for work that matters.

How RTK Compresses the Input Stream

RTK is an OSS CLI proxy. It sits between your terminal and the LLM, reading command output and dropping everything that is not signal.

The numbers are stark. Across 2,927 real-world developer commands, RTK saved 10.3M tokens from 11.6M input tokens—an 89.2% reduction [Source]. The tool is not guessing; it is measuring.

Per-command compression rates from the RTK website show consistent results:

cargo test: 91.8%
git status: 80.8%
find: 78.3%
grep: 49.5%

The RTK repository describes it as a “CLI proxy that reduces LLM token consumption by 60-90% on common dev commands.” The tool is lightweight and plugs into existing workflows without changing how you run commands.

caveman Takes the Output Side

If RTK handles the flood of input tokens, caveman disciplines the output. It is a Claude Code skill that instructs the model to respond with minimal words. The caveman repository states it “cuts 65% of tokens by talking like caveman.”

The principle is simple: fewer output tokens mean faster completion and lower costs. caveman does not alter the substance of the response; it just strips the fluff. For routine tasks—explaining an error, summarising a diff—the 65% saving is pure gain.

Why Both Sides Matter

Input token reduction is the biggest lever. An 89% drop on commands that run hundreds of times per session rapidly compounds. Output reduction is smaller in absolute terms but still valuable; 65% less output per interaction keeps the conversation tight and responsive.

Using both tools creates a high-efficiency loop: slim input, slim output, same results. Neither tool requires complex configuration, and both are available as OSS under the MIT licence for RTK and a similarly permissive setup for caveman.

What Is Missing

The evidence shows each tool works independently. No combined benchmark exists yet. The 65% output figure for caveman comes from the repository description alone; per-task examples would strengthen the case. RTK’s aggregate data is solid, but session-level detail is not published. These gaps do not undermine the core claim—that trimming both ends of the pipe saves meaningful money—but they are worth noting before measuring an integrated setup.

A Grounded Takeaway

If you pay for LLM tokens, you are paying for noise. RTK and caveman attack that noise at the input and output stages respectively. The savings are measurable, and both tools are free to use. Start with RTK—the 89% input reduction is the headline figure—and add caveman when verbose model responses are eating into your budget.

Would you use both tools in the same workflow? The data suggests you should.