Debate sobre o Harness da OpenAI e Anthropic: Modelos Mais Fortes, Apostas de Engenharia Opostas

Engenheiros da OpenAI reabriram uma disputa relevante com a Anthropic: modelos de IA mais fortes deveriam precisar de harnesses mais leves, embora tarefas exigentes ainda se beneficiem de supervisão mais robusta.

Esse debate sobre o harness da OpenAI e Anthropic não trata apenas de prompts ou preferências de interface. Ele envolve o software que circunda um modelo, incluindo ferramentas, memória, permissões, planejamento, avaliação e aprovação humana.

A OpenAI argumenta que uma estruturação excessiva pode codificar limitações que o próximo modelo já não terá. Experimentos recentes da Anthropic chegaram a uma conclusão mais condicional. Modelos melhores eliminaram parte da orquestração, mas planejadores e avaliadores independentes continuaram valiosos quando as tarefas se aproximavam dos limites do modelo.

A discordância afeta mais do que Codex e Claude Code. Empresas estão transformando modelos gerais em agentes que editam repositórios, operam navegadores, analisam documentos e coordenam projetos extensos. Cada controle adicional pode melhorar a confiabilidade, mas também acrescenta latência, complexidade e outra premissa que pode se tornar obsoleta.

A questão central, portanto, não é se os harnesses importam. O trabalho de engenharia de ambas as empresas mostra que sim. A questão é se o progresso transfere valor para o modelo, para o harness ou repetidamente entre as duas camadas.

O Que OpenAI e Anthropic Realmente Mudaram

Ambas as empresas agora tratam o harness de agentes como uma camada definidora do produto, mas discordam sobre quanta inteligência essa camada deve conter.

Um harness de agentes é o ambiente de execução que conecta um modelo a ferramentas, contexto, memória, ciclos de feedback e controles do usuário. O modelo gera decisões. O harness determina quais informações ele vê, quais ações pode realizar e como os erros são detectados.

A posição da OpenAI ficou clara em reportagens de agosto sobre seu esforço para expandir agentes além do desenvolvimento de software. Seus engenheiros descreveram uma boa engenharia de harness como oferecer a um modelo as ferramentas e informações precisas de que ele precisa, sem cercá-lo de regras desnecessárias.

O engenheiro Nick Gershenson disse ao TechCrunch que coleções elaboradas de lógica condicional e ferramentas podem gerar ganhos de curto prazo. No entanto, ele argumentou que um novo modelo pode tornar essas adições obsoletas em poucos meses. Sua direção preferida é uma interface contida que permita a um modelo capaz resolver uma parcela maior do problema por conta própria.

Esse princípio ecoa a bitter lesson, o influente argumento de Rich Sutton sobre a computação geral superar sistemas construídos em torno de amplo conhecimento humano. Aplicada a agentes, a lição favorece modelos com capacidades amplas em vez de fluxos de trabalho projetados manualmente para cada falha prevista.

A OpenAI não abandonou a engenharia de harness. Seu próprio relato sobre a engenharia do Codex descreve repositórios, documentação, testes, ciclos de feedback e planos legíveis por máquinas como infraestrutura essencial. A empresa relatou uma média de 3,5 pull requests por engenheiro a cada dia em um projeto interno.

A distinção está em onde a OpenAI quer que a complexidade resida. Seus engenheiros favorecem ambientes legíveis e feedback claro, em vez de ramificações cada vez mais elaboradas que determinam como o modelo deve raciocinar.

A pesquisa da Anthropic de 24 de março apresentou um teste de estresse diferente. O pesquisador Prithvi Rajasekaran usou um planejador, um gerador e um avaliador para criar aplicações completas em sessões autônomas prolongadas.

O planejador traduziu uma solicitação curta em uma especificação estruturada. O gerador implementou esse plano. O avaliador operou a aplicação, verificou critérios acordados e devolveu defeitos para correção.

A comparação inicial da Anthropic constatou que uma execução com um único agente produziu uma aplicação cuja principal funcionalidade de jogabilidade não funcionava. O harness multiagente entregou um resultado mais amplo e funcional, embora falhas permanecessem.

Isso não foi evidência de que uma estrutura mais robusta sempre vence. Posteriormente, a Anthropic removeu a decomposição em nível de sprint quando Claude Opus 4.6 passou a lidar com trabalhos mais longos de forma mais coerente. Ainda assim, o planejador e o avaliador continuaram encontrando recursos ausentes ou superficiais.

