How Alloy works

What happens between pressing Generate and seeing your site: the alloy-1.5flash model, the project skeleton, guardrails and the preview.

The model: alloy-1.5flash

Every generation and every fix runs on alloy-1.5flash, Alloy's own model setup tuned for building ForgeStack projects. It is fast, writes typed code, and follows the project structure rules described below. You never need an API key of your own.

From prompt to project

  1. Scope check. Alloy first checks that the prompt is about building a website or app. Off-topic prompts get a friendly refusal and do not use your quota.
  2. Skeleton. Each project starts from a proven skeleton (site, admin or CMS) with routing, theme, translations and layout already wired.
  3. Generation. alloy-1.5flash writes the pages, components, data and copy on top of the skeleton. Files stream into the Studio as they are written.
  4. Guardrails. The server checks the result: Bear components instead of raw HTML tags, no stray CSS frameworks, missing translation keys filled in, images matched to your topic.
  5. Preview. The project is compiled and rendered so you can see it immediately, and the Live tab can run it in a sandbox.

Project structure rules

Generated code follows the same rules we use for Alloy itself, so it stays readable as it grows:

  • Every component lives in its own folder: Name.tsx, Name.types.ts, Name.utils.ts, Name.consts.ts and index.ts.
  • Types only in .types.ts, constants only in .consts.ts.
  • Imports use path aliases such as @components instead of ../../.
  • UI text comes from translation files (English, Hebrew, Spanish), never hard-coded.
  • Backends (App kind) follow routes → controllers → services.

Fixes and new versions

Each follow-up prompt in the Studio creates a new version of the same project. Alloy sends the current files as context and changes only what you asked for, so existing features keep working. Every version is kept, and when the project is linked to Git each version can open its own pull request.