One of the most expensive mistakes in engineering is picking the wrong tool, and you usually don’t find out until you’re deep into the integration. By then you’ve written code against assumptions that turned out to be wrong, and backing out is slow and costly.

So I spend a lot of my week in the research phase, before I clone anything or write code. That research used to mean cloning the repo, opening the source, and manually inspecting how the tool actually worked. The problem is that the painful integration mistakes rarely come from a function that doesn’t exist. They come from a function that exists and behaves differently than I expected. Documentation describes intent. It doesn’t always describe structure, and it lags behind implementation details and edge cases.

A recent example: React to SvelteKit

I wanted to migrate a large React app to SvelteKit, and I was deciding between two agents for the job: Hermes and OpenClaw.

I had real constraints going in. The agent should have read-only access to the legacy repo and stand up a separate repo for the SvelteKit project, so there’s a clean read/write separation. The migration should run in batches, with verification at each step: the code compiles, the tests run, and the agent drives the browser to confirm the UI behavior is preserved. For setup, I’m running Copilot as the LLM provider, and I want the whole thing in Daytona sandboxes, because it’s a long-running task and I don’t want it on my laptop.

Exploring the code without cloning it

Instead of cloning both repos and reading through them, I had the agent use GitHits to explore each project against those criteria and tell me which one fit better. It searches and reads across the codebases in real time. Nothing is cloned, and nothing is on my machine.

The research session took a while, so I ran it ahead of the recording. The agent worked through each criterion and concluded that Hermes was the better fit. What matters more than the answer is how it got there. It didn’t reason from a README. Every claim points at real files, actual definitions, and the specific lines it pulled the context from. That trail is the difference between a guess and something I can check.

What it found

On the provider question, both agents support Copilot, with a slight edge to Hermes. Hermes supports Daytona as a backend. The per-step verification gates are where having the source in front of you pays off: the agent evaluated the browser-based UI testing path for both, went through the actual methods and capabilities, and checked the read/write repo separation and the long-running batched orchestration I’d asked for. It finished with a short outline of how I’d wire up Hermes, plus a caveat worth flagging about OpenClaw’s capabilities.

Better shot on target

The older approach is to try things and wait until the issues surface. That’s how you end up deep in an integration before you learn the tool doesn’t behave the way you assumed. Doing the research this way, I can answer the questions I already know I care about up front, and go into the build with a much better shot on target.