Construir software com IA: o que muda no trabalho e o que não muda

Software é construído por pessoas: desenvolvedores, testadores, arquitetos, operadores e os colegas que explicam para que serve um sistema. Muitas delas já trabalham todos os dias com assistentes de IA, e muitas fazem uma pergunta menos técnica do que parece: o que vai acontecer com o trabalho que fazem?

A pergunta merece uma resposta cuidadosa, não uma resposta confiante. Os anúncios de que a programação acabou e as promessas de que nada vai mudar vão, ambos, além das evidências. O que foi medido até agora é desigual: ganhos grandes em algumas tarefas bem especificadas, lentidão em outras e resultados que dependem muito do projeto, da equipe e da experiência das pessoas envolvidas.

Este artigo mantém separados três tipos de afirmação: o que estudos mediram, com a fonte citada; o que decorre dessas medições por raciocínio, marcado como inferência; e uma hipótese de trabalho, feita para ser testada, não para ser acreditada. A hipótese é esta: à medida que a IA assume mais da digitação da implementação, mais do valor do trabalho de engenharia se desloca para o julgamento em torno dela, decidir o que um sistema deve fazer, o que nunca pode fazer, o que os seus dados significam e como alguém pode saber que ele funciona. Esse julgamento já faz parte do trabalho diário de bons desenvolvedores. Não é um cargo novo para outra pessoa.

Não afirma que os desenvolvedores de software deixarão de ser necessários, que escrever código à mão está obsoleto ou que os desenvolvedores devem virar arquitetos. Boa parte do que este artigo chama arquitetura é trabalho que os desenvolvedores já fazem, na revisão de código, nas discussões de design e em cada decisão sobre o que uma função deve recusar. O artigo trata do ponto onde o esforço de engenharia cria mais valor, não de cargos nem do número de pessoas de que uma equipe precisa.

Não afirma que a IA já consegue construir software de produção com autonomia, que a arquitetura elimina alucinações ou que os controlos certos são tudo aquilo de que uma IA precisa. As evidências citadas acima incluem responsáveis pela manutenção que rejeitam cerca de metade dos patches que passam nos testes, benchmarks que exageram o grau de correção e falhas de segurança em código gerado.

E não afirma que a transição que descreve está completa, é universal ou inevitável. É uma hipótese sobre uma direção, com um mecanismo que pode ser examinado: à medida que a implementação fica mais fácil de gerar, a verificação ganha importância, e o trabalho de decidir o que tem de continuar verdadeiro passa a ser uma parcela maior da engenharia.

A capacidade das ferramentas é real e cresceu rápido, e cada número abaixo mede algo mais estreito do que as manchetes construídas sobre ele. O SWE-bench pede a um sistema que resolva issues reais do GitHub em repositórios Python reais e avalia o resultado com os testes dos próprios projetos; em 2023, o melhor modelo resolveu 1,96 % delas. No SWE-Bench Pro, mais difícil, construído a partir de mudanças maiores e em parte de código comercial que nunca foi público, o melhor resultado indicado na primeira versão do artigo, em setembro de 2025, foi de cerca de 23 %; em meados de 2026, a tabela de classificação mantida pelo responsável do benchmark mostrava cerca de 60 % no conjunto público e cerca de 50 % no comercial, com harnesses que variam entre as entradas. O horizonte temporal do METR é a duração de uma tarefa, cronometrada por uma pessoa qualificada, que um agente de IA conclui em metade das vezes. Nas suas tarefas bem especificadas e avaliadas automaticamente, essa duração duplicou aproximadamente de sete em sete meses entre 2019 e o início de 2025, e aproximadamente de quatro em quatro meses desde 2023, segundo a sua estimativa de 2026.

Dentro das organizações, a mudança manifesta-se como volume, relatado pelas próprias empresas. A Google relatou em janeiro de 2025 que, nos editores dos seus engenheiros, as sugestões de IA que eles aceitaram somavam 67 % dos caracteres de código introduzidos, sem contar código colado, e que 80 % das modificações numa série de grandes migrações internas, um tipo de tarefa bem especificado, foram escritas inteiramente por IA, cada uma delas sujeita a revisão como qualquer outro código. Num questionário sem anonimato respondido por 132 pessoas da própria empresa, os engenheiros da Anthropic indicaram usar o seu modelo em cerca de 59 % do trabalho, enquanto mais de metade disse que conseguia delegar por completo no máximo um quinto dele.

