RPCS3 ha actualizado sus normas para frenar la avalancha de código generado por IA que llega al proyecto. La regla es clara: la IA puede servir para investigar o para tareas de reverse engineering, pero el humano debe entender y asumir cada línea que envía. El cambio llega justo después de un mensaje en X en el que el equipo pidió parar los pull requests con “AI slop code”.
El movimiento importa porque RPCS3 no habla de teoría. Habla de mantenimiento real, de revisiones que consumen tiempo y de cambios que, si pasan el filtro, pueden romper funciones para todos los usuarios. También deja una pista de fondo sobre cómo se está gestionando el uso de google ai y herramientas parecidas en proyectos abiertos: no basta con generar código; hace falta probarlo, explicarlo y defenderlo.
La respuesta del proyecto fue tajante, incluso ante las críticas de algunos perfiles pro-IA en X. RPCS3 defendió que alcanzó su madurez con un 70% de juegos jugables varios años antes de que los LLMs se popularizaran. El mensaje es bastante directo: el proyecto no necesita ruido, necesita contribuciones que no añadan más trabajo al equipo de mantenimiento.
RPCS3 acepta la IA para investigar, pero bloquea el código que nadie entiende
Las nuevas normas permiten usar herramientas de IA con fines de investigación y reverse engineering. Hasta ahí, sin problema. El corte llega cuando ese apoyo se convierte en código listo para enviar: el colaborador debe comprenderlo por completo y asumir toda la comunicación con el equipo, incluidos comentarios en el pull request y notas en GitHub.
El texto también añade una advertencia práctica. Si una aportación ha sido creada por agentes de IA o herramientas automáticas, el PR debe incluir una declaración explicando qué parte generó la máquina y qué pruebas o revisiones humanas se hicieron antes del envío. Si esa información falta, el proyecto puede cerrar la propuesta sin revisarla. Y si las violaciones se repiten, llega el veto del repositorio.
La norma apunta a un problema muy concreto: código no probado, no verificado y, en muchos casos, enviado sin contexto suficiente. En un proyecto como RPCS3, eso no solo retrasa a los mantenedores. También puede acabar afectando a la funcionalidad de todos los usuarios si un cambio defectuoso se cuela en la base de código.
El caso de RPCS3 encaja con el ruido que ya sufren GitHub y cURL
RPCS3 no está solo en esta discusión. GitHub lleva meses lidiando con el peso de la IA “agentic”, con cambios de servicio en Copilot que incluyen pausas para nuevas altas de planes individuales y límites más estrictos de uso. El problema de fondo es parecido en todos los casos: más volumen, más automatización y más carga para quien revisa.
También cURL cerró este año su programa de bug bounty después de recibir un aluvión de informes que su responsable, Daniel Stenberg, describió como “AI crap”. La queja era la misma que ahora asoma en RPCS3: muchas herramientas no tienen el contexto necesario para redactar informes útiles o producir cambios fiables. El resultado es una montaña de trabajo para otros.
En ese mapa, la mención a Google AI y AICore o a servicios como Gemini no es casual: la expansión de estas herramientas está llegando a más capas del software, pero los proyectos abiertos están marcando límites más duros. RPCS3, que funciona en Windows, Linux, macOS y FreeBSD, ha preferido blindar su flujo de trabajo antes de que la revisión se convierta en una ruleta. Ese es el mensaje que deja la actualización: la IA puede ayudar a buscar, pero no a sustituir la responsabilidad del autor.
Qué cambia para los pull requests con IA en proyectos abiertos
A partir de ahora, cualquier contribución con participación de IA queda bajo una condición básica: transparencia. Si un agente generó parte del código, eso debe quedar declarado. Si el humano no lo ha probado ni entendido, la propuesta no debería seguir adelante. Es un filtro sencillo, pero muy explícito.
RPCS3 cierra así una puerta que ya había generado desgaste en otros proyectos. No elimina la IA del proceso, pero sí obliga a que el control siga en manos de la persona que firma el cambio. Con la comunidad viendo ya casos como GitHub o cURL, el mensaje es fácil de leer: el volumen de código no compensa cuando el coste de revisarlo y arreglarlo se dispara.
Puedes seguir a HardwarePremium en Facebook, Twitter (X), Instagram, Threads, BlueSky o Youtube. También puedes consultar nuestro canal de Telegram para estar al día con las últimas noticias de tecnología.
FAQ
No. El proyecto permite usar IA para investigación y reverse engineering. Lo que bloquea es el envío de código que el contributor no entiende o no puede asumir como propio.
Pide una declaración clara de qué parte fue generada por IA y qué revisión o pruebas humanas se hicieron antes de enviar el PR. Si falta esa información, el equipo puede cerrar la propuesta sin revisarla.
El proyecto dice que ha recibido demasiados cambios de baja calidad, sin pruebas y sin verificación. Eso consume tiempo de los mantenedores y, en algunos casos, puede romper funciones para todos los usuarios.
La noticia refleja el choque entre la expansión de herramientas como Google AI y la gestión real de repositorios abiertos. Cuanto más se usa automatización, más presión cae sobre la revisión humana y más estrictos se vuelven algunos proyectos.
