Você pergunta por que um teste falha. O assistente explica e oferece uma sugestão para o seu próximo pedido. Se você já ia escrever “corrige e roda de novo”, a conveniência é fácil de entender. Se só queria a explicação, há um pequeno desvio esperando ao lado da tecla Tab.
A OpenAI anunciou o Composer predictions em 9 de outubro. A beta atende contas pessoais ChatGPT Pro de pessoas com 18 anos ou mais nas regiões compatíveis: app desktop Codex atualizado, conversas locais/SSH e GPT-6 Astra/GPT-6.1 Sol. Gerar previsões não consome créditos nem franquia durante a beta; mensagens enviadas seguem cobrança e limites normais.
O recurso sugere uma mensagem inteira após a resposta, sem completar palavra por palavra. Tab aceita; o envio é separado. Chat fica excluído; conversas locais no Work podem exibir previsões. Sugestões podem demorar ou faltar. Ativas por padrão, são desativadas em General → Composer → Show predictions.
Não testamos esta beta. A análise a seguir examina o desenho anunciado, com exemplos hipotéticos de situações em que ele poderia ajudar e outras em que uma pausa seria bem-vinda.
Imagine que você pergunte a um assistente de programação por que um teste está falhando. Ele explica o problema. Você já pretendia pedir uma correção pontual e outra execução do teste. Se a mensagem proposta expressar exatamente esse pedido, a vantagem aparece sem esforço: suas mãos foram poupadas de uma tarefa pequena e repetitiva.
Numa tarde de ajustes pequenos, isso pode economizar mais do que teclas. Cada continuação tira a atenção do código enquanto você transforma uma intenção em instrução. Uma sugestão que acerta permite ficar um pouco mais concentrado no problema.
Ela também poderia tornar um pedido vago mais preciso. Talvez você fosse escrever “corrige isso” e percebesse que a continuação proposta identifica o teste problemático. Ler uma instrução possível ajuda a descobrir o que realmente queremos. Já seria uma boa utilidade, mesmo que quase toda a frase acabasse apagada.
A dificuldade aparece nos pedidos que parecem razoáveis o bastante para aceitar antes de perceber o que ficou de fora.
A restrição que ficou de fora
Pense no mesmo teste quebrado num projeto que você está apenas revisando. Fazer o reparo pode ser tecnicamente sensato, mas sua tarefa naquela manhã é explicar a falha a outra pessoa. Ou talvez a correção seja desejada, desde que não toque numa dependência delicada. Essa condição pode ser a parte mais importante do pedido.
Um próximo passo sensato ainda pode ser o próximo passo errado para você.
Uma frase bem escrita também pode acrescentar trabalho: alterar outro arquivo, arrumar uma função vizinha, resolver um segundo problema. Tudo isso pode valer a pena, mas, junto, transforma uma dúvida de cinco minutos numa encomenda maior. A sugestão merece a mesma conferência de escopo que um pedido escrito por você.
Esse é um risco para observar durante o uso, sem tratá-lo como uma conclusão sobre a beta. As notas de atualização não dizem se as pessoas preservam restrições importantes ao aceitar uma continuação proposta. Um teste precisaria examinar o trabalho produzido, além de contar quantas vezes alguém aperta Tab.
Comece pelo verbo
Para quem experimentar a beta, um hábito útil seria olhar primeiro para a ação proposta. Explicar, inspecionar, editar e publicar têm consequências bastante diferentes. Depois, confira o limite do pedido: qual arquivo, qual mudança, até onde?
Um teste relevante mediria se a sugestão ajuda a chegar ao resultado desejado, incluindo o tempo gasto corrigindo desvios indesejados. Contar apenas quantas sugestões foram aceitas deixaria essa diferença de fora.
Digitar menos é útil. Ter menos coisa para desfazer é melhor.
A previsão ganha espaço quando você a lê e reconhece o pedido que queria fazer. Quando isso não acontece, editar ou ignorar faz parte de usar bem o recurso.
Tem outro ponto de vista? Quero ouvir. hello@maisfps.com