As evidências de produtividade são mais mistas do que a curva de capacidade sugere. Num ensaio controlado com atribuição aleatória, realizado no início de 2025 com 16 programadores experientes que trabalhavam em projetos maduros para os quais contribuíam havia anos, o METR constatou que o acesso a ferramentas de IA fez as tarefas demorarem 19 % mais tempo, enquanto os programadores acreditavam ter ficado cerca de 20 % mais rápidos. Um estudo de acompanhamento no início de 2026 apontou para acelerações modestas, com intervalos de confiança que incluem zero, e o METR classificou esses dados como um sinal pouco fidedigno, porque os programadores recusavam cada vez mais trabalhar sem IA. Ensaios de campo com 4 867 programadores na Microsoft, na Accenture e numa terceira empresa, com coautores da Microsoft e realizados com o preenchimento automático de código de 2022 a 2024, encontraram 26 % mais tarefas concluídas, com ganhos maiores, mas estimados com muita incerteza, entre os menos experientes. Um ensaio com atribuição aleatória que a Google realizou com 96 dos seus próprios engenheiros estimou cerca de 21 % menos tempo numa tarefa, com um intervalo de confiança suficientemente amplo para incluir a ausência de efeito. O estudo DORA de 2024 associou cada aumento de 25 % na adoção de IA a uma queda estimada de 1,5 % no ritmo de entrega e de 7,2 % na estabilidade de entrega; o relatório de 2025 constatou que o ritmo de entrega agora sobe com a adoção, enquanto a instabilidade também sobe, e descreveu a IA como amplificadora dos pontos fortes e das disfunções que uma organização já tem.

Lidos em conjunto, estes estudos não mostram que a IA torna a engenharia de software barata. São compatíveis com algo mais restrito, que este artigo infere em vez de medir: produzir uma implementação candidata fica barato mais depressa do que estabelecer que uma candidata é aceitável. A IA também automatiza partes da verificação, de testes gerados a provas verificadas por máquina. O que ela não resolve sozinha é o que as verificações devem verificar. Essa assimetria é o ponto de partida de tudo o que vem a seguir.

Um benchmark conta uma tarefa como resolvida quando um patch faz passar os testes designados. A aceitação de um sistema acontece quando as pessoas responsáveis por ele estão dispostas a depender dele. A maior parte da dificuldade reside na distância entre as duas coisas.

Os próprios benchmarks mostram essa distância. O SWE-bench Verified existe porque, quando 93 programadores analisaram uma amostra das tarefas originais em 2024, 38,3 % foram assinaladas por enunciados subespecificados e 61,1 % por testes que podiam rejeitar soluções válidas, um filtro que os próprios autores consideram provavelmente demasiado rigoroso. Em 2026, a OpenAI deixou de relatar o benchmark, depois de uma auditoria de 138 tarefas, escolhidas porque o seu próprio modelo falhava nelas repetidamente, ter encontrado problemas relevantes nos testes ou nos enunciados de 59,4 %, e todos os modelos de ponta testados conseguiram reproduzir, para algumas tarefas, a correção original ou detalhes do enunciado. Um estudo apresentado no ICSE 2026 constatou que 29,6 % dos patches de agentes contados como plausíveis se comportavam de modo diferente da correção feita pelos próprios programadores, nem todos de forma errada; somado a outras fragilidades dos testes, isso inflacionou as taxas de resolução relatadas em cerca de seis pontos percentuais. E o METR pediu a responsáveis pela manutenção do scikit-learn, do Sphinx e do pytest que avaliassem patches que passavam nos testes, sem saberem quem os escrevera. Os patches vinham de agentes lançados até finais de 2025, cada um com uma tentativa e sem feedback, e cerca de metade não teria sido incorporada; o METR sublinha que isso não é um teto do que os agentes conseguem fazer.