O evento representa, portanto, convergência e discordância ao mesmo tempo. OpenAI e Anthropic simplificam os harnesses quando os modelos absorvem responsabilidades antigas. Elas divergem sobre a rapidez com que os desenvolvedores devem confiar nessa transferência.

Por Que o Debate sobre o Harness da OpenAI e Anthropic Importa Agora

A pressão vem de agentes que avançam além de tarefas de programação delimitadas para trabalhos nos quais o sucesso é mais difícil de definir e a falha é mais difícil de reverter.

A programação forneceu o primeiro ambiente favorável para agentes. Repositórios contêm arquivos estruturados, compiladores expõem erros e testes frequentemente produzem sinais claros de aprovação ou reprovação. Um harness pode transformar esses sinais em outra tentativa do modelo.

O trabalho geral do conhecimento oferece menos verificações confiáveis. Um memorando estratégico pode parecer coerente enquanto se apoia em premissas frágeis. Uma planilha pode calcular corretamente e ainda responder à pergunta de negócio errada. Um agente pode concluir uma apresentação bem-acabada sem perceber que suas evidências estão desatualizadas.

A OpenAI está expandindo sua abordagem de agentes para esses contextos menos estruturados. Esse movimento pressiona a empresa a preservar a simplicidade associada a modelos mais fortes, ao mesmo tempo que adiciona os controles exigidos por usuários comuns.

A Anthropic enfrenta a pressão oposta. Claude Code construiu boa parte de seu apelo em torno de progresso visível, interação frequente e envolvimento do usuário. Essa abordagem pode parecer mais segura, mas perguntas e aprovações repetidas aumentam a carga de trabalho do operador.

A rivalidade reflete dois instintos de produto. A OpenAI frequentemente buscou a experiência de atribuir um objetivo e receber um resultado concluído. A Anthropic, em geral, expôs mais do processo intermediário de raciocínio por meio de planos, alternativas e solicitações de permissão.

Nenhum dos dois instintos é universalmente melhor. A autonomia se torna atraente quando o objetivo é claro e a verificação é barata. A colaboração se torna valiosa quando as preferências não são declaradas ou as consequências são difíceis de medir.

Isso explica por que uma interface pode alterar a qualidade aparente de um modelo idêntico. Um harness controla a seleção de contexto, as descrições de ferramentas, o comportamento de novas tentativas, o acesso a arquivos e o momento da intervenção do usuário. Essas decisões moldam cada ação realizada pelo modelo.

Criadores independentes de frameworks observaram a mesma dependência. A LangChain relatou que perfis de harness específicos para cada modelo produziram melhorias de 10 a 20 pontos em um subconjunto do tau2-bench, em comparação com sua configuração padrão. Seus perfis de harness ajustam prompts, ferramentas e middleware para diferentes comportamentos de modelos.

Esse resultado desafia uma versão simples da tese da OpenAI. Se o harness fosse apenas uma muleta temporária, modificá-lo não deveria criar grandes diferenças de desempenho enquanto o modelo subjacente permanece fixo.

No entanto, também sustenta a crítica da OpenAI à abstração desnecessária. A LangChain não encontrou uma única arquitetura cada vez mais complicada que melhorasse todos os modelos. Ela constatou que modelos diferentes respondiam a configurações diferentes.

A pressão prática recai sobre as equipes de produto. Elas precisam decidir entre otimizar de perto para um provedor ou manter uma camada portátil entre vários modelos.

A otimização próxima pode proporcionar melhores resultados imediatos. Também pode criar dependência de ferramentas, prompts e comportamento de contexto específicos do provedor. A portabilidade limita essa dependência, mas um harness genérico pode deixar capacidades do modelo sem uso.

Essas escolhas se tornam mais relevantes à medida que os agentes recebem permissões mais amplas. Um assistente de programação que sugere um patch desempenha uma função limitada. Um agente que lê comunicações, edita documentos compartilhados e aciona sistemas empresariais atravessa vários limites de confiança.

As equipes que avaliam esses produtos deveriam, portanto, olhar além dos benchmarks de modelos. Elas precisam de evidências sobre a combinação completa entre modelo e harness sob permissões, dados e condições de falha realistas.

