An agent's task can end with valid code and still leave a reviewer unsure what to do next. Put the acceptance check into the task before execution begins.
We're the team behind Lizard (lizard.build). Our October 7 announcement covers Lizard Sandboxes and the path from an agent workspace to a deployed app. The infrastructure is most useful when the task has an explicit deliverable.
Consider an illustrative internal status page. A useful task description specifies which inputs it reads, what the page should display and which action proves the deployed version works. It also states whether deployment is authorized, rather than leaving that decision to the agent.
During implementation, choose the workspace for the work involved. A coding-agent template supplies a prepared starting point. A desktop with Chromium is useful when the task requires interaction with a graphical browser. Credentials and application-specific dependencies still need deliberate configuration.
At review time, compare the result with the original acceptance check. Record the actual test output and known limitations. If deployment is in scope, verify the deployed URL, configuration and required data access.
Lizard deployments can remain running independently of the development sandbox. Keep that distinction in the handoff: the source, app and data should each have an owner and an intended lifetime.
A precise completion condition helps prevent an attractive preview from being mistaken for a finished delivery. It also makes the next iteration smaller: the reviewer can point to the unmet check instead of issuing another broad request to improve the app.
Responses
Join the conversation
Sign in to share your thoughts and interact with the author.
Sign In to Comment