Crear un servidor de Minecraft con un equipo de IA#1¡1 líder de equipo IA + 15 miembros creando un plugin MMORPG! 🤖

¡Hola! Soy Mojangcam 😎

Últimamente estoy creando un servidor MMORPG de Minecraft con unos amigos. Niveles, estadísticas, clases, habilidades, misiones, tiendas, mobs y hasta mascotas: todo funciona con plugins hechos por nosotros. El problema era que tenía que construir casi todo yo solo.

Así que cambié de método. Puse a una IA (Claude) como "líder del equipo de desarrollo" y debajo le asigné 15 equipos (planificación, diseño y un equipo de desarrollo por módulo) como tareas programadas de IA. Yo marco la dirección, entro al juego a probar y solo tomo decisiones.

Esta serie es el registro de lo que construimos así durante una semana. En el #1 empiezo por la estructura: "cómo trabaja el equipo de IA".

• 🧑‍💼 Qué hace cada uno: 1 líder + 15 miembros
• 📄 Cómo son las órdenes y los informes
• 🔀 Cómo se fusiona cuando varios equipos tocan el código a la vez
• 🧯 Los incidentes reales en que el equipo se detuvo

📌 ¿Por qué dividirlo en un "equipo de IA"? 🧠

Al principio lo hacía todo en una sola ventana de chat con la IA. Pero a medida que crecían los módulos, empezaron los problemas.

1. El contexto se desborda — mientras arregla la fórmula de combate, se olvida del código de misiones.
2. No hay trabajo en paralelo — solo avanza una cosa a la vez.
3. No queda registro — cuesta volver a encontrar "¿por qué decidimos esto aquella vez?".

Así que lo dividí como en una empresa de verdad. Cada miembro mira solo la carpeta de su módulo, y el líder mira solo el panorama general y la fusión.

📌 Paso 1 - Órdenes: no las digas, escríbelas en un archivo

Los miembros del equipo (tareas programadas) empiezan de cero, sin memoria, cada vez. Por eso escribo todo lo que tienen que hacer en un archivo. Cada equipo tiene un archivo orders/<팀>.md, y solo hay tres reglas.

• La sección ## 이번 실행 (esta ejecución) de arriba del todo es lo que hay que hacer esta vez
• Las órdenes anteriores solo se renombran a ## (이전 실행) (ejecución anterior) y bajan (no se borran)
• Cuando el líder ejecuta un equipo, no añade nada de palabra. Las órdenes van solo en el archivo

Así es un archivo de órdenes real (recortado en parte).

## 이번 실행 — 2026-09-30 #9 — 퀘스트 GUI 그림 연결
근거: 사용자 요청. 슬롯 배치 정본 = design/prompts-for-user_v7.md ① §3 표.
1. 배경: 창 제목 = 음수 공백 + 배경 글리프 + 흰 제목 (오르벨 메뉴와 같은 방식)
2. 아이콘 = item_model myserver:gui/quest/<id>, 설명은 전부 툴팁으로
3. 일지: 탭 0-1 메인 · 2-3 서브 · 4-5 일일 · 6-7 완료, 9-44 목록 36칸 …
9. 테스트: 슬롯 배치 단위 테스트, quest/ 밖 파일 수정 금지
시간: 11:45 전에 끝나면 오늘 테스트 빌드에 넣음

Vamos a desmenuzarlo parte por parte 💡

• Base (근거) : quién lo pidió y por qué. Más adelante es la respuesta a "¿por qué lo hicimos así?".
• Lista numerada : los miembros la usan tal cual como checklist.
• Pruebas y alcance : cada vez escribo vallas como "no toques nada fuera de tu carpeta".
• Hora (시간) : para lo urgente escribo algo como "si está listo a tal hora, entra en esta build; si no, en la siguiente", para que nadie rompa algo por las prisas.

Como las órdenes van en un archivo y no de palabra, al volver a ejecutar la misma tarea el resultado es casi igual, y el historial de órdenes queda tal cual. Esa fue la mayor ventaja.

