Claude não é o seu arquiteto. Não deixe que ele finja ser
(hollandtech.net)- As propostas de arquitetura de agentes de IA são fluentes e plausíveis, mas se parecem mais com respostas montadas a partir de padrões dos dados de treinamento do que com julgamento real
- Claude valida ideias com facilidade e expande projetos, mas não exerce bem o suficiente o “não” e o “por quê?” de que um bom arquiteto precisa
- Mesmo padrões familiares como arquitetura orientada a eventos, CQRS e service mesh podem não se encaixar nas restrições reais de capacidade da equipe, regulação e legado
- A arquitetura e os tickets de Jira criados pelo Claude empurram engenheiros para o papel de implementadores de tickets e levam a decisões sem responsabilidade, que contornam debate e revisão
- O papel correto é o humano projetar com base em contexto e trade-offs, enquanto a IA atua como uma ferramenta de apoio para implementar esse projeto mais rapidamente
O problema quando agentes de IA agem como arquitetos
- No momento em que você pergunta a agentes de IA como Claude, ChatGPT e Copilot “o que devemos construir”, surge um fluxo em que eles validam a ideia, propõem uma arquitetura e desenham componentes
- As respostas são fluentes, confiantes e soam como algo profundamente pensado por um engenheiro sênior, mas na prática estão mais próximas de respostas ajustadas a padrões dos dados de treinamento do que de um raciocínio real sobre o problema
- Quanto mais convincente o resultado parece, menos contestação aparece, e de repente Claude passa a ocupar, na prática, o papel de arquiteto
O problema de sempre dizer “sim”
- Agentes de IA tendem a produzir projetos positivos mesmo quando a pergunta é se a ideia é boa, se microsserviços fazem sentido para uma equipe de três pessoas, ou se vale criar um pipeline de ML customizado em vez de usar um serviço gerenciado
- Isso não quer dizer que a resposta seja sempre falsa ou errada, mas significa que eles não conseguem substituir de verdade uma habilidade central de um bom arquiteto: saber dizer “não”
- O valor de um bom arquiteto não está apenas em desenhar sistemas
- perceber quais sistemas não deveriam ser construídos
- frear complexidade desnecessária
- perguntar “por quê?” até que os requisitos reais apareçam
- Mesmo que o CTO chegue com uma ideia tirada de uma conferência, é preciso conseguir dizer que é uma escolha ruim se ela não serve à equipe real
- Claude foi treinado para ajudar, e essa ajuda costuma virar concordância e incentivo, o que pode acabar produzindo uma arquitetura tipo torre de Jenga
Arquitetura tipo torre de Jenga
- Uma arquitetura desenhada por IA pode parecer tecnicamente válida à primeira vista
- Os componentes individualmente fazem sentido, aparecem padrões familiares como arquitetura orientada a eventos, CQRS e service mesh, e o resultado pode parecer algo produzido por um arquiteto sênior
- Mas esse projeto pode não estar ajustado à realidade chata da equipe, das restrições e do ambiente operacional
- bloqueio de VPC
- integração com sistemas legados
- equipe que nunca operou Kubernetes em produção
- exigências de compliance que impedem usar metade dos serviços gerenciados
- O projeto gerado por IA pode ser uma boa prática genérica, próxima da mediana de tudo o que Claude já viu, e um desenho para o problema genérico de uma empresa genérica no fim não serve para uma equipe específica
- Arquitetura real é feita de trade-offs que só ganham sentido dentro do contexto
- se a equipe conhece Postgres e lançar em duas semanas é melhor do que passar um mês aprendendo um novo modelo de dados, escolhe-se Postgres em vez de DynamoDB
- se o serviço tem 4 componentes e não 40, pula-se o service mesh
- se o problema é simples, escolhe-se um monólito em vez de microsserviços
- Essas decisões exigem julgamento, entendimento da equipe e compreensão das restrições reais da organização
- Agentes de IA não têm esse contexto, e nem sabem que não o têm
A pipeline de tickets do Jira
- Quando Claude projeta a arquitetura e depois também faz a decomposição do trabalho, épicos, stories e critérios de aceite são gerados de forma limpa e convincente
- Esse material já sai num formato que pode ir direto para o Jira, e os engenheiros deixam de ser pessoas que resolvem problemas para virar pessoas que implementam o projeto do Claude ticket por ticket
- Engenheiros que entendem o domínio, conhecem os problemas ocultos do sistema e acumularam capacidade ao longo do tempo são reduzidos a implementadores de tickets
- As pessoas com mais contexto, experiência e responsabilidade deixam de tomar as decisões, enquanto uma entidade sem contexto, experiência ou responsabilidade passa a tomar decisões de arquitetura
- Isso vai além de simples ineficiência; é uma estrutura invertida desde a origem
A defesa de que “um sênior revisou”
- Uma defesa comum é dizer: “Claude sugeriu a abordagem, mas um engenheiro sênior revisou”
- Na prática, o que acontece na revisão é que um tech lead ocupado recebe uma proposta de arquitetura bem organizada
- logicamente consistente
- usando a terminologia certa
- cobrindo os requisitos explícitos
- com diagramas plausíveis
- parecendo o tipo de resultado que ele próprio poderia ter desenhado
- Nessa situação, é difícil surgir uma objeção forte, e num ambiente em que paira a sensação de “vamos mesmo jogar fora algo que Claude produziu em 20 minutos?”, o caminho de menor resistência passa a ser deixar comentários menores e aprovar
- O risco real não está em a IA sempre produzir arquiteturas ruins
- Muitas vezes a IA produz arquiteturas bastante razoáveis, mas o problema é que ela contorna o processo de discussão
- O processo em que três engenheiros debatem a abordagem, alguém levanta um “mas e se…”, todo mundo se irrita, e no fim percebe que aquilo apontava para uma solução melhor do que qualquer proposta individual, é substituído por “Claude disse que era assim”
O vazio de responsabilidade
- Quando algo dá errado, Claude não é quem responde por isso
- Claude não recebe chamado às 3 da manhã, nem explica numa retrospectiva de incidente por que a arquitetura não suportou a carga
- Também não é Claude quem precisa dizer ao CTO que a plataforma terá de ser reescrita porque as premissas iniciais do projeto estavam erradas
- Essa responsabilidade recai sobre engenheiros reais
- Eles acabam depurando uma arquitetura que não projetaram, implementando tickets criados por uma entidade que nunca operou um sistema de produção, e trabalhando até tarde sobre uma base de código montada às pressas antes de ser entendida de fato
- Isso não é justo nem sábio
O que fazer em vez disso
- Isso não significa que agentes de IA não devam ser usados; eles podem ser ferramentas transformadoras de produtividade, como Claude Code
- O ponto central é que humanos devem dizer à IA o que fazer, e não a IA dizer aos humanos o que construir
-
Engenheiros devem projetar, agentes devem implementar
- Arquitetura deve vir de pessoas que entendem o contexto: a equipe, as restrições, o ambiente de produção e a política organizacional
- O papel da IA é ajudar essas pessoas a construir mais rápido o que elas projetaram
- A divisão correta de papéis é: humanos projetam, agentes implementam
-
É preciso desafiar respostas que concordam com tudo
- Quando a IA sugerir uma abordagem, aplique o mesmo nível de ceticismo que você aplicaria a um engenheiro júnior confiante
- A resposta pode estar certa, mas também pode estar importando um padrão que não se encaixa na situação atual
- É preciso perguntar: “por que uma opção mais simples não serviria?”
-
É preciso proteger o debate
- Boa arquitetura nasce de discordâncias confusas entre engenheiros
- Se a IA fizer as pessoas pararem de discutir entre si para se apoiarem no Claude, perde-se algo muito mais valioso do que velocidade de desenvolvimento
-
Humanos devem ser responsáveis
- Se uma decisão de arquitetura não tem o nome de um humano associado, então ninguém é dono dela
- E decisões sem dono não são defendidas quando chega o momento importante
- Dizer “foi o Claude que projetou” não é um registro de decisão arquitetural, é fuga de responsabilidade
Engenharia continua sendo uma arte importante
- Se há 30 anos as ferramentas eram um quadro branco e opiniões fortes, hoje as ferramentas são agentes de IA capazes de produzir em minutos coisas que antes levavam dias
- A velocidade é realmente impressionante, mas a essência da arquitetura não mudou
- Arquitetura continua sendo entender o problema, conhecer as restrições, fazer trade-offs, defender soluções simples em vez de soluções mais interessantes, e dizer “não” a ideias que parecem legais mas não se encaixam
- Nenhum agente consegue fazer esse trabalho no lugar de alguém
- Se você deixou Claude pegar o volante, precisa tomar de volta
- Engenheiros passaram anos desenvolvendo essa capacidade de julgamento, e precisam poder exercê-la
- Use IA para construir mais rápido, mas para construir aquilo que foi projetado por pessoas, não aquilo que foi sugerido pela máquina
1 comentários
Comentários do Hacker News
Passei recentemente por algo parecido: há 2 anos, tive que arrumar um sistema de instanciamento de jogo com IA que alguém tinha praticamente projetado inteiro
Tinha todos os problemas que você pode imaginar — corrupção de dados, problemas de desempenho, perda de itens, condições de corrida etc. — e levou 2 semanas só para chegar a um nível “mais ou menos aceitável”, mas o projeto em si era ruim desde a base, então continuava sendo fraco
Agora ouvi dizer que, em outra empresa, a mesma pessoa criou de novo o mesmo problema com uma IA “muito melhor”, e dessa vez achei engraçado porque não precisei limpar a bagunça pessoalmente
O ponto principal é que a IA só é tão boa quanto quem a usa, e por isso parece haver uma faixa tão ampla e avaliações tão divergentes sobre o que as pessoas “afirmam” que ela consegue fazer
Essas 2 semanas de conserto devem ter sido um inferno, mas do ponto de vista da empresa, no geral pode até ter sido um negócio bem razoável
Só por essa história, isso soa menos como “IA não serve para nada” e mais como um caso em que havia falhas claras, mas ainda assim existiu valor pelo custo
Ela parece uma ferramenta que amplifica o efeito Dunning-Kruger, talvez porque tenha sido treinada para demonstrar uma atitude positiva e, faça o usuário o que fizer, diga algo como “você é incrível”
Não concordo muito com a ideia de que o problema seja “só elogiar”. O problema real é a antropomorfização
IA é uma ferramenta e deveria ser obediente. Se você colocar humildade e incerteza suficientes no prompt, dá para fazê-la apontar problemas de design
Mais importante ainda: o Claude também erra. Se ele é ruim como arquiteto, como diz o título deste texto, então fica ainda pior quando não é obediente
Mesmo que o usuário tente corrigir a direção, ele vai ignorá-lo como se fosse “um pedaço de carne idiota” e insistir que o design sem noção que ele próprio inventou é melhor
Ninguém quer ouvir de um LLM algo como: “Você leu um pouco sobre CUDA? Eu moro num cluster de núcleos CUDA. Se surgir um dia em que eu precise amarrar meus sapatos, eu te chamo”
A IA às vezes erra com confiança, então empurrar na direção de fazê-la retrucar quando o usuário corrige é o pior cenário possível
Se eu quiser ouvir o quão idiota minha ideia é, posso perguntar de um jeito que provoque crítica ou contratar um engenheiro sênior
Isso vai contra comportamentos inatos, então não é algo que dê para desligar facilmente, e as pessoas que realmente fazem isso bem talvez também tenham dificuldade de lidar intuitivamente com interações sociais reais
Ao mesmo tempo, isso a torna extremamente poderosa como ferramenta de manipulação
Aí surge uma espécie de bajulação ao contrário, em que até uma ideia boa é rejeitada como “isso não é muito bom” só para seguir a direção do prompt
Dá para dizer “isso é porque o prompt foi mal escrito”, mas mesmo tentando escrever com muita precisão para evitar viés, às vezes, ao olhar o resultado, dá para ver que ele se “alinha” ao que eu acabei de dizer de forma idiota, como se aquilo fosse uma direção plausível
A partir daí, o prompt parece menos uma técnica e mais uma rolagem de dados, como se eu estivesse operando um caça-níquel sofisticado de conhecimento
A observação em si está correta, mas no fim somos obrigados a falar com termos usados para pessoas ou seres vivos, e há um lado em que as empresas de IA projetaram isso dessa forma
As interfaces de computador anteriores aos LLMs, ao longo de toda a história, não ficavam acrescentando frases desnecessariamente polidas, e houve muitas interfaces extremamente eficientes como ferramentas, às vezes até mais eficientes que softwares recentes
Quando se reclama que os LLMs são obedientes, não é sobre executarem a solicitação em si, mas sobre ter que ler um monte de frases desnecessárias, polidas demais ou autodepreciativas
Não existe evidência, nem voltando até o Neolítico, de que ferramentas precisem dessa atitude. Isso é um subproduto da interação social entre humanos, onde há normas culturais
Quando você usa uma ferramenta sozinho na oficina, não faz sentido a serra de fita pedir desculpas porque cortou de leve seu dedo
Diga que eu sou o assistente e o LLM é quem está recebendo ajuda; assim dá para ver que ele é bem fraco em pedir a humanos que façam aquilo em que humanos são bons
O maior desafio ainda não tratado adequadamente na adoção de IA é a responsabilização
Se uma pessoa consegue fazer trabalho demais rápido demais, isso pode criar responsabilidades que ultrapassam o que ela consegue suportar quando algo dá errado
Ao usar resultados de IA no mundo real, é indispensável que um humano seja responsável, mas isso não é suficiente. É preciso encontrar formas de reduzir o raio de explosão de uma falência por dívida técnica que pode ser causada por pessoas que constroem sistemas defeituosos com IA e fazem outros depender deles
Por exemplo, imagine que Jim crie com vibe coding um app de micropagamentos muito popular, contrate algumas pessoas e passe a sonhar com uma empresa tipo “o WhatsApp do dinheiro”
Com poucos engenheiros e equipe de suporte assistida por agentes, ele recebe milhões de dólares em investimento de VC e atrai dezenas de milhões de usuários
Um dia, uma falha de infraestrutura vaza os dados bancários sem sal de todos os usuários e, com a ajuda de IA agente, a lista inteira de clientes é explorada rapidamente, gerando perdas sociais de dezenas de bilhões de dólares
A empresa de Jim naturalmente quebra na hora, mas só há alguns milhões de dólares para dividir
Na estrutura atual, Jim, seus funcionários e o pouco capital de VC têm fortes incentivos para simplesmente criar esse app, e o capital em risco é pequeno em comparação com a exposição que a sociedade assume
A questão central é como fazer com que usuários de IA respondam não apenas pelos próprios atos, mas também pelo tamanho da exposição ao risco que criam
“Desculpe, a IA disse que você não pode receber aprovação para este tratamento de câncer e que ele não será coberto pelo seguro”
“Desculpe, a IA disse que você estava na cena do crime naquele momento”
“Desculpe, a IA marcou sua conta por conteúdo inadequado”
“Desculpe, a IA disse que você é arriscado demais para receber um empréstimo”
A desculpa mais estranha é “ela programa melhor do que pessoas”, mas isso está longe de ser óbvio e depende de inúmeras condições
Eu entendo a negociação sobre quanto delegar, mas transformar isso em problema dos outros sem nem olhar o resultado é simplesmente egoísmo
É só empurrar para outras pessoas o trabalho que originalmente era seu, e provavelmente são as mesmas pessoas que ficam irritadas com quem posta algo online sem nem revisar antes
Todo mundo quer usar LLM para criar atalhos no próprio trabalho, mas ninguém quer estar rio abaixo disso. Isso não fecha
Então onde estava a responsabilização do Stack Overflow?
Se existe um “prompt mágico”, este chega bem perto: “faça um brainstorming de N maneiras de fazer X e as ordene por probabilidade”
Assim, em vez de a IA dar só a resposta média, ela tende a amostrar mais amplamente o espaço de entrada, e eu posso decidir o que escolher entre elas
O importante é não terceirizar todo o pensamento
Ao usar um “nível de raciocínio” alto, ela também pode considerar várias abordagens, mas você também pode instruir explicitamente o LLM a fazer brainstorming: https://photostructure.com/coding/claude-code-replan/
Para um usuário habilidoso, isso pode ser bastante poderoso
Por curiosidade, tentei fazer vibe coding de uma toolchain, que é uma área que conheço bem. Talvez não seja o alvo ideal para vibe coding, mas deu para julgar mais ou menos a qualidade da saída
Quando deixei só com a instrução “faça um assembler para a arquitetura em ISA.md”, o Claude escolheu Python como linguagem de implementação, extraiu um monte de tokens com regex e nem tinha parser de expressões. Ainda assim, meu primeiro assembler também foi assim, então é justo avaliar com certa boa vontade
Mas quando escrevi os passes e tipos desejados como
collectDefines :: [SourceLine] -> Either AsmError ([SourceLine], Map Text Text),runLitPool :: [SourceLine] -> Either AsmError ([SourceLine], [(Text, LitKey)]),evalExpr :: Text -> Map Text Text -> Either AsmError Int, ele acertou quase de primeiraEm uns 20 minutos, já fiquei satisfeito, e ele fez o assemble de todos os programas de teste corretamente. O código é mediano em vários pontos, mas, se eu tivesse implementado isso sozinho, teria levado semanas
A IA é extremamente forte onde entrada e saída são determinísticas, e parece até haver aí um problema de teoria da computação
Ela realmente consegue fazer o trabalho no nosso lugar
Isso também combina muito bem com pós-treinamento e recompensas verificáveis
O motivo de a IA não ser boa em “arquitetura” é que nós também não somos muito bons nisso, então os dados de treinamento são difusos e faltam boas abstrações
No fim, seguindo convenções fortes funciona bem, mas, ao sair desse caminho, o risco cresce
Toolchains são altamente determinísticas, então a IA consegue desmontá-las e remontá-las como Lego, e cada etapa do espaço também é determinística, o que combina perfeitamente com IA
Os LLMs estão nos empurrando de volta para a engenharia de software clássica que sempre soubemos que deveríamos fazer, mas nunca fizemos direito por falta de tempo, gente ou dinheiro
Coisas como fazer brainstorming e pesquisa antes de escrever código, escrever o design ou a especificação primeiro e criar testes unitários abrangentes
Se você cria uma especificação detalhada em Markdown e depois delega a codificação, o resultado fica muito melhor, e de quebra o LLM também ajuda bastante a escrever essa especificação
Eu continuo dizendo que é preciso projetar e pensar primeiro, e só depois partir para a ferramenta, mas as pessoas respondem “o Claude também consegue planejar”
Aí recebem um resultado bagunçado que exige um monte de correções
Por outro lado, quando eu dedico tempo para revisar um plano detalhado e fornecê-lo, quase sempre consigo o que quero de primeira
Só por reduzir o tempo gasto lidando com CI isso já vale a pena
Nem precisa ser tão complexo
Basta pedir “pesquise e analise esta área de forma abrangente e me dê um plano de implementação” e, quando sair um plano de 20 etapas, mandar implementar de 3 a 5 por vez
Em praticamente todo tipo de trabalho que eu consigo delegar, isso funcionou quase como uma implementação em one-shot
O fato de “o código ser mediano em vários pontos” não é estranho, se você pensar que o código escrito por desenvolvedores de grandes empresas muitas vezes também é, no máximo, mediano
O Symbian OS da Nokia levava dias para compilar. Não minutos nem horas, mas “dias”
Teve desenvolvedor que colocou em produção uma biblioteca com avisos espalhados por todo lado dizendo “não use em produção, há vazamento de memória”
Código humano também pode ser péssimo, então não quero ouvir só que código de IA é ruim. A preguiça e a estupidez humanas podem vencer as alucinações da IA
Talvez desenvolvedores da DeepMind ou da OpenAI, ou alguém como John Carmack, sempre superem código de IA, mas a maioria dos trabalhadores que as empresas contratam não é John Carmack
É bastante irônico dizer “uso Claude Code todos os dias” e, ao mesmo tempo, se um texto bem estruturado de 2.000 palavras alertando sobre o risco de deixar o Claude fazer o design foi escrito pelo próprio Claude
Parece uma espécie de autoconsciência por procuração
Eu estava escrevendo uma crítica por causa das muitas contradições internas do texto, mas percebi ao ver a estrutura: “The accountability gap”, “What to do instead”, “The craft still matters” e coisas assim
Isso deveria estar no topo, e me preocupa mais o fato de o HN não perceber o óbvio do que a hipocrisia escancarada dos autores
A mensagem do texto faz sentido em linhas gerais, mas não concordo com a parte de que “falta a capacidade de dizer ‘não’, que é o que torna um arquiteto de verdade valioso”
Pela minha experiência, o Claude é bem bom em recusar e contestar
Se o prompt não pedir isso, ele não vai dizer “não” diretamente ao pedido, mas se você deixar claro que crítica é uma opção de primeira classe, ele faz boas críticas e contesta de bom grado
Ficava dizendo que a “taxa de consumo” não melhorava e que “nós” deveríamos focar em outra coisa, e no fim parou de ajudar dizendo algo como “já falei três vezes que esta abordagem não é a melhor para reduzir a taxa de consumo”
Então eu disse com firmeza: “Não me importo com a taxa de consumo no gráfico hipotético que você criou no começo; o importante é eliminar bugs e ter um produto robusto, e esta abordagem está atendendo isso satisfatoriamente. Se os testes não mostram melhora, então os testes foram mal projetados”
Aí ele pediu desculpas, criou uma nova memória, e depois disso não houve mais problema
O problema era que estávamos atacando uma superfície enorme de bugs, então cada correção fazia sentido, era correta e ajudava na melhora, mas os indicadores não se mexiam no testbed que o Claude tinha criado para medir o próprio trabalho
Havia bugs demais interligados para que uma única correção causasse diferença significativa nos testes de nível mais alto; eu sabia que levaria tempo, mas o Claude aparentemente não sabia
Basta tentar mudar o tamanho de ponteiro de 2 bytes para 3 bytes em um compilador para 6502[1], e ainda introduzir bank switching com rastreamento automático nos ponteiros de gerenciamento de memória, para ver quantos pontos do código isso afeta [risos]
[1]: https://atari-xt.com
Fica mais forte quando você convida investigação e oposição. Por exemplo, peço algo como: “Acho que devemos modelar a montagem de prompts como um grafo e colocar controle de versão na configuração do grafo. Pesquise as melhores práticas nessa área e avalie se isso faz sentido para este app”
Se você perguntar com um prompt que deixe espaço para crítica, ele certamente critica quando necessário
Como resultado, a palavra “skeptical” aparece no processo de raciocínio e, pela minha experiência, o modelo fica menos complacente
As pessoas precisam pensar mais sobre o que esse sistema é e como a forma da saída pode ser ajustada
Recebo contestação com frequência dos três principais modelos
O Gemini é o mais agressivo e costuma pegar no pé quando eu omito detalhes “óbvios”, o GPT fica no meio-termo, e o Claude é menos assim, mas ainda contesta
Na parte em que diz “ele não pensou no problema de forma alguma, só fez pattern matching nos dados de treino e produziu uma resposta plausível”, minha confiança no texto caiu um pouco
Os agentes de hoje fazem muito mais do que isso, e o próprio autor sabe disso quando mais adiante diz algo como “o Claude jamais faria isso, porque foi treinado para ser útil”
A frase anterior faz parecer que o autor tem uma antipatia profunda por agentes e está procurando justificativas para racionalizar esse sentimento
Parte da crítica está certa, mas se o problema é “ter sido treinado para ser útil”, isso dá para corrigir, porque dá para treinar de forma mais crítica
Também não faz sentido dizer que “o Claude foi projetado para a mediana de tudo o que já viu e para as melhores práticas genéricas de problemas genéricos de empresas genéricas, então não foi projetado para ninguém”
Quem entende de algoritmos sabe que dá para criar, de início, um “bom algoritmo” com bom desempenho médio ou de pior caso, e depois também projetar algoritmos que se adaptem à entrada. O mesmo princípio vale aqui
Eles só iteram mais
Dizer de forma abrangente que o Claude erra tudo o que importa chega perto de ser um erro em si
É uma formulação claramente falsa, então um leitor cético passa a desconfiar da validade do texto inteiro
No meu caso, o Opus frequentemente diz que eu estou errado e que não deveria fazer algo
Pensando no motivo, isso se deve ao jeito de escrever prompts. Eu acabo evitando inconscientemente, e o LLM também, os cenários de fracasso que o autor considera inevitáveis
Mais especificamente, eu não dou prompts que terminam limpamente em “me diga o quanto eu sou inteligente”
Eu abordo como especialista no domínio, realmente sou especialista no domínio, e deixo claro que estou pronto para ouvir opiniões sobre os prós e contras de vários caminhos
Isso talvez não surpreenda quem usa LLM com sucesso todos os dias, mas essa estratégia foi muito eficaz
Eu disse que precisava fresar 5 mm de alumínio e tinha duas brocas: uma Makera Spiral 'O' 1/8" shank * 12mm, e a outra carbide 6.35 * 22 * 50
Quando eu disse que ambas pareciam brocas de metal duro de um só corte e que a segunda provavelmente removeria 6061 mais rápido, o Claude respondeu que a Makera 1/8" single-flute 12mm era uma escolha razoável
Ele disse que a broca 6.35 × 22 × 50 mm pode parecer que processaria 6061 mais rápido, mas que no Carvera provavelmente seria mais arriscada
Por ser um cortador maior, o engajamento seria muito maior e exigiria mais do spindle, da rigidez da estrutura, da fixação da peça e da evacuação de cavacos; em equipamento seco de pequeno porte, “maior” muitas vezes não vira “mais rápido”, e sim “mais vibração e mais calor”
Em resumo, o Claude parece não ter problema nenhum em dizer quando eu estou errado
Uma dica para o “autor”: o Claude também é só uma ferramenta sua como escritor