Articles
Urban Development
December 19, 2025
Early-stage urban design has always been weirdly backwards.
We start with vague assumptions, static massing blocks, half-baked feasibility spread sheets, and then spend months “refining” things that were wrong from the beginning. Everyone knows this. Everyone shrugs and keeps going.
Now the workflow is breaking. Not loudly. Just efficiently.
This is how we currently work at Hektar, and where AI models like Nano Banana fitin.
Traditional massing studies answer the wrong question first.
They ask: Whatcould this look like?
They should ask: What is actually viable here?
At Hektar,massing is generated directly from constraints:
The outputis not a single “nice” option. It’s a design space.
Multiple massing alternatives, all technically plausible, all comparable. Feasibility is not a later Excel exercise. It’s embedded in the generation step.
This matters because once feasibility is baked in, everything downstream becomes faster and more honest.
Right now,we’re actively testing a workflow rather than claiming a finished integration.
Instead of spending days polishing a single chosen option, we use Nano Banana to rapidly visualize multiple viable massing alternatives. The goal isn’t final architecture. It’s speed, comparison, and legibility.
Nano Banana helps us turn raw massing into spatially convincing visuals early enough to support decision-making, while keeping everything intentionally provisional. Nothing is locked. Nothing is over-designed.
At this stage, Nano Banana sits alongside our generation and feasibility logic, not inside it. That distinction matters. The real opportunity lies ahead, when these tools become natively connected rather than manually orchestrated.
Right now, we’re actively testing a workflow rather than claiming a finished integration. Instead of spending days polishing a single chosen option, we tested Nano Banana to rapidly visualize multiple viable massing alternatives. The goal isn’t final architecture. It’s speed, comparison, and legibility.
Nano Banana helped us turn raw massing into spatially convincing visuals early enough to support decision-making, while keeping everything intentionally provisional.
At this stage, NB sits alongside our generation and feasibility logic in Hektar, not inside it. That distinction matters. The real opportunity lies ahead, when these tools become natively connected rather than manually orchestrated.
The images below show early outputs from this exploration.
Even though the rendering itself is impressive, the real value isn’t the image. It’s the integration. We’re watching how tools evolve from “output generators” into workflow nodes.
A good example outside our stack is how Finch connected generative logicdirectly to plan layouts. Not images. Actual spatial logic.
Nano Bananawon’t just render massing. It will sit inside workflows:
No rework.No broken chains.
We’re now looking beyond buildings. One interesting approach for Hektar would be applying this logic at the detail plan level:
This process today is painfully abstract. PDFs, legends, interpretations. The future is simulated, visual, explorable.
Not to replace planners and architects, but to give them better tools than static drawings and hope.
None of this is about replacing architects, planners, or designers.
It’s about removing the slow, fragile parts of the process that everyone privately hates but publicly defends.
Early-stagedesign should be:
We finally have tools that make that possible. We’re juststarting to connect them properly.
