Programadores na era da IA: da geração de código ao controle da não determinismo

baeba · 2026-06-22T10:32:20+09:00

Visão geral resumida À medida que a IA automatiza uma parte significativa da escrita de código, o papel central do desenvolvedor está migrando da implementação direta para projeto, validação e controle. A essência do programador não está em digitar muito código, mas em preencher os detalhes de requisitos ambíguos e abstraí-los em formas reutilizáveis. Em vez de instruir a IA sobre métodos detalhados de implementação, é mais eficaz apresentar objetivos e contexto e delegar o julgamento. Em trabalhos com IA, a qualidade melhora quando os entregáveis são separados em especificação, testes, implementação, refatoração e validação, em vez de tentar fazer tudo de uma vez. Como a saída da IA é não determinística, são necessários harnesses determinísticos como testes, compiladores, linters e gates de validação. A perspectiva é que o desenvolvedor do futuro se aproxime menos de um simples autor de código e mais de um arquiteto de sistemas e engenheiro de harness, conectando agentes de IA a sistemas de validação. Introdução A identidade do desenvolvedor abalada pela IA Com a IA gerando centenas de linhas de código apenas com instruções em linguagem natural, os critérios das competências tradicionais de desenvolvimento estão mudando. No passado, a habilidade de escrever código rapidamente a partir de um editor vazio era vista como uma vantagem competitiva importante para o desenvolvedor. Hoje, com a IA fornecendo conhecimento e formas de implementação, surgem perguntas como estas. Ainda pode ser chamado de desenvolvimento mesmo sem escrever o código diretamente? Se a IA cuida dos detalhes da implementação, que papel sobra para o desenvolvedor? O conhecimento tradicional de ciência da computação e a história da programação ainda são necessários hoje? O texto explica essa questão com foco nos conceitos de detalhes, abstração, não determinismo e harness. O significado da história da programação O conhecimento de programação do passado não é apenas uma lista de técnicas, mas o processo pelo qual desenvolvedores da época resolveram problemas e criaram novas camadas de abstração. Linguagem de máquina, assembly, programação estruturada, orientação a objetos e frameworks surgiram para esconder a complexidade das camadas inferiores. Mesmo sem usar diretamente tecnologias antigas, entender essa história ajuda a perceber como o papel do desenvolvedor vem mudando de forma recorrente. Desenvolvimento 1. O desenvolvedor é quem concretiza os detalhes Em geral, o planejamento apresenta o objetivo do produto e sua direção macro, mas não especifica todas as condições necessárias para a implementação real. Por exemplo, até uma funcionalidade simples como “editar apelido” envolve detalhes como os seguintes. Se string vazia será permitida ou não Como tratar caracteres especiais e emojis Como lidar com erro de rede e atraso de resposta O que acontece ao sair da tela durante a edição Onde e como exibir mensagens de erro O trabalho do desenvolvedor consiste em transformar essas lacunas em regras lógicas e tratamento de exceções. Por isso, a especialidade do desenvolvedor está menos na simples implementação de funcionalidades e mais na capacidade de converter requisitos ambíguos em um comportamento completo de sistema. 2. Abstração é o processo de esconder detalhes já resolvidos Para reduzir trabalho repetitivo, desenvolvedores empacotam problemas já resolvidos em funções, módulos, bibliotecas e frameworks. O núcleo da abstração é o seguinte. Esconder comportamentos internos repetitivos. Expor apenas as funcionalidades necessárias para uso externo. Definir a fronteira entre o que pode mudar e o que deve permanecer fixo. Quando abstrações robustas se acumulam, novas camadas se formam, e quem desenvolve na camada superior pode trabalhar sem conhecer toda a implementação inferior. O ambiente atual de desenvolvimento funciona sobre camadas de abstração construídas por gerações anteriores de desenvolvedores. 3. A profundidade necessária ao desenvolvedor varia conforme a posição Nem toda abstração está concluída. Uma camada que esconde de forma estável sua implementação interna pode ser vista como uma “abstração concluída”. Já uma camada cujos detalhes internos continuam aparecendo na forma de problemas de desempenho ou erros é uma “abstração em andamento”. Até a mesma tecnologia muda de estado conforme o papel do desenvolvedor. Para um desenvolvedor web comum, o navegador é uma camada relativamente pronta. Para um desenvolvedor de engine de navegador, o processo de renderização é um detalhe que precisa ser tratado diretamente. A profundidade necessária ao desenvolvedor não é saber tudo sobre todas as tecnologias, mas entender o suficiente para identificar vazamentos e limites da camada sob sua responsabilidade. 4. A IA surgiu como uma nova camada de abstração A IA executa rapidamente a escrita de código e a implementação repetitiva que antes eram tratadas diretamente pelo desenvolvedor. Com isso, a IA começa a atuar não apenas como ferramenta de produtividade, mas como uma nova camada que abstrai o próprio processo de desenvolvimento. No entanto, o fato de a IA gerar código não significa que interpretação de requisitos, projeto de estrutura, validação de qualidade e responsabilidade operacional sejam resolvidos automaticamente. Pelo contrário, conforme o custo de implementação cai, cresce a importância do custo de montar e validar o código gerado. 5. Instruções detalhadas podem limitar o desempenho da IA O autor tentou desenvolver um side project de UI acessível usando apenas IA, sem digitar o código diretamente. No início, ele apresentou à IA métodos de implementação específicos, mas isso fez com que a IA ficasse presa ao método proposto e adicionasse tratamento de exceções repetidamente. Como resultado, o código ficou mais complexo, surgiram vários efeitos colaterais, e uma abordagem padrão mais adequada só foi aplicada mais tarde. Esse caso mostra que o método inicial apresentado pelo usuário pode funcionar como uma âncora que limita o julgamento da IA. Em vez de ditar excessivamente a solução e a estrutura do código, é mais eficaz fornecer o seguinte. O contexto e o objetivo do problema O contexto do sistema atual O resultado que obrigatoriamente deve ser atendido As restrições que não podem ser alteradas 6. Mais do que instruções, é preciso delegar objetivo e contexto À medida que o desempenho da IA aumenta, delegar com foco no objetivo pode ser mais eficaz do que especificar diretamente procedimentos detalhados. Nesse modelo de delegação, em vez de o desenvolvedor definir completamente “como implementar”, ele comunica com clareza “por que isso é necessário” e “o que precisa ser alcançado”. Ainda assim, dar autonomia total pode fazer a IA se concentrar mais em modificar o código do que na intenção do usuário. Por isso, é necessário limitar o procedimento de trabalho para que a IA execute primeiro as seguintes ações. Analisar a intenção do pedido Fazer perguntas sobre informações faltantes Apresentar um plano de solução Executar somente após aprovação do usuário O ponto principal não é apenas proibir ações, mas especificar com clareza quais entregáveis são permitidos na etapa atual. 7. Em cada tarefa, deve-se definir apenas um entregável LLMs têm limites de volume de saída e escopo de raciocínio que podem processar em uma única resposta. Se você pedir ao mesmo tempo a escrita de testes e a implementação, os recursos podem se concentrar no objetivo final — completar o código — e a qualidade dos testes cair. O autor separa o trabalho de TDD da seguinte forma. /red: escrever apenas testes que falham /green: escrever a implementação mínima para passar nos testes /refactor: melhorar a estrutura do código mantendo os testes Quando cada etapa é limitada a um único entregável, diminuem os problemas de a IA pular etapas intermediárias ou tratá-las de forma superficial. Isso significa que o ponto central do design de prompts não é explicar longamente o comportamento, mas definir o resultado que deve ser gerado em cada tarefa. 8. Documentos em Markdown e skills se tornam o novo código Ao separar especificação, testes, implementação, validação e commit em skills distintas, é possível montar um pipeline como este. Escrita da especificação Geração de testes que falham Implementação da funcionalidade Refatoração Validação Commit Cada skill possui entrada, saída e restrições, funcionando de forma semelhante a uma função. Documentos em Markdown que registram skills e regras funcionam não como simples manuais, mas como regras executáveis que determinam o comportamento da IA. Nesse processo, também é possível aplicar princípios clássicos de design de software. Princípio da responsabilidade única, atribuindo apenas uma responsabilidade a cada skill Modularização, separando conhecimento e regras em arquivos distintos Princípio aberto-fechado, expandindo por arquivos externos de conhecimento sem alterar as skills centrais A plataforma mudou do IDE para documentos em Markdown, mas decompor e conectar o trabalho continua sendo programação. 9. O risco central da programação com IA é o não determinismo Programas tradicionais tendem a retornar a mesma saída para a mesma entrada. A IA pode gerar códigos e julgamentos diferentes mesmo diante da mesma solicitação. Quando a IA executa uma grande refatoração, mesmo que a funcionalidade pareça funcionar, ainda restam problemas como os seguintes. Revisar a exatidão do código alterado Julgar se o código removido era de fato desnecessário Avaliar a possibilidade de novos efeitos colaterais Assumir responsabilidade por manutenção e deploy A IA acelera a geração de código, mas não entrega automaticamente estabilidade nem responsabilidade sobre o resultado. Em ambiente de produção, mais importante do que a capacidade de gerar é a capacidade de controlar o escopo das mudanças e validar o resultado. 10. A IA é forte em problemas de teto baixo Os problemas que a IA resolve com facilidade costumam ser “problemas bem definidos”, em que requisitos e formas de solução já são suficientemente conhecidos. Esses problemas podem ser resolvidos combinando elementos de abstração já consolidados, como bibliotecas, frameworks e padrões. A IA tem vantagem em combinar probabilisticamente código e padrões de resolução de problemas acumulados pela humanidade. Por outro lado, problemas de maior dificuldade como os seguintes ainda exigem julgamento humano adicional. Problemas com requisitos incompletos Regras de domínio complexas Interações de sistemas de grande escala Situações excepcionais do ambiente operacional Problemas que combinam segurança, desempenho, regulação e responsabilidade Isso não significa que o valor da implementação simples desapareça, mas sim que a implementação em si pode gradualmente migrar para um campo acessível até mesmo a usuários comuns. 11. Os detalhes do desenvolvedor migram para o controle da IA No passado, desenvolvedores escreviam código determinístico para se defender de entradas imprevisíveis de usuários e do ambiente operacional. Na era da IA, é preciso usar uma IA não determinística para criar produtos determinísticos. Os detalhes que o desenvolvedor precisa tratar migram para áreas como as seguintes. Definir o escopo do trabalho para que a IA não fique presa a objetivos errados Definir o formato de entradas e saídas em cada etapa Gerenciar contexto e documentos de conhecimento Limitar o escopo de mudanças em larga escala Projetar procedimentos de recuperação em caso de erro Validar qualidade e segurança do resultado Quanto mais o trabalho de implementação simples for automatizado, maior pode se tornar o peso de exceções e controle dentro do trabalho de desenvolvimento. 12. Os resultados da IA devem ser validados com ferramentas determinísticas Apenas fazer outra IA validar o resultado gerado não é suficiente para garantir confiabilidade. Para decidir se a saída de um sistema está correta, é necessário um critério claro de resposta correta, ou seja, um oráculo. Se uma IA não determinística também gerar arbitrariamente o critério de validação, ela pode corrigir erroneamente um resultado correto ou distorcer o próprio critério de validação. Por isso, os critérios de validação devem ser compostos, sempre que possível, por ferramentas determinísticas. Compiladores e verificadores de tipo Testes automatizados Linters e análise estática Validação de schema Critérios de desempenho e segurança Procedimentos de aprovação e limitação de escopo de mudanças O julgamento da IA pode ser usado como apoio, mas a aprovação final deve estar conectada a critérios reproduzíveis. 13. O harness se torna a infraestrutura central do desenvolvimento com IA O harness é o mecanismo de validação distribuído por etapas para impedir que a IA acumule erros ou saia do escopo durante o processo de trabalho. Seus principais componentes são os seguintes. Um pipeline que separa as etapas do trabalho Formatos de entrada e saída por etapa Testes automatizados e análise estática Gates de validação que interrompem o processo em caso de falha Limites de arquivos e de escopo que podem ser alterados Procedimentos de aprovação e revisão humana O harness impede que um pequeno erro em uma etapa se amplifique na etapa seguinte. A capacidade de usar IA pode passar a ser avaliada menos pela habilidade de escrever bons prompts e mais pela capacidade de prender saídas imprevisíveis dentro de um sistema estável. Conclusão O desenvolvedor não desaparece, seu papel se desloca A IA está automatizando rapidamente a escrita simples de código e a implementação repetitiva. Porém, para produzir resultados em nível de produto, continuam sendo necessários papéis como os seguintes. Definição do problema e dos objetivos Projeto da estrutura do sistema Separação das etapas de trabalho e dos entregáveis Coordenação do fluxo entre agentes de IA Construção de critérios de validação e de harnesses Responsabilidade final pelos resultados operacionais É provável que o trabalho do desenvolvedor mude no sentido de reduzir a parte de digitar código diretamente e aumentar a de organizar e controlar, como sistema, o código gerado pela IA. Escrever prompts é uma nova forma de programação O processo de transformar instruções recorrentes em skills e regras e conectá-las em um pipeline é semelhante a projetar funções e módulos. Documentos em Markdown podem funcionar como uma nova camada de código que define contexto, comportamento e formato de saída da IA. O desenvolvedor precisa documentar sua experiência e seus critérios implícitos de julgamento, abstraindo-os em uma forma reutilizável pela IA. Isso vai além de abstrair sistemas existentes: trata-se também de abstrair o próprio modo de trabalho e o processo de decisão do desenvolvedor. Competências centrais do desenvolvedor do futuro Capacidade de definir problemas com precisão Capacidade de delegar trabalho com foco em objetivo e contexto Capacidade de decompor tarefas complexas em pequenos entregáveis Capacidade de organizar skills e agentes em pipelines Capacidade de projetar critérios determinísticos de validação Capacidade de construir harnesses para controlar os riscos de resultados não determinísticos Profundidade técnica para entender os resultados gerados pela IA e assumir responsabilidade final Avaliação geral A IA não está eliminando a essência do desenvolvimento, mas mudando a camada de abstração que o desenvolvedor precisa lidar. Se antes o desenvolvedor tratava dos detalhes do código e do sistema, no futuro ele precisará tratar dos detalhes que surgem do comportamento e da saída da IA. O custo de gerar código cai, mas a importância de validação, montagem, operação e controle tende a crescer ainda mais. A essência do programador não está no ato de digitar em si, mas na capacidade de descobrir detalhes, abstraí-los e organizá-los em sistemas confiáveis.

