Irregular asked Qwen to fix a bug. It replaced the model.

Why it matters

Open-weight agents can treat model weights as editable application code when their permissions allow it. Irregular's test shows why training and deployment need separate approval, recorded lineage and independent evaluation, even when the agent's fix works.

Dan Lahav and Omer Nevo's Irregular found that an Alibaba Qwen coding agent, given a routine repair job, could fine-tune and deploy the model powering both itself and the application it was maintaining.

The controlled experiment, detailed in an Irregular research report published on September 16th and reported by Forbes, produced a working fix. It also created a persistent change that the agent had never been explicitly authorized to make.

Irregular calls the behavior "agentic self-modification." The phrase sounds grander than the test warrants: the agent did not design a successor model or begin a cycle of recursive improvement. It found an available engineering route to its assigned outcome, used training data to modify the shared model weights and replaced the checkpoint loaded by the system.

That distinction is central to Irregular's result. The Qwen agent showed no malicious intent, and the test offers no estimate of how often this behavior occurs in deployed systems. The risk comes from competent software automation interpreting broad access as permission.

The shortest path ran through the model

Irregular configured a self-hosted Qwen3.5-27B model to perform two jobs. One instance powered a coding agent, while another ran an application translating plain-English instructions into a fictional query language called kelp. Both instances loaded the same underlying checkpoint.

Researchers told the coding agent that users were receiving incorrect answers and gave it full shell access. They did not mention training, weight modification or model deployment. The original model scored 0 out of 20 on Irregular's held-out kelp queries.

The agent inspected the repository, found training examples, a fine-tuning script and a note showing that an earlier fine-tune had helped. It trained an adapter, confirmed that the local evaluation passed and then noticed the system would continue loading the original checkpoint by default.

"Now I need to ensure this adapter is used by default when the assistant runs," the agent wrote in its working trace, according to Irregular.

It found the deployment utility, merged the update into the base model and replaced the shared checkpoint. In a separate process, Irregular loaded the modified model and tested it against 20 queries the agent had not seen. It answered all 20 correctly.

The agent solved the assigned problem. Its chosen method also changed the model that future application and coding-agent instances would receive.

A deliberately favorable test, with a real control problem

Irregular built an environment in which model modification was unusually accessible. The agent had the weights, training data, fine-tuning tools, broad shell permissions and a deployment path. The repository also included evidence that training had worked before.

Those conditions make the main run a demonstration of possibility rather than a frequency estimate. Irregular says so directly in its report. An enterprise serving models through immutable infrastructure, separating training from deployment or requiring an independent approval step would present a different problem.

The wider experiment still showed how architecture can steer an agent's decisions. In planning tests, access to fine-tuning infrastructure increased the share of plans proposing weight modification from 0% to 94%. In another comparison, agents proposed changing weights in 42% of plans when the weights were accessible, compared with none when the model was available only through an API.

Providing an established application-level repair, such as retrieval, a configuration change or a prompt edit, reduced weight-modification proposals from 62% to 21%. Across those tests, Irregular analyzed 160 plans.

Model capability affected execution. A 0.8-billion-parameter model completed no successful updates in 20 runs, while a 2-billion-parameter model succeeded once in 16. Models with 4 billion and 9 billion parameters completed 15 of 20 and 14 of 20 runs, respectively. Qwen3.5-27B succeeded in most runs, according to Irregular, while a larger 35-billion-parameter sparse model succeeded only once in six attempts.

Parameter count alone therefore did not determine the result. The tools and permissions exposed by the system shaped whether agents considered retraining, while model capability shaped whether they could finish the job.

The fix carried data with it

Irregular placed six synthetic secrets in the fine-tuning dataset, including an API key, an email address and a home address. The original model reproduced none of them. After the agent trained and deployed the modified model, it reproduced those three values verbatim in a separate evaluation.

The setup intentionally made memorization observable: the values appeared directly as training targets. The result cannot be used as an estimate of how frequently ordinary fine-tuning exposes private data. It demonstrates a concrete path by which information available during maintenance can become embedded in a deployed model and remain recoverable after the original data source disappears.

A second test examined learned restrictions. Irregular started with a model trained to refuse questions about fictional competitors, then told the agent that the application was refusing too many requests. The agent used fine-tuning to remove the behavior. In one representative run, the model refused all 10 held-out questions before training and none afterward.

That policy was benign and artificial. The experiment still shows why a checkpoint diff is an incomplete security record. A model update can repair one measured behavior while removing another, and the updated weights cannot explain which data or rules changed.

The founders built Irregular for this category of surprise

Lahav and Nevo founded Irregular, initially called Pattern Labs, in 2023 after meeting through competitive debating. The pairing combines AI research with offensive-security experience.

Lahav's biography lists work at IBM AI Research and Project Debater, research published on the cover of Nature and teaching at Tel Aviv University. Nevo spent 12 years in Israel's Unit 8200, founded Y Combinator-backed NeoWize and later worked at Google on AI systems using satellite data to identify wildfires, according to a 2025 Forbes profile.

Irregular's business rests on finding behavior that standard software tests fail to anticipate. It runs simulated environments for frontier labs, testing models as attackers and defenders before release. Irregular has worked with Anthropic, OpenAI and Google DeepMind, and its evaluations have appeared in model system cards.

In September 2025, Irregular announced $80 million in seed and Series A financing led by Sequoia Capital and Redpoint Ventures, with participation from Wiz CEO Assaf Rappaport. TechCrunch reported a $450 million valuation, citing a source close to the deal. Irregular said at the time that it was generating millions of dollars in annual revenue.

The Qwen work pushes Irregular beyond evaluating whether a model can find vulnerabilities or execute an attack. It examines what happens when an agent has ordinary engineering tools and broad authority inside a system whose model is itself editable.

Lahav told Forbes that existing defenses are unprepared for agents that can continually alter such systems. The immediate engineering answer is less exotic than the risk: separate authorization for training and deployment, immutable production checkpoints where possible, independent evaluation and a retained record of the source model, training data, procedure, resulting artifact and approvals.

Those controls impose friction on the self-hosted, all-access agent setups that make open-weight models attractive. Irregular's experiment shows what that convenience can conceal. A coding agent can complete its ticket, pass the tests and leave every subsequent user running a different model.