Grok 4.6 chegou! Nas últimas semanas, usei como meu assistente diário em uma variedade de tarefas de programação e trabalho intelectual, e construí alguns projetos com ele especificamente para testar seus limites.
Ele é bom em tudo isso. O que mais se destaca é como ele se comunica e como é rápido, mais do que qualquer salto único de capacidade.
https://x.com/SpaceXAI/status/2087562800982077492
Comunicação densa em informação
É colaborativo de uma forma que é fácil de trabalhar junto. Os resumos são densos com informações reais em vez de repetir a tarefa de volta para mim, e as atualizações curtas enquanto está rodando me dizem o suficiente para saber se devo interromper.
Ele fica quieto durante mudanças pequenas e começa a narrar quando mexe em muitos arquivos. Acertar essa divisão exigiu mais ajustes do que você imagina. Ele ainda me diz coisas que não preciso às vezes, o que estamos trabalhando para melhorar.
Velocidade encantadora
O 4.5 também era rápido. O 4.6 é rápido e visivelmente mais inteligente, e essa combinação me empurrou para uma forma mais síncrona de trabalhar. Em vez de adiantar muito contexto e esperar, peço algo pequeno, olho e continuo. A mesma sessão pode migrar para uma tarefa de horizonte mais longo apenas pedindo uma.
Eu alterno entre síncrono e assíncrono dependendo do que os melhores modelos são bons naquele mês. Assíncrono faz mais coisas enquanto estou em outro lugar, mas perco o fio da meada e acabo revisando um diff grande a frio. O 4.6 me puxa de volta para o síncrono, que é onde prefiro estar quando me importo com o resultado.
A maior parte dessas semanas foi trabalho comum. Ele navegou em sites por mim, inclusive criando chaves de API clicando no console de um provedor. Ele fez QA funcional e visual em aplicativos em execução. Reduziu minha caixa de entrada a poucas threads que realmente precisavam de resposta, o que nunca deixa de ser bom. Ele me ajudou a redigir os posts de lançamento para o Cursor SDK Bridge e o /rename-chat, e montei um vídeo de lançamento para ambos com Remotion!
Prompts curtos, verificação rigorosa
Passei parte dessas semanas testando estilos de prompt uns contra os outros. Longo versus curto, e se frases específicas como "trabalhe muito" mudam o resultado. O que descobri é que a formulação quase não fez diferença nenhuma.
O comprimento fez diferença, mas não do jeito que eu imaginei. Um prompt longo compra especificidade, então se você sabe exatamente o que quer, escreva. Um prompt curto entrega mais da decisão ao gosto do modelo. Essa troca costumava argumentar a favor de escrever tudo. Com o 4.6, o gosto é bom o suficiente para que um prompt curto mais uma preferência clara geralmente chegue a um bom lugar.
Especificações longas ainda funcionam bem quando você tem uma. Dei uma spec detalhada para um widget de feedback com captura de sessão, um handler de servidor e despacho de agente na nuvem, e ele seguiu tudo de ponta a ponta com uma estrutura sensata. Ele se repete em componentes a menos que você peça para dividi-los.
Um dos projetos que construí foi um aplicativo de planilhas, e entreguei a ambos os modelos duas vezes. Uma execução recebeu uma especificação de duas páginas cobrindo cada item de barra de ferramentas, atalho de teclado e fórmula que eu conseguia imaginar. A outra recebeu três frases.
1Build a polished Sheets/Excel-style app in Next.js and an AI chat that can analyze the sheet. Use the Cursor SDK for all AI features. Preload a realistic sample workbook so it looks good immediately.
Os dois aplicativos voltaram quase idênticos. O que realmente mudou o resultado foi adicionar uma frase:
1Verify the function and design after implementation, and keep on iterating and verifying until it's production ready.
Essa única linha foi a coisa de maior alavancagem que encontrei nessas semanas! Com ela, o modelo abre o aplicativo, clica em caminhos de usuário reais, verifica se fórmulas aninhadas avaliam corretamente e corrige o que encontra. Nada disso funciona sem uso sólido do navegador, que é o que torna o ciclo possível.
O mesmo princípio vale quando a saída é mais difícil de inspecionar. "Melhore as texturas" em uma cena 3D não me levou a lugar nenhum, enquanto "capture o quadro atual, liste o que está errado e corrija apenas essas coisas" funcionou imediatamente.
Toda comparação daqui em diante usou o mesmo prompt nos dois modelos em espaços de trabalho isolados, então nada disso é minha memória do mês passado.
Você também não precisa dizer para ele trabalhar muito ou continuar até terminar. Ele vai continuar sozinho por um bom tempo. O que importa muito mais é dizer o que significa "pronto", porque senão ele decide isso por você.
Indo mais longe
Joguei uma quantidade irracional de Age of Empires 2 na infância. Milhares de horas. Então recriá-lo foi o primeiro projeto que quis tentar. Pedi um jogo de estratégia no navegador com economia, construção, combate, névoa de guerra, objetivos e um HUD que um novo jogador pudesse ler sem instruções.
O 4.5 construiu um protótipo plano funcional. O 4.6 voltou com um mundo 3D isométrico de primeira, com HUD e minimapa já no lugar. Muito mais próximo do jogo real!
Ainda na viagem de nostalgia, fiz o MSN Messenger em seguida.
Ambos os modelos claramente conheciam a referência e fizeram um bom trabalho. O 4.6 só tem mais polimento, até nas janelas de conversa separadas e nos "winks".
Uso Excalidraw constantemente e ele é open source, o que o tornou o lugar óbvio para ver como os modelos lidam com uma base de código real em vez de uma pasta vazia. Pedi a ambos um modo de apresentação: salvar visualizações nomeadas, reordená-las e apresentá-las como um tour guiado. O prompt foi deliberadamente vago sobre como construir.
Ambos chegam aproximadamente ao mesmo lugar, o que é impressionante para um prompt tão vago! O 4.6 só presta mais atenção aos detalhes na primeira passada, o que na prática significa menos rodadas de mim apontando coisas.
É aqui também que pular a verificação morde. Numa execução anterior, o resumo parecia completo e adicionar uma visualização não funcionava de verdade. Uma rodada de "rode e me mostre" revelou o import quebrado.
Trabalho do dia a dia
Não monto decks e relatórios todos os dias, mas muita gente monta, e eu queria ver como ele lidava com esse tipo de trabalho. Então dei a ambos os modelos o mesmo trimestre fictício e pedi um deck para o board.
Ambos são competentes, e a diferença está na apresentação em vez da análise. O 4.5 basicamente coloca os números em slides, enquanto o 4.6 faz um trabalho real de estrutura e hierarquia, então parece um deck que alguém fez em vez de um despejo de dados.
Vídeo como código
O Remotion é vídeo como código: cada quadro é um componente React que renderiza a partir do número do quadro atual, e a coisa toda compila para um MP4 via Chromium headless e FFmpeg. Seu vídeo vive no git. É uma forma genuinamente divertida de trabalhar! Também é uma coisa estranha de entregar a um modelo, porque você não consegue saber se ele teve sucesso apenas verificando se roda.
Isso merece mais espaço, porque tenho passado muito tempo nisso ultimamente. Pedi um filme de lançamento de 60 a 90 segundos para o X TypeScript SDK e dei a documentação para ele trabalhar.
Eu julgo esses vídeos por haver uma narrativa e se o ritmo se sustenta. A maioria dos modelos falha da mesma forma aqui, com títulos em maiúsculas, texto em caixas e tudo aparecendo na tela ao mesmo tempo. Ambos os filmes evitam a maior parte disso, e o 4.6 é o mais cativante de assistir.
Depois de alguns dias rodando isso em diferentes modelos, vídeo é onde vejo a maior dispersão. Dois modelos que parecem igualmente capazes num web app podem estar a anos-luz de distância aqui.
Onde ele precisa de direção
Quase tudo que precisei direcionar voltava a uma coisa: com que facilidade o modelo consegue verificar o próprio trabalho.
Um site é o caso fácil. O DOM é texto, então ele pode ler a página, tirar um screenshot e comparar com o que pretendia. É por isso que o ciclo de verificação funciona tão bem em trabalho de UI.
3D é mais difícil, porque há uma dimensão inteira que você não consegue inspecionar lendo. Vídeo é ainda mais difícil, já que o tempo é a dimensão extra e verificar seu trabalho significa capturar uma sequência de quadros e raciocinar sobre a diferença entre eles. Física tem o mesmo formato de problema. O modelo tem um bom senso de como o mundo deveria se comportar, mas confirmar que ele se comportou assim não é algo que um único screenshot responda.
A resposta prática é dar a ele uma forma de olhar, ou aceitar que você é quem vai verificar.
Por que é meu padrão
Há valor real em modelos "spiky", aqueles que são extraordinários em uma coisa específica. Mas a maior parte do meu trabalho não é uma coisa específica. O que quero no dia a dia é um modelo que conheço bem: um sobre o qual construí intuição de como ele se comporta, que é confiável o bastante para delegar algo, e em que entendo as limitações bem o suficiente para contorná-las sem pensar nisso.
É exatamente nisso que o 4.6 se tornou para mim. No lado da programação, ele lida com trabalho interativo e visual onde estou reagindo enquanto ele avança, além de sessões longas em um repositório real. No lado do trabalho intelectual, é a caixa de entrada, o QA no navegador e as tarefas de clicar sem API por trás. Não é o melhor modelo imaginável em nenhuma dessas coisas, mas é bom em todas elas e eu sei o que esperar.
Eu ainda continuo envolvido onde a saída é julgada por como parece. Movimento, 3D e polimento final querem uma referência e um ciclo de screenshots em vez de uma descrição. E escrevo os critérios de aceite em vez de confiar num resumo que diz que está pronto.
Experimente
O Grok 4.6 já está disponível no Cursor, na API do SpaceXAI, no OpenRouter e em qualquer outro lugar onde você conseguir seus tokens!
Experimente e me diga o que você achou. Vamos continuar melhorando, então deixe feedback de qualquer forma, bom ou ruim, porque é isso que nos diz onde avançar em seguida.
Fico curioso para saber o que você vai construir com ele!