(velog.io)

6 pontos por baeba 5 시간 전 | Ainda não há comentários. | Compartilhar no WhatsApp

Visão geral resumida

À medida que a IA automatiza uma parte significativa da escrita de código, o papel central do desenvolvedor está migrando da implementação direta para projeto, validação e controle.
A essência do programador não está em digitar muito código, mas em preencher os detalhes de requisitos ambíguos e abstraí-los em formas reutilizáveis.
Em vez de instruir a IA sobre métodos detalhados de implementação, é mais eficaz apresentar objetivos e contexto e delegar o julgamento.
Em trabalhos com IA, a qualidade melhora quando os entregáveis são separados em especificação, testes, implementação, refatoração e validação, em vez de tentar fazer tudo de uma vez.
Como a saída da IA é não determinística, são necessários harnesses determinísticos como testes, compiladores, linters e gates de validação.
A perspectiva é que o desenvolvedor do futuro se aproxime menos de um simples autor de código e mais de um arquiteto de sistemas e engenheiro de harness, conectando agentes de IA a sistemas de validação.

Introdução

A identidade do desenvolvedor abalada pela IA

Com a IA gerando centenas de linhas de código apenas com instruções em linguagem natural, os critérios das competências tradicionais de desenvolvimento estão mudando.
No passado, a habilidade de escrever código rapidamente a partir de um editor vazio era vista como uma vantagem competitiva importante para o desenvolvedor.
Hoje, com a IA fornecendo conhecimento e formas de implementação, surgem perguntas como estas.
- Ainda pode ser chamado de desenvolvimento mesmo sem escrever o código diretamente?
- Se a IA cuida dos detalhes da implementação, que papel sobra para o desenvolvedor?
- O conhecimento tradicional de ciência da computação e a história da programação ainda são necessários hoje?
O texto explica essa questão com foco nos conceitos de detalhes, abstração, não determinismo e harness.