Para além dos testes funcionais, o quadro é parecido. No BaxBench, um benchmark de aplicações de backend apresentado no ICML 2025, o melhor modelo produziu um programa correto em 62 % das vezes, e, na média dos modelos, exploits de segurança tiveram êxito contra cerca de metade dos programas corretos. Em 576 000 amostras de código geradas em 2024 por 16 modelos, 19,7 % dos pacotes de software a que os modelos se referiam não existiam, 5,2 % nos modelos comerciais e 21,7 % nos abertos; um atacante pode reservar esses nomes. Num estudo de 2022 com 47 participantes, na maioria estudantes, e um modelo antigo, quem tinha um assistente de IA escreveu código menos seguro e acreditou com mais frequência que ele era seguro. Um estudo quase experimental de projetos públicos no GitHub que adotaram um editor de código com IA, o Cursor, encontrou um ganho de produção grande, mas passageiro, enquanto os alertas de análise estática subiram 30 % e a complexidade do código 41,6 %, e não voltaram a descer.

As evidências também apontam no sentido contrário, e isso importa. Um ensaio com protocolo declarado previamente e 151 participantes não encontrou diferença significativa na facilidade com que outros programadores conseguiam depois fazer evoluir código escrito com assistência de IA. A maioria dos estudos de segurança citados não tem uma linha de base humana equivalente. Nada disto mostra que código gerado é pior do que código humano.

O que mostra é que código gerado deve ser tratado como aquilo que é: uma implementação candidata. Uma mudança candidata deve ser verificada face às restrições da arquitetura e aos seus testes, validações e políticas; deve deixar evidências do que foi verificado; e deve ser objeto de aceitação ou rejeição com base nisso. Onde uma decisão comporta um risco que nenhuma verificação consegue resolver, uma pessoa deve ser consultada. Esse modelo não depende de quem produziu a candidata.

Se as implementações candidatas passarem a ser abundantes, a pergunta escassa passa a ser qual delas é aceitável, e responder-lhe exige saber o que significa aceitável. Este artigo argumenta que, à medida que a implementação fica mais fácil de gerar, aumenta o valor relativo de decidir o que tem de continuar verdadeiro. Isso é uma inferência, não uma medição, e não diz que o código não tem valor.

Há evidências de apoio nas margens. Mais de um terço das tarefas analisadas para o SWE-bench Verified foi assinalado como subespecificado. Os modelos notam mal quando uma instrução está subespecificada, e os agentes que fazem perguntas de esclarecimento obtêm resultados muito melhores, até 74 % em termos relativos, com um interlocutor simulado, num estudo do ICLR 2026. A Google descreve que o autor de código assistido por IA se torna cada vez mais o seu revisor, e os engenheiros da Anthropic descrevem um paradoxo da supervisão: usar bem o modelo exige supervisioná-lo, e supervisioná-lo exige justamente as competências que o excesso de delegação pode desgastar. O relatório DORA de 2025 observa que o atrito não desaparece tanto quanto muda de lugar, do trabalho manual para a decisão e a verificação. No questionário do Stack Overflow de 2025, mais programadores desconfiavam da precisão das ferramentas de IA do que confiavam nela, 46 % contra 33 %, e a frustração mais comum eram resultados quase certos, mas não exatamente.

Uma forma útil de descrever a mudança é separar duas perguntas. A arquitetura responde: o que tem de continuar verdadeiro? A implementação responde: como é isso realizado aqui? Um exemplo de propriedade: um resultado probabilístico não pode passar silenciosamente a dado com autoridade. A propriedade pode ser realizada por validação de esquema em tempo de execução, por uma fronteira tipada que só um serviço de validação consegue construir, por um adaptador na camada de aplicação, ou por um teste de arquitetura na integração contínua que falha quando um cliente de modelo é importado no núcleo. Cada uma destas formas cobre parte da propriedade, com força diferente; uma regra de importação, por exemplo, impõe a direção de uma dependência, não a propriedade em si. A tecnologia pode mudar. A propriedade permanece.

Uma IA pode produzir cada vez mais o segundo tipo de resposta. O primeiro continua a ser uma questão de intenção, compreensão do domínio, risco e responsabilidade. A linha não é totalmente nítida: uma camada de cache ou uma política de novas tentativas escolhidas durante a implementação criam propriedades próprias, e por isso o código gerado ainda precisa de revisão face à arquitetura, não só face aos seus testes.

A arquitetura de software já tem uma noção de intenção executável. Em Building Evolutionary Architectures, Ford, Parsons e Kua definem uma função de aptidão de arquitetura como uma avaliação objetiva da integridade de uma ou mais características de arquitetura. Ferramentas como o ArchUnit permitem que as regras de dependência entre camadas sejam executadas como testes unitários comuns. Contratos, esquemas, sistemas de tipos, testes baseados em propriedades e, onde o custo se justifica, verificação formal exprimem a mesma ideia em profundidades diferentes.

