Plain Tools, Self-Driving Development: How Muse Builds Itself

Meshy engineers built Muse, an internal model-evaluation platform for blind side-by-side comparison of 3D model checkpoints, and structured its codebase so an AI agent can carry changes from a Linear issue through implementation, CI, AI review, merge and deployment. The stack uses server-rendered HTML with Slack, Linear, GitHub and Claude Code, and enforces directory boundaries and a 500-line file ceiling so the agent gets explicit failures when it crosses a boundary. Every pull request passes seven automated checks plus a three-perspective AI review panel, with findings fixed or rebutted with evidence before merging.

Adapted from Andrew’s engineering article on the Meshy blog https://www.meshy.ai/blog/plain-tools-self-driving-development-muse?utm source=devto&utm medium=referral&utm campaign=muse engineering&utm content=intro . 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. 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: 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. 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: 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. Every pull request passes seven automated checks: 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. 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. 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 https://www.meshy.ai/blog/plain-tools-self-driving-development-muse?utm source=devto&utm medium=referral&utm campaign=muse engineering&utm content=full article 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?