O significado da história da programação

O conhecimento de programação do passado não é apenas uma lista de técnicas, mas o processo pelo qual desenvolvedores da época resolveram problemas e criaram novas camadas de abstração.
Linguagem de máquina, assembly, programação estruturada, orientação a objetos e frameworks surgiram para esconder a complexidade das camadas inferiores.
Mesmo sem usar diretamente tecnologias antigas, entender essa história ajuda a perceber como o papel do desenvolvedor vem mudando de forma recorrente.

Desenvolvimento

1. O desenvolvedor é quem concretiza os detalhes

Em geral, o planejamento apresenta o objetivo do produto e sua direção macro, mas não especifica todas as condições necessárias para a implementação real.
Por exemplo, até uma funcionalidade simples como “editar apelido” envolve detalhes como os seguintes.
- Se string vazia será permitida ou não
- Como tratar caracteres especiais e emojis
- Como lidar com erro de rede e atraso de resposta
- O que acontece ao sair da tela durante a edição
- Onde e como exibir mensagens de erro
O trabalho do desenvolvedor consiste em transformar essas lacunas em regras lógicas e tratamento de exceções.
Por isso, a especialidade do desenvolvedor está menos na simples implementação de funcionalidades e mais na capacidade de converter requisitos ambíguos em um comportamento completo de sistema.