A definição de trabalho usada aqui é simples. Uma restrição passa a ser de arquitetura no sentido que interessa a este artigo, aplicada e não apenas enunciada, quando violá-la leva o sistema ou o seu processo de entrega a rejeitar o resultado. Por essa definição, um princípio que nenhum build, nenhuma implantação e nenhuma verificação em tempo de execução consegue fazer falhar ainda é uma descrição, por mais cuidadosamente que esteja escrito. Nem tudo o que é de arquitetura pode ser aplicado assim; a forma como um sistema é decomposto, ou a quem pertencem os dados, é algo que se julga, não que se verifica.

Quando a implementação passa a ser abundante, a arquitetura passa a tratar menos de desenhar diagramas de sistema e mais de definir fronteiras executáveis: restrições verificáveis por máquina, propriedades de aceitação, requisitos de evidência, testes de arquitetura, requisitos de observabilidade, fronteiras de política e comportamento definido em caso de falha. Formulado como tese, e não como definição da disciplina: o produto do trabalho do arquiteto já não é só um diagrama. É também o conjunto de propriedades que o sistema é incapaz de violar em silêncio.

Executável não significa provado. Os testes são amostras de comportamento; podem revelar defeitos, mas não mostrar que não resta nenhum. Propriedades diferentes pedem garantias de natureza diferente: tipos e esquemas para a forma dos dados, análise estática e testes de arquitetura para dependências, testes baseados em propriedades para o comportamento sobre muitas entradas, verificação formal onde uma propriedade é crítica e pode ser especificada, controlos em tempo de execução para o que só pode ser observado em operação, e revisão humana para o que nenhum mecanismo consegue julgar.

A investigação sobre a geração de especificações juntamente com o código mostra ao mesmo tempo a promessa e o limite. Modelos de linguagem transformaram intenção em linguagem natural em pós-condições que identificaram 64 bugs históricos reais do conjunto de dados Defects4J. No benchmark VERINA, o melhor modelo escreveu código correto para 72,6 % das tarefas, mas uma especificação correta e completa para apenas 52,3 %. Lahiri formula o limite de fundo: verificar uma implementação face a uma especificação pode ser definido mecanicamente, mas não há caminho algorítmico para assegurar que a especificação capta o que a pessoa pretendia. Esse é o problema de arquitetura numa frase.

Instruir um modelo sobre o que não fazer não torna um sistema controlado. Um prompt de sistema, uma política escrita, uma instrução para evitar algo, a aparente disposição de um modelo para seguir uma regra e uma pessoa que lê tudo por alto depois descrevem um comportamento esperado. Nenhum deles bloqueia de forma consistente um estado inaceitável quando o modelo não coopera; uma pessoa que lê por alto depois identifica uma parte, tarde e de forma irregular.

O controlo, no sentido usado aqui, existe quando um estado inaceitável pode ser identificado, bloqueado, rejeitado ou escalado independentemente da cooperação do modelo. Os seus instrumentos são conhecidos: restrições de arquitetura executáveis, fronteiras de tipo, esquemas, validadores determinísticos, testes de arquitetura e de contrato, verificações na integração contínua que fazem o build falhar, aplicação de políticas, admissão na implantação, proveniência e rastreabilidade, testes de aceitação, revisão humana controlada e portões de publicação. Uma regra que uma IA pode ignorar ainda não é um controlo de arquitetura.

Uma consequência é que os controlos não precisam de saber quem escreveu o código. A mesma fronteira restringe uma mudança escrita por uma pessoa, uma mudança sugerida por um assistente e uma mudança produzida de ponta a ponta por um agente. A pergunta importante já não é só quem escreveu o código, mas se o sistema resultante preserva as propriedades exigidas. O perfil do NIST para o desenvolvimento seguro por quem constrói modelos de IA generativa adota a mesma posição para as vulnerabilidades: as suas práticas não distinguem entre código-fonte escrito por humanos e gerado por IA, porque todo o código deve ser avaliado antes de ser usado. Isto não é um regime de policiamento de código escrito por máquina. É arquitetura que restringe a implementação qualquer que seja a sua origem, incluindo os erros que as pessoas cometem.