A OpenAI Quer que o Modelo Lidere

O argumento da OpenAI por harnesses mais leves afirma que os desenvolvedores devem expor o ambiente com clareza e, então, permitir que o modelo forneça a maior parte do comportamento adaptativo.

Essa posição não significa remover testes, permissões ou gestão de contexto. Significa resistir a procedimentos de raciocínio construídos manualmente que compensam limitações que se espera que desapareçam.

A experiência da OpenAI com a primeira aplicação web do Codex ajuda a explicar essa convicção. A empresa inicialmente apostou que um modelo concluiria tarefas com envolvimento mínimo do usuário. A abordagem mais interativa do Claude Code, da Anthropic, mostrou-se mais alinhada ao que os modelos conseguiam fazer de forma confiável naquele momento.

Mais tarde, a OpenAI acrescentou mais oportunidades para os usuários orientarem o Codex. Um engenheiro reconheceu que o produto anterior estava à frente do que seu modelo e harness podiam suportar.

Esse histórico importa porque mostra o perigo dos dois lados. Um harness pode conter lógica rígida demais. Ele também pode presumir mais competência do modelo do que os usuários realmente recebem.

A abordagem atual da OpenAI busca evitar outro desalinhamento por meio de ambientes mais claros e feedback mais forte. Seu relato interno de engenharia enfatiza documentação estruturada, regras de repositório, planos e verificações automatizadas.

Esses elementos são mais leves do que um fluxo de trabalho que prescreve cada etapa de raciocínio. No entanto, ainda representam engenharia extensa. O harness delega julgamento enquanto torna o sucesso mais fácil de inspecionar.

A abordagem também se encaixa nas ambições de produto da OpenAI. Um agente geral para o ambiente de trabalho não pode depender de designers prevendo cada sequência que um usuário possa solicitar. O espaço de tarefas possíveis é amplo demais.

Um sistema liderado pelo modelo pode escolher ferramentas e revisar planos à medida que as condições mudam. Essa flexibilidade é atraente quando os usuários passam de pesquisa para planilhas, mensagens, código e apresentações dentro de uma única atribuição.

No entanto, um harness mínimo transfere mais responsabilidade para o modelo. O modelo precisa perceber ambiguidades, solicitar informações ausentes e reconhecer quando uma ação merece confirmação.

Esses comportamentos não são garantidos apenas pela capacidade geral. Um modelo pode se tornar melhor na execução de instruções sem se tornar igualmente melhor em detectar um objetivo falho.

A experiência do usuário agrava esse risco. Ethan Mollick, professor da Wharton que estuda IA no ambiente de trabalho, contrastou sistemas que tentam concluir o trabalho imediatamente com aqueles que mostram comparações e solicitam feedback.

O design mais autônomo reduz a fricção quando o agente interpreta corretamente o objetivo. Quando isso não ocorre, os usuários podem descobrir o erro apenas depois de uma longa cadeia de trabalho coerente, mas mal direcionado.

Isso torna a qualidade do contexto central. Um harness leve funciona melhor quando fornece informações concisas, relevantes e atuais. Um contexto grande e não filtrado pode ocultar prioridades, mesmo quando o modelo oferece suporte a uma longa janela de contexto.

Para trabalhadores do conhecimento, organizar essas evidências continua sendo um problema de engenharia distinto. Uma base de conhecimento pesquisável pode reduzir o ruído de recuperação antes de um agente começar a agir.

A tese da OpenAI é mais forte para tarefas com feedback denso de máquinas. Compiladores, suítes de testes, linters e verificações no navegador permitem que um agente avalie o progresso sem julgamento humano constante.

Ele se torna mais fraco quando a conclusão depende de gosto, histórico organizacional ou expectativas não registradas. Um modelo não pode inferir evidências que nunca entram em seu contexto.

A OpenAI está, portanto, fazendo uma aposta calculada. À medida que os modelos melhoram, eles lidarão internamente com mais planejamento e recuperação. Os projetistas de harnesses devem preservar a generalidade, em vez de congelar no produto de amanhã as limitações dos modelos de ontem.

Anthropic Diz que Trabalhos Mais Difíceis Ainda Precisam de Mais Estrutura

As evidências da Anthropic sobre harnesses mais robustos mostram que modelos mais fortes não eliminam a orquestração; eles deslocam seu limite útil para tarefas mais difíceis.

