bolt.diy Local Model Hands-On Test: Code Was Generated, but the Registration Page Never Ran

A Real "Get It Working" Test

Handing a registration page requirement for a ten-person event to bolt.diy while connecting a local 8B vision model—this combination seemed capable of closing the "look at an image and write code" loop. The requirement itself wasn't complex: the page should show registration success, the backend should add a three-person record and deduct the remaining seven spots; duplicate submissions of the same registration shouldn't deduct spots again; data should be stored server-side and readable after a restart; the same event and email shouldn't allow duplicate registration.

The author fed the prototype image and the rules into the same request, expecting a complete project to be generated. The result: the code was indeed generated, but the registration page never ran. This outcome is more informative than "generation failed"—it exposes the breaking points of a local model combination in real engineering.

Round One: Planning Stuck at Six Steps, No Code Yet

The workbench handled step planning, and the model handled reading images and writing code. It got stuck in the first round: after tool-call retries, the plan still exceeded the six-step limit, and it was repeatedly merged down to six steps before the model read the project file list.

The plan passed, but the registration code still hadn't been written. Then came a long wait—the workbench waited two minutes without receiving new content and resent the request; but the local model was actually still generating. The author raised the local model's wait limit to ten minutes and fixed the cancellation handling when recording requests. After continuing the task, another call path was found to still wait only 45 seconds, which had to be patched as well.

All these runtime adjustments were done manually. In other words, the "usability" of the local model combination was built on extensive manual tuning, not out-of-the-box readiness.

Tool Calling and Agent Workbenches: The article's description that "the workbench handled step planning, and the model handled reading images and writing code" describes a typical Agent orchestration pattern. The workbench (such as bolt.diy) is itself an orchestration layer that breaks user requirements into multiple steps; each step requests structured actions from the model through a "tool calling" interface (such as reading files, writing files, executing commands). What the model returns is not free text but JSON conforming to a preset schema, and the workbench executes real operations accordingly. Because small local models have weak adherence to complex schemas, problems such as exceeding the step limit and invalid formats often occur, so the workbench needs to retry, merge steps, or even truncate the plan—this is the technical root of "the plan stuck at six steps" in the article. Understanding this layer is necessary to understand why "generation failure" does not necessarily mean the model cannot write code, but that the orchestration protocol is difficult to run stably on local models.

The Code Landed, but the Page Wasn't Wired Up

After the second correction, the files were finally written into the project. The registration form component, save logic, and API entry point were all there, and the code could be exported.

Next, the project was started directly to see whether Xiaoyu could actually register three people. First the page: the workbench showed no available preview. Then the exported main page file was opened, and it still contained only the initial prompt and had not entered the plan—although the newly generated registration component appeared in the directory, the page had not wired it up.

Then the backend startup command it provided was run as-is in an independent local environment, and the process exited with the error on the first line: the configuration set the entire project as ES modules, but the backend loaded dependencies with Require, so the two styles did not match. The service stopped before it even began receiving registration requests.

Interoperability Conflict Between ES Modules and CommonJS: In the article, the backend exits immediately on startup, with the error that "the configuration set the entire project as ES modules, but the backend loaded dependencies with Require." This is a typical manifestation of incompatibility between two module systems in the Node.js ecosystem. After setting "type": "module" in package.json, all .js files are parsed as ES Modules by default and must use import/export; while require() is the CommonJS loading method and does not exist in ES module scope, so a ReferenceError is thrown on the first line. Conversely, ES modules cannot be directly loaded synchronously by require() either. A common mistake in generated code is mixing the frontend (Vite/ESM) with the backend (traditional CommonJS style) under the same project configuration without unifying the module format or using .cjs/.mjs suffixes to distinguish them. Such problems are easily overlooked when "the code looks complete," yet they crash the service before it receives any request.

A Fatal Logic Flaw Hidden in the Source Code

Source code inspection also found a problem directly related to the three-person registration: when calculating the balance, it counted the number of database records and then subtracted that number from 10. Under this logic, even if a record says three people, only one spot would be deducted.

This was discovered through source code inspection; the actual registration test had not yet reached this point. But its significance lies in the reminder: generated code "looking right" and "being right for the business" are two different things. Verification items such as saving, reading back after restart, duplicate requests, and spot checks were not executed in this round.

The Gap Between Business Logic Correctness and "Runnability": In the article, spot deduction is calculated by "number of database records" rather than "number of people," which is a typical semantic-level error—the code is syntactically correct and runs, but does not match the requirement semantics. Such defects are difficult for static checks or unit tests to find automatically, because tests are often generated by the same model and tend to inherit the same incorrect assumptions. In scenarios such as registration, inventory, and billing, the correct approach is to model "a record" as an entity containing fields such as number of people and status, sum the people field when deducting, and use unique constraints or idempotency keys to prevent duplicate submissions. The author's emphasis that "saving, reading back after restart, duplicate requests, and spot checks" had not yet been executed precisely shows that verification must cover business assertions and cannot stop at "files generated, command starts."

Onboarding Cost: Not Something You Can Calculate in a Few Minutes

Starting from no existing environment, workbench installation took about 4 minutes 41 seconds, and visual model download, verification, and registration took about 7 minutes. This does not include generation waiting, environment adjustments, and item-by-item verification.

Some interrupted calls did not return complete usage, so the author kept only known records and did not give a seemingly precise total—this handling approach itself is worth learning from: the true cost of local models is hard to summarize with a single generation duration.

The Result of This Round: Partially Complete

Final status: partially complete—the form, components, and backend files were generated, and the plan and runtime environment were corrected; but page wiring and service startup still had gaps. The three-person registration from the beginning had not yet actually been saved in this round.

The author also mentioned two alternative routes: for an interface starting point, see Screenshot to Code; if you already have a frontend/backend project and are used to modifying in a terminal, see Aider. When using images to assist modifications, the selected model must also have vision capabilities. These two routes were not run on the same task, so no ranking of generation quality is given.

If you want to use such tools to start a project, the author's advice is practical: put page wiring, startup, and one real read-back at the top of the checklist. For this local model combination, someone still needs to continue debugging before the registration flow can be connected.