Muda também aquilo que um sistema deve deixar para trás. Um sistema gerado que apenas parece correto não deixou evidência do que foi verificado. As propriedades importantes devem deixar evidências de que foram avaliadas: que testes foram executados, que versão de política foi aplicada, o que uma validação devolveu, como uma mudança se liga ao requisito a que serve, de onde vieram as suas entradas e o que o portão de publicação de versões decidiu. Os frameworks de cadeia de fornecimento de software já tratam informação deste tipo como algo que um build produz e um consumidor verifica: o SLSA especifica a proveniência de como um produto de build foi construído, e o in-toto verifica que cada etapa de uma cadeia de fornecimento foi executada como previsto. A proveniência mostra como um produto de build foi produzido, não que ele esteja correto.

De volta à pergunta que fazem as pessoas que constroem software. Por mais implementação que a IA produza, a engenharia ainda precisa estabelecer o que a implementação pode significar e fazer, que propriedades ela não pode violar em silêncio e que evidências são necessárias antes de se poder confiar nela. Nada disso é digitação, e tudo isso é engenharia.

Na prática, é uma lista de responsabilidades: definir o propósito do sistema, decidir que resultados são inaceitáveis, determinar o que conta como evidência, resolver a ambiguidade semântica, fixar a tolerância ao risco, definir invariantes, analisar casos fora do comum, validar a arquitetura, aceitar o risco residual e manter a responsabilidade. Nem todos os itens exigem que uma pessoa os execute à mão de cada vez. Cada um exige uma pessoa ou função nomeada, que atue dentro de um processo definido e que seja responsável por ele. Um sistema pode automatizar trabalho sem tornar a responsabilidade indefinida. Seja qual for a forma de escrever o código, as pessoas continuam responsáveis pelo que o sistema faz.

A intenção humana não é automaticamente correta, nem está automaticamente disponível. Um requisito que vive só na cabeça de alguém não é um controlo de arquitetura. Para restringir a implementação gerada, a intenção tem de ser tornada explícita, representada numa forma que possa ser verificada, sujeita a revisão, versionada quando muda e ligada à verificação que a aplica.

É no significado que isto é mais difícil. Um gerador pode produzir um sistema sintaticamente impecável que compreende mal o seu domínio, porque os termos transportam contexto: o mesmo rótulo significa coisas diferentes em duas organizações, as definições de uma norma mudam entre versões, e os dados que atravessam uma fronteira entram num vocabulário jurídico diferente. Gerar sintaxe não resolve o alinhamento semântico. Decidir o que um campo significa, e manter esse significado estável enquanto os dados passam entre sistemas, organizações e jurisdições, é trabalho de arquitetura que mais implementação não substitui.

A atenção humana é também um recurso limitado, com modos de falha conhecidos. Bainbridge observou em 1983 que a automação deixa aos operadores as tarefas que os seus criadores não conseguiram automatizar e lhes pede que supervisionem um sistema instalado justamente por fazer o trabalho melhor do que eles. Uma revisão sistemática sobre o automation bias, a tendência para confiar demasiado em resultados automatizados, inclui a ênfase na responsabilização de quem usa o sistema entre as medidas que o reduzem. A conclusão não é que as pessoas devam ler cada linha gerada, o que não escala. É que os sistemas devem concentrar a atenção humana no juízo e no risco por resolver, e dar consequência a essa atenção. Decorre também, como inferência a partir do paradoxo da supervisão descrito acima, que as competências por trás dessa atenção precisam de cuidado: quem deixa de escrever código pode ter mais dificuldade para julgar o código que revisa, e por isso tempo para praticar e aprender faz parte da forma como uma equipe adota essas ferramentas.

Este artigo argumenta que só se pode contar com a autonomia na implementação na medida em que o comportamento resultante pode ser restringido e verificado de forma independente. Dito como princípio, e não como fórmula: a autonomia concedida a um agente de implementação deve estar relacionada com o grau de independência com que o seu resultado pode ser verificado. Onde as propriedades estão bem especificadas e as verificações são fortes, como numa migração mecânica, numa atualização de dependência coberta por um conjunto de testes rigoroso ou num adaptador atrás de uma fronteira tipada, muito pode ser delegado. Onde as propriedades são vagas, as verificações fracas ou o custo de um erro alto, a autonomia deve crescer devagar ou simplesmente não crescer.