O harness de longa duração da Anthropic partiu de duas fraquezas recorrentes. Os modelos perdiam coerência durante trabalhos extensos e avaliavam sua própria produção de forma generosa demais.

O primeiro problema dizia respeito ao contexto. Tarefas longas acumulam decisões, resultados de ferramentas, erros e implementações parciais. Mesmo quando uma janela de contexto consegue conter esse material, sua organização afeta o que o modelo percebe.

A Anthropic usou redefinições de contexto com arquivos estruturados de transferência. Uma redefinição dava a uma nova sessão de agente um estado de trabalho limpo, preservando o progresso essencial e os próximos passos.

O segundo problema era a autoavaliação. O mesmo modelo que produzia uma aplicação frequentemente aceitava resultados fracos, especialmente quando a qualidade dependia de julgamento de design.

A Anthropic separou a criação da revisão. Seu avaliador usava critérios explícitos e automação de navegador para testar a funcionalidade. O gerador recebia constatações concretas e tentava corrigir os problemas.

O primeiro harness completo expandiu uma solicitação de jogo de uma frase em 16 recursos distribuídos por dez sprints. Seu avaliador aplicou contratos detalhados a cada sprint, incluindo 27 critérios para uma etapa do editor de níveis.

A Anthropic relatou que o resultado multiagente ofereceu funcionalidades centrais operacionais que a tentativa com um único agente não tinha. No entanto, exigiu substancialmente mais tempo de execução, orquestração e uso de modelo.

Essa troca torna o experimento mais útil do que uma simples vitória em benchmark. Ela mostra o que uma estrutura adicional pode proporcionar, ao mesmo tempo que expõe por que as equipes não podem adicionar avaliadores indiscriminadamente.

A Anthropic então repetiu o processo com um modelo mais forte. O Opus 4.6 sustentou a construção principal por mais de duas horas sem a decomposição anterior em sprints.

Isso corroborou a observação central da OpenAI. Uma capacidade antes fornecida pelo harness havia migrado para o modelo, tornando parte da estrutura de apoio desnecessária.

O avaliador ainda encontrou lacunas relevantes. Ele identificou recursos centrais de áudio que existiam apenas como elementos superficiais de interface ou espaços reservados. O gerador então resolveu várias dessas omissões.

A conclusão da Anthropic não foi que toda tarefa precisa de três agentes. O avaliador gerou seu maior valor quando o trabalho estava próximo do limite do que o gerador conseguia concluir de forma confiável.

Esse limite é dinâmico. Uma nova versão do modelo o desloca para fora. Uma tarefa mais exigente o move novamente para dentro.

Isso produz uma interpretação diferente da bitter lesson. Modelos generalistas substituem soluções feitas à mão para os problemas de ontem, mas também tornam alcançáveis objetivos antes impraticáveis.

Quando as equipes passam a tentar esses objetivos, surgem novos modos de falha. O harness não desaparece. Ele acompanha a fronteira das capacidades.

A posição da Anthropic também reconhece que a avaliação é parte do produto. Um sistema que gera mais produção não é automaticamente mais útil. Alguém ou algo precisa determinar se essa produção atende ao requisito real.

Para desenvolvedores, suítes de testes podem fornecer grande parte desse julgamento. Para trabalhos de design, pesquisa e gestão, os critérios frequentemente precisam ser definidos antes de o agente agir.

Uma arquitetura de planejador-avaliador torna essas expectativas explícitas. Ela também pode amplificar critérios ruins. Um avaliador imporá o proxy mensurável que recebe, mesmo quando esse proxy não capta o que os usuários valorizam.

Harnesses mais robustos, portanto, criam seu próprio problema de governança. Mais componentes significam mais prompts, permissões, logs, transferências e caminhos de falha a manter.

As evidências da Anthropic apoiam uma estrutura seletiva, não complexidade permanente. Remova o que um modelo mais forte agora consegue lidar, depois reinvista o esforço de engenharia onde a verificação ainda produz um ganho significativo.

O Teste Modelo versus Harness Continua em Aberto

Nenhum dos lados mostrou que sua arquitetura preferida vence em todos os modelos, tarefas, orçamentos e níveis de risco.

