← Back to blog

Branching as a Design Exploration Technique

Nuit Team · · 12 min read
branchingaiarchitectureconcept-designworkflowexploration

Branching is the single feature that changes how AI concept design actually feels. Most architectural AI tools, including the strongest image models on their own, treat each prompt as a fresh start: write, generate, replace, repeat. Branching breaks this loop by making every image a fork point — variations grow from a parent, the parent never disappears, and the canvas accumulates a tree of decisions rather than a list of unrelated artifacts. The effect is that exploration becomes free, comparison becomes honest, and going back to a previous direction costs nothing. This article is the deep dive on why branching matters for architectural concept work, how it works in practice, and why architects who do not use it leave most of the value of AI on the table.

This is one of the satellite pieces of the topic cluster on architectural AI workflows. The pillar is Nano Banana for Architecture: Where It Works, Where It Falls Short. For consistency-specific mechanics see How to Get AI to Generate Consistent Designs Across a Project. For phase modeling see One AI Tool for Exterior, Plan, and Interior.

The Default Workflow and Why It Hurts

The default workflow for a designer using a general image model goes like this:

  1. Write a prompt.
  2. Generate an image.
  3. Like 80% of it. Want to change the other 20%.
  4. Edit the prompt and regenerate.
  5. The new image fixes the 20%, breaks something else.
  6. Edit the prompt and regenerate again.
  7. After fifteen rounds, you have a folder full of images. The folder is sorted by time. The names are auto-generated. You do not remember which one was the one you liked.

This loop has two structural problems. The first is state loss: each regeneration replaces the previous state in your attention, even if the file still exists somewhere. The second is comparison difficulty: when you do scroll back, the images are laid out in linear time, not in the logical structure of your decisions. You cannot easily see which version is a sibling of which, or which decision led to which result.

For mood images or single hero renders, this does not matter much. For concept design, where the entire job is making a sequence of related decisions, it is the core problem. Concept design is exploration. Exploration that loses state is not exploration — it is wandering.

What is branching, actually?

Branching is the workflow operation where a new generation explicitly grows from a parent image. The parent remains. The new image is a child. The relationship between parent and child is preserved as data, not as memory of which file came after which.

Mechanically in Nuit, every generated image has three forward paths:

  • Branch. Create variations from this exact image. The original stays on the canvas. The variations appear as children, visually connected by a line.
  • Improve. Refine this exact image in place — same composition, change a specific element. Optionally annotate the image (draw on it, select a region) to mark what should change.
  • New Prompt. Start a fresh direction unrelated to this image. Useful when you want to try a different concept entirely.

Branch and New Prompt produce different children. Improve modifies the image in place. All three preserve previous state. None of them destroys the image you started from.

The result is that the canvas accumulates a tree, not a list. The root is the first generation. Each successful image can have children. Each child can have children. Going back to a previous direction means clicking on a node in the tree — it is still there.

Why do trees beat lists for concept design?

The reason this changes work, rather than just being a nicer UI, is that the work you are doing is fundamentally tree-shaped.

A concept-phase project is a series of decisions, each of which depends on the previous ones. You start with a high-level direction (modernist villa in Bali, two stories, indoor-outdoor). You generate. You like one of the three variants. From that variant, the next decision opens up — which roof typology, which material palette, which way the entrance faces. Each of those decisions has its own set of plausible answers. You want to see two or three of them before committing.

If your tool models work as a list, every decision overwrites the previous one. To explore three roof options on the variant you liked, you have to either:

  • Regenerate three times in a row, losing each intermediate state.
  • Save each image manually to a folder with a hand-written name, then keep track of which folder represents which decision branch.

Neither scales. After two or three layers of nested decisions, the cognitive cost of keeping track exceeds the cognitive cost of the design work itself.

A tree models the work correctly. Each decision is a node. Each alternative is a sibling. Going back is a click. Showing a client three directions is showing them three branches that share a parent. The tree is not a feature added on top — it is the right shape for the work.

The Economics of Exploration

A practical way to understand why this matters: branching changes the cost of trying things.

In a flat-list workflow, the cost of trying an aggressive variant is the loss of the safe variant. You generated the safe exterior. You consider a more dramatic version. To try it, you have to commit — regenerate, and the safe version recedes into history. If the aggressive version is worse, getting back to the safe one is painful enough that you stop trying.

In a branching workflow, the cost of the aggressive variant is the cost of one generation. The safe version is still on the canvas, right next to the aggressive one. If the aggressive variant is worse, you ignore it. If it is better, you keep going on that branch. Either way, you keep both options visible.

The effect on actual design behavior is significant. Architects working in a branching workflow try more variants per project, commit later to a final direction, and produce concept packages that show clearer thinking — because the thinking is preserved in the tree.

