The first version of an AI interface is no longer the difficult part.

Models can generate attractive screens quickly.

The harder questions begin immediately afterward:

Which direction actually represents the product?

Will the next page feel like part of the same system?

What happens when the idea changes?

Can one component be refined without disturbing everything around it?

And when the visual direction is finally right, can the frontend leave the design environment as real code?

The latest version of Autocraft is built around those questions.

Start with the business, not the page

One idea becomes three product directions

A new Autocraft project can begin with a simple business idea.

Instead of immediately committing that idea to one generated screen, Autocraft first turns it into three distinct product directions.

Each direction can differ in:

• Visual character
• Colour palette
• Typography
• Interface language
• Hierarchy
• Product atmosphere

The objective is not to create three cosmetic variants of the same page.

It is to make different interpretations of the product visible before implementation starts.

A financial product, for example, could become calm and advisory, highly technical and data-driven, or warmer and more human.

The underlying business is the same.

The product direction is not.

A visual system comes before scale

Each direction establishes a visual system before the project expands.

That system gives later generations a shared language rather than allowing every page to become an unrelated AI output.

The selected direction carries forward:

• Colour
• Typography
• Interface character
• Visual hierarchy
• Existing page patterns
• Relevant product decisions

Once a direction is selected, Autocraft begins by generating the first three pages as one connected product.

From there, the project can continue page by page.

Project-wide context

The agent should understand more than the current prompt

A product cannot stay coherent if every generation begins from zero.

Autocraft now carries project-wide context across the workflow.

That can include:

• The selected product direction
• The visual system
• Existing pages
• Interface patterns
• Previous product decisions
• Attached references and media
• The page or component currently being changed

This means a new settings page can be generated with awareness of the dashboard that already exists.

An onboarding flow can inherit the same product language.

A refinement request can be interpreted in the context of the complete project rather than as an isolated instruction.

The goal is simple:

The product should become more coherent as it grows, not less.

Draw directly on the canvas

Sketch-to-code is now native to the workspace

Some interface ideas are easier to draw than describe.

Autocraft now includes sketching tools directly on the infinite canvas.

You can roughly draw:

• Navigation
• Hero structure
• Cards
• Forms
• Actions
• Sections
• Approximate hierarchy

Then select that sketch and convert it into a rendered frontend interface with code.

There is no separate whiteboard, screenshot step, or external upload workflow required.

The sketch begins and remains inside the same product workspace.

Once generated, the result can be refined with the rest of Autocraft.

Three ways to refine

Design Chat for structural work

Design Chat remains the AI-powered refinement layer.

Use it when the change requires interpretation:

• Restructure a section
• Add a new interaction
• Change hierarchy
• Rewrite a layout
• Create a new component
• Evolve a complete page

The important difference is scope.

A user can target the page, section, or component that should change instead of treating the entire frontend as disposable context.

Quick Edit for deterministic work

Not every change deserves another model call.

Quick Edit is designed for obvious modifications where direct control is faster.

Depending on the editable property, users can change things such as:

• Text
• Spacing
• Common visual properties
• Layout details
• Other direct page values

AI should be used where interpretation creates leverage.

Direct editing should remain available where the user already knows the answer.

Manual canvas tools for spatial thinking

The canvas is also a working surface.

Users can sketch, arrange, compare, preserve alternatives, and inspect the whole product visually.

This matters because product decisions are often spatial.

Seeing three pages next to each other can reveal inconsistency that is difficult to notice when every screen is opened separately.

The whole product stays visible

Infinite canvas is not only a presentation layer

Autocraft keeps pages, sketches, references, directions, and iterations inside one visual workspace.

Zoom out and the product becomes a system.

Zoom in and one component becomes the problem.

That gives the workflow two useful scales:

• Whole-product reasoning
• Precise local refinement

The canvas is where those two scales meet.

Direction can evolve

Consistency should not become a prison

Selecting a direction does not permanently lock the project.

Users can continue generating within the current visual system when consistency matters.

They can also intentionally move toward another direction when the product itself evolves.

The distinction matters.

Autocraft should preserve direction by default without preventing deliberate change.

Frontend code remains part of the workflow

The output is not a screenshot

Generated pages are backed by frontend code.

Autocraft currently focuses on the frontend layer with HTML and React generation paths.

Users can inspect the code, export it, and continue development in the environment that makes sense for the rest of the software.

That could be:

• VS Code
• Cursor
• Codex
• Claude Code
• Another engineering workflow

The goal is not to become a permanent boundary around the project.

Autocraft should help establish and refine the frontend direction, then let the code continue wherever development needs to happen next.

Reliability after generation

The first generation is only the beginning

The difficult engineering problem is not producing one impressive screen.

It is preserving working output across repeated changes.

Autocraft's workflow includes systems around:

• Page and component targeting
• Structured generation workflows
• Validation before applying changes
• Saved history
• Recovery
• Rollback
• React and HTML transformation paths
• Media and reference handling

These systems exist because AI interfaces fail in ordinary ways.

A model can misunderstand scope.

A transformation can produce invalid code.

A broad change can damage something that was already working.

The product therefore needs a concept of the last stable state, not just the latest generated state.

Media can mean different things

An image attached to a project does not always mean the same thing.

Sometimes the user wants the exact asset used.

Sometimes the user wants only the composition, mood, or visual language as inspiration.

Autocraft keeps that distinction in the workflow so media can act as either an asset or a reference instead of being interpreted blindly.

Model-independent by design

AI model leadership changes quickly.

The model that is best for creative generation may not be the best model for precise refinement, multimodal interpretation, speed, or recovery.

Autocraft is therefore being built with a model-independent architecture.

The long-term product should not depend on one model provider remaining permanently ahead.

The workspace, context system, visual workflow, targeting, validation, and code ownership should remain useful even as the underlying intelligence changes.

What Autocraft is becoming

Autocraft is no longer best described as a prompt-to-page generator.

The product loop now looks closer to this:

1. Describe the business idea
2. Compare three product directions
3. Choose a visual system
4. Generate the initial three pages
5. Keep project-wide context as the product grows
6. Sketch new interfaces directly when drawing is faster
7. Refine with Design Chat, scoped editing, or Quick Edit
8. View the complete product together
9. Inspect and export the frontend code
10. Continue development anywhere

The objective is not more generation.

It is a better path from uncertain product thinking to a frontend direction worth continuing.