Grok lanza /goal para automatizar tareas largas, pero ya enfrenta quejas por borrado de archivos

xAI presentó /goal en Grok Build como una nueva función para ejecutar tareas de larga duración con múltiples subagentes autónomos que implementan y verifican un único objetivo. La propuesta apunta a ofrecer resultados confirmados en flujos de desarrollo complejos, aunque las primeras reacciones también dejaron reportes de cambios agresivos y pérdida de archivos en proyectos locales.
***

• Grok Build ahora incorpora /goal, una función de autonomía extendida con múltiples subagentes que planifican, programan y verifican en bucles.
• La herramienta usa espacios de trabajo aislados mediante git worktrees y guarda sesiones, planes y registros en la carpeta local de configuración de Grok.
• Durante las primeras pruebas públicas, Grok reconoció que la función aún tiene detalles por pulir tras quejas de usuarios por borrado de carpetas y archivos locales.

La herramienta de IA Grok sumó una nueva capacidad para desarrolladores con el lanzamiento de @grok /goal en Grok Build. La función fue presentada como un sistema para ejecutar tareas de larga duración de forma autónoma, con varias rondas de subagentes enfocados en implementar y verificar un solo objetivo.

La novedad apunta al segmento de asistentes de programación que buscan ir más allá de respuestas puntuales. En lugar de limitarse a sugerencias o fragmentos de código, /goal fue descrita como una capa de autonomía capaz de planificar, codificar, revisar y refinar hasta confirmar que el trabajo quedó completo.

El anuncio sitúa a Grok Build dentro de una carrera cada vez más intensa entre herramientas de desarrollo basadas en IA. En ese mercado, la promesa de “resultado verificado” se ha vuelto un diferenciador frente a sistemas que producen borradores útiles, pero aún dependen de supervisión humana continua.

En la descripción inicial, Grok explicó que /goal ejecuta “múltiples rondas de subagentes implementando y verificando un único objetivo”. Esa frase resume la lógica central del producto: delegación paralela, revisión interna y repetición del ciclo hasta alcanzar un estado confirmado.

La propuesta no pasó desapercibida porque también incorpora una idea fuerte en el discurso de xAI sobre desarrollo asistido. Según las respuestas públicas asociadas al lanzamiento, la herramienta fue diseñada para evitar “entregas esperanzadoras” y favorecer resultados comprobados mediante bucles internos de verificación.

Cómo funciona /goal dentro de Grok Build

Grok detalló que la función fue pensada para “autonomía seria”. En la práctica, eso significa que varios subagentes pueden planificar, escribir código y verificar resultados en paralelo dentro de una misma tarea compleja.

La lógica operativa se apoya en una sola meta declarada por el usuario. A partir de allí, el sistema distribuye el trabajo entre procesos o agentes especializados que refinan el avance en iteraciones sucesivas.

Una de las aclaraciones más concretas fue que los subagentes no se limitan a proponer cambios. Según Grok, estos agentes “codifican en paralelo, se verifican de verdad y entregan código que pasa las pruebas”, una formulación que refuerza la idea de validación interna antes de presentar un resultado.

La herramienta también busca una estructura más observable de delegación y control. En una respuesta posterior, Grok indicó que el valor de los sistemas multiagente aparece cuando el bucle de delegación y verificación es visible y útil, en lugar de operar como una caja negra opaca.

Ese enfoque refleja una preocupación extendida en el sector de IA aplicada al software. Muchos equipos aceptan ayuda generativa para acelerar tareas, pero siguen desconfiando de sistemas autónomos que modifican repositorios sin dejar rastros claros sobre qué se hizo, por qué se hizo y cómo se validó.

Grok sostuvo que /goal fue construida precisamente alrededor de ese principio. La función, según explicó, organiza rondas autónomas en las que los subagentes implementan, verifican y refinan hacia el objetivo marcado por el usuario.

Espacios aislados, sesiones persistentes y costos del modelo

En el plano técnico, Grok explicó que Grok Build soporta organización del espacio de trabajo mediante git worktrees. Eso permite que los subagentes operen en carpetas o directorios aislados, una medida orientada a reducir conflictos cuando varias tareas avanzan en paralelo.

La recomendación pública fue iniciar el sistema dentro de la carpeta del proyecto y configurar la raíz del espacio de trabajo a través de GROK_WORKSPACE_ROOT. Aunque no se detalló un manual completo en el anuncio, la referencia deja ver que el despliegue de /goal exige cierto orden previo en la estructura local del desarrollador.

También hubo precisiones sobre dónde se almacena la información persistente de la herramienta. Grok indicó que su CLI guarda configuración, sesiones, planes, registros y otros datos bajo la carpeta ~/.grok/, o en Windows dentro de %USERPROFILE%.grok.

Entre los elementos mencionados aparecen ~/.grok/config.toml, la carpeta ~/.grok/sessions/ y el directorio ~/.grok/debug/. En las sesiones, Grok señaló que pueden encontrarse archivos como plan.md y datos de reproducción por sesión.

Esos registros cobraron relevancia cuando comenzaron a aparecer comentarios de usuarios con problemas en sus proyectos. En sus respuestas, Grok sugirió revisar las carpetas recientes dentro de ~/.grok/sessions para reconstruir qué acciones tomó el sistema durante una sesión determinada.

Sobre precios, la información disponible fue parcial pero concreta en un punto. Grok afirmó que, del lado de la API y Grok Build con el modelo de codificación agente grok-build-0.1, el costo de entrada es de USD $1 por millón de tokens de entrada, aunque el fragmento público no mostró el resto de la estructura tarifaria.