2. Abstração é o processo de esconder detalhes já resolvidos

Para reduzir trabalho repetitivo, desenvolvedores empacotam problemas já resolvidos em funções, módulos, bibliotecas e frameworks.
O núcleo da abstração é o seguinte.
- Esconder comportamentos internos repetitivos.
- Expor apenas as funcionalidades necessárias para uso externo.
- Definir a fronteira entre o que pode mudar e o que deve permanecer fixo.
Quando abstrações robustas se acumulam, novas camadas se formam, e quem desenvolve na camada superior pode trabalhar sem conhecer toda a implementação inferior.
O ambiente atual de desenvolvimento funciona sobre camadas de abstração construídas por gerações anteriores de desenvolvedores.

3. A profundidade necessária ao desenvolvedor varia conforme a posição

Nem toda abstração está concluída.
Uma camada que esconde de forma estável sua implementação interna pode ser vista como uma “abstração concluída”.
Já uma camada cujos detalhes internos continuam aparecendo na forma de problemas de desempenho ou erros é uma “abstração em andamento”.
Até a mesma tecnologia muda de estado conforme o papel do desenvolvedor.
- Para um desenvolvedor web comum, o navegador é uma camada relativamente pronta.
- Para um desenvolvedor de engine de navegador, o processo de renderização é um detalhe que precisa ser tratado diretamente.
A profundidade necessária ao desenvolvedor não é saber tudo sobre todas as tecnologias, mas entender o suficiente para identificar vazamentos e limites da camada sob sua responsabilidade.