Segundo este argumento, a implementação pode ganhar cada vez mais autonomia sem que o controlo a ganhe. A autonomia é concedida pelas restrições, medida face às evidências e retirada quando as evidências deixam de a sustentar. Os critérios de aceitação não precisam de depender de quem escreveu o código; quanto um produtor pode fazer antes que uma pessoa olhe pode, ainda assim, depender do seu histórico.

É também por isso que o argumento não depende de uma linguagem ou plataforma específica. A mesma propriedade de arquitetura pode ser verificada em tempo de compilação por um tipo em TypeScript, em tempo de execução por um esquema em Python, por uma fronteira de módulo em Java ou por uma política de admissão no Kubernetes. Quando a implementação muda, incluindo quando é gerada de novo, a propriedade é o que sobrevive.

O COADF, o Compliance-Oriented AI Development Framework, é uma exploração prática desta tese, e apenas uma. É um método de desenvolvimento para sistemas de IA que têm de se sustentar perante a regulação europeia. Lido à luz desta tese, pergunta que propriedades têm de continuar verdadeiras quando componentes probabilísticos participam na produção, transformação ou publicação de informação, e como um build pode dar conta de que elas deixaram de ser verdadeiras. Nasce do projeto de investigação e desenvolvimento AnyLAI, que investiga como a intenção de arquitetura pode continuar aplicável em sistemas que contêm cada vez mais comportamento probabilístico e gerado por máquina.

Os seus princípios aplicam a tese a um caso mais restrito: aquilo em que a saída de um modelo se pode tornar enquanto o sistema funciona. O P-1 mantém o comportamento probabilístico limitado pelo comportamento determinístico do sistema: um modelo devolve um valor juntamente com a sua confiança e o método que está por trás dele, nunca um valor nu. O P-4 mantém rastreáveis as transformações importantes, de uma saída publicada às evidências em que ela se apoia. O P-6 transforma barreiras em fences, verificações que bloqueiam a publicação de uma versão em vez de conselhos num documento, e pede a cada fence que mostre que dispara. O P-7 mantém normas externas, sistemas de classificação e serviços de terminologia em adaptadores fora do núcleo. O P-8 mantém as regras explícitas e versionadas como dados, para que uma decisão nomeie a versão da regra que a produziu. O P-2 e o P-3 estabelecem que confiança baixa nunca chega a uma saída publicada e que aí uma pessoa decide, um dado de cada vez, perante a sua fonte.

Só os seus modelos de governação tratam do outro caso, agentes de IA que escrevem código de produção. Uma escada de autonomia define quanto um agente pode fazer antes que uma pessoa olhe: no degrau mais baixo, uma pessoa lê cada linha; no mais alto, uma pessoa lê os resultados dos testes e a saída dos guardiões, um degrau que exige cobertura madura de fences e um histórico e que, segundo o framework, deveria continuar raro. Uma lista curta de decisões, entre elas mudanças de esquema da base de dados, configuração de segurança, contratos de interface cuja mudança quebra quem os chama e mudanças no próprio sistema de fences, fica com uma pessoa em todos os degraus.

O COADF não torna segura a programação com autonomia e não estabelece que o software gerado está correto. Não é um framework para programar com autonomia. Torna algumas premissas de arquitetura explícitas e testáveis, e é publicado para que essas premissas possam ser examinadas e contestadas.

Uma tese só é útil se produzir perguntas a que se possa responder. Estas parecem as mais urgentes.

1. 01Quanto detalhe de implementação pode ser delegado antes que a verificação passe a ser o custo dominante?
2. 02Que propriedades de arquitetura podem ser verificadas automaticamente, e quais ainda exigem juízo humano?
3. 03Como deve a arquitetura ser representada para que pessoas e máquinas possam raciocinar sobre ela?
4. 04A intenção de arquitetura pode passar a ser verificável por máquina sem ficar presa a uma tecnologia de implementação?
5. 05Quanta autonomia deve ser concedida quando as técnicas de garantia diferem em força?
6. 06Como as equipes podem adotar essas ferramentas mantendo as competências de que precisam para julgar o resultado?

Nenhuma delas tem resposta definitiva. Entre a afirmação de que a IA apenas ajuda os desenvolvedores a programar mais rápido e a de que os desenvolvedores já não são necessários está a pergunta de que trata esta pesquisa: o que um sistema deve ser incapaz de fazer, quem o decide, como a decisão é aplicada e como as pessoas que constroem o sistema mantêm o julgamento para decidir bem.