Most buildings are still designed as though nothing like them has ever existed. The staircase in your office was redrawn by someone who had drawn a hundred staircases before it, and will draw a hundred more.
That habit made sense when the drawing was the only place a design could live. It makes much less sense now. A building is not one enormous shape. It is a small number of parts, repeated and combined, each following rules that barely change from one project to the next. Treat those parts as building blocks that understand their own rules, and design stops being an act of drawing and becomes an act of assembly.
A staircase is a set of rules, not a picture
Look closely at any staircase and you find a bundle of relationships. Each step has a height and a depth, and the two are tied together so that people do not trip. Enough space must be left overhead so nobody hits their head. Long flights need landings to rest on. The whole thing has to rise exactly from one floor level to the next, no more and no less.
None of this is taste. It is logic, and logic can be written down once.
A digital block for a staircase carries that logic inside it. Tell it the height between two floors and it works out how many steps it needs, how long it has to be and where the landing goes. Ask it to fit into a narrower space and it either reshapes itself or reports, honestly, that it cannot. The block does not store a drawing of a staircase. It stores the knowledge of how to become one.
The same holds for an elevator, a floor plate, a corridor, a column grid. Each is a small, well-understood problem with a small, well-understood set of rules.
Blocks earn their value by how they connect
A block on its own is a convenience. Blocks that know how to connect to one another are something more.
An elevator shaft has to run straight up through every floor it serves. A staircase has to land where a corridor can meet it. Floors pass their weight down to the structure below. These are the joints of a building, and each block can be taught what it offers and what it needs at every joint.
Once the joints are defined, blocks combine into larger blocks. Stairs, elevators and service shafts gather into a core: the vertical spine most multi-storey buildings are organised around. The core then becomes a block in its own right, one that knows how to sit among floors. Floors stacked around a core become a building. The same interlocking toy bricks that snap into a wall can snap into a house, and the house can sit on a street.
This nesting is the whole trick. At every level, the larger assembly only has to understand the joints of the pieces inside it, not every detail of how those pieces work. A building does not need to know how many steps its staircase has. It only needs to know the staircase will reach the next floor.
You describe the space, and the system searches it
With blocks that shape themselves and joints that define how they fit, the way a design begins changes.
Instead of starting with a sketch, you start with a description of what is available and what is wanted: the outline of the site, how tall the building may go, roughly what it must hold. The system then does what people are slow at and computers are fast at. It tries arrangements. Core in the middle, core at the edge, two cores, a different floor depth, one more storey. Every combination either fits the rules or it does not, and the ones that fit can be measured and compared.
This kind of search already has a public track record. When Autodesk fitted out its Toronto office in 2017, the design team used algorithms that took engineering constraints into account to produce thousands of design possibilities, treating fixed items such as windows, stairs, elevators and the floor area as elements that could not be moved. Employees were surveyed about what mattered to them, six measurable preferences such as daylight, visual distraction and closeness to colleagues were fed into the process, and around 10,000 possible layouts were generated before the best were chosen.
What the Toronto project showed is that search does not replace judgment. It moves it. Because each option came with data on how well it met each goal, the options could be ranked and compared against one another, and the people involved spent their time arguing about trade-offs rather than about whose sketch looked better.
Block-based design takes this a step further. When the pieces themselves carry their rules, the search is not limited to shuffling desks inside a fixed shell. It can explore the shell too.
The idea came from architecture and is coming home
Composing designs from reusable, well-defined parts is not a new idea. It is an old architectural idea that spent a few decades abroad.
In 1977 the architect Christopher Alexander and his colleagues published A Pattern Language, a book that set out 253 patterns, each describing a recurring problem and a solution to it. The patterns ran from the scale of whole urban regions down to towns, buildings and eventually furniture, trim and door handles, and they were meant to be combined, the way words combine into sentences.
Software engineers took the idea and ran with it. Alexander inspired an early pattern language for user interfaces in 1987, and in 1994 a group of authors known as the Gang of Four published a book on design patterns for software that carried the concept to a much wider audience. Over the following decades, software learned to build almost everything out of components with clear boundaries: small pieces that each do one job and plug into larger systems through well-defined connections.
Building blocks for architecture close the loop. They take the discipline software refined, parts with clean joints that compose into larger parts, and return it to the field that first described it.
Improve a small block and every building improves
The most useful property of this approach is also the least visible one.
In conventional practice, a lesson learned on one project tends to stay on that project. Someone discovers a better way to lay out a staircase, and the improvement lives in one set of drawings. The next project starts again from the office's usual habits, and the lesson travels only as far as the people who remember it.
With blocks, the lesson lives in the block. Make the staircase block smarter, perhaps better at fitting tight footprints or more economical with space, and every core that uses that staircase inherits the improvement. Every building that uses that core inherits it too. One fix at the smallest scale ripples upward through every design that depends on it, without anyone redrawing anything.
This is how knowledge compounds. The value of the system grows each time any piece of it gets better, and the pieces can be improved independently by the people who understand them best. The engineer who knows lifts refines the lift block. The designer who knows stairs refines the stair block. Neither has to understand the whole building for their work to reach it.
The architect's job moves up a level
It is tempting to read all this as automation taking the craft away. It is closer to the opposite.
The blocks handle what can be written as rules: clearances, alignments, counts, fits. What cannot be written as rules stays with people. Which of the arrangements that work is actually the right one for this street, this client, this climate. What a building should feel like to walk into. Which trade-off between light and floor area is worth making. These questions do not get easier when there are more options on the table. They get more important.
What changes is where people spend their hours. Less time producing the hundredth version of a staircase, more time on the questions only a person can answer. And every good decision made along the way can be captured in a block and handed forward, rather than lost when the project closes.
A drawing records one building. A block remembers every building it has been part of.