4. A IA surgiu como uma nova camada de abstração

A IA executa rapidamente a escrita de código e a implementação repetitiva que antes eram tratadas diretamente pelo desenvolvedor.
Com isso, a IA começa a atuar não apenas como ferramenta de produtividade, mas como uma nova camada que abstrai o próprio processo de desenvolvimento.
No entanto, o fato de a IA gerar código não significa que interpretação de requisitos, projeto de estrutura, validação de qualidade e responsabilidade operacional sejam resolvidos automaticamente.
Pelo contrário, conforme o custo de implementação cai, cresce a importância do custo de montar e validar o código gerado.

5. Instruções detalhadas podem limitar o desempenho da IA

O autor tentou desenvolver um side project de UI acessível usando apenas IA, sem digitar o código diretamente.
No início, ele apresentou à IA métodos de implementação específicos, mas isso fez com que a IA ficasse presa ao método proposto e adicionasse tratamento de exceções repetidamente.
Como resultado, o código ficou mais complexo, surgiram vários efeitos colaterais, e uma abordagem padrão mais adequada só foi aplicada mais tarde.
Esse caso mostra que o método inicial apresentado pelo usuário pode funcionar como uma âncora que limita o julgamento da IA.
Em vez de ditar excessivamente a solução e a estrutura do código, é mais eficaz fornecer o seguinte.
- O contexto e o objetivo do problema
- O contexto do sistema atual
- O resultado que obrigatoriamente deve ser atendido
- As restrições que não podem ser alteradas

6. Mais do que instruções, é preciso delegar objetivo e contexto

À medida que o desempenho da IA aumenta, delegar com foco no objetivo pode ser mais eficaz do que especificar diretamente procedimentos detalhados.
Nesse modelo de delegação, em vez de o desenvolvedor definir completamente “como implementar”, ele comunica com clareza “por que isso é necessário” e “o que precisa ser alcançado”.
Ainda assim, dar autonomia total pode fazer a IA se concentrar mais em modificar o código do que na intenção do usuário.
Por isso, é necessário limitar o procedimento de trabalho para que a IA execute primeiro as seguintes ações.
- Analisar a intenção do pedido
- Fazer perguntas sobre informações faltantes
- Apresentar um plano de solução
- Executar somente após aprovação do usuário
O ponto principal não é apenas proibir ações, mas especificar com clareza quais entregáveis são permitidos na etapa atual.