A specific number from internal usage data: in projects where the user uses branching, the average number of generations per project is roughly fifteen times higher than in projects where the user does not. Generations cost money. The increase is not waste — it is the exploration that the workflow makes possible.

Selecting What to Change: Annotation in Branch and Improve

The other piece of branching that is easy to miss is what it accepts as input.

A naive branch operation accepts only a text prompt for the variation. That is fine for “more dramatic,” “lighter materials,” “different time of day.” But concept design often involves changing one specific element of an otherwise good image: the front door, a specific window, the proportion of the roof on one corner, the lighting fixture in the kitchen.

Nuit allows annotation on the image when you Branch or Improve. You can draw on the image with a brush or rectangle, in any of several colors, to mark exactly what should change. The annotation is composited with the prompt and sent to the model as a structural hint. The model then changes the marked region and leaves the rest alone.

This is a small affordance with a large effect. Without it, changing a single element of a good image means writing a prompt that describes the entire image plus the change, and hoping the model preserves what was working. With annotation, you point at the thing.

When is branching not the right move?

Branching is the default move, but it is not the only one. Honest list of when something else fits better:

  • You are happy with the image as-is and want to keep it. Click Save. The image becomes a saved-concept reference for the project and stays accessible without further generation.
  • You want a completely different direction, not a variation. Use New Prompt, not Branch. Branch grows from the parent; if the parent is not the starting point you want, you are paying a cost for nothing.
  • You want to fix the model’s quality on a specific image without changing the design. Use Improve with a quality-focused prompt (“restore detail, fix soft edges”) and no annotation. This is for re-rendering at higher fidelity, not for design changes.
  • You want to explore a completely new project. Create a new project. Branching is per-project; cross-project branching is not a thing and should not be.

The reflex to develop is: when the image you have is mostly right and you want a variation, Branch. When the image is mostly right and you want to change one specific element, Improve. When the image is wrong and you want to start over conceptually, New Prompt. When the image is right and you are done, Save.

Why do most architects not discover branching on their own?

A specific note from product usage, in case it is useful: most architects who try an AI workflow tool for the first time do not click Branch on their own. They click New Prompt — because the muscle memory from working with general image models is “regenerate to iterate,” and Branch looks like just another generate button.

The result is that the same tool, used without branching, produces the same flat-list experience as a general image model. Used with branching, it produces a structured tree. The difference is roughly an order of magnitude in how much exploration happens per project.

This is why purpose-built tools surface branching prominently in onboarding and why they default to multiple variations per Branch operation (three, in Nuit’s case). The discoverability of the feature is the bottleneck for new users, not the feature itself.

If you are using a workflow tool and not branching, you are using it as a slower image generator. Try branching the next time you have a generated image you mostly like. The change in how the work feels is immediate.

What Branching Enables in Practice

Three concrete things change when branching becomes a habit:

Multiple directions stay alive longer. Instead of committing to a direction at iteration three, you can hold two or three directions open through iteration ten or fifteen. The right direction usually only becomes clear after several rounds. Branching lets you keep options open without paying the cost of starting each over.

Client presentations get clearer. Showing three directions from the same parent is structurally honest — they are siblings, they share the brief, they differ only on the dimensions you wanted to compare. Showing three unrelated images and calling them “directions” is dishonest, and clients can feel it.

Going back is free. Concept design is iterative, and the final direction is often a return to something you tried at iteration five. With branching, that earlier node is right there. Without it, you are reconstructing it from memory of what prompt you wrote three days ago.

A Short Note on Naming

Branching is borrowed terminology from version control — the same operation a developer performs in Git. The analogy is exact enough to be useful. A repository has a main branch and feature branches. A project has a primary direction and explored variants. Merging the variants is, in the architectural case, a curator’s job — you pick the variant that becomes the next main direction. The rest stay as ancestors on the tree, recoverable if the design changes course.

If you are coming from a software background, branching is intuitive. If you are coming from a design background, the underlying mental model takes one project to internalize. After that, the flat-list workflow of a general image model feels uncomfortable — like editing a document with no undo history.

Try It On Your Next Project

The recommendation is simple: on your next concept-phase project, make a rule that you Branch instead of New Prompt whenever the image you have is something you would consider keeping. Even if you do not end up using the branched variants, the tree of decisions you build is the deliverable. Clients respond to the structure. You respond to the speed.

Nuit defaults to three variations per Branch operation. The default is deliberate — exploring three siblings is the move that makes the tree useful. Adjust the count in the toolbar if you want fewer or more.

For the wider context, the pillar is at Nano Banana for Architecture: Where It Works, Where It Falls Short. For the head-to-head if you are still deciding which tool, see Nuit vs Nano Banana: When Each Fits.

Start designing with Nuit

Generate architectural concepts from a simple description. No sketches, no 3D software.

Try it free