Your agent builds an app in minutes, but the third change breaks a previous screen. The usual response is to grant more autonomy or buy a more expensive model. On November 4, 2026, Lovable co-founder Anton Osika described a less obvious move: at one stage, the team removed almost all of its open-ended agent code and returned to a more predictable flow. His account helps founders decide what to improve first in an AI product, but Lovable's success is not a universal recipe.

What Lovable reported

In his official technical account, Osika says the codebase passed 100,000 pull requests and users created over 70 million projects. Those are Lovable-reported figures, not our own measurements. The valuable detail is in the engineering choices: the team started with new projects and an opinionated stack instead of supporting every existing codebase and environment immediately. That let them understand the execution environment and reuse fixes across projects.

When agents gained wide freedom to create tasks and delegate, the author says they wandered into technical rabbit holes, made more errors, and became hard to predict. Lovable stepped back to a user request that produced a bounded sequence of tools and a live preview a person could inspect. Later, as models and controls improved, the team expanded capability again. My inference for a founder: increase autonomy at the pace your system can verify results, rather than because autonomy sounds advanced.

A small experiment for your own agent

Choose one task your product often fails, such as “add a validated form” in apps that share a stack. For a week, record each request, changed files, build error, correction, and visible outcome. You do not need a giant evaluation platform: ten classified cases can reveal whether the main problem is missing context, excessive freedom, or weak feedback.

Then write a retrievable note for just the recurring failure:

# Forms in our product stack
Before editing, find the component and validation pattern already used here.
Do not invent component names or dependencies.
After the change, run typecheck and a test for invalid input.
If it fails, report the exact error and fix only related files.
Leave the preview and diff available for human review.

Compare five new tasks with the note against five without it, using the same project type. Measure first-attempt build rate, time to a correct preview, unrequested changes, and human interventions. If the note does not help, revisit context selection or task definition before piling on instructions. Lovable's “knowledge files” were short notes on recurring mistakes selected through retrieval—not one enormous prompt always attached to every request.

Feedback speed matters as much as model choice

Osika explains that Lovable kept sandbox files and a development server alive, with incremental TypeScript checks returning errors quickly to the agent. He also describes checkpointing memory, CPU state, and disk to resume environments. A small founder should not copy that entire infrastructure. Ask instead how long your edit → check → correct loop takes. If every change requires a full build and fifteen minutes of waiting, changing models may not fix the experience.

Start with a stable preview, a quick typecheck, and one test representing the user's failure. Save the conditions needed to reproduce it and let a person inspect the diff. Add autonomy only after the agent consistently detects and fixes that class of error without breaking another area. For data and payments, keep human review and production safeguards even if the demo feels effortless.

Verification status: the choices and figures attributed to Lovable come from Osika's article; the ten-case exercise is SoyJB's editorial proposal, not a test we ran or a Lovable metric. The useful outcome for your product is evidence about which constraint or feedback loop reduces its actual failures.