O debate entre os harnesses da OpenAI e da Anthropic depende fortemente de experimentos internos e observações de produto. Essas fontes revelam escolhas de engenharia, mas não fornecem uma comparação controlada entre Codex e Claude Code.

O relato da OpenAI reflete seus próprios modelos, repositórios e práticas de equipe. Os exemplos da Anthropic usam modelos Claude em tarefas selecionadas de construção de aplicações. Cada empresa escolheu o ambiente e os critérios de sucesso.

Até a comparação detalhada da Anthropic alterou diversas variáveis de uma só vez. O sistema completo adicionou planejamento, avaliação, decomposição, execução mais longa e mais chamadas ao modelo. O resultado não consegue isolar qual componente gerou cada melhoria.

Mais tarde, a empresa usou a remoção de componentes para entender essa questão. Ainda assim, suas conclusões vieram de uma pequena coleção de demonstrações, e não de replicação independente ampla.

Benchmarks de terceiros ajudam, mas introduzem complicações adicionais. Um harness pode ter bom desempenho porque o benchmark se assemelha ao seu fluxo de trabalho preferido. Outra configuração pode otimizar uso de tokens, taxa de aprovação, latência ou capacidade de recuperação.

A mesma pontuação também pode ocultar riscos operacionais diferentes. Um agente pode falhar de maneira visível e parar. Outro pode produzir um resultado plausível, mas incorreto, que passa pela verificação automatizada.

Pesquisas sobre sistemas de programação em produção tratam cada vez mais o modelo e o harness como uma unidade combinada. Um recente estudo de código-fonte examinou 11 harnesses de programação, incluindo Claude Code, Codex CLI, Gemini CLI, Pi, OpenCode e OpenHands.

Essa diversidade enfraquece a ideia de um único harness ideal. Esses sistemas diferem em gestão de contexto, pontos de extensão, planejamento, isolamento e execução de ferramentas porque seus projetistas visam usuários diferentes.

A portabilidade apresenta outra questão ainda sem solução. Reportagens citaram uma comparação na qual o harness de código aberto Pi superou o Codex usando o mesmo modelo da OpenAI.

Um resultado assim sugere que o provedor do modelo não constrói automaticamente o melhor ambiente para todas as tarefas. Ele não estabelece que o Pi vence de forma ampla, já que a configuração do benchmark e os ajustes continuam decisivos.

Harnesses abertos podem expor rastros, uso de tokens e detalhes de configuração que produtos proprietários ocultam. Essa transparência ajuda as equipes a diagnosticar falhas e trocar de provedores.

Harnesses controlados pelo provedor recebem acesso antecipado a capacidades específicas do modelo. Seus desenvolvedores podem ajustar o sistema em torno de comportamentos não documentados e implementar atualizações coordenadas.

Os incentivos de negócio importam. OpenAI e Anthropic se beneficiam quando clientes usam seus modelos por meio de suas próprias interfaces. Controlar o harness fortalece a distribuição e pode aumentar os custos de troca por meio de contexto armazenado, integrações e fluxos de trabalho aprendidos.

Isso não torna falsas suas alegações de engenharia. Significa que os clientes devem separar evidência técnica de estratégia de plataforma.

O custo é outra incerteza, mesmo sem comparar números públicos de preço. Planejamento e avaliação multiagente consomem tokens e tempo adicionais. Uma taxa de conclusão maior pode justificar essa sobrecarga quando falhar é caro.

O oposto se aplica a trabalhos rotineiros e reversíveis. Executar um avaliador sobre cada pequena edição pode consumir mais recursos do que corrigir o erro ocasional.

A segurança complica ainda mais a tese do harness mais leve. Modelos melhores podem executar sequências de ações mais longas e usar ferramentas de forma mais eficaz. Essas melhorias aumentam as consequências de instruções mal compreendidas.

Limites de permissão, logs de auditoria, sandboxing e confirmações são funções do harness. Uma capacidade maior pode aumentar sua importância, mesmo reduzindo a necessidade de estruturas de planejamento.

As equipes devem, portanto, rejeitar testes unidimensionais. Uma avaliação útil precisa medir conclusão de tarefas, defeitos ocultos, tempo de revisão humana, consumo de recursos e recuperação após falhas.

Ela também deve comparar configurações sob o mesmo modelo. Caso contrário, uma equipe pode comprar um modelo mais capaz quando uma mudança de contexto ou ferramenta teria resolvido o problema.

