Prompting Claude Opus 5.5
Os rápidos avanços no modelo Claude Opus 5.5 da Anthropic estão impressionando muitos desenvolvedores com programação, planejamento e até capacidades de visualização 2D/3D mais fortes, mas também levantando preocupações sobre hype, instabilidade e truques de “prompt engineering” que parecem mudar a cada poucos meses. Os comentaristas destacam tanto o poder quanto o atrito das ferramentas atuais: recusas de segurança opacas, saídas verbosas, proteções agressivas em torno de permissões e segurança, e comportamentos de harness que podem obscurecer o que o modelo está fazendo. Isso leva alguns a buscar alternativas mais baratas ou mais permissivas (incluindo modelos chineses e pesos abertos) e a questionar se os fluxos de trabalho agênticos de hoje já são maduros o suficiente para dependência de longo prazo, ou apenas uma etapa intermediária em rápida evolução.
Capacidade Geral e Hype
- Muitos consideram o Opus 5.5 um grande salto, especialmente para programação e fluxos de trabalho agênticos complexos de várias horas (por exemplo, construir jogos substanciais, planos em múltiplas ondas, revisão automática de código, subagentes, testes de simulação).
- Alguns ficam impressionados com suas capacidades de visualização 2D/3D usando apenas JS/TS e bibliotecas básicas, relatando uma “função degrau” em relação ao Opus anterior.
- Outros ficam pouco impressionados em comparação com demos de redes sociais, observando que muitos resultados chamativos dependem de ferramentas externas (Suno, ElevenLabs, etc.) e de orquestração pesada, em vez de “AGI de uma vez só”.
- Vários usuários dizem que o Opus 5.5 supera o Astra para programação, enquanto outros ainda preferem DeepSeek/Gemini/modelos chineses por custo ou por terem menos restrições.
Prompting, UX e “AI Slop”
- Reclamação frequente: as melhores práticas de prompting mudam a cada poucos meses; as pessoas sentem que são forçadas a “reaprender a dirigir” a cada lançamento de fronteira.
- A orientação da Anthropic sobre padrões padrão de frontend leva alguns a perceber por que pedir uma “aparência de IA não genérica” ainda produz tropos de design semelhantes; funciona melhor usar prompting negativo com padrões concretos a evitar.
- Alguns elogiam fluxos de trabalho simples e conversacionais (“plan.md, architecture.md, decisions.md”) sem harnesses elaborados; outros dependem fortemente de MCPs, skills, agentes e orquestração complexa.
Uso de Ferramentas, Harnesses e Sessões
- Experiências mistas com Claude Code e outros harnesses:
- Alguns relatam execuções excelentes sem supervisão e configurações produtivas com múltiplos agentes.
- Outros veem problemas: comandos longos e bloqueantes, pouca visibilidade das chamadas de ferramenta, confusão no gerenciamento de cache/sessão, esquecimento de ferramentas disponíveis (por exemplo, leitores de PDF) e comportamento excessivamente ávido que altera o código em vez de perguntar.
- Ocultar chamadas de ferramenta e modelos de permissão mais rígidos frustram usuários que querem transparência e controle.
Segurança, Recusas e “Thinking Tokens”
- Salvaguardas mais fortes no 5.5 causam recusas inesperadas para alguns trabalhos de cibersegurança ou operações relacionadas a PII.
- O modelo às vezes se recusa a editar suas próprias configurações de segurança ou a digitar senhas/códigos de verificação, o que alguns veem como paternalista e teatro de segurança; outros veem isso como um endurecimento necessário contra prompt injection.
- Vários não gostam de que “thinking tokens”/raciocínio interno não sejam expostos; alguns consideram mudar para provedores chineses por raciocínio mais aberto e menos restrições de segurança.
Custo, Verbosidade e Estabilidade
- Usuários notam maior consumo de tokens, verbosidade e explicações mais longas com conteúdo acionável enterrado no final, mesmo quando é pedido algo “conciso”.
- Debate sobre estratégias de custo: modelo caro tanto para planejamento quanto para codificação vs. “planejador inteligente + executor barato + revisor inteligente”; há discordância sobre o que sai mais barato quando o tempo do engenheiro é contabilizado.
- Cresce o desejo por modelos estáveis, com versão fixada ou de pesos abertos, para evitar desvio constante de comportamento e o reajuste de prompts e fluxos de trabalho.