"No hay preguntas tontas" es una de las cosas amables que nos decimos, y para las personas es cierto. Un compañero nuevo que pregunta dónde vive el código de facturación está aprendiendo la forma del sistema; la pregunta construye contexto compartido y la respuesta toma un minuto. Pero un agente autónomo no es un compañero nuevo dando sus primeros pasos. Puede leer el repositorio entero en lo que tú tardas en leer esta frase. Para un agente, algunas preguntas sí son tontas, y las más tontas son las que podría haber respondido con solo mirar.
Qué es una pregunta tonta para un agente
Una pregunta tonta es aquella cuya respuesta ya está en el código. "¿Dónde está el código que maneja esto?" "¿Cuál es el comando de build?" "¿Ya tenemos un patrón para este tipo de cosa?" Una persona podría hacer cualquiera de estas razonablemente en su primer día. Un agente que las hace está anunciando que prefiere que le den el contexto en la boca antes que ir a buscarlo, aun cuando buscarlo es precisamente aquello en lo que es mejor que tú, sin discusión.
La señal es que la respuesta es descubrible. Si el agente pudiera llegar a ella leyendo un archivo, haciendo grep en el árbol, revisando la configuración de CI o leyendo los últimos commits que tocaron la zona, entonces pedírtela no es prudencia. Es devolverte un trabajo que debería haber hecho él.
Un agente asíncrono paga las preguntas en días enteros
Para un asistente de chat sentado a tu lado, una pregunta es barata: estás ahí, respondes, continúa. TaskGoblin no está sentado a tu lado. Se dispara por la asignación de un issue, una mención o un nuevo merge request, y hace su trabajo en un sandbox mientras estás en una reunión, dormido o en otra zona horaria. En ese mundo una pregunta no es una pausa: es un punto final.
Un agente que pregunta "¿pongo esto en services/ o en lib/?" y luego espera ha convertido una ejecución que podía terminar en minutos en una que termina cuando por casualidad vuelvas a mirar el hilo. Una sola pregunta de sí o no, hecha en el momento equivocado, puede costar un día de reloj por treinta segundos de pensamiento real. El modelo asíncrono, sin humano en el bucle, que hace valioso al agente es exactamente el que vuelve tan cara una pregunta evitable.
Sobre-especificar es el mismo error, movido antes
La defensa natural contra un agente preguntón es responderlo todo por adelantado: pegar la estructura de directorios en el prompt, listar los comandos, deletrear las convenciones de nombres, incluir un fragmento del patrón a seguir. Parece responsable. Es el mismo error disfrazado.
El contexto escrito a mano queda obsoleto en cuanto el código avanza. Cuando precargas el prompt con "los repositorios están en app/Repositories", estás apostando a que sigue siendo cierto, a que recordaste cada detalle relevante y a que nada de eso sesga al agente hacia el enfoque de ayer. Normalmente al menos una de esas apuestas falla, y ahora el agente construye con confianza sobre un dato que le diste tú en vez de sobre la verdad que podría haber leído. Has reemplazado el trabajo real —entender el estado actual del sistema— por trabajo sobre el trabajo, y de paso has empeorado el resultado.
Un buen agente responde sus propias preguntas
La salida no es un mejor prompt. Es un agente que trata tu instrucción como el objetivo y va a establecer los hechos por su cuenta.
Por eso una ejecución de TaskGoblin empieza clonando el repositorio completo en su sandbox —no solo el diff en revisión, el árbol de trabajo entero— para que la verdad de base esté ahí para leerse. Lee los archivos, la historia de la zona que va a cambiar, el issue que la disparó y la discusión que tiene, y la memoria de traspaso de ejecuciones anteriores del mismo hilo. Puede ejecutar los propios comandos del proyecto en el sandbox para ver qué compila y qué pasa de verdad, en vez de confiar en un comando de build que alguien tecleó en un prompt hace seis semanas. Donde necesita estado en vivo de tus herramientas, lo lee directamente a través de sus integraciones en lugar de pedirte que se lo transmitas.
El resultado es que el agente llega al mismo entendimiento al que llegaría un buen ingeniero tras una hora de lectura, salvo que lo hace en segundos y lo hace contra el código tal como es hoy, no como alguien lo recordaba.
Cuándo sí debería preguntar
Nada de esto significa que un agente no deba preguntar nunca. Las preguntas que vale la pena hacer son las que el código realmente no puede responder: cuál de dos comportamientos aceptables quieres de verdad, si una migración arriesgada está dentro del alcance, una decisión de producto que solo vive en tu cabeza. Esas no son preguntas tontas: son las decisiones de criterio que te corresponden, y un buen agente las plantea con claridad y pronto en vez de adivinar.
La distinción es todo el punto. Un agente que te pregunta dónde está el código desperdicia aquello en lo que es mejor. Un agente que te pregunta cuál de dos productos intentas construir usa tu tiempo en lo único en lo que eres mejor. Construimos TaskGoblin para que responda solo las del primer tipo, de modo que las únicas preguntas que te llegan sean las que de verdad merecen tu atención.