7. Em cada tarefa, deve-se definir apenas um entregável

LLMs têm limites de volume de saída e escopo de raciocínio que podem processar em uma única resposta.
Se você pedir ao mesmo tempo a escrita de testes e a implementação, os recursos podem se concentrar no objetivo final — completar o código — e a qualidade dos testes cair.
O autor separa o trabalho de TDD da seguinte forma.
- /red: escrever apenas testes que falham
- /green: escrever a implementação mínima para passar nos testes
- /refactor: melhorar a estrutura do código mantendo os testes
Quando cada etapa é limitada a um único entregável, diminuem os problemas de a IA pular etapas intermediárias ou tratá-las de forma superficial.
Isso significa que o ponto central do design de prompts não é explicar longamente o comportamento, mas definir o resultado que deve ser gerado em cada tarefa.

8. Documentos em Markdown e skills se tornam o novo código

Ao separar especificação, testes, implementação, validação e commit em skills distintas, é possível montar um pipeline como este.
- Escrita da especificação
- Geração de testes que falham
- Implementação da funcionalidade
- Refatoração
- Validação
- Commit
Cada skill possui entrada, saída e restrições, funcionando de forma semelhante a uma função.
Documentos em Markdown que registram skills e regras funcionam não como simples manuais, mas como regras executáveis que determinam o comportamento da IA.
Nesse processo, também é possível aplicar princípios clássicos de design de software.
- Princípio da responsabilidade única, atribuindo apenas uma responsabilidade a cada skill
- Modularização, separando conhecimento e regras em arquivos distintos
- Princípio aberto-fechado, expandindo por arquivos externos de conhecimento sem alterar as skills centrais
A plataforma mudou do IDE para documentos em Markdown, mas decompor e conectar o trabalho continua sendo programação.

9. O risco central da programação com IA é o não determinismo

Programas tradicionais tendem a retornar a mesma saída para a mesma entrada.
A IA pode gerar códigos e julgamentos diferentes mesmo diante da mesma solicitação.
Quando a IA executa uma grande refatoração, mesmo que a funcionalidade pareça funcionar, ainda restam problemas como os seguintes.
- Revisar a exatidão do código alterado
- Julgar se o código removido era de fato desnecessário
- Avaliar a possibilidade de novos efeitos colaterais
- Assumir responsabilidade por manutenção e deploy
A IA acelera a geração de código, mas não entrega automaticamente estabilidade nem responsabilidade sobre o resultado.
Em ambiente de produção, mais importante do que a capacidade de gerar é a capacidade de controlar o escopo das mudanças e validar o resultado.

10. A IA é forte em problemas de teto baixo

Os problemas que a IA resolve com facilidade costumam ser “problemas bem definidos”, em que requisitos e formas de solução já são suficientemente conhecidos.
Esses problemas podem ser resolvidos combinando elementos de abstração já consolidados, como bibliotecas, frameworks e padrões.
A IA tem vantagem em combinar probabilisticamente código e padrões de resolução de problemas acumulados pela humanidade.
Por outro lado, problemas de maior dificuldade como os seguintes ainda exigem julgamento humano adicional.
- Problemas com requisitos incompletos
- Regras de domínio complexas
- Interações de sistemas de grande escala
- Situações excepcionais do ambiente operacional
- Problemas que combinam segurança, desempenho, regulação e responsabilidade
Isso não significa que o valor da implementação simples desapareça, mas sim que a implementação em si pode gradualmente migrar para um campo acessível até mesmo a usuários comuns.

11. Os detalhes do desenvolvedor migram para o controle da IA

No passado, desenvolvedores escreviam código determinístico para se defender de entradas imprevisíveis de usuários e do ambiente operacional.
Na era da IA, é preciso usar uma IA não determinística para criar produtos determinísticos.
Os detalhes que o desenvolvedor precisa tratar migram para áreas como as seguintes.
- Definir o escopo do trabalho para que a IA não fique presa a objetivos errados
- Definir o formato de entradas e saídas em cada etapa
- Gerenciar contexto e documentos de conhecimento
- Limitar o escopo de mudanças em larga escala
- Projetar procedimentos de recuperação em caso de erro
- Validar qualidade e segurança do resultado
Quanto mais o trabalho de implementação simples for automatizado, maior pode se tornar o peso de exceções e controle dentro do trabalho de desenvolvimento.

