Testing Meta AI and the Muse CLI by Building LLM Wars

Idea

Meta AI did not have an app available when this test began, but that seemed like a poor excuse not to give it an awkward job. We asked it to build LLM Wars: a browser game inspired by the old Drug Wars formula, with WebGL first-person movement added because sensible project briefs are apparently optional.

The game was a compact way to test several coding abilities in one conversation. Meta AI had to manage trading rules, game state and player movement while also reasoning about a 3D space. The goal was not to produce a polished commercial game. It was to see whether the model could turn an odd idea into working software, then improve it without losing track of what already worked.

Shortly before publication, Meta released the Muse cli, so we repeated part of the experiment there. That gave us a useful comparison between the restricted web experience and an agent working directly through a terminal.

This test is useful for developers and small teams deciding whether Meta AI is ready for real coding work or still belongs on the watch list.

Status

The first result was acceptable, with a fairly large asterisk attached. After several rounds of prompting, the game ran and the basic loop worked. The trouble was how it got there: each revision felt closer to a rewrite than a careful continuation of the existing project.

That matters because generated code is only the beginning. A useful coding assistant must preserve working behaviour, understand the effect of a change and make targeted edits. Rebuilding large sections can look productive while quietly introducing regressions and making review harder. It is the software equivalent of tidying a desk by buying another desk.

Muse was a better working environment. Terminal access made the process feel more direct, and the model showed a few promising abilities. Even so, it did not earn a place among our first-choice coding tools. The output was usable, but the editing discipline and responsiveness were behind the alternatives we rely on for day-to-day development.

Problems Faced

The web interface limited how much useful project context we could provide and manage. Muse reduced that friction, but exposed a different problem: once the agent had agreed to a plan, it treated that plan as law.

We approved a proposed approach, then changed our mind about a testing step and sent a clear steering message. The agent ignored it, then ignored a second steering attempt and continued with the original tests. We stopped the run, supplied a more explicit instruction and tried again. It still followed the old plan.

Plans should support the work, not outrank the person requesting it. Requirements change during development because new information appears, an assumption proves wrong or somebody remembers that customers exist. An assistant that cannot respond to a clear correction creates extra work and raises the risk of an unwanted command or change slipping through.

Cost was the other concern. During our UK based testing, the cheaper model option appeared to be unavailable, while the available model consumed tokens quickly. That makes experimentation difficult to justify, especially for a small business trying to compare several tools. Watching the token counter felt rather too much like feeding a parking meter that had learned to code.

Techniques That Helped

Simple, conversational instructions worked better than an elaborate prompt full of speculative steps. We described the next visible outcome, asked for a small change and reviewed the result before continuing. Keeping each request narrow made it easier to spot when the model had replaced working code or drifted away from the brief.

For anyone testing Muse on a real project, a few safeguards are sensible:

• Start with a small, disposable feature or prototype rather than a production system.
• Keep the repository under version control and inspect the diff after every meaningful change.
• Ask for targeted edits, naming the files and behaviour that must remain unchanged.
• Interrupt the run if a steering instruction is ignored; do not assume the next message will fix it.
• Run your own checks after each change instead of treating the agent's test report as proof.

Muse may suit work that already has a clear specification, acceptance criteria and an external review process. A pre-agreed spec gives the model a fixed target, while small commits make unwanted rewrites easier to catch. Open-ended development is less convincing at this stage because the agent's attachment to its first plan works against the feedback loop that good software work needs.

Our hope is that we encountered an edge case, but alas the cost is not worth testing that hope.

Lessons Learned

Meta AI could build the game, which is meaningful. LLM Wars ran, the core idea survived and the result was better than a failed experiment dressed up with optimistic adjectives. The weak point was not raw code generation; it was collaboration across several iterations.

The tendency to rewrite code made progress harder to trust, while MUSE's reluctance to accept new direction made the workflow feel rigid. For prototypes, those faults are manageable. On a client project, they would mean more review time, tighter safeguards and a higher risk of paying for work that must be undone.

We will test it again after future updates, using the same game as a rough benchmark. Repeating a known task should make changes in code quality, instruction-following and token use easier to judge. Product rankings can change quickly, and a tool that misses the shortlist today may be worth another look in a few months.

For now, Meta AI and Muse are interesting tools to watch rather than our default recommendation. If you are comparing AI coding tools or need practical guidance on your own web project, talk to us at holeaf.uk.