u/fykup

Coding agents have changed how I use VS Code. More of the implementation happens in an agent, and when it finishes I spend more of my time in Source Control reviewing the resulting diff.

One workflow I've found useful is to review the whole change with a different model from the one that implemented it.

I built a small VS Code extension called AI Badger to make that easier.

From the Source Control view, AI Badger: Copy All Changes for Review packages the current git changes, including staged and unstaged changes, additions, deletions, and bounded file context, into a structured review prompt.

Then you just paste it into ChatGPT, Claude, Grok, or another AI chat and ask for an independent review.

The basic workflow is:

1. Agent finishes implementing a change.
2. Open Source Control in VS Code.
3. Click Copy All Changes for Review.
4. Paste into a different AI model.
5. If the reviewer needs an unchanged supporting file, use Copy File for AI from Explorer.

Nothing is uploaded automatically. AI Badger is local-first and clipboard-based, so you decide exactly what leaves the machine and which model receives it.

For more complicated reviews, there is also an optional CLI workflow where the reviewer can request specific missing repository context, but the normal VS Code workflow does not require the CLI.

VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=pvrlabs.ai-badger

Live interactive demo:
https://pvrlabs.xyz/aibadger/vscode-demo.html

Full workflow article:
https://pvrlabs.xyz/articles/reviewing-ai-generated-code-vscode-aibadger.html

I'm curious how other people are handling this now. When an agent changes several files, are you mostly reviewing the diff manually, asking the same agent to review itself, or handing the change to a second model?

One thing I keep seeing in agentic coding is that the model gets fed a lot of output that is technically correct but not very useful.

A successful Maven build can print hundreds of lines. Same with npm tests. For an agent, the useful result is often just:

PASS · 11.8 s

So I built a few small deterministic CLI tools around a simple rule:

Success should consume almost no context. Failure should preserve enough evidence to act without forcing a rerun.

The main tools:

• mvn-lite: compact Maven builds and tests
• npm-lite: compact selected npm verification/test workflows
• repo-map: machine-local repo and tool discovery
• html-screenshot: one-shot Chrome screenshots
• launch-browser: reusable Chrome DevTools sessions

A few measured success-path reductions:

• Spring Maven: 5,564 bytes / 70 lines → 16 bytes / 1 line
• Scriptella Maven: 66,812 bytes / 928 lines → 17 bytes / 1 line
• npm + Vitest: 2,260 bytes / 43 lines → 25 bytes / 1 line
• npm + Tape: 136,262 bytes / 1,476 lines → 12 bytes / 1 line
• npm + Jest: 2,491 bytes / 68 lines → 24 bytes / 1 line

The failure path is more interesting.

If you compress failures too hard, the agent often reruns the command just to see what broke, which defeats the purpose.

So failures keep the full raw log locally. Short failures are printed in full, while long ones get bounded, marker-aware diagnostics. The goal is not “minimum bytes at all costs”. It is minimum context required for the next useful action.

repo-map tackles a different kind of context waste. Instead of hardcoding machine-specific paths into every AGENTS.md, related repos can use stable aliases:

repo-map get orders-api

A frontend can resolve its backend, the backend can resolve the frontend, and shared helpers like mvn-lite, npm-lite, and html-screenshot can be discovered without repeating tool paths in every repo.

Everything is Bash, local-only, deterministic, with no LLM calls, API keys, telemetry, or background service.

Sometimes context engineering is simply not putting irrelevant data into the context window in the first place.

Repo: github.com/ejboy/agent-scripts

Curious how others here handle command-output policy for agents.

Successful Maven builds can produce thousands of lines that mostly confirm routine lifecycle steps.

That output is noisy when working in a terminal, clutters CI logs, and becomes especially expensive when build output is passed to a coding agent.

I built mvn-lite, a small deterministic Bash wrapper that keeps successful Maven output to one line while preserving the original exit code and complete raw log.

On a real four-module application:

• Standard Maven output: about 6,753 bytes
• mvn-lite output: 16 bytes
• Result: PASS · 3.944 s
• Reduction: more than 99.7%

Failures still return a nonzero exit code and show bounded diagnostics, while the full unmodified Maven output remains available in the raw log.

For example, an invalid lifecycle error was reduced by 91.6% while retaining the actual Maven error.

There is no LLM summarization, API key, or Maven extension involved. It is just a local Bash wrapper with deterministic text extraction.

Source and script: https://github.com/ejboy/agent-scripts

Benchmark details and design notes: https://pvrlabs.xyz/articles/introverted-maven.html

I’d be interested in feedback on Maven failure cases where compact output could hide something essential.

I’m relatively new to the formal “context engineering” framing, but I ran into a practical problem that seems related.

Autonomous coding agents like Cursor, Claude Code, Codex are great for implementation, but I found them inefficient for higher-level tasks like architecture review, debugging strategy, onboarding, and design discussion.

They often rescan broad parts of the repo, pull in noisy context, and burn through metered limits just to answer questions that mostly need a good structural overview plus a few precise snippets.

My natural workaround was to move those discussions into fixed-cost web chats like Claude Web or ChatGPT, while keeping the repo scanning/extraction local.

So I built a small local-first CLI tool called AI Badger around this workflow:

The map: a local command scans the repo and builds a compact structural map.

The handoff: you paste that map into a reasoning chat.

The extraction: the model asks for specific files/snippets, the tool extracts only those locally, and you paste the focused context back.

The goal is not to replace coding agents. It’s more of a bridge for split workflows:

• agent for implementation
• web/local chat for review, design, debugging, and explanation
• local tool for precise context extraction

I put the source code here: https://github.com/PVRLabs/aibadger
There’s also a browser demo showing the workflow: https://pvrlabs.xyz/aibadger/demo.html

I’m curious whether this maps to problems people here think about:

• Is explicit “map first, fetch snippets on demand” a useful context workflow?
• How do you avoid wasting tokens when moving between implementation agents and reasoning chats?
• Where do you think the boundary should be between explicit context handoff and automatic retrieval?