ModSmith

ModSmith is an AI-powered Minecraft mod generator. You describe what you want in natural language — "a glowing apple that restores 4 hunger points" — and the system translates your idea into a fully compilable, installable Minecraft Fabric mod.

The core design decouples "user intent" from "code implementation": the LLM only translates natural language into a verifiable JSON blueprint, then deterministic templates generate the actual Java source and resource files. This approach is predictable, verifiable, and rollback-safe. Two layers of verification — compile-time and runtime — ensure the generated mod actually works before it ever reaches the player.

I grew up playing Minecraft and always admired modders who could turn their ideas into real in-game items. I wanted to do the same, but every time I opened a tutorial I hit a wall: Java, Gradle, Fabric API, resource pack formats — the learning curve was overwhelming, and I never knew where to start.

Then, at an MBZUAI admissions presentation, I heard about a senior's startup called ModCraft that could generate publishable mods from natural language. I was fascinated: how was this possible? Back home, I thought — I don't know much Java, but in the AI era anything seems possible. Could I build something similar myself?

So I started ModSmith. The goal was not to replace mod developers, but to let anyone with an idea — even without Java knowledge — turn that idea into a playable mod.

I read an article on the Fabric Wiki titled "Using LLMs for Minecraft Modding". It warned that beginners should not let LLMs write mods from scratch — you would miss the practice and have no ability to judge whether the AI-generated code is correct.

So I took the long route first. I taught myself IntelliJ IDEA and Java, then worked through the official Fabric tutorial manually. By typing every line myself, I understood the registry system, the relationship between Item and Item.Properties, the structure of resource packs and model JSONs, Gradle build flows, and the API differences between Minecraft versions.

Only after I had that foundation did I bring in AI. With the ability to judge correctness, I could now use LLMs as a multiplier instead of a crutch.

The system architecture is built around a clear separation of concerns: LLMs handle the "what" (translating intent into a structured blueprint), while hand-written templates handle the "how" (generating compilable Java and resources). This keeps generation deterministic and debuggable.

The web interface offers two distinct modes for two different workflows:

Chat Mode for iterative requirements clarification, powered by a Requirements Advisor agent that asks follow-up questions until the intent is fully specified;

and Execute Mode for one-shot generation with live progress logging, so you can watch each stage — blueprint, codegen, build, verification — as it happens.

Users can generate basic items, food items, and tools — each with their own template pipeline. The same blueprint drives both modes, so a spec refined in Chat Mode can be handed straight to Execute Mode without rewriting anything.

Every successful generation produces four downloadable artifacts: the full project source (ZIP), the installable mod JAR, the blueprint JSON for reproducibility, and a README with installation instructions. The generated content panel shows the complete blueprint with all item properties, visual settings, and localization strings.

The ultimate test: launching Minecraft and seeing the generated item appear in the inventory. The in-game verification panel shows live log output from the game launch, confirming that the mod loads without errors and the custom items are registered. In the screenshot above, the "Blue-Glowing Fruit" (generated from the description "Small, round, blue-glowing fruit") is visible both in the inventory slot and as a dropped item in the world.