Using Hoplite to build Hoplite
What our published use of Hoplite says about delegation and a workflow for making agent work reviewable.
The easy version is familiar. An agent builds a small demo in one prompt and it looks finished. Then you point it at your own codebase, with real users and real review. The question shifts from what it wrote to whether you can trust it.
Our launch post says we build Hoplite with Hoplite, including the website. Readers can see the website and know it was built with the product. That leaves a practical question. How do you judge changes an agent makes?
What follows is a suggested workflow built around a hypothetical bug. It shows how to make agent work reviewable. It is not a reconstruction of an internal Hoplite pull request.
Start with a change someone can judge
A website makes the process easy to explain because you can inspect the result directly. Take a hypothetical task. Fix a settings form that loses a draft when validation fails.
The brief should describe the current behavior and the expected result. Name the form, explain how to reproduce the loss, and say which existing behavior must stay intact. Ask for a test covering the failed submission plus a check in the running app.
Leave product decisions with their owner. If the form is supposed to save partial data but the rules are undecided, settle that question before you ask the agent to implement a guess.
Make the development environment part of the task
A change that cannot be run is expensive to review. Configure the project's setup and run scripts so the cloud environment can install dependencies and start the application. If the flow needs one, supply a test account or safe fixture.
Hoplite's agent-ready guide explains how to prepare your project. Treat a setup failure as config work to fix, not as a reason to skip validation. Fix it once so the next task benefits.
For the hypothetical form fix, the agent needs a way to trigger a validation error without touching a real customer's data. A small, repeatable fixture makes that test useful to both the agent and the reviewer.
Keep the evidence attached to the change
Ask the agent to describe the reproduction, the test command it ran, and any remaining limitation. For a visual change, inspect the running app. Request before-and-after screenshots only when the comparison helps review. Most tasks do not need them.
Hoplite's browser tools can inspect the app inside the sandbox. Its pull-request workflow links the PR back to the thread, where a reviewer can find the conversation behind the diff.
That connection helps when a reviewer asks why the agent chose a particular implementation. The explanation should point to a constraint or test. Compare any confident summary against the test output.
Give feedback on the behavior you need
In the form example, a review comment might say the input survives the error but focus moves to the wrong field. Ask for that behavior to be corrected and checked. Keep the follow-up in the same task so the next attempt keeps the context of the first.
Decide on a review and merge policy. Current Hoplite documentation describes autofix and auto-merge as separate controls. If a person must approve each change, set those controls and the repository protections to require it.
Keep a short record of rejected changes. A diff can be technically valid and still implement the wrong product decision. Record which requirement was missing or misunderstood so the next brief can address it.
Try this workflow on one visible bug in your own application. Give it a reproduction, inspect the result, and leave a real review comment. That exchange teaches more about using Hoplite than any claim about lines written.