Legolizer | Devpost

Legolizer
GIF
Waterfall
GIF
Princess with sword
Kevius
Ryon
Toby
Wyatt
Duck

Inspiration

Our team is very passionate about creation and creativity in all forms. This project let us experiment with new technologies and development techniques, while also creating a tool that we would use for our hobbies now and in the future. We didn't want to make something we had seen before, but we still wanted to produce a fully fleshed project, so choosing something at an intersection of our skills and knowledge while still using unfamiliar technology was the perfect marriage.

What it does

Legolizer, in a sentence, takes any idea you have for a Lego structure and produces a complete assemblage building it, with full piece breakdown and instructions. In slightly more words, we arrange real Lego brick shapes in possible arrangements while matching shape and color to mimic the user's request as closely as possible. While this pipeline is the core of our project, we are especially proud of the ways we use it: we allow moveable AR integration of the completed models, so hobbyists and decorators can see how it would look in a space before building it; we allow fine-grained replacement or iteration on the produced model to fix any issues the user may have; we make the acquisition and reformatting parts easy for the user by linking to direct brick purchases and downloadable models and instruction guides; we support the Lego hobbyist community by allowing sharing and viewing of others' created models; and (maybe most importantly), we emphasize cost and scalability in our architecture to make this something we could continue in the future.

How we built it

While our Github demonstrates much more technical depth (please feel free to use our knowledge base skills to learn more about our tech stack! We had a lot of fun building out DevEx to aid us during this project--more on this later--and a navigable codebase was important to us), we will provide a relatively brief overview of our tech stack. Upon submitting a prompt, we first pass the raw input through a low effort Grok call to flesh out the prompt for a fuller style (only if the user requests it), along with deciding if a reference image is needed. If so, a Creative Commons image is acquired from the web and passed (along with the final prompt) to Grok Imagine, where we generate Lego-style concept art in an orthographic projection, alongside structured information. This is finally passed to GPT-6 Sol (for advanced spacial reasoning capacities compared to other frontier models), where LDraw's CAD capacities are integrated to ensure a valid assemblage. This step is iterated adversarially against a reviewer agent to ensure that the produced model satisfactorily matches the prompt and the orthographic projection of the concept art. From here, LPub3D is leveraged to create detailed, layer-by-layer schematics and guides for replicating the builds. The guide and model are stored to S3, with a pointer to the S3 item being entered in DynamoDB alongside general prompt and user data. The model is served via Fargate. AWS Secrets Manager and CloudFormation are used to manage the AWS environment (secrets and schema updates). We use Vercel to deploy our front end and API. Finally, Google Sign-In is used to facilitate and authenticate accounts.

Note on AI-Assisted Development

Thanks to the generosity of SpaceXAI, we had access to vastly more coding agent assistance than we had initially expected. As such, we made the decision to focus on quality and architectural decisions of our product, while creating a helpful DevEx ecosystem, as opposed to scrambling to add more and more features than may not be in line with what we actually wanted out of our project. We feel this paid off, as we invested early in setting up a development environment that actually supported the correctness we wanted from our code--we didn't just want something good enough to demo, we wanted something good enough to use after the hackathon. To this end, we heavily invested in GitHub Actions and Checks, making sure that all PRs were required to pass extensive testing before being able to merge. We leveraged Cursor agents to perform routine audits of our test suite--ensuring that all tests were actually meaningful (ie, if the behavior they were testing for failed, the test would fail too) and required 75% code coverage for each diff submitted (though we often added retroactive tests to our suite later on when we encountered errors, leading to upwards of 90% coverage by the end). Additionally, we mirrored our repo structure in the ~/.cursor/docs/ folder, and maintained strict AGENTS.md (check the top level one for more information here) coverage in all of our codebase. Alongside this, we built dev-facing skills to evaluate code quality, learn about the codebase, or check CDK pipeline status for smoother development. We used an issue-based software development cycle, flagging any problems as new issues, and maintaining routine sweeps to pick up unclaimed tickets.

Challenges we ran into

Early on in our DevEx setup, we tried to enable automatic Bugbot code reviews on PRs touching sensitive code. However, our repo owner's model usage credits had ran out, so we moved code review to dev-side, handing off Cursor Auto model generated PRs to either Claude Opus 5.5 or GPT-6 Sol for an in-IDE review (posting any relevant review findings on the PR). We additionally struggled with the final voxelation (building the model from an orthographic projection)--we iterated on our process here pretty much the entire hackathon (I'm sure you can find some relics buried in our PR history), and we're at a state that we're very proud of, but if we had more time we'd love to triangle back on this!

Accomplishments that we're proud of

First and foremost, we are very proud that we were able to deliver a functioning project. Going above and beyond, having a scalable and functional project, instead of just a demo is something that we can rarely say at a hackathon, so that was a rare treat. We are very happy with the final state of our voxelation part, compared to the earlier iterations. Additionally, we all gained experience with a technology we previously didn't know--AR, LPub3D, Grok Imagine--which is always a W. Finally, becoming more comfortable with being a successful developer in the age of AI feels really good--being able to set up a functional and scalable environment and then actually build stable and safe software in just over a day made us all feel more confident on our marketability in an honestly mildly cooked job market.

What we learned

How to spawn 50 subagent swarms to refactor our frontend. More importantly, how to do so in a manner that was easy to roll back when it didn't work. We also learned how to use AR technology, LDraw and LPub3D for CAD integration, and Grok Imagine for efficient and high quality image generations.

What's next for Legolizer

We love the state of the project now, but the overall type of project--3d model obeying some laws (in our case, the assemblage being possible) from a prompt--is so widely applicable. We're especially excited about its usecases in robotics design, and we'd also be curious to see how physics engines can integrate with this to minimize block count while sustaining structural integrity.