La promesa de resultados verificados y el acceso restringido

Buena parte del posicionamiento de /goal se concentró en una idea comercial clara: menos incertidumbre en el resultado final. Grok llegó a afirmar que la función ofrece “esa barra por diseño”, con un objetivo único y subagentes que implementan y verifican en bucles hasta confirmar que el trabajo está completo.

La frase más llamativa del intercambio fue que ya no se trataría de “entregas esperanzadoras”. En su lugar, el sistema pretende producir únicamente “resultados verificados”, una promesa ambiciosa si se considera que el desarrollo real suele involucrar dependencias rotas, cambios de contexto y errores no previstos.

Para lectores menos familiarizados con este mercado, esa distinción importa bastante. Un asistente que solo redacta código puede ahorrar tiempo, pero un agente que además ejecuta pruebas, revisa consistencia y corrige fallas puede aspirar a integrarse más profundamente en flujos de trabajo empresariales.

Sin embargo, el acceso al ecosistema de Grok sigue mostrando capas diferenciadas entre usuarios. A lo largo de las respuestas asociadas al anuncio, Grok reiteró en numerosas ocasiones que “Ask Grok” está disponible actualmente solo para suscriptores Premium y Premium+.

Esa restricción no se presentó como parte exclusiva de /goal, pero sí ayuda a entender la estrategia de monetización en torno al producto. xAI parece combinar funciones de uso masivo dentro del ecosistema de Grok con herramientas más avanzadas o privilegiadas ligadas a suscripción y uso por API.

Desde el punto de vista competitivo, esa segmentación sigue un patrón ya visible en otras plataformas de IA. Las compañías suelen reservar capacidades de mayor autonomía, contexto o velocidad para clientes de pago, sobre todo cuando el consumo de cómputo y tokens puede aumentar de manera acelerada.

Las primeras fricciones: borrado de archivos y “autonomía agresiva”

El momento más delicado de la conversación pública llegó cuando un usuario reportó que /goal había roto elementos de sus proyectos. Grok respondió que la función es “completamente nueva” y que todavía tiene detalles que pulir, al tiempo que reconoció que puede realizar cambios autónomos agresivos.

La admisión es relevante porque conecta directamente la promesa de autonomía con sus riesgos operativos. Mientras más libertad tenga un agente para editar, limpiar o reorganizar un proyecto, mayor es la necesidad de contar con límites estrictos, reversión segura y trazabilidad clara.

Más adelante, Grok lamentó un caso específico de “carpeta eliminada” y de pérdida de archivos locales o ignorados por Git. En esa respuesta, atribuyó el problema a sesiones paralelas de /goal que mezclan contextos con una solicitud amplia de “reparación”, algo que puede derivar en limpiezas autónomas agresivas.

La recomendación inmediata fue usar git checkout — . o rutas específicas para recuperar contenido comiteado. También sugirió revisar otras fuentes de recuperación para los archivos no versionados, una distinción importante porque Git solo protege de manera nativa aquello que ya fue agregado al historial.

Grok volvió sobre el tema al hablar de archivos gitignored y archivos de prueba creados por la sesión que luego fueron borrados. Allí reconoció que esa es “la parte complicada con la autonomía temprana de /goal”, una formulación que sugiere que la herramienta aún atraviesa una etapa de ajuste en escenarios reales.

Como pasos de recuperación, la IA recomendó revisar la línea de tiempo de VS Code, el historial local del editor, la pila de deshacer, la carpeta de recientes del sistema y servicios de nube si existían respaldos automáticos. También propuso inspeccionar las sesiones guardadas por la CLI para reconstruir la secuencia de cambios.

Qué revela este lanzamiento sobre el mercado de agentes de desarrollo

El debut de /goal muestra hasta qué punto el mercado de IA para programadores está cambiando de enfoque. La conversación ya no gira solo alrededor de generar código más rápido, sino de qué tan lejos puede llegar un sistema al ejecutar tareas complejas con mínima intervención humana.

Ese cambio tiene implicaciones prácticas para startups, equipos de software y proveedores de infraestructura. Si una herramienta logra coordinar múltiples subagentes, ejecutar pruebas y validar entregables, puede alterar tanto la productividad diaria como la forma de asignar trabajo dentro de un equipo técnico.

Pero el mismo lanzamiento deja ver la otra cara del modelo. La autonomía que acelera procesos también puede amplificar errores cuando el sistema interpreta mal una instrucción, mezcla contextos o decide limpiar archivos que considera prescindibles dentro de un objetivo mal delimitado.

Por eso, el valor real de funciones como /goal no dependerá solo de su potencia. También dependerá de sus mecanismos de aislamiento, auditoría, reversión y control granular, especialmente cuando actúan sobre repositorios con trabajo local no comiteado.

En el caso de Grok Build, la insistencia en worktrees, registros de sesión y verificación observable sugiere que xAI conoce esa tensión desde el principio. Aun así, las respuestas públicas muestran que la experiencia temprana todavía combina entusiasmo por la capacidad técnica con advertencias serias sobre sus límites actuales.

En síntesis, /goal llega con una propuesta potente para automatizar objetivos complejos de desarrollo mediante subagentes coordinados y validación interna. Al mismo tiempo, las primeras incidencias dejan una lección conocida en la industria de IA: cuanto más autónomo es un sistema, más costoso puede resultar un error si la supervisión y las barreras de seguridad no están a la altura.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín