Meta just entered the AI coding race. Its benchmarks don't answer the only question we care about.

This is not a scan study. We have not tested Muse Spark, because it launched today and there is essentially no code built with it in the wild yet. When there is, we will scan it and report exactly what we find. This post is about the question the launch does not address, and what the evidence we already have says the answer will be.

What Meta actually announced

Muse Spark 1.1 is Meta's new agentic and coding model, its first pay-to-use model, positioned explicitly to chase Anthropic and OpenAI. The headline claims are about capability: stronger at understanding large codebases, finding bugs across files, writing production-ready code, and multi-step reasoning, and beating Google's latest Gemini on coding and reasoning benchmarks. All at a price designed to undercut the competition.

Read that list again and notice what every item has in common. Every benchmark cited measures one thing: does the model produce code that works and solves the problem. That is a real and hard thing to be good at. It is also not the same question as whether the code it produces is secure.

Two different tests

“Does it work” and “is it safe” are different tests, and models are optimized and benchmarked almost entirely on the first. A model can write a flawless authentication flow that also hardcodes the signing secret into the repo. It passes the coding benchmark. It ships the vulnerability. Nothing in a benchmark that rewards working code penalizes a committed API key, a disabled TLS check, or a Math.random() where a cryptographic token belongs.

So a launch that leads with “beats Gemini at coding” tells you the model is more capable. It tells you nothing about the security of what it generates, because that was never what the benchmark was measuring.

What our data across the other vendors predicts

Here is where we can say something concrete, because we have measured the vendors Meta is chasing. We scanned real web apps built with three generations of Anthropic's Claude and with OpenAI's Codex, hundreds of apps, every high-severity finding reviewed by hand. Two results matter for Muse Spark:

• The rate barely moves between models. Across four models and two vendors, the high-severity flaw rate landed in a narrow band with no statistically significant difference between any of them. A more capable model, or a cheaper one, did not produce more secure apps.
• The reason is the same everywhere. The flaws that dominate every cohort are hardcoded credentials, weak randomness, and disabled TLS, all things a human pastes in or switches off to make something work. They are not reasoning failures a smarter model avoids, which is exactly why the rate does not move when the model gets smarter.

So here is a testable prediction, on the record before we have the data: Muse Spark-built apps will land in the same band as Claude and Codex, and the flaws will be the same short list of human shortcuts. If Meta's capability claims are true, its apps will work better. They will not be measurably safer, because capability is not the variable that controls this. We will scan it when there is a corpus and tell you if we are wrong.

Why a cheaper, better coding model can make this worse, not better

There is a second-order effect worth naming. A more capable model at a lower price does one thing very reliably: it puts more code into production, written by more people, faster. If the security-flaw rate per app is constant across models, and the number of apps goes up, the total amount of vulnerable code in the world goes up with it. Cheaper and better coding models are good for shipping. They do not reduce the security debt per app, so at scale they increase the absolute amount of it. The review step matters more as the models get better, not less.

If you are already trying Muse Spark

The checklist does not depend on which model wrote the code, which is the whole point. Before a repo goes public: pull every secret into an environment variable and rotate anything ever committed, use a cryptographic random source for anything that guards access, never ship with certificate verification disabled, and confirm generated endpoints check that the user owns the data they are requesting, not just that they are logged in. Those are the issues that showed up regardless of vendor, and there is no reason to expect a new one to be exempt.

We are genuinely glad there is another strong coding model, and we will give Muse Spark the same fair, hands-reviewed scan we gave the others the moment there is enough code to measure. Until then, treat the benchmark wins as what they are, evidence the model is capable, and keep asking the question the benchmarks do not: is what it built safe to ship.