Preguntas por qué falla una prueba. El asistente lo explica y ofrece una sugerencia para tu siguiente petición. Si ya ibas a escribir “arréglalo y ejecútala otra vez”, la comodidad se entiende enseguida. Si solo querías la explicación, hay un pequeño desvío esperando junto a la tecla Tab.
OpenAI anunció Composer predictions el 9 de octubre. La beta admite cuentas personales ChatGPT Pro de personas de 18 años o más en regiones compatibles: aplicación de escritorio Codex actualizada, conversaciones locales/SSH y GPT-6 Astra/GPT-6.1 Sol. Generar predicciones no consume créditos ni cuota durante la beta; enviar mensajes mantiene los límites y la facturación habituales.
La función propone un mensaje completo tras la respuesta, sin completar palabra por palabra. Tab acepta; el envío es independiente. Excluye Chat; algunas conversaciones locales de Work pueden mostrar predicciones. Estas pueden tardar o faltar. Vienen activadas; se desactivan en General → Composer → Show predictions.
No hemos probado esta beta. El análisis examina el diseño anunciado, con ejemplos hipotéticos de dónde podría ayudar y dónde convendría detenerse un momento.
Imagina que preguntas a un asistente de programación por qué falla una prueba. Te explica el problema. Ya pensabas pedir una corrección puntual y ejecutar la prueba otra vez. Si el mensaje propuesto recoge exactamente esa petición, el atractivo resulta evidente: tus manos se han ahorrado una tarea pequeña y repetitiva.
En una tarde de pequeños ajustes, eso podría ahorrar algo más que pulsaciones. Cada continuación aparta la atención del código mientras conviertes una intención en una instrucción. Una sugerencia acertada permite seguir concentrado en el problema un poco más.
También podría dar precisión a una petición vaga. Quizá ibas a escribir “arréglalo” y descubres que la continuación propuesta identifica la prueba problemática. Leer una posible instrucción puede ayudarte a averiguar qué quieres realmente. Ya sería una utilidad valiosa, aunque acabaras borrando casi toda la frase.
La dificultad aparece en las peticiones que parecen lo bastante razonables para aceptarlas antes de advertir lo que falta.
La condición que falta
Piensa en la misma prueba fallida dentro de un proyecto que solo estás revisando. Repararla puede ser técnicamente sensato, pero tu trabajo esa mañana consiste en explicar el fallo a otra persona. O quizá sí quieres arreglarlo, siempre que no se toque una dependencia delicada. Esa condición puede ser la parte más importante de la petición.
Un siguiente paso razonable puede seguir siendo el paso equivocado para ti.
Una frase bien escrita también puede añadir trabajo: modificar otro archivo, retocar una función vecina, abordar un segundo problema. Todo podría merecer la pena, pero, junto, convierte una consulta de cinco minutos en un encargo mayor. La sugerencia necesita la misma revisión de alcance que una petición escrita por ti.
Es un riesgo que observar durante el uso, sin presentarlo como una conclusión sobre esta beta. Las notas de actualización no dicen si las personas conservan condiciones importantes al aceptar una continuación propuesta. Una prueba tendría que examinar el trabajo resultante, además de contar cuántas veces alguien pulsa Tab.
Empieza por el verbo
Para quien pruebe la beta, un hábito útil sería fijarse primero en la acción propuesta. Explicar, inspeccionar, editar y publicar tienen consecuencias muy diferentes. Después conviene revisar el alcance: ¿qué archivo, qué cambio, hasta dónde?
Una prueba relevante mediría si la sugerencia ayuda a conseguir el resultado deseado, incluido el tiempo dedicado a corregir desvíos innecesarios. Contar únicamente cuántas propuestas se aceptan dejaría fuera esa diferencia.
Escribir menos es útil. Tener menos que deshacer es mejor.
La predicción se gana su sitio cuando la lees y reconoces la petición que querías hacer. Cuando no ocurre, editarla o ignorarla forma parte de aprovechar bien la función.
¿Tienes otro punto de vista? Quiero escucharlo. hello@maisfps.com
