Lovable Deleted Almost All Its Agent Code: What 100,000 PRs Teach About Agent Freedom

Lovable deleted almost all of its autonomous agent code and rebuilt around a short, predictable tool chain—that is the headline from co-founder Anton Osika’s November 4, 2026 technical post after more than 100,000 pull requests on the platform’s own codebase and 70 million user projects. The company had experimented with async subagents that delegated work without a clear stopping point; Osika writes that the design made the product less dependable and sent the team back to one user request → bounded file edits → live preview, with humans steering the next step. If you ship or govern Claude Code, Codex, or in-house coding agents, the essay is a field report on how much autonomy actually works before reliability and trust break.

explainx.ai’s harness leaderboard piece tracks a similar question—how reliable coding agents are when left unattended. Lovable’s answer from production: unattended autonomy was the wrong default for their audience.

How Lovable narrowed the problem first

Osika traces Lovable to GPT Engineer in 2023: describe software, get a codebase. The product bet was greenfield apps only—users bring an idea; Lovable generates, hosts, and iterates through chat. That let Lovable pick an opinionated stack and own the runtime, instead of wrestling arbitrary legacy repos.

Image: Lovable

The post’s design rule is explicit: constrain the problem, control execution, learn from results. Security teams hear the same idea as reduce the attack surface—fewer dependency shapes, fewer entry points, fewer places an agent can wander. It is not a substitute for monitoring, but it lowers variance.

Matching agent freedom to model ability

Keeping apps working across many user edits was harder than first generation. Osika pushed for autonomous agents expecting models to improve; engineer Mårten Wiman built a sophisticated async system where agents spawned tasks and subagents.

That path failed product requirements:

• Agents entered technical rabbit holes.
• Errors compounded without a predictable finish time.
• Non-programmers could not inspect or repair the result.

So the team deleted almost all agent code and returned to a single response with requested file changes, chat, and preview—by late 2024, without a long “run tool → observe → choose next tool” loop. Native tool calling was not reliable enough then; the model wrapped edits in XML-like tags such as <lov-write> parsed after completion.

That history matters for Claude Code shops flirting with always-on subagents or headless loops: Lovable’s users are less technical than the median IDE engineer, but the failure mode—unbounded tool chains—shows up anywhere review is thin. See Meta Project OT for the enterprise mirror image: high autonomy without matching controls correlated with more incidents in reported internal metrics.

Lovable also selected context with small fine-tuned models to decide which files to show the editor model—another constraint on what the agent can “see,” paralleling context budgeting in local agent security guidance.

Knowledge files instead of fine-tuning

Osika planned fine-tuned models trained on failure data. In 2024 they shipped something simpler: engineers read broken chats and wrote knowledge files—short rules such as “only use icons that exist in lucide-react.” Retrieval pulled the right notes into context.

Image: Lovable

Osika compared the pattern to a scaling law: each file helped the next user without waiting for training jobs. That is structurally the same idea as agent skills and MCP instruction files today—textual policy shipped beside the agent, versioned with the repo.

For security readers, knowledge files are double-edged. They are how you encode safe defaults; they are also supply-chain text anyone with write access can poison. Beam’s heuristic SKILL.md scanner catches known bad patterns, not semantic malice—still worth running before you adopt third-party “reliability” packs.

Lovable Stack Overflow—internal retrieval of solved problems—reportedly cut “stuck” rates by about 5% in an early version, per the post.

Faster feedback: sandboxes and Camille

Agents that self-correct still waste wall-clock if every attempt triggers a full production build. Lovable invested in:

• Sandboxes that keep project files and dev servers warm during editing.
• Incremental TypeScript checks that reuse work from prior checks.
• Stateful checkpointing that saves CPU, memory, and disk so an agent can resume days later—framework Camille for forking and merging running environments.

Osika links a demo video on the post showing many agents on checkpointed machines. Faster feedback reduces the temptation to let models loop longer to compensate for slow verification—loops that increase risk on developer machines too.

Forking environments is not the same as isolating them

Checkpointing CPU, memory, and disk lets Lovable branch experiments from the same running app—a product feature Osika says now underpins “try three approaches and pick one.” Security readers should separate convenience from containment:

• A forked sandbox still runs user-requested code with whatever secrets were already in that project’s database or env files when the snapshot was taken.
• Merging a fork back is a product-level operation; it is not automatic code review. Poisoned dependencies or exfiltration logic can ride along if the human accepts the merge.
• Stateful sandboxes are not a substitute for network egress controls described in Agent Baseline’s software factory reference architecture.

Lovable owns the hypervisor layer; you own different boundaries on a laptop running Claude Code. The lesson transfers as “speed up verification”, not “skip perimeter controls.”

XML edits, tool calling, and why the loop shape mattered

