One-shot prompting? Prefiro conversar com a minha IA

Há uns dias, numa conversa com colegas, surgiu o debate sobre a utilidade do one-shot prompting na geração de código com IA. Eu defendia que não é útil, e o argumento que usei creio que merece ser partilhado.

O problema do one-shot como objetivo

Quando assumimos que o one-shot pode dar-nos os resultados esperados, estamos a carregar toda a responsabilidade da qualidade do output na parte humana: se o LLM não produz uma boa resposta, o problema é que não escrevemos o prompt correto.

Mas esta ideia choca frontalmente com a natureza da IA generativa, que é não-determinística. Para o mesmo prompt e modelo, obtemos respostas diferentes em cada execução. Portanto, torna-se impossível—sobretudo com tarefas complexas—obter a resposta ótima numa só interação. A iteração torna-se inevitável.

Nesse debate, com pequenos matizes, todos concordávamos que o one-shot não é válido como fim em si mesmo, mas como exercício para melhorar os nossos prompts. É impossível alcançar 100% de qualidade, mas com esta prática aprendemos a passar, por assim dizer, de 60% para 70%.

De Figma ao código: outra perspetiva

Este fim de semana li The only AI workflow I use in production, de Tommy Geoco. O artigo descreve o fluxo que Tommy utiliza para desenvolver o seu trabalho de design assistido por IA (Figma → Claude Code), afirmando que supera em termos absolutos o uso de outras ferramentas como Lovable, Replit ou Bolt. Se és designer UX/UI interessado na integração de IA no teu trabalho, recomendo a leitura porque contém ideias verdadeiramente interessantes.

Entre essas ideias há uma que me fez refletir novamente sobre a inconveniência do one-shot. Segundo o autor, devemos desmistificá-lo porque não capta o valor real. A verdadeira potência não está na geração inicial, mas nas iterações posteriores.

O seu fluxo de trabalho é o seguinte:

1. Desenhar o "happy path" (fluxo ótimo) no Figma
2. Alimentar o design ao Claude Code via Figma MCP
3. Obter uma base sólida em 15 minutos (vs. 50 horas de codificação manual)
4. Iterar e refinar durante 50 horas

O último ponto é chave para ele: a iteração não é desenvolvimento, é trabalho de design. Não se trata de refinar o código para representar um design fechado, mas com ele tomar decisões sobre hierarquia visual, padrões de interação, casos extremos, estados de erro, etc.

E se o valor está na iteração?

Daqui tiro duas conclusões igualmente importantes. A primeira: o autor está a transferir grande parte do exercício de design do Figma para o código, algo inovador que esbate a fronteira UX/UI-Desenvolvimento. Não vou desenvolvê-la aqui para não me desviar do tema, mas merece um post próprio.

A segunda, relacionada com o debate sobre one-shot: o autor não usa a IA para que desenhe por ele com base em instruções iniciais, mas apoia-se nela para iterar mais rapidamente, refletir sobre o design de forma mais profunda e conseguir um melhor resultado. Creio que não só porque a IA lhe poupa tempo de trabalho repetitivo sem valor e ganha-o para pensar, mas porque o diálogo gerado pode levá-lo a lugares, pensamentos e decisões aos quais sozinho não teria chegado.

Fica por ver se este esquema se translada igualmente ao desenvolvimento de software, mas se funciona de forma similar, então a inconveniência do one-shot não se deve unicamente às limitações que nos impõe a natureza não-determinística dos LLMs. Há algo mais importante: a iteração—esse diálogo continuado entre humano e IA—proporciona-nos valor real, obtemos melhores resultados.

Esta ideia da iteração como diálogo fez-me recordar os planteamentos sobre cocriação humano-IA de Owen Matson. E tenho de reconhecer que foi escrevendo este post—em diálogo com uma IA—quando creio que finalmente entendi o que Owen planteia. Fica pendente aprofundar esta via 🙂