{"slug": "plain-tools-self-driving-development-how-muse-builds-itself", "title": "Plain Tools, Self-Driving Development: How Muse Builds Itself", "summary": "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.", "body_md": "*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).*\n\nAn AI agent can produce a working implementation in minutes. What happens between that first implementation and a production deployment?\n\nFor 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.\n\nThe 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.\n\nHere is how the pieces fit together.\n\nMuse 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.\n\nThe application uses a deliberately straightforward stack:\n\nMost 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.\n\nThe repository also gives each layer a clear responsibility:\n\n| Directory | Responsibility | \n|---|---|\n| `main/` | Compose features and register routes | \n| `apps/<feature>/` | Keep a feature’s routes, pages, services, storage logic, and tests together | \n| `adapters/` | Handle rendering, databases, and object storage | \n| `libs/` | Provide shared, separately versioned libraries | \n\nDependencies point downward. Features cannot import sibling features directly; shared behavior is connected through the composition layer.\n\nThese 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.\n\nThe 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.\n\nA Muse task starts in Linear, often from a discussion in Slack.\n\nOnce 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.\n\nFrom there, the loop continues:\n\nClaude 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.\n\nThe work remains accessible to the rest of the team through ordinary issues, commits, checks, and review threads.\n\nEvery pull request passes seven automated checks:\n\nAn AI review panel then examines the change from three perspectives:\n\n**Principal engineer:** Does the change fit the architecture and reuse existing capabilities?\n\n**Senior engineer:** Is the implementation correct, testable, and secure?\n\n**QA engineer:** Does the behavior match the request, and could the change cause a regression?\n\nEvery finding must be fixed or rebutted with evidence before merging. Rebuttal matters because reviewers can be wrong too.\n\nIn 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.\n\nPassing tests established one kind of evidence. Reviewing the effect on existing data supplied another.\n\nThe original article compares two tasks:\n\n|  | Remove an unused feature | Improve a network diagnostic tool | \n|---|---|---|\n| First implementation | 2 minutes | 5 minutes | \n| Issue to merge | 16 minutes | About 3 hours | \n| Review | Advisory only | 7 blocking findings across 5 rounds | \n\nThe diagnostic tool needed more verification because users would rely on its measurements. Review uncovered problems involving units, error handling, permissions, and tests.\n\nThese are two examples, not a controlled productivity benchmark. They illustrate why time to the first implementation tells only part of the delivery story.\n\nPeople still decide which problems deserve attention, write requirements, and resolve ambiguous design choices. Those decisions give the automated workflow its direction.\n\nThe 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.\n\nThe [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.\n\nIf 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?", "url": "https://wpnews.pro/news/plain-tools-self-driving-development-how-muse-builds-itself", "canonical_source": "https://dev.to/meshyai/plain-tools-self-driving-development-how-muse-builds-itself-4ali", "published_at": "2026-11-09 06:09:13+00:00", "updated_at": "2026-11-09 06:22:45.051629+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "mlops", "artificial-intelligence"], "entities": ["Meshy", "Muse", "Claude Code", "GitHub", "Linear", "Slack", "Andrew"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/plain-tools-self-driving-development-how-muse-builds-itself", "markdown": "https://wpnews.pro/news/plain-tools-self-driving-development-how-muse-builds-itself.md", "text": "https://wpnews.pro/news/plain-tools-self-driving-development-how-muse-builds-itself.txt", "jsonld": "https://wpnews.pro/news/plain-tools-self-driving-development-how-muse-builds-itself.jsonld"}}