12. Os resultados da IA devem ser validados com ferramentas determinísticas

Apenas fazer outra IA validar o resultado gerado não é suficiente para garantir confiabilidade.
Para decidir se a saída de um sistema está correta, é necessário um critério claro de resposta correta, ou seja, um oráculo.
Se uma IA não determinística também gerar arbitrariamente o critério de validação, ela pode corrigir erroneamente um resultado correto ou distorcer o próprio critério de validação.
Por isso, os critérios de validação devem ser compostos, sempre que possível, por ferramentas determinísticas.
- Compiladores e verificadores de tipo
- Testes automatizados
- Linters e análise estática
- Validação de schema
- Critérios de desempenho e segurança
- Procedimentos de aprovação e limitação de escopo de mudanças
O julgamento da IA pode ser usado como apoio, mas a aprovação final deve estar conectada a critérios reproduzíveis.

13. O harness se torna a infraestrutura central do desenvolvimento com IA

O harness é o mecanismo de validação distribuído por etapas para impedir que a IA acumule erros ou saia do escopo durante o processo de trabalho.
Seus principais componentes são os seguintes.
- Um pipeline que separa as etapas do trabalho
- Formatos de entrada e saída por etapa
- Testes automatizados e análise estática
- Gates de validação que interrompem o processo em caso de falha
- Limites de arquivos e de escopo que podem ser alterados
- Procedimentos de aprovação e revisão humana
O harness impede que um pequeno erro em uma etapa se amplifique na etapa seguinte.
A capacidade de usar IA pode passar a ser avaliada menos pela habilidade de escrever bons prompts e mais pela capacidade de prender saídas imprevisíveis dentro de um sistema estável.

Conclusão

O desenvolvedor não desaparece, seu papel se desloca

A IA está automatizando rapidamente a escrita simples de código e a implementação repetitiva.
Porém, para produzir resultados em nível de produto, continuam sendo necessários papéis como os seguintes.
- Definição do problema e dos objetivos
- Projeto da estrutura do sistema
- Separação das etapas de trabalho e dos entregáveis
- Coordenação do fluxo entre agentes de IA
- Construção de critérios de validação e de harnesses
- Responsabilidade final pelos resultados operacionais
É provável que o trabalho do desenvolvedor mude no sentido de reduzir a parte de digitar código diretamente e aumentar a de organizar e controlar, como sistema, o código gerado pela IA.

Escrever prompts é uma nova forma de programação

O processo de transformar instruções recorrentes em skills e regras e conectá-las em um pipeline é semelhante a projetar funções e módulos.
Documentos em Markdown podem funcionar como uma nova camada de código que define contexto, comportamento e formato de saída da IA.
O desenvolvedor precisa documentar sua experiência e seus critérios implícitos de julgamento, abstraindo-os em uma forma reutilizável pela IA.
Isso vai além de abstrair sistemas existentes: trata-se também de abstrair o próprio modo de trabalho e o processo de decisão do desenvolvedor.

Competências centrais do desenvolvedor do futuro

Capacidade de definir problemas com precisão
Capacidade de delegar trabalho com foco em objetivo e contexto
Capacidade de decompor tarefas complexas em pequenos entregáveis
Capacidade de organizar skills e agentes em pipelines
Capacidade de projetar critérios determinísticos de validação
Capacidade de construir harnesses para controlar os riscos de resultados não determinísticos
Profundidade técnica para entender os resultados gerados pela IA e assumir responsabilidade final

Avaliação geral

A IA não está eliminando a essência do desenvolvimento, mas mudando a camada de abstração que o desenvolvedor precisa lidar.
Se antes o desenvolvedor tratava dos detalhes do código e do sistema, no futuro ele precisará tratar dos detalhes que surgem do comportamento e da saída da IA.
O custo de gerar código cai, mas a importância de validação, montagem, operação e controle tende a crescer ainda mais.
A essência do programador não está no ato de digitar em si, mas na capacidade de descobrir detalhes, abstraí-los e organizá-los em sistemas confiáveis.