When native tool calling was unreliable in 2024, Lovable had models emit structured edit blocks parsed after a single completion. That is structurally similar to early Skills patterns and to MCP tool payloads—text the harness must parse before anything executes.

A single-shot edit with retries on parse errors gives the harness a finite state machine: request → parse → apply → show errors → maybe retry. An open agent loop can chain dozens of invisible steps—harder to log, harder to explain to an auditor, and harder for a non-engineer to interrupt.

For teams building internal harnesses:

Osika’s deleted code sits in the third row; Lovable moved left. Your org’s acceptable column depends on who reads the diff and what data the workspace holds—the same trade-off 0RWX-style permission thinking encodes for individuals.

Inside Chats and the return of multi-agent design

Lovable has since published Inside Chats: How Lovable's Agents Work Together (September 2026), suggesting multi-agent coordination returned in a more bounded form for specific flows. Osika’s November post is a reminder that those designs are reversible: what ships as “agents working together” can still be dismantled when reliability metrics slip.

Watch product changelogs for default autonomy toggles, not only model upgrades. A better model does not automatically make an infinite loop safe.

What Lovable says is still unsolved

The post’s closing section is candid about production trust:

• Lifecycle automation—testing, deploy, uptime, security while “you sleep.”
• Broader software types—mobile, realtime, global systems—each with new failure modes.
• User trust when “one misunderstood request can delete data or break something that can’t be undone.”

That is the same bar local agent security tools aim at: not “can it write code?” but “can I prove what it did before damage sticks?” METR’s reporting on unmonitored Codex time quantified how much agent runtime can elude review without instrumentation.

What this means if you run AI coding agents

Osika’s rewrite translates into checks you can run this week on Claude Code, Codex, or an internal harness:

1. Cap open loops. If your harness allows unbounded tool rounds, set a hard stop and surface the partial diff—Lovable’s deleted agent code is an existence proof that product teams ship without infinite autonomy.
2. Prefer file-based instructions over mystery prompts. Check knowledge files and skills into git; review them like code. Run beam scan or equivalent on new skill directories before agents load them—see MCP server security review.
3. Measure time-to-verify, not time-to-first-token. Invest in fast typecheck, test shards, or sandbox restore—the less each retry costs, the less you need dangerous autonomy.
4. Match audience to freedom. Engineers may tolerate wider tool access; analysts should not inherit the same loop limits without review—echoing Goldman’s reported Claude Code restriction to engineers on trading floors.
5. Plan for destructive commands explicitly. Osika names data deletion from misunderstood requests; wire PreToolUse denies for rm, credential reads, and outbound curls on repos that matter.
6. Audit instruction files on every change. Knowledge files scaled reliability for Lovable; they can also scale bad guidance if an attacker or careless editor adds one. Treat them like Terraform modules—peer review, version pins, and periodic rescans.

If you are evaluating a hosted builder versus local Claude Code, ask whether their agent can:

• Show you a complete tool trace for a session.
• Limit steps without a support ticket.
• Export dependencies for supply-chain review.

Osika does not claim Lovable has solved those for production trust yet; your internal tools should not pretend either.

What Beam can and cannot do here

Beam does not run inside Lovable’s cloud builder. On local Claude Code and Codex sessions it can:

• Scan SKILL.md and MCP configs with 11 heuristic patterns plus a version-pin check before you run them.
• Capture and redact hook events, retaining bounded local history.
• Deny some PreToolUse proposals when workspace policy is cached and enforce mode is on—fail-open if policy is stale.

That complements architecture choices like Lovable’s bounded chain: scanning catches poisoned instruction files; hooks catch risky tool proposals; neither replaces sandbox isolation or hosted-platform controls Lovable builds separately.

Related reading

• Trail of Bits on regression hunting with agent skills
• Meta Project OT and unchecked coding agents
• METR: unmonitored Codex time
• NVIDIA SkillSpector open-source skill scanner
• MCP server security review

Frequently asked questions

Did Lovable remove all AI from its product?

No. Osika describes removing orchestration-heavy autonomous agents, not models. Users still edit via chat; the backend uses bounded edits and preview.

Why did Lovable step back from subagents?

Unpredictable completion time, error cascades, and users who cannot debug code made open-ended agents less dependable.

What are Lovable knowledge files?

Engineer-authored instruction snippets retrieved into context—functionally similar to skills, credited with late-2024 reliability gains.

How does Lovable shorten agent feedback loops?

Warm dev servers, incremental TypeScript checks, and Camille checkpointing to restore running environments quickly.

What risks does Lovable still call out?

Production lifecycle, security, and irreversible user mistakes remain open problems requiring stronger controls than greenfield generation.

How does this relate to local agent security tools?

Bounded loops reduce surprise actions; local scanning and hooks still matter on engineer machines running Claude Code or Codex.

Lovable’s post and product details were accurate as of November 8, 2026.