Should be titled “Why Ramp built its own in-house coding agent, Inspect” (that’s the title of the post at the time of this comment)

I think the more coding agents the better, more ideas mixing and borrowing that’s yielding improvements across actively developed agents and different tradeoffs being made. From the article, Ramp’s Inspect was made with frontend in mind and is particularly good with Ramp internal tooling. Looks like it’s not open source? https://inspect.ramp.engineering/auth/

The blog post doesn’t have much further material or at least not before the paid envelope.

Some thoughts I have -

> 1. Local machines are limited in how many agents they can run. Ramp found third-party products below expectations; they liked Claude Code on day 1, but were constrained by only being able to run one or two sessions on local machines.

I haven’t seen this constraint? I only started using Claude Code ~4 months ago so maybe it was different before.

> 3. Need for remote dev environments. As Ramp scaled, so did the complexity, and with it there was more work at the intersection of systems, like debugging backward compatibility, and broken API contracts. The solution was to create remote dev environments.

This seems disjoint, not sure I follow how remote dev environments was necessary to solve this or why remote dev environments would be the only solution?

> Hooking up Inspect to the data sources that engineers would browse with the same tools seems to be a key difference between Inspect and third-party AI harnesses.

You can do the same with third party AI harnesses, I guess we’d have to see what Inspect does that’s better than providing MCPs, CLIs, scripts, etc. to an agent.