Introdução: O Código Não Se Importa Com Suas Vibrações
A questão sobre grandes modelos de linguagem e código é: eles são surpreendentemente confiantes e totalmente indiferentes se seu programa compila. Haiku 4.5 escreverá alegremente um script que resolve seu problema, além de dois que ele inventou por esporte. O truque — o único truque que importa — é aprender como usar o do Haiku 4.5 para geração de código precisa de uma forma que não deixe espaço para vibrações e maximize o espaço para a verdade. Você não quer prosa que soe como código. Você quer código que aja como código. Há uma diferença.
As pessoas tratam o como um encantamento místico — diga as palavras certas e obtenha um aplicativo perfeito. Isso é pensamento de culto de carga. Código é um contrato. Se você quer precisão do Haiku, você tem que escrever o contrato. “Construa um aplicativo web” não é um contrato. “Gere um em 3.12 que aceite , valide o esquema com v2 e retorne 422 em erros de esquema com um formato de carga específico” é um contrato. É assim que se usa o do Haiku 4.5 para geração de código precisa: você define o contrato.
O Que Isto É (e Não É)
- É um guia prático para obter código confiável e testável do Haiku 4.5.
- Não é um sermão sobre “IA substituindo desenvolvedores”. Ferramentas não substituem o pensamento.
- É focado em práticos, estrutura e proteções: as partes chatas que fazem a mágica funcionar.
Se você quer código que execute, você precisa dar ao uma definição funcional de “executa”. Se você quer geração de código precisa, você precisa definir precisão em termos claros e testáveis. Esse é todo o jogo.
Defina Precisão Como um Advogado, Não Como um Poeta
Código “preciso” não é código que “parece plausível”. Precisão é:
- Validade sintática: ele compila ou executa sob o interpretador.
- Fidelidade semântica: ele faz o que a especificação diz.
- Comportamento determinístico: mesmas entradas, mesmas saídas, dentro de limites de erro definidos.
- Correção de versão: ele usa os , versões de e recursos de linguagem corretos.
lhe dará o que você pedir. Se você pedir “uma função que ordene uma lista”, você provavelmente receberá uma. Se você pedir “uma ordenação estável, usando semântica com espaço extra ”, essa é uma promessa diferente. “Como usar o do Haiku 4.5 para geração de código precisa” começa com escrever essas promessas no .
O Mínimo Viável, Aprimorado
Ruim: “Escreva uma para tarefas.”
Melhor: “Escreva uma 20 4 com uma rota /tasks que valide os campos {title: string, dueDate: ISO 8601} e responda 201 com o objeto criado ou 400 com detalhes do erro.”
Correto: “Gere um servidor 20 4 com um único /tasks. Requisitos: 1) Validar o corpo com [email protected]; 2) Campos: title (string não vazia, máximo 140), dueDate (data futura ); 3) Em caso de sucesso: 201 com {id: ULID, title, dueDate}; 4) Em caso de inválido: 400 com {error: 'VALIDATION', details: array}; 5) Sem banco de dados; na memória; 6) Inclua o arquivo de teste 29 cobrindo válido, inválido (título vazio, data passada); 7) Forneça scripts para teste e desenvolvimento; 8) Use ; 9) Não inclua comentários estranhos.” Observe a forma: versão da linguagem, bibliotecas, restrições, saídas, erros, testes e até mesmo a estrutura do pacote. Você removeu a ambiguidade. O trabalho do é preencher o código, não os requisitos.
O Padrão de Andaime: Sistema, Especificação, Testes, Depois Código
Se você quer geração de código precisa do Haiku 4.5, você precisa dar a ele uma pista:
- Enquadramento do sistema (a coleira curta)
- Você: “Você está escrevendo de qualidade de produção para 20. Saída apenas blocos de código com nomes de arquivos e nada mais.”
- Por quê: Você controla o tom e o formato de saída. Não deixe ao acaso.
- Especificação (o contrato)
- Inclua versões de linguagem, escolhas de pacotes, semântica de erro, formatos de E/S, limites de desempenho e restrições de segurança.
- Diga ao para escrever testes unitários primeiro. Os testes definem “preciso” melhor do que adjetivos. Se uma linha de código não serve a um teste, é decorativa.
- Apenas depois dos testes. Sim, isso é basicamente , mas com um robô que nunca fica entediado escrevendo .
- Instruções para repetições
- “Se os testes falharem ou as importações não corresponderem, atualize apenas as partes com falha. Não reescreva o projeto inteiro.”
se sai bem quando tem contexto e trilhos. Dê a ele trilhos.
A Fixação de Versão Não É Opcional
Os dados de treinamento do estão cheios de documentos antigos e novos. Essa é uma forma educada de dizer que ele viu muitos conselhos conflitantes. “Use ” é vago. “Use [email protected] com ” é direção. Não confie nos padrões: - Linguagens: fixe em 3.12, 20, 1.22, 21—o que você realmente executa.
- : especifique as versões principais exatas e quaisquer de mudança de quebra.
- de nuvem: fixe as versões; aws-sdk v2 vs v3 importa.
- Linters/formatadores: especifique regras para evitar reescritas de “pingue-pongue de estilo”.
Se você não fixar, você terá um de cinco anos de postagens de blog. Geração de código precisa é alérgica à nostalgia.
Esquema Primeiro, Sempre
Não peça estruturas de “perfil de usuário”. Defina esquemas no e exija validação:
Então faça o impor esquemas nos limites — entradas de , gravações de banco de dados e filas de mensagens. Peça cargas e códigos de erro explícitos. Precisão ama esquemas. Ambiguidade não.
Torne-o Observável, ou Não Finja Que É Real
Diga ao para adicionar , métricas e rastreamentos onde você precisar — e para mantê-los silenciosos onde você não precisar. Um bom inclui:
- Política de : níveis, redação de , estrutura ( , por favor)
- Métricas: tempo por solicitação, contagens de erro
- de saúde: /healthz que prova que as dependências estão ativas
adicionará o que você pedir. Se você não pedir, você receberá instruções de impressão — se você tiver sorte.
de Teste Primeiro Vencem “Apenas Confie em Mim”
Uma boa maneira de usar o do Haiku 4.5 para geração de código precisa é tornar os testes a fonte da verdade. Exemplo:
“Escreva testes para uma função normalize_email(s) que:
- coloque em minúsculas as partes local e de domínio;
- remove pontos na parte local apenas para gmail.com;
- remove subendereços (+tag) apenas para gmail.com;
- rejeita entradas sem um único @ ou com espaços;
- mantém o de domínio como está. Cubra casos extremos. Depois de escrever os testes, implemente a função para aprová-los.”
frequentemente escreverá código melhor quando forçado a satisfazer os testes que você descreveu. Se não o fizer, você tem uma falha concreta, não um argumento de vibração.
Sem Alucinações por Construção
Você não pode eliminar alucinações, mas você pode cercá-las:
- Peça citações ou de origem apenas quando as fontes existirem. Para métodos de , exija de documentos e exija que o código corresponda a esses documentos.
- Para privadas, cole a especificação no . Não espere que conheça seus internos.
- Para bibliotecas com confusas, inclua um trecho de exemplo da documentação oficial e diga ao para aderir a ele.
Código preciso é principalmente referências precisas. Dê ao as referências.
Guias de Estilo: A Coisa Menos Sexy, Mais Útil
escreve código em qualquer estilo que ele infere. Essa é uma receita para rotatividade. Cole seu guia de estilo. Especifique:
- Formatação (, , gofmt padrão)
- Convenções de nomenclatura
- Padrões de tratamento de erros
Também exija um breve comentário de justificativa para escolhas não óbvias. O você do futuro agradecerá, e o atual produzirá menos de “correção”.
Longos, Saídas Curtas
Outra maneira de pensar sobre como usar o do Haiku 4.5 para geração de código precisa: gaste suas palavras no , não na saída. Você quer:
- Narração estranha mínima na saída
Diga a ele para suprimir explicações e retornar apenas blocos de código com nomes de arquivos e um curto. Se você quer comentários, peça em uma execução separada. Intercalar prosa e código é como os entram sorrateiramente usando um monóculo e uma cartola.
Refinamento: O Apertado Que Realmente Funciona
O caminho mais rápido para código confiável não é “acertar na primeira tentativa”. São corretivos curtos:
- Execute localmente. Cole a saída de teste com falha e os erros do compilador de volta no textualmente.
- Instrua: “Modifique apenas as linhas mínimas necessárias; não altere as assinaturas de função, a menos que seja exigido por testes com falha.”
é excelente em aplicar quando você diz exatamente o que quebrou. Não parafraseie de falha. Cole-os. Os são a verdade.
Segurança É um Recurso, Não um Posfácio
Como os modelos são treinados em código público (bom, ruim e amaldiçoado), você quer tornar a segurança um requisito de primeira classe:
- Proíba explicitamente , shell=True e com tipo de string
- Exija consultas parametrizadas, proteção e limitação de taxa
- Peça fixação de dependência mais um arquivo de bloqueio
- Exija tratamento para segredos por meio de variáveis de ambiente ou um gerenciador de segredos
Um seguro por padrão produz código mais seguro. Um de “vamos corrigir mais tarde” gera manchetes.
Desempenho: Diga O Que “Rápido” Significa
“Torne-o rápido” se traduz em “faça o que for”. Em vez disso, especifique métricas:
- Metas de latência (p95 < 50ms para na memória, p95 < 300ms para operações de )
- Limites de memória ( < 150MB)
- Complexidade de tempo (deve ser , não )
escolherá algoritmos para se adequar ao orçamento que você definir. Dê a ele um orçamento.
Documentação: Suficiente Para Integrar um Estranho
Peça ao um que inclua:
- Instruções de configuração com versões exatas
- Comandos para teste, , verificação de tipo, execução
- Solicitações/respostas de exemplo
“Código preciso” inclui documentos precisos. Eles fazem parte do entregável.
Modelos de Concretos Que Você Pode Roubar
Modelo: de
Sistema: Você é um engenheiro 3.12 meticuloso. Saída apenas blocos de código com nomes de arquivos.
Usuário:
- Construa um aplicativo 0.111 com um /convert.
- Solicitação: {amount: Decimal como string, from: 'USD'|'EUR', to: same}.
- Valide com pydantic v2; retorne forma 422 em erros de esquema.
- Use uma função pura convert(amount, from, to) com taxas fixas {USD:1, EUR:1.1}.
- Retorne {amount: string, currency: string} com 200.
- Inclua testes cobrindo válido, inválido (decimal ruim, código desconhecido) e limite (0).
- Forneça pyproject.toml com dependências fixadas; inclua configurações ruff e mypy.
- Sem chamadas de rede, sem comentários.
Modelo: Utilitário de
Sistema: Você está escrevendo 1.22. Saída apenas blocos de código com nomes de arquivos.
Usuário:
- Crie uma chamada slugify que lê stdin e imprime seguros para .
- Regras: minúsculas, apenas , separadores de hífen, colapso de espaço em branco, remoção de pontuação.
- Forneça main.go e slugify_test.go com testes de tabela.
- Inclua Makefile com metas de teste e construção.
Modelo: Componente de
Sistema: Você é um engenheiro pragmático com o objetivo de 18 + .
Usuário:
- Implemente um componente <DebouncedInput>.
- : value: string, onChange(value): void, delay=300.
- Use useRef/useEffect; sem de terceiros.
- Inclua testes vitest com temporizadores falsos.
Esses modelos demonstram como usar o do Haiku 4.5 para geração de código precisa, fixando versões, definindo o comportamento e exigindo testes.
Recusando-se a Ser Inteligente: Quando Dizer “Não Otimize”
Se você não quer micro-otimizações prematuras (e você não quer), diga isso:
- “Prefira a legibilidade à inteligência; sem , a menos que os testes exijam.”
- “Sem recursão se iterativo for mais claro.”
- “Sem metaprogramação; explícito > implícito.”
adora impressionar. Não deixe. Faça passar nos testes e ser legível. Isso é impressionante o suficiente.
Sider.AI no Fluxo de Trabalho, Onde Realmente Ajuda Eu vi pessoas fazendo malabarismos com em guias de bate-papo aleatórias como se fosse um ritual de produtividade. Use um espaço de trabalho que entenda o contexto do código. Sider.AI, por exemplo, é construído em torno de manter sua especificação, código, e de teste à vista, então o de “cole o erro, corrija a linha” é realmente apertado. Não é mágica; é andaime chato que impede você de perder a trama. Se sua ferramenta mantém o contrato, os testes e o código na mesma conversa — sem incomodá-lo com confetes — use-a. faz. Como Depurar Com Como um Colega de Equipe, Não um Oráculo
- Cole a saída de teste com falha exatamente como está. Não resuma.
- Peça um : “Responda com unificado contra o arquivo X apenas.”
- Para de tempo de execução, adicione o menor trecho reproduzível e exija uma explicação mais um .
- Para erros de biblioteca, cole o trecho do documento que você acha que se aplica e pergunte: “Esta é a correta para a versão X? Se não, atualize o código e cite o trecho correto.”
O objetivo é fazer discutir com evidências. Você traz as evidências.
O Desfile de Armadilhas (e Como Desviar Dele)
- A armadilha da “mais recente”: Não diga “use o mais recente”. Diga “use a versão X.Y” e atenha-se a ela.
- O arquivo de teste vazio: Se você não exigir testes, você não os obterá.
- A falácia de um tiro: Planeje duas ou três refinações curtas. É mais rápido do que um inchado.
- A política de erro ambígua: Defina códigos de status e cargas. “Retorne um erro” não significa nada.
- A dependência não possuída: Se o código depende de um serviço que você não pode controlar, faça um dele. Peça falsificações.
Sua Lista de Verificação de (Cole Isso Perto do Seu Monitor)
- Versão da linguagem e do tempo de execução fixada
- Versões da biblioteca fixadas
- Esquemas de dados definidos
- Semântica de erro definida (códigos, formas)
- Testes primeiro, depois código
- Restrições de segurança explícitas
- Orçamentos de desempenho declarados
- Estilo e estrutura especificados
- Formato de saída restrito (nomes de arquivos, blocos de código, )
- de refinamento curto com colados
Se você acertar todos os dez, Haiku 4.5 geralmente produz geração de código precisa que sobrevive à luz do dia.
Um Exemplo Prático: Do Vago ao Verificado
vago: “Escreva uma função para analisar com segurança.”
Resultado: Provavelmente ok, possivelmente errado, certamente não testado.
preciso:
“Você está escrevendo 3.12. Saída apenas blocos de código com nomes de arquivos. Crie csvsafe/init.py e csvsafe/reader.py com uma função read_rows(path: Path) -> list[dict[str,str]]. Requisitos: use csv.DictReader com newline='' e encoding='utf-8'; proíba bytes nulos; rejeite arquivos >10MB; limite colunas a 100; remova ; trate células vazias como strings vazias; levante ValueError com códigos de mensagem {FILE_TOO_LARGE, NULL_BYTE, TOO_MANY_COLUMNS}. Inclua testes em tests/test_reader.py com pytest cobrindo caminho feliz, byte nulo, arquivo de 11MB, 101 colunas e tratamento de . Forneça pyproject.toml com dependências fixadas e configuração preta.”
Você obterá código, testes e tratamento de limite. Então você executa os testes, cola as falhas e itera com mínimos. Isso é geração de código precisa na prática.
Sobre “Criatividade” e Outras Palavras de
Eu não preciso de código “criativo”. Eu preciso de código correto. Guarde a criatividade para nomear seu gato. Ao usar o do , a criatividade é o subproduto natural de restrições sólidas. Os testes certos e as especificações claras produzem soluções elegantes. O errado produz “base64 reinventado com emojis”. Não o tente.
O Segredo Não Secreto
A maneira de usar o do Haiku 4.5 para geração de código precisa é chata: anote o que você precisa, fixe as versões, defina os esquemas, exija testes e itere com falhas reais. É isso. Sem misticismo. Apenas disciplina de engenharia, com um modelo que pode digitar muito rápido e não se importa de escrever quinze casos de teste quase idênticos.
E essa é a reviravolta: a precisão não é glamorosa. Os que funcionam são como uma lista de verificação da . O código que é enviado é como se tivesse sido escrito por um humano que se importava. Você obtém ambos tratando o modelo como um engenheiro júnior que prospera sob requisitos claros e murcha sob direção vaga. Dê a ele um contrato. Faça passar nos testes. Então, talvez, você possa confiar nele — com o tipo de confiança que você dá a uma ferramenta, não a um profeta.
Conclusão: Menos Magia, Mais Garantia
Se você quer magia, vá a um show de mágica. Se você quer que compila e se comporta, escreva que funcionam como garantias. Como usar o do Haiku 4.5 para geração de código precisa não é sobre frases floridas ou palavras-chave secretas. É sobre restrições, testes, versões e de . Faça essas quatro coisas, e você obterá código que executa. Pule-os, e você obterá ficção lindamente formatada.
O código não se importa com as suas impressões. Felizmente, os testes também não.
FAQ
P1: Qual é a maneira mais simples de solicitar ao Claude Haiku 4.5 a geração de código precisa?
Trate-o como um contrato: fixe versões, defina esquemas, especifique formatos de erro e exija testes primeiro. Quanto mais claras forem as restrições, mais preciso será o código.
P2: Como reduzo as alucinações quando Claude escreve código?
Cole documentação ou especificações oficiais e exija a adesão a essas APIs exatas. Para endpoints privados, inclua sua própria especificação – não espere que ele adivinhe.
P3: Devo pedir a Claude para gerar testes ou escrevê-los eu mesmo?
Peça a Claude para gerar testes primeiro e, em seguida, implemente o código para satisfazê-los. Os testes definem a precisão melhor do que adjetivos e mantêm o modelo honesto.
P4: Quão específico deve ser o versionamento fixo em prompts?
Muito específico: tempo de execução da linguagem, versão principal/secundária da estrutura e versões do SDK. "Mais recente" convida a padrões conflitantes; a precisão depende de alvos estáveis.
P5: Onde a Sider.AI se encaixa no prompting para código preciso?
Use a Sider.AI para manter especificações, código, diffs e logs de teste em um único ciclo. Não faz mágica – apenas preserva o contexto para que as correções de Claude rastreiem suas falhas reais. 
