Comments URL: https://news.ycombinator.com/item?id=47671790

Points: 1

# Comments: 0

The problem is diffs are the wrong format. A PR might change how three buttons behave. Staring at green and red lines to understand that is crazy.

The core reason we built this is that we feel that products today are built with assumptions from the past. 100x code with the same review systems means 100x human attention. Human attention cannot scale to fit that need, so we built something different. Humans are provably more engaged with video content than text.

So we RL trained and built an agent that watches your preview deployment when you open a PR, clicks around the stuff that changed, and posts a video in the PR itself.

Hardest part was figuring out where changed code actually lives in the running app. A diff could say Button.tsx line 47 changed, but that doesn't tell you how to find that button. We walk React's Fiber tree where each node maps back to source files, so we can trace changes to bounding boxes for the DOM elements. We then reward the model for showing and interacting within it.

This obviously only works with React so we have to get more clever when generalizing to all languages.

We trained an RL agent to interact with those components. Simple reward: points for getting modified stuff into viewport, double for clicking/typing. About 30% of what it does is weird, partial form submits, hitting escape mid-modal, because real users do that stuff and polite AI models won't test it on their own.

This catches things unit tests miss completely: z-index bugs where something renders but you can't click it, scroll containers that trap you, handlers that fail silently.

What's janky right now: feature flags, storing different user states, and anything that requires context not provided.

Free to try: https://morphllm.com/dashboard/integrations/github

Demo: https://www.youtube.com/watch?v=Tc66RMA0nCY

Comments URL: https://news.ycombinator.com/item?id=46891827

Points: 35

# Comments: 13

Comments URL: https://news.ycombinator.com/item?id=46739785

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46728546

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46698684

Points: 13

# Comments: 0

We’re the team behind WarpGrep. It’s a FAST context retrieval subagent designed to fix coding agents spending ~60% of their time searching for context + the huge context rot problem.

We built this because we found that standard RAG or naive context stuffing leads to "context rot"—where irrelevant files poison the model’s reasoning on long-horizon tasks. Inspired by Cognition’s SWE-Grep, we wanted to build an accessible version that integrates via MCP (Model Context Protocol) or SDK.

How it works: Instead of a single prompt trying to do everything, WarpGrep treats context retrieval as a distinct, RL-trained system. We reward correct context retrieval and penalize irrelevant lines.

Constraints: It operates on a strict budget of 4 turns. Parallelism: It executes up to 8 parallel tool calls per turn (grep, list, read, etc.).

Inference: We worked with NVIDIA to optimize this on B200s. We are hitting ~900 tokens/sec (compared to SWE-Grep’s ~650 t/s). The heavy prefill optimization was critical here because grep operations are read-heavy.

The Results: In our internal benchmarks, offloading retrieval to this subagent speeds up tasks by 40% and reduces token usage by roughly the same amount. More importantly, it seems to reduce "context rot" by ~70% on longer tasks because the agent isn't distracted by irrelevant file headers. On SWE-Bench Pro we see 5-12% improvement on long horizon tasks and stable chats for 2-3x more user messages.

It works with every coding agent - Claude Code, Codex, and OpenCode. We’re curious to see how it handles your edge cases (especially huge repos).

There is a free tier, but if you want to push it hard, you can use the code BF16 for 40M tokens of credit to test the API limits. We do recommend adding a payment method to get around the rate limits but you won't be charged until December 14th. At which point it will still be almost 10x cheaper than Claude Haiku.

Happy to answer questions about the CUDA optimizations or the RL training process!

Comments URL: https://news.ycombinator.com/item?id=46210111

Points: 1

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=46106013

Points: 5

# Comments: 1

Using fast apply is more reliable at first pass and is faster/cheaper. You prompt your agent to output in a lazy format and our model learns hoe to merge it in.

The ides listed typically do turn based search and replace which uses more tokens and takes longer

Kilo supports morph as well!

Morph now merges code at 10,500 tokens/sec — roughly 4× faster than the best speeds on Cerebras.

That kind of speed makes previously impractical workloads trivial: applying complex edits across a 40k-token document now takes under 4 seconds. This isn’t a vanity metric - we think it unlocks an entirely new domain of AI use cases where codebases, configs, or long documents can be semantically edited in real time.

Morph is a Fast Apply model dedicated to merging edits from frontier LLMs We want to enable developers to build realtime interfaces with AI

Comments URL: https://news.ycombinator.com/item?id=45253167

Points: 2

# Comments: 4

Imagine going to 500k publishers to buy it individually. 3k per book is way cheaper. The copyright system is turning into a data marketplace in front of our eyes

now we need a web framework with faster reload times