make it brick.

From prompts
to bricks.

Before this map came trained models, several languages and a lot of builds to check. Here’s what those experiments changed.

Back to the playground

Teaching a model about bricks

My starting point was to explore AI-generated builds. I prepared a corpus of LDraw models, a format that describes parts and their positions. Then I built tools to view them, check them and train models on that data.

With BrickIR, I tested complete generation as well as smaller tasks: adding a part, replacing one or continuing an assembly.

A correct file isn’t enough

Edits improved. Files followed the format more reliably. Yet in my experiments, a well-formed response could still produce a build that didn’t match the request closely enough. The parts, positions and connections needed checking beyond the generated text.

A good-looking 3D view doesn’t yet tell you how to build it.

Changing what we ask the AI to do

I tried several intermediate languages, from BrickIR to BrickScript, then Brickwright. Too many coordinates meant the model had to place everything. Shapes that were too abstract lost the details.

With Brickwright, the approach is to have the model describe an assembly’s intent: modules, symmetry and connections. A compiler then calculates the parts and their placement. Geometric and visual checks look for errors. This research continues; it isn’t a finished universal generator.

And now, a playground

Make it brick makes part of that work usable: pick a place on the map, turn its data into a model, edit it and explore 3D instructions. The tools developed around generation have become a project in their own right.