As evidências atuais sustentam uma regra condicional. Use o harness mais leve que atinja um limiar de confiabilidade definido e, então, adicione estrutura onde falhas observadas a justifiquem.

Essa regra soa como um compromisso, mas cria um trabalho operacional exigente. As equipes precisam de avaliações repetíveis, inspeção de rastros e configurações versionadas para saber quando um componente continua útil.

Sem essas evidências, “mais leve” vira fé no próximo modelo. “Mais pesado” vira folclore acumulado, codificado como prompts e ramificações de fluxo de trabalho.

Três Sinais Decidirão Qual Abordagem Vence

A próxima fase será decidida por evidências comparativas, e não pela descrição preferida de sua arquitetura por qualquer uma das empresas.

O primeiro sinal é o desempenho sob troca de harnesses. Pesquisadores e criadores de frameworks precisam de testes controlados que mantenham constantes o modelo, a tarefa, o acesso a ferramentas e os limites de recursos.

Se harnesses de terceiros superarem repetidamente as interfaces dos provedores usando o mesmo modelo, o valor estará migrando para a orquestração. Esse resultado enfraqueceria a crença de que o progresso dos modelos absorve naturalmente a maior parte da diferenciação de produto.

Se as diferenças de desempenho diminuírem entre harnesses bem projetados, a tese da OpenAI ganha apoio. Isso sugeriria que modelos mais fortes precisam de menos intervenções especializadas e podem operar em ambientes mais simples e padronizados.

O segundo sinal é como Anthropic e OpenAI simplificam seus próprios sistemas após cada lançamento de modelo. A Anthropic já mostrou uma versão desse teste ao remover a decomposição em sprints dos fluxos de trabalho do Opus 4.6.

Observe quais componentes desaparecem em seguida. Planejamento, redefinições de contexto, avaliação independente e aprovações frequentes representam, cada um, uma suposição diferente sobre os limites dos modelos.

Remover um componente sem reduzir a qualidade da tarefa fortalece o argumento do harness mais leve. Transferir esse componente para uma classe de trabalho mais difícil apoia a interpretação de fronteira móvel da Anthropic.

O terceiro sinal é a adoção fora da engenharia de software. Agentes de programação se beneficiam de repositórios, testes e feedback digitalizado. O trabalho do conhecimento contém sinais mais fracos e preferências mais implícitas.

Um agente liderado pelo modelo parecerá convincente se as pessoas aceitarem o trabalho concluído sem correções extensas. Um harness colaborativo parecerá mais forte se os usuários precisarem consistentemente de prévias, comparações e pontos de aprovação.

A métrica de adoção mais útil não será o número de tarefas iniciadas. Será a parcela concluída corretamente após considerar a revisão humana e o retrabalho.

Os desenvolvedores também devem acompanhar a gravidade das falhas. Um harness que conclui menos tarefas, mas para com segurança, pode ser preferível a outro que conclui mais enquanto comete erros difíceis de detectar.

Compradores corporativos devem exigir avaliações usando seus documentos, permissões e fluxos de trabalho. Rankings públicos não conseguem representar definições de correção específicas de cada organização.

Profissionais do conhecimento podem conduzir uma versão mais simples desse processo. Comecem com uma tarefa conhecida e reversível e comparem o resultado do agente com uma referência humana estabelecida.

Registrem onde o modelo não tinha contexto, escolheu a ferramenta errada ou precisou de orientação subjetiva. Essas observações revelam se a próxima intervenção pertence às instruções, à recuperação de informações, às regras de aprovação ou à revisão independente.

O debate sobre os harnesses da OpenAI e da Anthropic não terminará com uma empresa escolhendo uma camada fina e a outra construindo uma espessa. Ambas já estão adicionando e removendo componentes à medida que os modelos e as tarefas mudam.

A vantagem duradoura pertencerá às equipes capazes de medir essas mudanças rapidamente. Elas saberão quais restrições ainda evitam falhas e quais apenas preservam pressupostos de um modelo mais antigo.

Para qualquer pessoa que implemente agentes, a ação imediata é simples: teste o modelo e o harness em conjunto, examine rastros reais e defina o sucesso antes de conceder maior autonomia. Modelos mais fortes alteram a fronteira da engenharia, mas não eliminam a necessidade de identificá-la.