{"content_id":"zuag1vtnf2","slug":"ai-native-developer-definition-and-practices","locale":"pt","schema_type":"TechArticle","category":"ai_data","category_name":"Dados de IA","title":"O que é um desenvolvedor nativo em IA: papel, competências e estrutura operacional de agentes","summary":"O desenvolvedor nativo em IA projeta sistemas para que a IA execute tarefas de implementação, enquanto assume a definição dos problemas, o estabelecimento de restrições, a validação da qualidade e a responsabilidade final. Este artigo explica, sob uma perspectiva prática, a documentação, o harness de agentes, o processo de adoção pelas equipes, as métricas de desempenho e os princípios de segurança.","author":{"name":"injoys","url":"https://injoys.com/ko/about"},"key_points":["O cerne do desenvolvimento nativo em IA não são os truques de prompt, mas o projeto de sistemas capazes de delegar tarefas e validar os resultados.","Mesmo que a IA gere código rapidamente, a definição dos problemas, a visão de produto, as decisões de arquitetura, a análise de segurança e a responsabilidade não são resolvidas automaticamente.","Fornecer especificações, restrições, esquemas e registros de decisões como documentos gerenciados facilita o trabalho dos agentes em um contexto consistente.","As etapas Plan, Draft e Review podem ser implementadas com um único agente; a abordagem multiagente deve ser escolhida quando os benefícios da separação superarem os custos e a complexidade.","O desempenho da adoção pela equipe deve ser avaliado pelo tempo de conclusão das tarefas, taxa de defeitos, taxa de retrabalho, custos e carga de revisão humana, e não pela quantidade de código gerado."],"content_markdown":"Um desenvolvedor nativo em IA não é simplesmente alguém que usa com habilidade ferramentas como ChatGPT, Claude Code e GitHub Copilot. Mais precisamente, pode ser definido como **um desenvolvedor que projeta o contexto, as ferramentas, as permissões e os critérios de avaliação para que a IA execute tarefas viáveis, enquanto as pessoas assumem a definição de objetivos, a validação, a aprovação e a responsabilidade**.\n\nNo entanto, “desenvolvedor nativo em IA” não é uma certificação oficial nem um cargo padronizado sobre o qual todo o setor tenha chegado a um consenso. Como o alcance da automação varia conforme o nível de risco da organização e do produto, isso não deve ser equiparado a transferir todas as decisões para a IA.\n\n## Definição de desenvolvedor nativo em IA\n\nO desenvolvimento nativo em IA é uma abordagem que trata a IA não como uma ferramenta complementar de conclusão de código, mas como uma **camada de execução do desenvolvimento**. As pessoas estruturam o trabalho a ser realizado e definem as condições de sucesso e as proibições, enquanto a IA executa tarefas de exploração, criação, execução e correção dentro dos limites permitidos.\n\nAs principais funções são divididas da seguinte forma.\n\n- **Pessoas:** definição do problema, prioridades, restrições, classificação de risco, critérios de aprovação e responsabilidade final\n- **Agente de IA:** busca de informações, rascunho do plano, criação de código e testes, análise estática e correções iterativas\n- **Harness:** documentação, ferramentas, permissões, gerenciamento de estado, testes, logs, limites de custo e condições de interrupção\n\nEm geral, um agente de IA é um sistema no qual um modelo de linguagem usa ferramentas e escolhe a próxima ação com base nos resultados intermediários. Diferentemente de um fluxo de trabalho que segue procedimentos predefinidos, um agente pode determinar dinamicamente a ordem das tarefas dentro dos limites permitidos.\n\n| Categoria | Desenvolvimento assistido por IA | Desenvolvimento nativo em IA |\n|---|---|---|\n| Posição da IA | Ferramenta de conclusão de código ou perguntas e respostas | Parte da camada de execução do trabalho |\n| Entrada | Centrada em prompts curtos | Especificações, contexto do repositório, restrições e critérios de avaliação |\n| Papel das pessoas | Implementação direta com auxílio da IA | Definição do problema, julgamento de exceções, validação e aprovação |\n| Controle de qualidade | Depende da verificação manual do desenvolvedor | Inclui testes, avaliadores e regras de revisão no harness |\n| Forma de operação | Depende da forma de uso de cada pessoa | Gerenciada por políticas e processos de equipe reproduzíveis |\n\nUm princípio importante é que **o trabalho pode ser delegado, mas a responsabilidade não**. A IA pode tomar decisões operacionais de baixo risco, mas decisões de grande impacto, como as relacionadas a segurança, dados pessoais, pagamentos, medicina, questões jurídicas e alterações em produção, exigem uma aprovação humana mais rigorosa.\n\n## Nivelamento da programação e novos diferenciais dos desenvolvedores\n\nA IA generativa reduz a barreira de entrada para implementações repetitivas, como a criação de código boilerplate, a busca de exemplos de uso de APIs, os rascunhos de testes e as sugestões de refatoração. Há certo efeito de nivelamento, pois até mesmo desenvolvedores com menos experiência conseguem criar protótipos funcionais mais rapidamente do que antes.\n\nNo entanto, não é correto afirmar categoricamente que “a diferença de habilidade em programação desapareceu”. Para avaliar os resultados produzidos pela IA, os seguintes conhecimentos ainda são necessários.\n\n1. Capacidade de identificar requisitos contraditórios ou ausentes\n2. Capacidade de projetar os limites do sistema e o fluxo de dados\n3. Capacidade de avaliar os compromissos entre desempenho, segurança, custo e manutenibilidade\n4. Capacidade de identificar implementações plausíveis, porém incorretas\n5. Capacidade de rastrear a causa e realizar a recuperação quando ocorre uma falha\n\nAs competências que produzem diferenças maiores na era da IA são as seguintes.\n\n- **Definição do problema:** especificar o problema que o usuário realmente enfrenta e as condições de sucesso.\n- **Noção de produto e UX:** avaliar o fluxo de uso, a facilidade de compreensão, a acessibilidade e a confiança, em vez de apenas a existência da funcionalidade.\n- **Capacidade de decomposição:** dividir um objetivo amplo em tarefas pequenas e verificáveis.\n- **Projeto de avaliação:** criar previamente testes, checklists, tabelas de pontuação e critérios de aprovação.\n- **Projeto de contexto:** organizar a documentação e o repositório para que a IA encontre com precisão apenas as informações necessárias.\n- **Avaliação de riscos:** distinguir as tarefas que podem ser automatizadas daquelas que exigem aprovação humana.\n\nEm última análise, quanto maior a velocidade de implementação, maior o valor da capacidade de decidir “o que criar e por quê” e “se o resultado é bom o suficiente”.\n\n## Markdown e projeto de documentos de referência\n\nOs agentes não conhecem automaticamente o conhecimento implícito de uma organização. Se os requisitos e as restrições estiverem dispersos em conversas, reuniões, comentários no código e na memória individual, haverá uma probabilidade maior de repetição das mesmas perguntas ou de trabalho baseado em premissas diferentes.\n\nMarkdown é útil como formato de documentação prática porque facilita o gerenciamento do histórico de alterações no Git e é relativamente simples tanto para leitura humana quanto para processamento por IA. No entanto, mais importante do que o próprio formato do arquivo é **definir claramente qual documento representa o padrão mais atualizado**.\n\n### Informações a incluir no documento de referência\n\n- Objetivos e não objetivos do produto, além de cenários de usuário\n- Requisitos funcionais e critérios de aceitação verificáveis\n- Estrutura do repositório e responsabilidades de cada módulo\n- Contratos de API, modelos de dados e regras de migração\n- Regras de programação, comandos de teste e procedimentos de implantação\n- Registros de decisões arquiteturais e motivos das alterações\n- Permissões de acesso, operações proibidas e condições de aprovação humana\n- Limitações conhecidas, procedimentos de resposta a incidentes e responsáveis\n\nEm uma GitHub Issue, é possível registrar o contexto, o escopo, os critérios de aceitação, a documentação relacionada e a definição de conclusão da tarefa. É adequado manter a arquitetura de longo prazo e as regras operacionais em documentação versionada, como um diretório `docs`, e apontar para esses documentos na Issue.\n\n### Exemplo de especificação de tarefa\n\n```markdown\n# Objetivo\nMelhorar a mensagem de falha no login para que o usuário saiba como se recuperar.\n\n# Escopo\n- Tela de login da Web\n- Mensagens em coreano e inglês\n\n# Fora do escopo\n- Alteração do método de autenticação\n- Alteração da política de senhas\n\n# Critérios de aceitação\n- Não expor externamente se a conta existe ou não.\n- Passar na verificação de acessibilidade e nos testes de autenticação existentes.\n- Permitir o retorno ao comportamento original em caso de falha.\n\n# Comandos de validação\n- npm test\n- npm run lint\n```\n\nUma documentação bem organizada pode reduzir a necessidade de o agente ler toda a base de código a cada tarefa. No entanto, isso não significa necessariamente uma redução de tokens ou custos. Se a documentação estiver duplicada ou desatualizada, ela poderá provocar ainda mais buscas e alterações incorretas. Também é necessário definir o responsável pela documentação, o momento da atualização e as regras de validação automática.\n\nSenhas, chaves de API, dados reais de clientes e permissões excessivas de banco de dados não devem ser registrados na documentação. Os exemplos de esquema devem ser desidentificados, e as informações secretas devem ser gerenciadas em um repositório seguro separado.\n\n## Estrutura mínima de um harness de agentes de IA\n\nA engenharia de harness refere-se ao trabalho de projetar os mecanismos de execução ao redor do modelo. Isso inclui instruções de sistema, conexão com ferramentas, recuperação de contexto, permissões, memória, testes, observabilidade, novas tentativas e condições de interrupção.\n\nO ciclo mínimo de execução pode ser composto por Plan, Draft e Review.\n\n| Etapa | Pergunta principal | Entregável | Tratamento em caso de falha |\n|---|---|---|---|\n| Plan | Esta tarefa é necessária? Quais são o escopo e os riscos? | Plano, itens a alterar e método de validação | Solicitar informações adicionais ou interromper a tarefa |\n| Draft | O plano foi implementado na menor unidade segura? | Alterações no código, nos testes e na documentação | Corrigir por um número limitado de tentativas |\n| Review | Os requisitos e os critérios de qualidade foram atendidos? | Resultado da avaliação, lista de defeitos e proposta de aprovação | Refazer o trabalho ou encaminhar para uma pessoa |\n\nUm harness real precisa dos seguintes mecanismos de controle.\n\n- Arquivos, comandos, rede e escopo de dados permitidos\n- Tempo máximo de execução, número de chamadas de ferramentas e limite de custo\n- Condições de interrupção em caso de falha nos testes ou alta incerteza\n- Logs de todas as entradas, chamadas de ferramentas, alterações e aprovações\n- Etapa de aprovação humana antes da aplicação em produção\n- Procedimento de rollback para retornar ao estado original\n\n### Agente único e múltiplos agentes\n\nPlan, Draft e Review não exigem necessariamente três modelos ou agentes separados. Um único agente também pode executá-los usando instruções e ferramentas específicas para cada etapa.\n\nEm uma estrutura de múltiplos agentes, as funções podem ser separadas da seguinte forma.\n\n- **Planner:** analisa os requisitos e examina a necessidade, o escopo e os riscos da funcionalidade.\n- **Generator:** cria o código, os testes e a documentação de acordo com o plano.\n- **Evaluator:** inspeciona o resultado com base em critérios independentes e apresenta defeitos e pontos de melhoria.\n\nA separação de funções pode ajudar na crítica independente e na exploração paralela. Por outro lado, também aumenta a complexidade do custo das chamadas, da latência, da sincronização de estado e do rastreamento das causas dos erros. Para tarefas simples, scripts determinísticos ou um único agente podem ser mais estáveis, e múltiplos agentes devem ser adotados quando a melhoria medida justificar a complexidade.\n\n## Procedimento de adoção por equipes e empresas\n\nApenas anunciar a adoção da IA e oferecer treinamento não transforma uma organização em nativa em IA. Também é necessário estabelecer o escopo permitido, a política de dados, os critérios de qualidade e a estrutura de responsabilidades.\n\n### Etapa 1: definição da linha de base e das políticas\n\n- Medir o tempo atual das tarefas, a taxa de defeitos, o tempo de espera por revisão e a frequência de implantação.\n- Definir quais dados não podem ser inseridos e quais ferramentas podem ser usadas.\n- Distinguir tarefas que podem ser executadas automaticamente daquelas que exigem aprovação humana.\n\n### Etapa 2: champions e piloto limitado\n\nDesignar na equipe champions com experiência no uso de IA e capacidade de treinamento. O papel dos champions não é promover ferramentas, mas organizar casos de uso reproduzíveis, casos de falha e regras de segurança.\n\nÉ mais seguro iniciar o piloto com trabalhos cujos resultados sejam fáceis de validar, como geração de testes, organização da documentação interna e refatorações de baixo risco.\n\n### Etapa 3: padronização de padrões bem-sucedidos\n\n- Priorizar o registro dos documentos de entrada e dos critérios de avaliação, em vez dos prompts que funcionaram.\n- Criar um modelo comum de Issue e uma definição de conclusão.\n- Automatizar testes, lint, verificações de segurança e procedimentos de revisão.\n- Documentar as causas das falhas e os pontos de intervenção humana.\n\n### Etapa 4: operação e expansão\n\nAmpliar o escopo de aplicação quando os resultados do piloto apresentarem melhorias em relação à linha de base. A seleção de ferramentas, o treinamento, o gerenciamento de custos, as permissões de acesso, a resposta a incidentes e as avaliações periódicas devem ser conectados em um único sistema operacional.\n\n## Métricas para medir o desempenho\n\nO número de linhas de código geradas ou a frequência de uso da IA não demonstram diretamente a produtividade e a qualidade. É necessário medir também métricas orientadas a resultados, como as seguintes.\n\n| Área | Métrica recomendada | Cuidados na interpretação |\n|---|---|---|\n| Velocidade | Tempo entre o início da tarefa e a implantação | Incluir também o tempo de revisão e retrabalho. |\n| Qualidade | Taxa de defeitos após a implantação, taxa de falha nos testes | Separar tarefas fáceis de tarefas difíceis. |\n| Eficiência | Custo do modelo por tarefa, número de chamadas de ferramentas | Não excluir o custo da revisão humana. |\n| Estabilidade | Taxa de rollback, alertas de segurança, violações de permissão | Considerar também a possibilidade de problemas não detectados. |\n| Adoção | Proporção de equipes com uso recorrente, trabalho real concluído | Distinguir de simples logins ou números de chamadas. |\n| Experiência | Satisfação dos desenvolvedores, carga cognitiva, fadiga de revisão | A fadiga pode aumentar mesmo quando a velocidade melhora. |\n\nOs resultados do grupo que usa IA e do grupo que utiliza o método existente devem ser comparados em tarefas do mesmo tipo, observando não apenas a velocidade no curto prazo, mas também os custos de manutenção e os incidentes.\n\n## Riscos de segurança e qualidade\n\nComo os agentes de IA podem ler código, executar comandos e obter conteúdo externo, eles têm uma superfície de ataque mais ampla do que um chat comum.\n\nOs principais riscos são os seguintes.\n\n- Injeção de prompt que leva o agente a seguir instruções ocultas na documentação do repositório ou em páginas externas\n- Concessão de permissões desnecessárias a arquivos, bancos de dados ou implantações\n- Código incorreto que usa APIs ou pacotes inexistentes\n- Introdução de dependências vulneráveis ou de código com licença incerta\n- Ações que enfraquecem os próprios critérios de validação para fazer os testes passarem\n- Transmissão externa de dados de clientes, chaves secretas e código interno\n- Aumento inesperado de custos devido a execuções repetidas\n\nOs princípios de resposta são privilégio mínimo, ambiente de execução isolado, lista de permissões, separação de informações secretas, testes independentes, logs de alterações e aprovação humana. Em especial, avaliar a implementação de um agente apenas com os testes criados pelo próprio agente pode fazer com que erros em comum não sejam detectados; portanto, é recomendável manter os testes de regressão existentes e critérios de revisão separados.\n\n## Como evitar reações excessivas às ferramentas\n\nNovos modelos, plugins e frameworks de agentes continuam surgindo, mas não é necessário aprender todas as ferramentas. Em vez de nomes ou tendências, as ferramentas devem ser avaliadas com base nas seguintes perguntas.\n\n1. A tarefa repetitiva que se pretende resolver no momento está clara?\n2. A ferramenta pode ser conectada com segurança ao ambiente de desenvolvimento e ao sistema de permissões existentes?\n3. A qualidade da saída pode ser validada de forma automática ou manual?\n4. É possível observar custos, latência e taxa de falhas?\n5. Mesmo que a ferramenta seja substituída, as especificações, os testes e a documentação permanecem?\n\nConcluir uma melhoria real no produto com uma ferramenta adequada à equipe e medir o resultado é mais valioso do que aprender superficialmente apenas como usar várias ferramentas.\n\n## Checklist prático do desenvolvedor nativo em IA\n\n- [ ] Documentar os objetivos, os não objetivos e os critérios de aceitação antes da implementação.\n- [ ] Minimizar as ferramentas e o escopo de acesso que a IA poderá usar.\n- [ ] Dividir tarefas grandes em unidades verificáveis de forma independente.\n- [ ] Exigir testes, documentação e um método de rollback junto com o código.\n- [ ] Fazer com que uma pessoa revise o diff e os resultados da execução em alterações importantes.\n- [ ] Registrar falhas, novas tentativas, custos e intervenções humanas.\n- [ ] Medir se a automação realmente melhorou a qualidade e o tempo de conclusão.\n- [ ] Permitir que o agente recuse ou encaminhe tarefas de baixo valor ou alto risco.\n\n## Conclusão\n\nA competitividade de um desenvolvedor nativo em IA não vem de um prompt específico nem do nome de uma ferramenta. Ela vem da **capacidade de definir o problema com precisão, criar um ambiente no qual o agente possa atuar com segurança, avaliar a qualidade dos resultados e assumir a responsabilidade por eles**.\n\nA IA pode produzir rapidamente grande parte da implementação, mas não garante automaticamente a direção correta do produto, a experiência do usuário, a segurança do sistema nem a responsabilidade final. Portanto, os desenvolvedores não devem abandonar a programação, mas ampliar sua função, com base no conhecimento de programação, para incluir especificações, avaliação, decisões de produto e operação de sistemas.","content_html":"\u003cp\u003eUm desenvolvedor nativo em IA não é simplesmente alguém que usa com habilidade ferramentas como ChatGPT, Claude Code e GitHub Copilot. Mais precisamente, pode ser definido como \u003cstrong\u003eum desenvolvedor que projeta o contexto, as ferramentas, as permissões e os critérios de avaliação para que a IA execute tarefas viáveis, enquanto as pessoas assumem a definição de objetivos, a validação, a aprovação e a responsabilidade\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eNo entanto, “desenvolvedor nativo em IA” não é uma certificação oficial nem um cargo padronizado sobre o qual todo o setor tenha chegado a um consenso. Como o alcance da automação varia conforme o nível de risco da organização e do produto, isso não deve ser equiparado a transferir todas as decisões para a IA.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#defini%C3%A7%C3%A3o-de-desenvolvedor-nativo-em-ia\" class=\"anchor\" id=\"definição-de-desenvolvedor-nativo-em-ia\"\u003e\u003c/a\u003eDefinição de desenvolvedor nativo em IA\u003c/h2\u003e\n\u003cp\u003eO desenvolvimento nativo em IA é uma abordagem que trata a IA não como uma ferramenta complementar de conclusão de código, mas como uma \u003cstrong\u003ecamada de execução do desenvolvimento\u003c/strong\u003e. As pessoas estruturam o trabalho a ser realizado e definem as condições de sucesso e as proibições, enquanto a IA executa tarefas de exploração, criação, execução e correção dentro dos limites permitidos.\u003c/p\u003e\n\u003cp\u003eAs principais funções são divididas da seguinte forma.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003ePessoas:\u003c/strong\u003e definição do problema, prioridades, restrições, classificação de risco, critérios de aprovação e responsabilidade final\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eAgente de IA:\u003c/strong\u003e busca de informações, rascunho do plano, criação de código e testes, análise estática e correções iterativas\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eHarness:\u003c/strong\u003e documentação, ferramentas, permissões, gerenciamento de estado, testes, logs, limites de custo e condições de interrupção\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eEm geral, um agente de IA é um sistema no qual um modelo de linguagem usa ferramentas e escolhe a próxima ação com base nos resultados intermediários. Diferentemente de um fluxo de trabalho que segue procedimentos predefinidos, um agente pode determinar dinamicamente a ordem das tarefas dentro dos limites permitidos.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eCategoria\u003c/th\u003e\n\u003cth\u003eDesenvolvimento assistido por IA\u003c/th\u003e\n\u003cth\u003eDesenvolvimento nativo em IA\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Categoria\"\u003ePosição da IA\u003c/td\u003e\n\u003ctd data-label=\"Desenvolvimento assistido por IA\"\u003eFerramenta de conclusão de código ou perguntas e respostas\u003c/td\u003e\n\u003ctd data-label=\"Desenvolvimento nativo em IA\"\u003eParte da camada de execução do trabalho\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Categoria\"\u003eEntrada\u003c/td\u003e\n\u003ctd data-label=\"Desenvolvimento assistido por IA\"\u003eCentrada em prompts curtos\u003c/td\u003e\n\u003ctd data-label=\"Desenvolvimento nativo em IA\"\u003eEspecificações, contexto do repositório, restrições e critérios de avaliação\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Categoria\"\u003ePapel das pessoas\u003c/td\u003e\n\u003ctd data-label=\"Desenvolvimento assistido por IA\"\u003eImplementação direta com auxílio da IA\u003c/td\u003e\n\u003ctd data-label=\"Desenvolvimento nativo em IA\"\u003eDefinição do problema, julgamento de exceções, validação e aprovação\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Categoria\"\u003eControle de qualidade\u003c/td\u003e\n\u003ctd data-label=\"Desenvolvimento assistido por IA\"\u003eDepende da verificação manual do desenvolvedor\u003c/td\u003e\n\u003ctd data-label=\"Desenvolvimento nativo em IA\"\u003eInclui testes, avaliadores e regras de revisão no harness\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Categoria\"\u003eForma de operação\u003c/td\u003e\n\u003ctd data-label=\"Desenvolvimento assistido por IA\"\u003eDepende da forma de uso de cada pessoa\u003c/td\u003e\n\u003ctd data-label=\"Desenvolvimento nativo em IA\"\u003eGerenciada por políticas e processos de equipe reproduzíveis\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eUm princípio importante é que \u003cstrong\u003eo trabalho pode ser delegado, mas a responsabilidade não\u003c/strong\u003e. A IA pode tomar decisões operacionais de baixo risco, mas decisões de grande impacto, como as relacionadas a segurança, dados pessoais, pagamentos, medicina, questões jurídicas e alterações em produção, exigem uma aprovação humana mais rigorosa.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#nivelamento-da-programa%C3%A7%C3%A3o-e-novos-diferenciais-dos-desenvolvedores\" class=\"anchor\" id=\"nivelamento-da-programação-e-novos-diferenciais-dos-desenvolvedores\"\u003e\u003c/a\u003eNivelamento da programação e novos diferenciais dos desenvolvedores\u003c/h2\u003e\n\u003cp\u003eA IA generativa reduz a barreira de entrada para implementações repetitivas, como a criação de código boilerplate, a busca de exemplos de uso de APIs, os rascunhos de testes e as sugestões de refatoração. Há certo efeito de nivelamento, pois até mesmo desenvolvedores com menos experiência conseguem criar protótipos funcionais mais rapidamente do que antes.\u003c/p\u003e\n\u003cp\u003eNo entanto, não é correto afirmar categoricamente que “a diferença de habilidade em programação desapareceu”. Para avaliar os resultados produzidos pela IA, os seguintes conhecimentos ainda são necessários.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eCapacidade de identificar requisitos contraditórios ou ausentes\u003c/li\u003e\n\u003cli\u003eCapacidade de projetar os limites do sistema e o fluxo de dados\u003c/li\u003e\n\u003cli\u003eCapacidade de avaliar os compromissos entre desempenho, segurança, custo e manutenibilidade\u003c/li\u003e\n\u003cli\u003eCapacidade de identificar implementações plausíveis, porém incorretas\u003c/li\u003e\n\u003cli\u003eCapacidade de rastrear a causa e realizar a recuperação quando ocorre uma falha\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eAs competências que produzem diferenças maiores na era da IA são as seguintes.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003eDefinição do problema:\u003c/strong\u003e especificar o problema que o usuário realmente enfrenta e as condições de sucesso.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eNoção de produto e UX:\u003c/strong\u003e avaliar o fluxo de uso, a facilidade de compreensão, a acessibilidade e a confiança, em vez de apenas a existência da funcionalidade.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eCapacidade de decomposição:\u003c/strong\u003e dividir um objetivo amplo em tarefas pequenas e verificáveis.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eProjeto de avaliação:\u003c/strong\u003e criar previamente testes, checklists, tabelas de pontuação e critérios de aprovação.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eProjeto de contexto:\u003c/strong\u003e organizar a documentação e o repositório para que a IA encontre com precisão apenas as informações necessárias.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eAvaliação de riscos:\u003c/strong\u003e distinguir as tarefas que podem ser automatizadas daquelas que exigem aprovação humana.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eEm última análise, quanto maior a velocidade de implementação, maior o valor da capacidade de decidir “o que criar e por quê” e “se o resultado é bom o suficiente”.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#markdown-e-projeto-de-documentos-de-refer%C3%AAncia\" class=\"anchor\" id=\"markdown-e-projeto-de-documentos-de-referência\"\u003e\u003c/a\u003eMarkdown e projeto de documentos de referência\u003c/h2\u003e\n\u003cp\u003eOs agentes não conhecem automaticamente o conhecimento implícito de uma organização. Se os requisitos e as restrições estiverem dispersos em conversas, reuniões, comentários no código e na memória individual, haverá uma probabilidade maior de repetição das mesmas perguntas ou de trabalho baseado em premissas diferentes.\u003c/p\u003e\n\u003cp\u003eMarkdown é útil como formato de documentação prática porque facilita o gerenciamento do histórico de alterações no Git e é relativamente simples tanto para leitura humana quanto para processamento por IA. No entanto, mais importante do que o próprio formato do arquivo é \u003cstrong\u003edefinir claramente qual documento representa o padrão mais atualizado\u003c/strong\u003e.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#informa%C3%A7%C3%B5es-a-incluir-no-documento-de-refer%C3%AAncia\" class=\"anchor\" id=\"informações-a-incluir-no-documento-de-referência\"\u003e\u003c/a\u003eInformações a incluir no documento de referência\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eObjetivos e não objetivos do produto, além de cenários de usuário\u003c/li\u003e\n\u003cli\u003eRequisitos funcionais e critérios de aceitação verificáveis\u003c/li\u003e\n\u003cli\u003eEstrutura do repositório e responsabilidades de cada módulo\u003c/li\u003e\n\u003cli\u003eContratos de API, modelos de dados e regras de migração\u003c/li\u003e\n\u003cli\u003eRegras de programação, comandos de teste e procedimentos de implantação\u003c/li\u003e\n\u003cli\u003eRegistros de decisões arquiteturais e motivos das alterações\u003c/li\u003e\n\u003cli\u003ePermissões de acesso, operações proibidas e condições de aprovação humana\u003c/li\u003e\n\u003cli\u003eLimitações conhecidas, procedimentos de resposta a incidentes e responsáveis\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eEm uma GitHub Issue, é possível registrar o contexto, o escopo, os critérios de aceitação, a documentação relacionada e a definição de conclusão da tarefa. É adequado manter a arquitetura de longo prazo e as regras operacionais em documentação versionada, como um diretório \u003ccode\u003edocs\u003c/code\u003e, e apontar para esses documentos na Issue.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#exemplo-de-especifica%C3%A7%C3%A3o-de-tarefa\" class=\"anchor\" id=\"exemplo-de-especificação-de-tarefa\"\u003e\u003c/a\u003eExemplo de especificação de tarefa\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e# Objetivo\n\u003c/span\u003e\u003cspan\u003eMelhorar a mensagem de falha no login para que o usuário saiba como se recuperar.\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# Escopo\n\u003c/span\u003e\u003cspan\u003e- Tela de login da Web\n\u003c/span\u003e\u003cspan\u003e- Mensagens em coreano e inglês\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# Fora do escopo\n\u003c/span\u003e\u003cspan\u003e- Alteração do método de autenticação\n\u003c/span\u003e\u003cspan\u003e- Alteração da política de senhas\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# Critérios de aceitação\n\u003c/span\u003e\u003cspan\u003e- Não expor externamente se a conta existe ou não.\n\u003c/span\u003e\u003cspan\u003e- Passar na verificação de acessibilidade e nos testes de autenticação existentes.\n\u003c/span\u003e\u003cspan\u003e- Permitir o retorno ao comportamento original em caso de falha.\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# Comandos de validação\n\u003c/span\u003e\u003cspan\u003e- npm test\n\u003c/span\u003e\u003cspan\u003e- npm run lint\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eUma documentação bem organizada pode reduzir a necessidade de o agente ler toda a base de código a cada tarefa. No entanto, isso não significa necessariamente uma redução de tokens ou custos. Se a documentação estiver duplicada ou desatualizada, ela poderá provocar ainda mais buscas e alterações incorretas. Também é necessário definir o responsável pela documentação, o momento da atualização e as regras de validação automática.\u003c/p\u003e\n\u003cp\u003eSenhas, chaves de API, dados reais de clientes e permissões excessivas de banco de dados não devem ser registrados na documentação. Os exemplos de esquema devem ser desidentificados, e as informações secretas devem ser gerenciadas em um repositório seguro separado.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#estrutura-m%C3%ADnima-de-um-harness-de-agentes-de-ia\" class=\"anchor\" id=\"estrutura-mínima-de-um-harness-de-agentes-de-ia\"\u003e\u003c/a\u003eEstrutura mínima de um harness de agentes de IA\u003c/h2\u003e\n\u003cp\u003eA engenharia de harness refere-se ao trabalho de projetar os mecanismos de execução ao redor do modelo. Isso inclui instruções de sistema, conexão com ferramentas, recuperação de contexto, permissões, memória, testes, observabilidade, novas tentativas e condições de interrupção.\u003c/p\u003e\n\u003cp\u003eO ciclo mínimo de execução pode ser composto por Plan, Draft e Review.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eEtapa\u003c/th\u003e\n\u003cth\u003ePergunta principal\u003c/th\u003e\n\u003cth\u003eEntregável\u003c/th\u003e\n\u003cth\u003eTratamento em caso de falha\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Etapa\"\u003ePlan\u003c/td\u003e\n\u003ctd data-label=\"Pergunta principal\"\u003eEsta tarefa é necessária? Quais são o escopo e os riscos?\u003c/td\u003e\n\u003ctd data-label=\"Entregável\"\u003ePlano, itens a alterar e método de validação\u003c/td\u003e\n\u003ctd data-label=\"Tratamento em caso de falha\"\u003eSolicitar informações adicionais ou interromper a tarefa\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Etapa\"\u003eDraft\u003c/td\u003e\n\u003ctd data-label=\"Pergunta principal\"\u003eO plano foi implementado na menor unidade segura?\u003c/td\u003e\n\u003ctd data-label=\"Entregável\"\u003eAlterações no código, nos testes e na documentação\u003c/td\u003e\n\u003ctd data-label=\"Tratamento em caso de falha\"\u003eCorrigir por um número limitado de tentativas\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Etapa\"\u003eReview\u003c/td\u003e\n\u003ctd data-label=\"Pergunta principal\"\u003eOs requisitos e os critérios de qualidade foram atendidos?\u003c/td\u003e\n\u003ctd data-label=\"Entregável\"\u003eResultado da avaliação, lista de defeitos e proposta de aprovação\u003c/td\u003e\n\u003ctd data-label=\"Tratamento em caso de falha\"\u003eRefazer o trabalho ou encaminhar para uma pessoa\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eUm harness real precisa dos seguintes mecanismos de controle.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eArquivos, comandos, rede e escopo de dados permitidos\u003c/li\u003e\n\u003cli\u003eTempo máximo de execução, número de chamadas de ferramentas e limite de custo\u003c/li\u003e\n\u003cli\u003eCondições de interrupção em caso de falha nos testes ou alta incerteza\u003c/li\u003e\n\u003cli\u003eLogs de todas as entradas, chamadas de ferramentas, alterações e aprovações\u003c/li\u003e\n\u003cli\u003eEtapa de aprovação humana antes da aplicação em produção\u003c/li\u003e\n\u003cli\u003eProcedimento de rollback para retornar ao estado original\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#agente-%C3%BAnico-e-m%C3%BAltiplos-agentes\" class=\"anchor\" id=\"agente-único-e-múltiplos-agentes\"\u003e\u003c/a\u003eAgente único e múltiplos agentes\u003c/h3\u003e\n\u003cp\u003ePlan, Draft e Review não exigem necessariamente três modelos ou agentes separados. Um único agente também pode executá-los usando instruções e ferramentas específicas para cada etapa.\u003c/p\u003e\n\u003cp\u003eEm uma estrutura de múltiplos agentes, as funções podem ser separadas da seguinte forma.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003ePlanner:\u003c/strong\u003e analisa os requisitos e examina a necessidade, o escopo e os riscos da funcionalidade.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eGenerator:\u003c/strong\u003e cria o código, os testes e a documentação de acordo com o plano.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eEvaluator:\u003c/strong\u003e inspeciona o resultado com base em critérios independentes e apresenta defeitos e pontos de melhoria.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eA separação de funções pode ajudar na crítica independente e na exploração paralela. Por outro lado, também aumenta a complexidade do custo das chamadas, da latência, da sincronização de estado e do rastreamento das causas dos erros. Para tarefas simples, scripts determinísticos ou um único agente podem ser mais estáveis, e múltiplos agentes devem ser adotados quando a melhoria medida justificar a complexidade.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#procedimento-de-ado%C3%A7%C3%A3o-por-equipes-e-empresas\" class=\"anchor\" id=\"procedimento-de-adoção-por-equipes-e-empresas\"\u003e\u003c/a\u003eProcedimento de adoção por equipes e empresas\u003c/h2\u003e\n\u003cp\u003eApenas anunciar a adoção da IA e oferecer treinamento não transforma uma organização em nativa em IA. Também é necessário estabelecer o escopo permitido, a política de dados, os critérios de qualidade e a estrutura de responsabilidades.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#etapa-1-defini%C3%A7%C3%A3o-da-linha-de-base-e-das-pol%C3%ADticas\" class=\"anchor\" id=\"etapa-1-definição-da-linha-de-base-e-das-políticas\"\u003e\u003c/a\u003eEtapa 1: definição da linha de base e das políticas\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eMedir o tempo atual das tarefas, a taxa de defeitos, o tempo de espera por revisão e a frequência de implantação.\u003c/li\u003e\n\u003cli\u003eDefinir quais dados não podem ser inseridos e quais ferramentas podem ser usadas.\u003c/li\u003e\n\u003cli\u003eDistinguir tarefas que podem ser executadas automaticamente daquelas que exigem aprovação humana.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#etapa-2-champions-e-piloto-limitado\" class=\"anchor\" id=\"etapa-2-champions-e-piloto-limitado\"\u003e\u003c/a\u003eEtapa 2: champions e piloto limitado\u003c/h3\u003e\n\u003cp\u003eDesignar na equipe champions com experiência no uso de IA e capacidade de treinamento. O papel dos champions não é promover ferramentas, mas organizar casos de uso reproduzíveis, casos de falha e regras de segurança.\u003c/p\u003e\n\u003cp\u003eÉ mais seguro iniciar o piloto com trabalhos cujos resultados sejam fáceis de validar, como geração de testes, organização da documentação interna e refatorações de baixo risco.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#etapa-3-padroniza%C3%A7%C3%A3o-de-padr%C3%B5es-bem-sucedidos\" class=\"anchor\" id=\"etapa-3-padronização-de-padrões-bem-sucedidos\"\u003e\u003c/a\u003eEtapa 3: padronização de padrões bem-sucedidos\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003ePriorizar o registro dos documentos de entrada e dos critérios de avaliação, em vez dos prompts que funcionaram.\u003c/li\u003e\n\u003cli\u003eCriar um modelo comum de Issue e uma definição de conclusão.\u003c/li\u003e\n\u003cli\u003eAutomatizar testes, lint, verificações de segurança e procedimentos de revisão.\u003c/li\u003e\n\u003cli\u003eDocumentar as causas das falhas e os pontos de intervenção humana.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#etapa-4-opera%C3%A7%C3%A3o-e-expans%C3%A3o\" class=\"anchor\" id=\"etapa-4-operação-e-expansão\"\u003e\u003c/a\u003eEtapa 4: operação e expansão\u003c/h3\u003e\n\u003cp\u003eAmpliar o escopo de aplicação quando os resultados do piloto apresentarem melhorias em relação à linha de base. A seleção de ferramentas, o treinamento, o gerenciamento de custos, as permissões de acesso, a resposta a incidentes e as avaliações periódicas devem ser conectados em um único sistema operacional.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#m%C3%A9tricas-para-medir-o-desempenho\" class=\"anchor\" id=\"métricas-para-medir-o-desempenho\"\u003e\u003c/a\u003eMétricas para medir o desempenho\u003c/h2\u003e\n\u003cp\u003eO número de linhas de código geradas ou a frequência de uso da IA não demonstram diretamente a produtividade e a qualidade. É necessário medir também métricas orientadas a resultados, como as seguintes.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eÁrea\u003c/th\u003e\n\u003cth\u003eMétrica recomendada\u003c/th\u003e\n\u003cth\u003eCuidados na interpretação\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área\"\u003eVelocidade\u003c/td\u003e\n\u003ctd data-label=\"Métrica recomendada\"\u003eTempo entre o início da tarefa e a implantação\u003c/td\u003e\n\u003ctd data-label=\"Cuidados na interpretação\"\u003eIncluir também o tempo de revisão e retrabalho.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área\"\u003eQualidade\u003c/td\u003e\n\u003ctd data-label=\"Métrica recomendada\"\u003eTaxa de defeitos após a implantação, taxa de falha nos testes\u003c/td\u003e\n\u003ctd data-label=\"Cuidados na interpretação\"\u003eSeparar tarefas fáceis de tarefas difíceis.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área\"\u003eEficiência\u003c/td\u003e\n\u003ctd data-label=\"Métrica recomendada\"\u003eCusto do modelo por tarefa, número de chamadas de ferramentas\u003c/td\u003e\n\u003ctd data-label=\"Cuidados na interpretação\"\u003eNão excluir o custo da revisão humana.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área\"\u003eEstabilidade\u003c/td\u003e\n\u003ctd data-label=\"Métrica recomendada\"\u003eTaxa de rollback, alertas de segurança, violações de permissão\u003c/td\u003e\n\u003ctd data-label=\"Cuidados na interpretação\"\u003eConsiderar também a possibilidade de problemas não detectados.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área\"\u003eAdoção\u003c/td\u003e\n\u003ctd data-label=\"Métrica recomendada\"\u003eProporção de equipes com uso recorrente, trabalho real concluído\u003c/td\u003e\n\u003ctd data-label=\"Cuidados na interpretação\"\u003eDistinguir de simples logins ou números de chamadas.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área\"\u003eExperiência\u003c/td\u003e\n\u003ctd data-label=\"Métrica recomendada\"\u003eSatisfação dos desenvolvedores, carga cognitiva, fadiga de revisão\u003c/td\u003e\n\u003ctd data-label=\"Cuidados na interpretação\"\u003eA fadiga pode aumentar mesmo quando a velocidade melhora.\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eOs resultados do grupo que usa IA e do grupo que utiliza o método existente devem ser comparados em tarefas do mesmo tipo, observando não apenas a velocidade no curto prazo, mas também os custos de manutenção e os incidentes.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#riscos-de-seguran%C3%A7a-e-qualidade\" class=\"anchor\" id=\"riscos-de-segurança-e-qualidade\"\u003e\u003c/a\u003eRiscos de segurança e qualidade\u003c/h2\u003e\n\u003cp\u003eComo os agentes de IA podem ler código, executar comandos e obter conteúdo externo, eles têm uma superfície de ataque mais ampla do que um chat comum.\u003c/p\u003e\n\u003cp\u003eOs principais riscos são os seguintes.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eInjeção de prompt que leva o agente a seguir instruções ocultas na documentação do repositório ou em páginas externas\u003c/li\u003e\n\u003cli\u003eConcessão de permissões desnecessárias a arquivos, bancos de dados ou implantações\u003c/li\u003e\n\u003cli\u003eCódigo incorreto que usa APIs ou pacotes inexistentes\u003c/li\u003e\n\u003cli\u003eIntrodução de dependências vulneráveis ou de código com licença incerta\u003c/li\u003e\n\u003cli\u003eAções que enfraquecem os próprios critérios de validação para fazer os testes passarem\u003c/li\u003e\n\u003cli\u003eTransmissão externa de dados de clientes, chaves secretas e código interno\u003c/li\u003e\n\u003cli\u003eAumento inesperado de custos devido a execuções repetidas\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eOs princípios de resposta são privilégio mínimo, ambiente de execução isolado, lista de permissões, separação de informações secretas, testes independentes, logs de alterações e aprovação humana. Em especial, avaliar a implementação de um agente apenas com os testes criados pelo próprio agente pode fazer com que erros em comum não sejam detectados; portanto, é recomendável manter os testes de regressão existentes e critérios de revisão separados.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#como-evitar-rea%C3%A7%C3%B5es-excessivas-%C3%A0s-ferramentas\" class=\"anchor\" id=\"como-evitar-reações-excessivas-às-ferramentas\"\u003e\u003c/a\u003eComo evitar reações excessivas às ferramentas\u003c/h2\u003e\n\u003cp\u003eNovos modelos, plugins e frameworks de agentes continuam surgindo, mas não é necessário aprender todas as ferramentas. Em vez de nomes ou tendências, as ferramentas devem ser avaliadas com base nas seguintes perguntas.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eA tarefa repetitiva que se pretende resolver no momento está clara?\u003c/li\u003e\n\u003cli\u003eA ferramenta pode ser conectada com segurança ao ambiente de desenvolvimento e ao sistema de permissões existentes?\u003c/li\u003e\n\u003cli\u003eA qualidade da saída pode ser validada de forma automática ou manual?\u003c/li\u003e\n\u003cli\u003eÉ possível observar custos, latência e taxa de falhas?\u003c/li\u003e\n\u003cli\u003eMesmo que a ferramenta seja substituída, as especificações, os testes e a documentação permanecem?\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eConcluir uma melhoria real no produto com uma ferramenta adequada à equipe e medir o resultado é mais valioso do que aprender superficialmente apenas como usar várias ferramentas.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#checklist-pr%C3%A1tico-do-desenvolvedor-nativo-em-ia\" class=\"anchor\" id=\"checklist-prático-do-desenvolvedor-nativo-em-ia\"\u003e\u003c/a\u003eChecklist prático do desenvolvedor nativo em IA\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e Documentar os objetivos, os não objetivos e os critérios de aceitação antes da implementação.\u003c/li\u003e\n\u003cli\u003e Minimizar as ferramentas e o escopo de acesso que a IA poderá usar.\u003c/li\u003e\n\u003cli\u003e Dividir tarefas grandes em unidades verificáveis de forma independente.\u003c/li\u003e\n\u003cli\u003e Exigir testes, documentação e um método de rollback junto com o código.\u003c/li\u003e\n\u003cli\u003e Fazer com que uma pessoa revise o diff e os resultados da execução em alterações importantes.\u003c/li\u003e\n\u003cli\u003e Registrar falhas, novas tentativas, custos e intervenções humanas.\u003c/li\u003e\n\u003cli\u003e Medir se a automação realmente melhorou a qualidade e o tempo de conclusão.\u003c/li\u003e\n\u003cli\u003e Permitir que o agente recuse ou encaminhe tarefas de baixo valor ou alto risco.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#conclus%C3%A3o\" class=\"anchor\" id=\"conclusão\"\u003e\u003c/a\u003eConclusão\u003c/h2\u003e\n\u003cp\u003eA competitividade de um desenvolvedor nativo em IA não vem de um prompt específico nem do nome de uma ferramenta. Ela vem da \u003cstrong\u003ecapacidade de definir o problema com precisão, criar um ambiente no qual o agente possa atuar com segurança, avaliar a qualidade dos resultados e assumir a responsabilidade por eles\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eA IA pode produzir rapidamente grande parte da implementação, mas não garante automaticamente a direção correta do produto, a experiência do usuário, a segurança do sistema nem a responsabilidade final. Portanto, os desenvolvedores não devem abandonar a programação, mas ampliar sua função, com base no conhecimento de programação, para incluir especificações, avaliação, decisões de produto e operação de sistemas.\u003c/p\u003e\n","tags":["Engenharia de harness","Agentes de IA","Nativo de IA","Desenvolvimento de software","Documentação"],"faqs":[{"question":"Desenvolvedores nativos de IA são o mesmo que engenheiros de prompts?","answer":"Não. A elaboração de prompts é apenas uma das habilidades; desenvolvedores nativos de IA lidam com todo o sistema de execução, incluindo a decomposição de problemas, o fornecimento de contexto, o projeto de ferramentas e permissões, testes, observação, aprovação e operação."},{"question":"Desenvolvedores nativos de IA não programam diretamente?","answer":"Não necessariamente. A proporção de código escrito diretamente pode diminuir, mas é necessário ter sólidos conhecimentos de desenvolvimento para compreender e depurar o código criado pela IA e avaliar problemas de arquitetura, desempenho e segurança."},{"question":"Podemos deixar todas as decisões a cargo dos agentes de IA?","answer":"Não. Escolhas limitadas e de baixo risco podem ser automatizadas, mas decisões de grande impacto, como exclusão de dados, pagamentos, permissões de segurança e implantação em produção, exigem aprovação humana explícita e procedimentos de recuperação."},{"question":"Plan, Draft, Review exigem necessariamente três agentes?","answer":"Não. Um único agente ou um fluxo de trabalho determinístico também pode executar as três etapas. Uma abordagem multiagente é adequada quando os benefícios da avaliação independente ou da exploração paralela superam os custos adicionais e a complexidade operacional."},{"question":"Documentos em Markdown sempre reduzem o custo de tokens?","answer":"Nem sempre. Documentos curtos, estruturados e atualizados podem reduzir buscas desnecessárias, mas documentos duplicados ou desatualizados provocam trabalhos incorretos e buscas adicionais. Também é necessário definir a responsabilidade pela atualização da documentação e os procedimentos de validação."},{"question":"Por onde devemos começar a transição para uma abordagem nativa de IA?","answer":"Após medir a linha de base do desempenho atual, é recomendável escolher uma tarefa fácil de validar, como geração de testes, organização da documentação ou refatoração de baixo risco. A expansão deve ocorrer após verificar, em um projeto-piloto limitado, a qualidade, o tempo de conclusão, o custo e a carga de revisão."},{"question":"A IA nivelou completamente as habilidades de programação?","answer":"A IA reduz a barreira de entrada para implementações repetitivas e elaboração de rascunhos, mas não elimina as diferenças de competência entre desenvolvedores. As capacidades de análise de requisitos, arquitetura, depuração, segurança, desempenho e validação de resultados ainda têm grande impacto na qualidade."},{"question":"É preciso aprender várias ferramentas de desenvolvimento com IA para se tornar competitivo?","answer":"A quantidade de ferramentas, por si só, não é uma vantagem competitiva. É melhor escolher primeiro uma ferramenta que permita concluir de forma confiável uma tarefa real e medir a qualidade e o custo. Se as especificações e os testes forem gerenciados sem dependência de uma ferramenta, também será mais fácil substituí-la posteriormente."},{"question":"Como medir o desempenho de uma equipe de desenvolvimento nativa de IA?","answer":"Em vez da quantidade de código gerado, é preciso medir em conjunto o tempo de conclusão das tarefas, os defeitos após a implantação, o retrabalho, as reversões, o custo dos modelos, o tempo de revisão e o nível de exaustão dos desenvolvedores. Para que os resultados possam ser interpretados, é necessário compará-los com a linha de base anterior à adoção e com tipos de tarefas semelhantes."}],"sources":[{"url":"https://www.anthropic.com/research/building-effective-agents","title":"Anthropic: Criando agentes eficazes","type":"source"},{"url":"https://docs.github.com/en/issues/tracking-your-work-with-issues/about-issues","title":"GitHub Docs: Sobre issues","type":"source"},{"url":"https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/about-writing-and-formatting-on-github","title":"GitHub Docs: Sobre escrita e formatação no GitHub","type":"source"},{"url":"https://www.nist.gov/itl/ai-risk-management-framework","title":"Estrutura de gerenciamento de riscos de IA do NIST","type":"source"},{"url":"https://genai.owasp.org/llm-top-10/","title":"OWASP Top 10 para aplicações de modelos de linguagem de grande porte","type":"source"}],"images":[{"id":461,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NTQ1NiwicHVyIjoiYmxvYl9pZCJ9fQ==--dcc52a99856a48635d1882fba812226f930329f5/ai-4dab44ed.webp","is_representative":true,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"개발자가 여러 대시보드에서 AI 에이전트의 설계, 코딩, 검증, 배포 흐름을 관리하는 다이어그램","caption":"AI 네이티브 개발자가 연결된 에이전트와 도구를 운영하는 전체 개발 구조를 보여준다.","description":null},"en":{"alt":"Developer managing AI agent design, coding, testing, security, and deployment across connected dashboards","caption":"The diagram shows an AI-native developer orchestrating connected agents and tools throughout development.","description":null},"ja":{"alt":"開発者が複数の画面でAIエージェントの設計、実装、検証、展開を管理する図","caption":"AIネイティブ開発者が連携するエージェントとツールを運用する開発構造を示している。","description":null},"es":{"alt":"Desarrollador gestionando diseño, código, pruebas, seguridad y despliegue de agentes de IA en paneles conectados","caption":"El diagrama muestra a un desarrollador nativo de IA coordinando agentes y herramientas durante el desarrollo.","description":null},"id":{"alt":"Pengembang mengelola desain, kode, pengujian, keamanan, dan penerapan agen AI lewat dasbor terhubung","caption":"Diagram ini menunjukkan pengembang native AI yang mengorkestrasi agen dan alat dalam proses pengembangan.","description":null},"pt":{"alt":"Desenvolvedor gerenciando design, código, testes, segurança e implantação de agentes de IA em painéis conectados","caption":"O diagrama mostra um desenvolvedor nativo de IA orquestrando agentes e ferramentas ao longo do desenvolvimento.","description":null},"zh-hant":{"alt":"開發者透過多個互連儀表板管理 AI 代理的設計、編碼、測試、安全與部署","caption":"此圖呈現 AI 原生開發者在開發流程中協調代理與工具的整體架構。","description":null},"de":{"alt":"Entwickler steuert Entwurf, Code, Tests, Sicherheit und Bereitstellung von KI-Agenten über vernetzte Dashboards","caption":"Das Diagramm zeigt, wie ein KI-nativer Entwickler vernetzte Agenten und Werkzeuge im Entwicklungsprozess koordiniert.","description":null}}},{"id":462,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NTQ2MiwicHVyIjoiYmxvYl9pZCJ9fQ==--9fdf22aa2cbd420f209ff5c18baea59124f816b9/ai-f15eba1a.webp","is_representative":false,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"보안 장벽 안에서 여러 AI 에이전트가 개발 모듈을 연결하고 검증하는 워크플로 다이어그램","caption":"AI 에이전트들이 코딩, 도구, 설정, 배포 단계를 협업하며 보안과 성능 지표로 검증받는 구조를 보여준다.","description":null},"en":{"alt":"Workflow diagram of AI agents connecting and validating development modules inside a secure boundary","caption":"AI agents collaborate across coding, tooling, configuration, and deployment stages with security and performance checks.","description":null},"ja":{"alt":"安全な領域内で複数のAIエージェントが開発モジュールを連携・検証するワークフロー図","caption":"AIエージェントがコーディング、ツール、設定、デプロイを分担し、セキュリティと性能を確認する構造を示している。","description":null},"es":{"alt":"Diagrama de agentes de IA que conectan y validan módulos de desarrollo en un entorno seguro","caption":"Los agentes de IA colaboran en las fases de código, herramientas, configuración y despliegue con controles de seguridad y rendimiento.","description":null},"id":{"alt":"Diagram alur agen AI yang menghubungkan dan memvalidasi modul pengembangan dalam batas aman","caption":"Agen AI berkolaborasi pada tahap pengodean, alat, konfigurasi, dan penerapan dengan pemeriksaan keamanan serta kinerja.","description":null},"pt":{"alt":"Diagrama de agentes de IA conectando e validando módulos de desenvolvimento em um ambiente seguro","caption":"Agentes de IA colaboram nas etapas de código, ferramentas, configuração e implantação com verificações de segurança e desempenho.","description":null},"zh-hant":{"alt":"多個 AI 代理在安全邊界內連接並驗證開發模組的工作流程圖","caption":"AI 代理協作完成編碼、工具、設定與部署階段，並接受安全和效能檢查。","description":null},"de":{"alt":"Workflow-Diagramm von KI-Agenten, die Entwicklungsmodule in einer sicheren Umgebung verbinden und prüfen","caption":"KI-Agenten arbeiten bei Code, Werkzeugen, Konfiguration und Bereitstellung zusammen und durchlaufen Sicherheits- und Leistungsprüfungen.","description":null}}}],"published_at":"2026-08-04T10:59:54+09:00","updated_at":"2026-08-04T10:59:54+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant","de"],"url":"https://injoys.com/en/articles/ai-native-developer-definition-and-practices"}