Muse Code: a business pilot checklist

Retrospective covering 6 August 2026, written on 9 September 2026. This is an evaluation framework, not a hands-on product review.

Muse Code should be evaluated on the work a team can accept and maintain, rather than the amount of code it can generate. My recommendation for a small engineering team is a controlled pilot using ordinary repository maintenance, with reviewer time included in the result.

Meta released Muse Code in beta on 5 August 2026, powered by Muse Spark 1.2. Its announcement describes a terminal agent for repository-scale work, including planning, implementation and validation. Meta launch announcement.

Why this launch deserved attention

Meta described persistent background agents and a local event log intended to support recovery after interruption. Those are claims about how work continues over a session, not just how a model answers a prompt. The company also said it trained the model and agent together. Meta's architecture description.

That makes the announcement relevant to teams whose AI experiments already produce plausible first drafts but struggle with completion. My assessment is that task continuity and handover deserve explicit testing whenever a supplier promises longer-running work.

I have not benchmarked Muse Code for this article. The checklist below describes the evidence I would ask a team to collect before approving broader use. It deliberately avoids declaring a winner against tools that have not been tested under the same conditions.

Choose maintenance work, not a showcase

Start with tasks your team actually receives: a reproducible defect, a small integration change, an accessibility correction or a dependency update with known acceptance criteria. Avoid a blank application that nobody will operate after the demonstration.

The task should have a clear endpoint. For a defect, write down the unwanted behaviour, expected behaviour and a way to reproduce both. For a feature, identify the user who will accept it and the existing workflows that must continue to work.

Use your normal repository conventions. If the agent needs a special project stripped of history, integrations and awkward tests to appear useful, record that limitation. The pilot should reveal the effort required to use the tool in your environment.

For a wider comparison framework, connect the pilot to your AI return-on-investment measures.

Make the reviewer part of the experiment

Assign a reviewer before work begins. Give that person authority to reject a change, even when the demo looks impressive or a deadline is approaching.

My suggested review record includes the time spent understanding the diff, correcting errors, checking tests and requesting changes. Separate those activities from time spent configuring the tool. The distinction helps identify whether the problem is an initial setup cost or a continuing operating burden.

Ask the reviewer to explain the resulting change without relying on the agent's summary. If the implementation cannot be understood well enough to maintain, completion has not yet been demonstrated.

Do not let the same agent provide the only acceptance judgement for its own work. Keep business acceptance with the relevant person and technical acceptance with someone accountable for the repository.

Test interruption and handover deliberately

Because continuity is part of Meta's product description, I would include a disposable interruption exercise. Use a safe test repository and stop a task at an agreed point. Observe the restart, then have a different developer review what happened.

The questions are practical: which actions completed, which remain outstanding, whether work was duplicated and whether the log explains the state. For example, ask whether a background agent repeats a file edit after restart, or whether a previously approved action is replayed after the task has changed. These are illustrative acceptance failures to test, not defects reported in Muse Code. Do not infer that a recoverable session necessarily produces correct code. Those are different tests.

A useful handover record would contain the original request, files changed, checks performed, unresolved concerns and the next human decision. Ask the replacement developer whether they can continue from that record without reconstructing the whole session.

Use a scorecard that can reject the tool

This is my proposed comparison sheet. The measures are deliberately independent of any vendor benchmark.

Agree a decision rule before seeing the results. For example, the team might require a clear improvement in accepted maintenance work without increasing reviewer burden. Set the actual threshold around your team's constraints rather than borrowing a universal percentage.

Keep failed tasks in the record. Excluding them makes the tool look easier to operate than it is and prevents the team from learning which work remains unsuitable.

Treat access and data as procurement questions

Before using a real repository, ask for the applicable terms, data handling description and available administrative controls. Confirm the exact product and plan being evaluated. Do not assume a public announcement answers every question about your proposed use.

My preference is to start with a repository whose data has already been approved for the pilot, then expand after the owner reviews the evidence. Record any external tools or integrations needed to complete the work so the pilot does not silently become a larger procurement decision.

Use your existing vendor due diligence process to document unanswered questions. An unknown should remain visible until someone resolves it.

Decide on a workflow, not a launch-day favourite

The decision at the end of the pilot should name approved tasks, required review and the conditions that would trigger another assessment. It may approve a narrow use case while leaving more sensitive work with the existing process.

Keep the outcome intelligible to the budget holder: what work became easier, what effort moved elsewhere and what risks remain. That is the evidence needed for a purchase decision. It is also the discipline that keeps a promising coding-agent launch from becoming another subscription with no accountable benefit.