Grok para desenvolvedores

Grok é um excelente patinho de borracha que responde para você. No grok.online ele é totalmente gratuito e não exige cadastro: o Grok 4.20 é veloz para dúvidas rápidas, o Grok 4.3 Thinking raciocina antes de responder e é a melhor escolha para bugs, e o Grok 4.7, o modelo mais recente, está disponível para os problemas mais complexos usando 10 das suas 30 mensagens diárias. Os três leem capturas de tela. Veja a seguir sete casos de uso, cada um com um prompt pronto para abrir no chat e ajustar.

Encontre e resolva problemas

A maior parte do tempo de depuração vai para entender o que está acontecendo. Estes prompts aceleram essa etapa.

Decodifique um stack trace

Cole o erro completo, sem parafrasear, além das linhas indicadas por ele. Peça a causa em palavras simples antes de qualquer correção, para que você possa avaliar.

Estou usando [linguagem e versão] com [framework]. Aqui está o erro completo e o stack trace: [colar erro]. Aqui está o código indicado: [colar código]. Explique em palavras simples o que deu errado e o motivo, aponte a causa mais provável primeiro e depois mostre a menor alteração necessária para corrigir.

Abra no chat. O Code Assistant faz o mesmo em um único painel.

Obtenha um mapa de código que você não escreveu

Herdar um arquivo sem comentários é um clássico. Antes de alterar qualquer coisa, peça uma visão geral guiada apontando as partes mais arriscadas.

Acabei de herdar este arquivo em [linguagem] e preciso alterar [funcionalidade]. Faça um tour resumido: qual a responsabilidade do arquivo, as principais funções na ordem em que rodam, quais estados globais ou efeitos colaterais devo monitorar e o local mais seguro para fazer minha alteração: [colar código]

Peça o tour e depois tire dúvidas sobre qualquer função que ainda pareça estranha.

Cace um bug de lógica com um modelo de raciocínio

Quando nada quebra, mas a saída está incorreta, você precisa de um rastreamento detalhado. O Grok 4.3 Thinking analisa o código passo a passo antes de responder, ideal para erros de off-by-one e condições incorretas.

Esta função em [linguagem] deveria [comportamento esperado], mas para a entrada [entrada] ela retorna [saída real] em vez de [saída esperada]. Rastreie a execução passo a passo com essa entrada, mostre os valores das variáveis principais a cada etapa e aponte a linha exata onde ocorre o erro: [colar função]

Rastreie o bug com o Grok 4.3 Thinking.

Corrija um layout quebrado a partir de uma captura de tela

Anexe um print da página como ela está agora, cole o HTML e o CSS relevantes e descreva como ela deveria ficar.

Anexei uma captura de tela de uma página onde [descreva o problema, ex.: a barra lateral sobrepõe o conteúdo em telas estreitas]. Aqui está o HTML e o CSS dessa parte: [colar código]. Explique o que está causando isso e forneça o CSS corrigido, alterando o mínimo possível.

Abra este prompt e anexe sua captura de tela.

Planeje uma refatoração arriscada

Organizar um módulo complexo é onde o modelo mais recente faz valer uma de suas mensagens diárias limitadas. Peça um plano, não uma reescrita imediata.

Abaixo está um módulo em [linguagem] que ficou difícil de manter: [colar código]. Não reescreva ainda. Descreva as responsabilidades dele, as dependências ocultas e um plano de refatoração em etapas curtas onde o código continue funcionando após cada uma. Indique quais testes devo adicionar antes do primeiro passo.

Planeje com o Grok 4.7 e envie as etapas uma a uma para o Grok 4.20.

Escreva o código ao redor do código

Testes, queries, revisões e documentação são as partes deixadas de lado quando os prazos apertam.

Escreva testes para os casos de borda esquecidos

Peça a lista de casos primeiro e o código de teste depois. O verdadeiro valor está na lista.

Aqui está uma função em [linguagem]: [colar função]. Primeiro, liste os casos de borda que valem a pena testar, como entradas vazias, limites e tipos inválidos, explicando o motivo em uma linha para cada um. Em seguida, escreva os testes usando [framework de teste], um teste por caso, com nomes claros.

Gere os testes, execute-os e mantenha aqueles que falharem por bons motivos.

Receba um code review de um dev sênior ranzinza

O Grok assume com prazer o papel do revisor que já viu todos os bugs possíveis. Ranzinza pode ser; vago, não. Por isso, peça referências de linha.

Revise este diff como um engenheiro de software sênior ranzinza, mas justo. Aponte bugs, nomes pouco claros, falta de tratamento de erros e tudo o que pode dar dor de cabeça daqui a seis meses, indicando a linha e sugerindo uma correção para cada item. Ordene os problemas por gravidade e ignore detalhes meramente estéticos: [colar diff]

Solicite a revisão antes que o seu time veja o código.

Transforme um schema em SQL e em um README

Forneça as definições das tabelas e a sua dúvida em linguagem natural, pedindo uma breve explicação junto com a query.

Aqui estão as definições das minhas tabelas para [banco de dados, ex.: PostgreSQL]: [colar schema]. Escreva uma consulta que retorne [o que você precisa em palavras simples]. Explique cada join e filtro em uma linha e me diga qual índice pode acelerar a busca quando as tabelas tiverem milhões de linhas.

Escreva a query e depois peça uma seção de README documentando as tabelas.

O que evitar

• Colar dados sensíveis. Chaves de API, senhas, tokens e dados de clientes não devem ir para nenhum chat. Use placeholders.
• Confiar cegamente em detalhes de bibliotecas. Os modelos possuem data limite de conhecimento e não acessam a internet, portanto uma função ou parâmetro pode estar desatualizado ou ser inventado. Consulte a documentação oficial.
• Enviar código para produção sem testar. Um código bem escrito ainda pode falhar. Execute, teste e revise.
• Enviar repositórios inteiros. Mensagens muito longas são cortadas. Envie apenas a função relevante.

Páginas relacionadas

• Mais vinte pontos de partida em prompts para programação.
• Nosso guia sobre como programar com o Grok e uma explicação sobre modelos de raciocínio.
• Criando seu próprio app? Conheça a Grok API.