Adapted from Andrew’s engineering article on the Meshy blog.
An AI agent can produce a working implementation in minutes. What happens between that first implementation and a production deployment?
For Muse, Meshy’s internal model evaluation platform, that is where much of the engineering work happens: checking architecture, running tests, investigating failures, answering review comments, and validating the branch before it merges.
The workflow uses Slack, Linear, GitHub, and Claude Code. Humans choose priorities and resolve important design questions. The agent handles implementation and follows the change through verification, review, merge, and deployment.
Here is how the pieces fit together.
Start with a codebase the agent can understand
Muse helps teams compare 3D model checkpoints through blind, side-by-side voting. Both outputs use the same reference image, their positions are randomized, and teammates vote without knowing which checkpoint produced each result.
The application uses a deliberately straightforward stack:
- Backend: Python, FastAPI, and Postgres.
- Asset storage: S3 for meshes and images.
- Frontend: Jinja2 templates, HTMX, and Tailwind.
- Interactive rendering: a WebGL viewer for the 3D models.
Most interface state stays on the server. A page update follows the same basic path as an initial page load: the server renders HTML, and the browser displays it.
The repository also gives each layer a clear responsibility:
| Directory | Responsibility |
|---|---|
main/ |
Compose features and register routes |
apps/<feature>/ |
Keep a feature’s routes, pages, services, storage logic, and tests together |
adapters/ |
Handle rendering, databases, and object storage |
libs/ |
Provide shared, separately versioned libraries |
Dependencies point downward. Features cannot import sibling features directly; shared behavior is connected through the composition layer.
These boundaries are enforced by build checks. Directory-level documentation explains the rules and the commands required before merging. Files have a 500-line ceiling, with existing exceptions allowed to shrink but not grow.
The practical benefit is a smaller search space: an agent can identify where a change belongs and receive an explicit failure when it crosses a boundary.
Keep the work visible in familiar tools
A Muse task starts in Linear, often from a discussion in Slack.
Once directed to the issue, the agent reads the requirements, gathers context, and surfaces decisions that need human judgment. It then implements the change and opens a GitHub pull request.
From there, the loop continues:
- Read CI results and review findings.
- Investigate failures.
- Update the implementation and tests.
- Respond to review threads.
- Enter the merge queue when the requirements are satisfied.
Claude Code’s Monitor feature wakes the agent when watched states change, such as a failed CI job or a new review comment. This lets the workflow continue without someone repeatedly checking the pull request.
The work remains accessible to the rest of the team through ordinary issues, commits, checks, and review threads.
Make verification part of the delivery process
Every pull request passes seven automated checks:
- Architecture and repository guardrails.
- Formatting and linting with Ruff.
- Type checking with Pyrefly.
- Unit and integration tests, including a real Postgres database.
- Playwright visual comparisons against committed baselines.
- Static security analysis and secret scanning.
- A container startup check, including declared access requirements for routes.
An AI review panel then examines the change from three perspectives:
Principal engineer: Does the change fit the architecture and reuse existing capabilities?
Senior engineer: Is the implementation correct, testable, and secure?
QA engineer: Does the behavior match the request, and could the change cause a regression?
Every finding must be fixed or rebutted with evidence before merging. Rebuttal matters because reviewers can be wrong too.
In one real example, a change passed the tests but altered how existing datasets would be grouped during synchronization. The reviewer identified that this could invalidate sample identities still referenced by live evaluations. The agent corrected the behavior and added regression coverage.
Passing tests established one kind of evidence. Reviewing the effect on existing data supplied another.
Measure time to a verified change
The original article compares two tasks:
| Remove an unused feature | Improve a network diagnostic tool | |
|---|---|---|
| First implementation | 2 minutes | 5 minutes |
| Issue to merge | 16 minutes | About 3 hours |
| Review | Advisory only | 7 blocking findings across 5 rounds |
The diagnostic tool needed more verification because users would rely on its measurements. Review uncovered problems involving units, error handling, permissions, and tests.
These are two examples, not a controlled productivity benchmark. They illustrate why time to the first implementation tells only part of the delivery story.
What this approach leaves to humans
People still decide which problems deserve attention, write requirements, and resolve ambiguous design choices. Those decisions give the automated workflow its direction.
The reusable lesson is to make the repository understandable, turn important constraints into executable checks, and keep the review process visible. Autonomy becomes more practical when the agent can inspect failures and continue working through them.
The full engineering write-up includes architecture diagrams, reviewer prompt outlines, and additional examples of defects caught before deployment.
If you use coding agents, which step still needs the most human attention in your workflow: specifying the task, reviewing the implementation, or verifying production behavior?
Top comments (0)