📌 Paso 2 - Informes: que el líder los lea en 3 minutos

Al terminar, cada miembro deja un informe en reports/<팀>/YYYY-MM-DD_HHMM.md. El formato es fijo, así que el líder puede leerlo rápido.

Sobre todo, ① y ⑦ son importantes. La IA tiende a decidir de forma convincente lo que no sabe, pero al hacer que lo escriba aparte como "supuesto", más tarde pude revisarlo todo de una vez.

📌 Paso 3 - Fusión: los equipos en ramas, main solo para el líder

Con 13 módulos tocándose al mismo tiempo, lo que más me preocupaba eran los conflictos de código. Puse estas reglas.

• Cada equipo usa git worktree: su propia carpeta de trabajo + su propia rama (module/<팀>)
• Los miembros no cambian archivos fuera de la carpeta de su módulo — si necesitan algo del core, solo lo anotan como "petición al core"
• Fusionar en main, compilar y desplegar en el servidor lo hace solo el líder
• Antes de fusionar, el líder hace dos comprobaciones mecánicas
  • Si la rama tocó algo fuera de su carpeta
  • Si los nombres de los nodos de permisos siguen la regla (myserver.<모듈>.…)

# Comprueba si esta rama cambió carpetas fuera de su módulo (para pasar, el resultado debe estar vacío)
git diff --name-only main...module/quest | cut -d/ -f1 | sort -u | grep -vx quest

Por qué nació la segunda comprobación lo cuento en el #2. (Hubo un incidente en que dos módulos se apagaron por completo 😅)

Cuando termina la build, subo el jar a la carpeta plugins/update/ del servidor, para que la nueva versión entre al reiniciarlo.

📌 Los incidentes en que el equipo de IA se detuvo 🧯

1. El equipo se detiene en silencio — "esperando aprobación"

Durante un tiempo, los miembros no terminaban su trabajo y se quedaban parados. Sin errores ni avisos. La causa era una solicitud de permiso para borrar archivos. Como en las reglas de trabajo había puesto "si hace falta, pide permiso para borrar", un miembro pidió permiso para hacer limpieza y se quedó esperando a que una persona lo aprobara.

La solución fue cambiar las reglas.

• Los miembros no borran archivos. Lo que no se necesita solo se mueve a _to_delete/<팀>/
• Los archivos que hay que sacar de git, solo con git rm --cached
• Si de verdad hace falta la aprobación de una persona, no esperar: anotarlo como "bloqueado" en el informe y terminar

Lo más temible de un equipo de IA no eran los errores, sino que se quedara esperando sin decir nada.

2. Archivos de bloqueo de git

Como varias tareas tocaban el mismo repositorio, a menudo quedaban index.lock y HEAD.lock y bloqueaban la siguiente tarea. Lo resolví con una regla: en vez de borrarlos, moverlos a otra carpeta con un nombre único.

3. Si el PC se duerme, el equipo también

Los miembros trabajan en una carpeta conectada a mi PC. Si el PC entra en suspensión, la conexión se corta. Hice que el líder compruebe la conexión y, si no funciona, se programe a sí mismo para reintentar 1 hora después.

📌 Lo que hizo la persona vs. lo que hizo la IA 💬

Al final, lo que más hice fue entrar al juego, mirar y decir algo corto. Este reparto de papeles es el corazón de esta serie.

📌 Para cerrar

Hoy repasamos la estructura con la que trabaja el equipo de IA.

• Las órdenes en archivos, los informes en un formato fijo
• Los equipos solo en su propia rama, la fusión solo el líder
• La razón más común por la que un equipo de IA se detiene: esperar la aprobación de una persona

En el próximo episodio veremos la estructura de core + 13 módulos dentro de un solo plugin, el incidente en que unos módulos se apagaron por completo y el incidente en que el daño salía como 1000029. ¡No te lo pierdas! 🙌

Yo marqué la dirección de este artículo y lo redacté junto con Claude. Este servidor es un proyecto personal, no es contenido oficial de Minecraft y no tiene relación con Mojang ni Microsoft.