O futuro da Programação com uso de IA

Prévia do material em texto

CADERNOS DE TECNOLOGIA E TRABALHO
O FUTURO DA PROGRAMAÇÃO
COM IA
Arquitetura, testes, segurança e autoria técnica em uma
era de código assistido
E-BOOK COMPLETO
Edição digital • 2026 Leitura crítica, casos e roteiros de aplicação
O FUTURO DA PROGRAMAÇÃO COM IA
01 • EDIÇÃO DIGITAL 2026
APRESENTAÇÃO
Assistentes de código diminuem o custo de produzir rascunhos, exemplos e testes
iniciais. Isso não torna dispensável a engenharia de software. Requisitos, integração,
segurança, desempenho, dependências e operação continuam exigindo decisões
explícitas. Este livro apresenta uma disciplina de desenvolvimento assistido: usar IA
para acelerar trabalho mecânico, mas preservar controle sobre o que entra em
produção.
Como usar este e-book
Cada capítulo apresenta uma ideia central, um caso hipotético comentado, um método de
implantação, medidas úteis, contrapontos e uma oficina para aplicação. Você pode ler de forma
linear ou selecionar os capítulos ligados ao seu contexto. O objetivo não é induzir adoção
automática de tecnologia, mas ampliar a capacidade de formular requisitos, avaliar evidências,
estabelecer limites e comunicar decisões.
Uma premissa editorial
Tecnologias de inteligência artificial mudam com rapidez, enquanto a necessidade de
qualidade, responsabilidade e documentação permanece. Por isso, as páginas
seguintes distinguem possibilidade técnica de decisão organizacional. Toda afirmação
operacional deve ser testada contra dados, pessoas, normas e objetivos da situação
concreta.
O FUTURO DA PROGRAMAÇÃO COM IA
02 • EDIÇÃO DIGITAL 2026
CAPÍTULO 01 — CÓDIGO É APENAS UMA
PARTE DO SISTEMA
IDEIA CENTRAL
Software confiável depende de requisitos, dados, interfaces, implantação e operação. Essa
afirmação parece simples até que a decisão chega ao contexto de uma equipe, a um orçamento e
a pessoas que dependerão do resultado. É necessário separar mecanismo, finalidade e limites: o
que a tecnologia consegue fazer sob condições controladas não equivale ao que deve fazer em
uma operação real. O capítulo trabalha com uma situação específica, observa seus pontos de
falha e propõe um modo de avaliar resultados sem esconder incertezas.
COMO O PROCESSO FUNCIONA
Comece pela unidade de análise: cada mudança de software tem entrada, transformação, saída e
consequência. No caso de “código é apenas uma parte do sistema”, a entrada pode estar
incompleta, contraditória ou fora do padrão; por isso, o equipe de desenvolvimento precisa
verificar condições de uso antes de produzir o código versionado com testes. Uma maneira útil de
representar o processo é desenhar quatro caixas: origem da informação, critérios aplicados,
resultado entregue e verificação posterior. Descreva também o que não deve ser decidido pelo
sistema. A fronteira operacional aqui é revisão, testes e segurança antes de publicar. Sem essa
fronteira, o fluxo pode aparentar eficiência enquanto transfere risco para usuários e equipes de
suporte.
Faça a distinção entre três tipos de problema. O primeiro é erro de entrada: os dados não
correspondem à situação real. O segundo é erro de método: mesmo com dados corretos, as
regras ou o modelo não tratam adequadamente a exceção. O terceiro é erro de uso: a saída é
apropriada como sugestão, mas alguém a interpreta como aprovação final. O controle de
qualidade muda para cada situação. Conferência da fonte reduz o primeiro; ensaios com casos
difíceis reduzem o segundo; treinamento, interface clara e responsabilidade definida reduzem o
terceiro. Essa decomposição vale mais do que afirmar genericamente que o sistema “tem
precisão”.
O FUTURO DA PROGRAMAÇÃO COM IA
03 • EDIÇÃO DIGITAL 2026
CASO COMENTADO
Considere esta situação hipotética: Um plugin funciona localmente, mas falha quando encontra
versão diferente da API. A equipe não começa pela ferramenta. Primeiro, define o resultado
aceitável e reúne exemplos de rotina, exceções e situações em que não há dados suficientes. Em
seguida, alguém executa o fluxo atual para formar uma referência de comparação. Só então a
nova abordagem é aplicada aos mesmos casos, com registro do que mudou e do que permaneceu
igual. O objetivo não é fabricar uma vitória da tecnologia: é identificar quais partes do trabalho
foram realmente aprimoradas.
Imagine agora que surge medir produtividade apenas por linhas geradas.. O problema não deve
ser resolvido ocultando o caso ruim da amostra. Registre o ocorrido, classifique a gravidade,
preserve as entradas necessárias para reproduzi-lo sem violar privacidade e defina quem pode
corrigir ou interromper o processo. Se houver impacto externo, a resposta precisa incluir
comunicação ao afetado e reparação proporcionada. Um piloto que aprende com esse episódio
tem mais valor do que uma implantação que só apresenta exemplos bem-sucedidos.
No fechamento do caso, compare duas perguntas diferentes: “o sistema concluiu a tarefa?” e “o
usuário obteve o resultado certo com esforço aceitável?”. Uma resposta pode ser tecnicamente
válida e ainda gerar retrabalho, insegurança ou falta de confiança. Observe o correção e
facilidade de manutenção; registre custos que surgiram fora da equipe central; e evite inferir
qualidade apenas pela satisfação imediata. Usuários podem gostar de uma resposta rápida sem
perceber uma omissão, enquanto profissionais experientes podem notar uma falha crítica em
poucos segundos.
MÉTODO DE IMPLANTAÇÃO
A primeira etapa é delimitar o escopo em uma página: público, objetivo, dados permitidos,
condições para recusar uma resposta, responsável e forma de reversão. A segunda é montar um
conjunto pequeno, porém heterogêneo, de casos: típicos, extremos, incompletos e
deliberadamente adversariais. A terceira é testar sem alterar o padrão de avaliação entre
alternativas. Nesta etapa, a ação recomendada é: começar por contrato e cenário de uso. Ela
deve ser executada de modo observável, com data, versão e pessoa responsável.
A quarta etapa é tornar explícito o custo total. Some tempo de preparação, esforço de revisão,
treinamento, licença, infraestrutura, falhas e manutenção. Uma economia em minutos por
mudança de software não se converte automaticamente em economia organizacional: talvez a
equipe precise corrigir dados, acolher reclamações ou reconstruir confiança. A quinta etapa é
instituir revisão regular. À medida que documentos, usuários, processos e tecnologia mudam, o
resultado anterior deixa de representar a situação presente. Guarde uma amostra fixa para
comparação entre versões e complemente-a com ocorrências novas da operação.
A sexta etapa consiste em distribuir autoridade: quem pode alterar regras, quem aprova
exceções, quem acessa informações e quem determina a suspensão. Não basta declarar que há
“humano no circuito” se essa pessoa não tem tempo, informação ou poder para discordar. A
revisão humana precisa de critérios, exemplos de erro e canal para registrar divergências.
Quando essas condições estão presentes, a tecnologia pode reduzir trabalho mecânico sem
transferir silenciosamente a responsabilidade a quem recebe a saída.
O FUTURO DA PROGRAMAÇÃO COM IA
04 • EDIÇÃO DIGITAL 2026
MEDIDAS QUE IMPORTAM
Use como indicador principal defeitos em produção e custo de manutenção.. Não o leia
isoladamente. Separe os resultados por tipo de caso, contexto, grupo afetado e grau de
dificuldade; depois compare com a linha de base anterior. Se o indicador melhorar apenas em
situações simples, talvez o sistema tenha deslocado o trabalho difícil para pessoas menos visíveis.
Acrescente uma medida de segurança: quantidade de erros graves por amostra auditada.
Acrescente ainda uma medida de custo: esforço total por resultado validado, incluindo correção
posterior.
Defina o que conta como sucesso antes do teste. Uma meta que muda depois de observar os
resultados não permite comparação honesta. Analise também os casos de recusa: há situações
em que o melhor resultado é admitir dúvida, interromper a ação ou encaminhar a uma pessoa
competente. Registre falsos positivos e falsos negativos quando houver classificação;como tal. Exercício 5: apresente a um colega a principal limitação
encontrada, sem defender previamente a ferramenta. Peça que ele formule uma explicação
alternativa para o ganho observado. Esse confronto melhora a avaliação e previne o entusiasmo
seletivo. Ao final, pergunte se o código versionado com testes produzido poderia ser
compreendido e contestado por alguém que não participou do projeto.
O FUTURO DA PROGRAMAÇÃO COM IA
26 • EDIÇÃO DIGITAL 2026
CAPÍTULO 09 — DEPURAÇÃO ASSISTIDA
IDEIA CENTRAL
IA pode sugerir hipóteses, mas logs e reprodução são a base da investigação. A consequência
prática é que uma solução só faz sentido se melhorar uma tarefa definida. Antes de discutir
fornecedores, imagine duas alternativas: continuar com o procedimento atual ou alterar apenas
uma etapa. A comparação obriga a observar qualidade, tempo e impacto sobre as pessoas, em
vez de presumir que toda automação representa progresso.
COMO O PROCESSO FUNCIONA
Comece pela unidade de análise: cada mudança de software tem entrada, transformação, saída e
consequência. No caso de “depuração assistida”, a entrada pode estar incompleta, contraditória
ou fora do padrão; por isso, o equipe de desenvolvimento precisa verificar condições de uso antes
de produzir o código versionado com testes. Uma maneira útil de representar o processo é
desenhar quatro caixas: origem da informação, critérios aplicados, resultado entregue e
verificação posterior. Descreva também o que não deve ser decidido pelo sistema. A fronteira
operacional aqui é revisão, testes e segurança antes de publicar. Sem essa fronteira, o fluxo pode
aparentar eficiência enquanto transfere risco para usuários e equipes de suporte.
Faça a distinção entre três tipos de problema. O primeiro é erro de entrada: os dados não
correspondem à situação real. O segundo é erro de método: mesmo com dados corretos, as
regras ou o modelo não tratam adequadamente a exceção. O terceiro é erro de uso: a saída é
apropriada como sugestão, mas alguém a interpreta como aprovação final. O controle de
qualidade muda para cada situação. Conferência da fonte reduz o primeiro; ensaios com casos
difíceis reduzem o segundo; treinamento, interface clara e responsabilidade definida reduzem o
terceiro. Essa decomposição vale mais do que afirmar genericamente que o sistema “tem
precisão”.
O FUTURO DA PROGRAMAÇÃO COM IA
27 • EDIÇÃO DIGITAL 2026
CASO COMENTADO
Considere esta situação hipotética: Uma equipe cria caso mínimo que reproduz falha intermitente.
A equipe não começa pela ferramenta. Primeiro, define o resultado aceitável e reúne exemplos de
rotina, exceções e situações em que não há dados suficientes. Em seguida, alguém executa o
fluxo atual para formar uma referência de comparação. Só então a nova abordagem é aplicada
aos mesmos casos, com registro do que mudou e do que permaneceu igual. O objetivo não é
fabricar uma vitória da tecnologia: é identificar quais partes do trabalho foram realmente
aprimoradas.
Imagine agora que surge enviar log com dados confidenciais sem saneamento.. O problema não
deve ser resolvido ocultando o caso ruim da amostra. Registre o ocorrido, classifique a gravidade,
preserve as entradas necessárias para reproduzi-lo sem violar privacidade e defina quem pode
corrigir ou interromper o processo. Se houver impacto externo, a resposta precisa incluir
comunicação ao afetado e reparação proporcionada. Um piloto que aprende com esse episódio
tem mais valor do que uma implantação que só apresenta exemplos bem-sucedidos.
No fechamento do caso, compare duas perguntas diferentes: “o sistema concluiu a tarefa?” e “o
usuário obteve o resultado certo com esforço aceitável?”. Uma resposta pode ser tecnicamente
válida e ainda gerar retrabalho, insegurança ou falta de confiança. Observe o correção e
facilidade de manutenção; registre custos que surgiram fora da equipe central; e evite inferir
qualidade apenas pela satisfação imediata. Usuários podem gostar de uma resposta rápida sem
perceber uma omissão, enquanto profissionais experientes podem notar uma falha crítica em
poucos segundos.
MÉTODO DE IMPLANTAÇÃO
A primeira etapa é delimitar o escopo em uma página: público, objetivo, dados permitidos,
condições para recusar uma resposta, responsável e forma de reversão. A segunda é montar um
conjunto pequeno, porém heterogêneo, de casos: típicos, extremos, incompletos e
deliberadamente adversariais. A terceira é testar sem alterar o padrão de avaliação entre
alternativas. Nesta etapa, a ação recomendada é: sanear dados e registrar hipótese, teste e
resultado. Ela deve ser executada de modo observável, com data, versão e pessoa responsável.
A quarta etapa é tornar explícito o custo total. Some tempo de preparação, esforço de revisão,
treinamento, licença, infraestrutura, falhas e manutenção. Uma economia em minutos por
mudança de software não se converte automaticamente em economia organizacional: talvez a
equipe precise corrigir dados, acolher reclamações ou reconstruir confiança. A quinta etapa é
instituir revisão regular. À medida que documentos, usuários, processos e tecnologia mudam, o
resultado anterior deixa de representar a situação presente. Guarde uma amostra fixa para
comparação entre versões e complemente-a com ocorrências novas da operação.
A sexta etapa consiste em distribuir autoridade: quem pode alterar regras, quem aprova
exceções, quem acessa informações e quem determina a suspensão. Não basta declarar que há
“humano no circuito” se essa pessoa não tem tempo, informação ou poder para discordar. A
revisão humana precisa de critérios, exemplos de erro e canal para registrar divergências.
Quando essas condições estão presentes, a tecnologia pode reduzir trabalho mecânico sem
transferir silenciosamente a responsabilidade a quem recebe a saída.
O FUTURO DA PROGRAMAÇÃO COM IA
28 • EDIÇÃO DIGITAL 2026
MEDIDAS QUE IMPORTAM
Use como indicador principal tempo de diagnóstico e reincidência.. Não o leia isoladamente.
Separe os resultados por tipo de caso, contexto, grupo afetado e grau de dificuldade; depois
compare com a linha de base anterior. Se o indicador melhorar apenas em situações simples,
talvez o sistema tenha deslocado o trabalho difícil para pessoas menos visíveis. Acrescente uma
medida de segurança: quantidade de erros graves por amostra auditada. Acrescente ainda uma
medida de custo: esforço total por resultado validado, incluindo correção posterior.
Defina o que conta como sucesso antes do teste. Uma meta que muda depois de observar os
resultados não permite comparação honesta. Analise também os casos de recusa: há situações
em que o melhor resultado é admitir dúvida, interromper a ação ou encaminhar a uma pessoa
competente. Registre falsos positivos e falsos negativos quando houver classificação; use
exemplos concretos para orientar a equipe, não apenas médias. Se a amostra for pequena, diga
explicitamente que o piloto sugere possibilidades e ainda não comprova desempenho estável.
DECISÕES DIFÍCEIS E CONTRAPONTOS
O erro mais tentador é código plausível sem teste. Ele se agrava quando enviar log com dados
confidenciais sem saneamento.. A mitigação não é exigir perfeição abstrata, mas reduzir
exposição: limitar alcance, registrar decisões e estabelecer parada segura. Há também uma
tensão entre personalização e padronização. Personalizar pode ajudar a atender contextos
diferentes, mas dificulta reproduzir decisões e explicar tratamentos distintos. Padronizar facilita
auditoria, mas pode ignorar necessidades individuais. A escolha deve ser justificada em função da
tarefa, não pela capacidade da ferramenta.
Outro contraponto é a possibilidade de uma solução sem IA ser melhor. Um formulário claro, uma
lista de verificação, uma regra determinística, uma formação breve ou a correção da base de
dados podem resolver o problema por menos custo e com maior previsibilidade. Use a tecnologia
quando ela acrescentar capacidade demonstrável, não quando for a opção mais fácil de anunciar.
Para decidir, documente alternativa rejeitada, motivo, restriçãode orçamento e condição que
faria a equipe rever a escolha.
OFICINA PARA O LEITOR
Exercício 1: descreva, em até seis linhas, uma situação própria relacionada a “depuração
assistida”. Identifique uma entrada verificável, uma saída útil e uma pessoa que sofrerá as
consequências de um erro. Exercício 2: elabore três casos normais, dois de borda e um caso em
que a resposta correta é “não sei”. Escreva antes do teste o que considerará resultado aceitável.
Exercício 3: aplique a orientação “sanear dados e registrar hipótese, teste e resultado.” e registre
o que mudou no processo, não apenas na interface.
Exercício 4: desenhe uma tabela com cinco colunas — caso, resultado esperado, resultado
observado, gravidade e ação corretiva. Preencha a tabela com exemplos reais autorizados ou
fictícios, claramente sinalizados como tal. Exercício 5: apresente a um colega a principal limitação
encontrada, sem defender previamente a ferramenta. Peça que ele formule uma explicação
alternativa para o ganho observado. Esse confronto melhora a avaliação e previne o entusiasmo
seletivo. Ao final, pergunte se o código versionado com testes produzido poderia ser
compreendido e contestado por alguém que não participou do projeto.
O FUTURO DA PROGRAMAÇÃO COM IA
29 • EDIÇÃO DIGITAL 2026
CAPÍTULO 10 — DOCUMENTAÇÃO VIVA
IDEIA CENTRAL
Documentação útil explica por que decisões foram tomadas e como operar o sistema. Essa
afirmação parece simples até que a decisão chega ao contexto de uma equipe, a um orçamento e
a pessoas que dependerão do resultado. É necessário separar mecanismo, finalidade e limites: o
que a tecnologia consegue fazer sob condições controladas não equivale ao que deve fazer em
uma operação real. O capítulo trabalha com uma situação específica, observa seus pontos de
falha e propõe um modo de avaliar resultados sem esconder incertezas.
COMO O PROCESSO FUNCIONA
Comece pela unidade de análise: cada mudança de software tem entrada, transformação, saída e
consequência. No caso de “documentação viva”, a entrada pode estar incompleta, contraditória
ou fora do padrão; por isso, o equipe de desenvolvimento precisa verificar condições de uso antes
de produzir o código versionado com testes. Uma maneira útil de representar o processo é
desenhar quatro caixas: origem da informação, critérios aplicados, resultado entregue e
verificação posterior. Descreva também o que não deve ser decidido pelo sistema. A fronteira
operacional aqui é revisão, testes e segurança antes de publicar. Sem essa fronteira, o fluxo pode
aparentar eficiência enquanto transfere risco para usuários e equipes de suporte.
Faça a distinção entre três tipos de problema. O primeiro é erro de entrada: os dados não
correspondem à situação real. O segundo é erro de método: mesmo com dados corretos, as
regras ou o modelo não tratam adequadamente a exceção. O terceiro é erro de uso: a saída é
apropriada como sugestão, mas alguém a interpreta como aprovação final. O controle de
qualidade muda para cada situação. Conferência da fonte reduz o primeiro; ensaios com casos
difíceis reduzem o segundo; treinamento, interface clara e responsabilidade definida reduzem o
terceiro. Essa decomposição vale mais do que afirmar genericamente que o sistema “tem
precisão”.
O FUTURO DA PROGRAMAÇÃO COM IA
30 • EDIÇÃO DIGITAL 2026
CASO COMENTADO
Considere esta situação hipotética: Um README descreve versão, limites e como rodar testes. A
equipe não começa pela ferramenta. Primeiro, define o resultado aceitável e reúne exemplos de
rotina, exceções e situações em que não há dados suficientes. Em seguida, alguém executa o
fluxo atual para formar uma referência de comparação. Só então a nova abordagem é aplicada
aos mesmos casos, com registro do que mudou e do que permaneceu igual. O objetivo não é
fabricar uma vitória da tecnologia: é identificar quais partes do trabalho foram realmente
aprimoradas.
Imagine agora que surge gerar documentação genérica que não acompanha o código.. O
problema não deve ser resolvido ocultando o caso ruim da amostra. Registre o ocorrido,
classifique a gravidade, preserve as entradas necessárias para reproduzi-lo sem violar privacidade
e defina quem pode corrigir ou interromper o processo. Se houver impacto externo, a resposta
precisa incluir comunicação ao afetado e reparação proporcionada. Um piloto que aprende com
esse episódio tem mais valor do que uma implantação que só apresenta exemplos
bem-sucedidos.
No fechamento do caso, compare duas perguntas diferentes: “o sistema concluiu a tarefa?” e “o
usuário obteve o resultado certo com esforço aceitável?”. Uma resposta pode ser tecnicamente
válida e ainda gerar retrabalho, insegurança ou falta de confiança. Observe o correção e
facilidade de manutenção; registre custos que surgiram fora da equipe central; e evite inferir
qualidade apenas pela satisfação imediata. Usuários podem gostar de uma resposta rápida sem
perceber uma omissão, enquanto profissionais experientes podem notar uma falha crítica em
poucos segundos.
MÉTODO DE IMPLANTAÇÃO
A primeira etapa é delimitar o escopo em uma página: público, objetivo, dados permitidos,
condições para recusar uma resposta, responsável e forma de reversão. A segunda é montar um
conjunto pequeno, porém heterogêneo, de casos: típicos, extremos, incompletos e
deliberadamente adversariais. A terceira é testar sem alterar o padrão de avaliação entre
alternativas. Nesta etapa, a ação recomendada é: atualizar documentos junto com mudança de
código. Ela deve ser executada de modo observável, com data, versão e pessoa responsável.
A quarta etapa é tornar explícito o custo total. Some tempo de preparação, esforço de revisão,
treinamento, licença, infraestrutura, falhas e manutenção. Uma economia em minutos por
mudança de software não se converte automaticamente em economia organizacional: talvez a
equipe precise corrigir dados, acolher reclamações ou reconstruir confiança. A quinta etapa é
instituir revisão regular. À medida que documentos, usuários, processos e tecnologia mudam, o
resultado anterior deixa de representar a situação presente. Guarde uma amostra fixa para
comparação entre versões e complemente-a com ocorrências novas da operação.
A sexta etapa consiste em distribuir autoridade: quem pode alterar regras, quem aprova
exceções, quem acessa informações e quem determina a suspensão. Não basta declarar que há
“humano no circuito” se essa pessoa não tem tempo, informação ou poder para discordar. A
revisão humana precisa de critérios, exemplos de erro e canal para registrar divergências.
Quando essas condições estão presentes, a tecnologia pode reduzir trabalho mecânico sem
transferir silenciosamente a responsabilidade a quem recebe a saída.
O FUTURO DA PROGRAMAÇÃO COM IA
31 • EDIÇÃO DIGITAL 2026
MEDIDAS QUE IMPORTAM
Use como indicador principal tempo de onboarding e incidentes por uso errado.. Não o leia
isoladamente. Separe os resultados por tipo de caso, contexto, grupo afetado e grau de
dificuldade; depois compare com a linha de base anterior. Se o indicador melhorar apenas em
situações simples, talvez o sistema tenha deslocado o trabalho difícil para pessoas menos visíveis.
Acrescente uma medida de segurança: quantidade de erros graves por amostra auditada.
Acrescente ainda uma medida de custo: esforço total por resultado validado, incluindo correção
posterior.
Defina o que conta como sucesso antes do teste. Uma meta que muda depois de observar os
resultados não permite comparação honesta. Analise também os casos de recusa: há situações
em que o melhor resultado é admitir dúvida, interromper a ação ou encaminhar a uma pessoa
competente. Registre falsos positivos e falsos negativos quando houver classificação; use
exemplos concretos para orientar a equipe, não apenas médias. Se a amostra for pequena, diga
explicitamente que o piloto sugere possibilidades e ainda não comprova desempenho estável.
DECISÕES DIFÍCEIS E CONTRAPONTOS
O erro mais tentador é código plausível sem teste. Ele se agrava quando gerar documentação
genérica que não acompanhao código.. A mitigação não é exigir perfeição abstrata, mas reduzir
exposição: limitar alcance, registrar decisões e estabelecer parada segura. Há também uma
tensão entre personalização e padronização. Personalizar pode ajudar a atender contextos
diferentes, mas dificulta reproduzir decisões e explicar tratamentos distintos. Padronizar facilita
auditoria, mas pode ignorar necessidades individuais. A escolha deve ser justificada em função da
tarefa, não pela capacidade da ferramenta.
Outro contraponto é a possibilidade de uma solução sem IA ser melhor. Um formulário claro, uma
lista de verificação, uma regra determinística, uma formação breve ou a correção da base de
dados podem resolver o problema por menos custo e com maior previsibilidade. Use a tecnologia
quando ela acrescentar capacidade demonstrável, não quando for a opção mais fácil de anunciar.
Para decidir, documente alternativa rejeitada, motivo, restrição de orçamento e condição que
faria a equipe rever a escolha.
OFICINA PARA O LEITOR
Exercício 1: descreva, em até seis linhas, uma situação própria relacionada a “documentação
viva”. Identifique uma entrada verificável, uma saída útil e uma pessoa que sofrerá as
consequências de um erro. Exercício 2: elabore três casos normais, dois de borda e um caso em
que a resposta correta é “não sei”. Escreva antes do teste o que considerará resultado aceitável.
Exercício 3: aplique a orientação “atualizar documentos junto com mudança de código.” e registre
o que mudou no processo, não apenas na interface.
Exercício 4: desenhe uma tabela com cinco colunas — caso, resultado esperado, resultado
observado, gravidade e ação corretiva. Preencha a tabela com exemplos reais autorizados ou
fictícios, claramente sinalizados como tal. Exercício 5: apresente a um colega a principal limitação
encontrada, sem defender previamente a ferramenta. Peça que ele formule uma explicação
alternativa para o ganho observado. Esse confronto melhora a avaliação e previne o entusiasmo
seletivo. Ao final, pergunte se o código versionado com testes produzido poderia ser
compreendido e contestado por alguém que não participou do projeto.
O FUTURO DA PROGRAMAÇÃO COM IA
32 • EDIÇÃO DIGITAL 2026
CAPÍTULO 11 — INTEGRAÇÃO CONTÍNUA
IDEIA CENTRAL
O ponto de partida deste capítulo é uma escolha de desenho, não uma corrida por novidade:
pipelines reduzem risco ao executar testes, lint e análise antes da integração. Para transformar a
ideia em trabalho confiável, explicite quem solicita, quem executa, de onde vêm os dados,
quando o processo termina e quem pode contestar uma falha. Esse percurso revela custos e
limitações que uma demonstração isolada não mostra.
COMO O PROCESSO FUNCIONA
Comece pela unidade de análise: cada mudança de software tem entrada, transformação, saída e
consequência. No caso de “integração contínua”, a entrada pode estar incompleta, contraditória
ou fora do padrão; por isso, o equipe de desenvolvimento precisa verificar condições de uso antes
de produzir o código versionado com testes. Uma maneira útil de representar o processo é
desenhar quatro caixas: origem da informação, critérios aplicados, resultado entregue e
verificação posterior. Descreva também o que não deve ser decidido pelo sistema. A fronteira
operacional aqui é revisão, testes e segurança antes de publicar. Sem essa fronteira, o fluxo pode
aparentar eficiência enquanto transfere risco para usuários e equipes de suporte.
Faça a distinção entre três tipos de problema. O primeiro é erro de entrada: os dados não
correspondem à situação real. O segundo é erro de método: mesmo com dados corretos, as
regras ou o modelo não tratam adequadamente a exceção. O terceiro é erro de uso: a saída é
apropriada como sugestão, mas alguém a interpreta como aprovação final. O controle de
qualidade muda para cada situação. Conferência da fonte reduz o primeiro; ensaios com casos
difíceis reduzem o segundo; treinamento, interface clara e responsabilidade definida reduzem o
terceiro. Essa decomposição vale mais do que afirmar genericamente que o sistema “tem
precisão”.
O FUTURO DA PROGRAMAÇÃO COM IA
33 • EDIÇÃO DIGITAL 2026
CASO COMENTADO
Considere esta situação hipotética: Uma regra impede merge sem testes e varredura de
segredos. A equipe não começa pela ferramenta. Primeiro, define o resultado aceitável e reúne
exemplos de rotina, exceções e situações em que não há dados suficientes. Em seguida, alguém
executa o fluxo atual para formar uma referência de comparação. Só então a nova abordagem é
aplicada aos mesmos casos, com registro do que mudou e do que permaneceu igual. O objetivo
não é fabricar uma vitória da tecnologia: é identificar quais partes do trabalho foram realmente
aprimoradas.
Imagine agora que surge confiar em execução manual irregular.. O problema não deve ser
resolvido ocultando o caso ruim da amostra. Registre o ocorrido, classifique a gravidade, preserve
as entradas necessárias para reproduzi-lo sem violar privacidade e defina quem pode corrigir ou
interromper o processo. Se houver impacto externo, a resposta precisa incluir comunicação ao
afetado e reparação proporcionada. Um piloto que aprende com esse episódio tem mais valor do
que uma implantação que só apresenta exemplos bem-sucedidos.
No fechamento do caso, compare duas perguntas diferentes: “o sistema concluiu a tarefa?” e “o
usuário obteve o resultado certo com esforço aceitável?”. Uma resposta pode ser tecnicamente
válida e ainda gerar retrabalho, insegurança ou falta de confiança. Observe o correção e
facilidade de manutenção; registre custos que surgiram fora da equipe central; e evite inferir
qualidade apenas pela satisfação imediata. Usuários podem gostar de uma resposta rápida sem
perceber uma omissão, enquanto profissionais experientes podem notar uma falha crítica em
poucos segundos.
MÉTODO DE IMPLANTAÇÃO
A primeira etapa é delimitar o escopo em uma página: público, objetivo, dados permitidos,
condições para recusar uma resposta, responsável e forma de reversão. A segunda é montar um
conjunto pequeno, porém heterogêneo, de casos: típicos, extremos, incompletos e
deliberadamente adversariais. A terceira é testar sem alterar o padrão de avaliação entre
alternativas. Nesta etapa, a ação recomendada é: automatizar verificações e tratar alertas
relevantes. Ela deve ser executada de modo observável, com data, versão e pessoa responsável.
A quarta etapa é tornar explícito o custo total. Some tempo de preparação, esforço de revisão,
treinamento, licença, infraestrutura, falhas e manutenção. Uma economia em minutos por
mudança de software não se converte automaticamente em economia organizacional: talvez a
equipe precise corrigir dados, acolher reclamações ou reconstruir confiança. A quinta etapa é
instituir revisão regular. À medida que documentos, usuários, processos e tecnologia mudam, o
resultado anterior deixa de representar a situação presente. Guarde uma amostra fixa para
comparação entre versões e complemente-a com ocorrências novas da operação.
A sexta etapa consiste em distribuir autoridade: quem pode alterar regras, quem aprova
exceções, quem acessa informações e quem determina a suspensão. Não basta declarar que há
“humano no circuito” se essa pessoa não tem tempo, informação ou poder para discordar. A
revisão humana precisa de critérios, exemplos de erro e canal para registrar divergências.
Quando essas condições estão presentes, a tecnologia pode reduzir trabalho mecânico sem
transferir silenciosamente a responsabilidade a quem recebe a saída.
O FUTURO DA PROGRAMAÇÃO COM IA
34 • EDIÇÃO DIGITAL 2026
MEDIDAS QUE IMPORTAM
Use como indicador principal falhas bloqueadas antes do merge.. Não o leia isoladamente. Separe
os resultados por tipo de caso, contexto, grupo afetado e grau de dificuldade; depois compare
com a linha de base anterior. Se o indicador melhorar apenas em situações simples, talvez o
sistema tenha deslocado o trabalho difícil para pessoas menos visíveis. Acrescente uma medida
de segurança: quantidade de erros graves por amostra auditada.Acrescente ainda uma medida
de custo: esforço total por resultado validado, incluindo correção posterior.
Defina o que conta como sucesso antes do teste. Uma meta que muda depois de observar os
resultados não permite comparação honesta. Analise também os casos de recusa: há situações
em que o melhor resultado é admitir dúvida, interromper a ação ou encaminhar a uma pessoa
competente. Registre falsos positivos e falsos negativos quando houver classificação; use
exemplos concretos para orientar a equipe, não apenas médias. Se a amostra for pequena, diga
explicitamente que o piloto sugere possibilidades e ainda não comprova desempenho estável.
DECISÕES DIFÍCEIS E CONTRAPONTOS
O erro mais tentador é código plausível sem teste. Ele se agrava quando confiar em execução
manual irregular.. A mitigação não é exigir perfeição abstrata, mas reduzir exposição: limitar
alcance, registrar decisões e estabelecer parada segura. Há também uma tensão entre
personalização e padronização. Personalizar pode ajudar a atender contextos diferentes, mas
dificulta reproduzir decisões e explicar tratamentos distintos. Padronizar facilita auditoria, mas
pode ignorar necessidades individuais. A escolha deve ser justificada em função da tarefa, não
pela capacidade da ferramenta.
Outro contraponto é a possibilidade de uma solução sem IA ser melhor. Um formulário claro, uma
lista de verificação, uma regra determinística, uma formação breve ou a correção da base de
dados podem resolver o problema por menos custo e com maior previsibilidade. Use a tecnologia
quando ela acrescentar capacidade demonstrável, não quando for a opção mais fácil de anunciar.
Para decidir, documente alternativa rejeitada, motivo, restrição de orçamento e condição que
faria a equipe rever a escolha.
OFICINA PARA O LEITOR
Exercício 1: descreva, em até seis linhas, uma situação própria relacionada a “integração
contínua”. Identifique uma entrada verificável, uma saída útil e uma pessoa que sofrerá as
consequências de um erro. Exercício 2: elabore três casos normais, dois de borda e um caso em
que a resposta correta é “não sei”. Escreva antes do teste o que considerará resultado aceitável.
Exercício 3: aplique a orientação “automatizar verificações e tratar alertas relevantes.” e registre
o que mudou no processo, não apenas na interface.
Exercício 4: desenhe uma tabela com cinco colunas — caso, resultado esperado, resultado
observado, gravidade e ação corretiva. Preencha a tabela com exemplos reais autorizados ou
fictícios, claramente sinalizados como tal. Exercício 5: apresente a um colega a principal limitação
encontrada, sem defender previamente a ferramenta. Peça que ele formule uma explicação
alternativa para o ganho observado. Esse confronto melhora a avaliação e previne o entusiasmo
seletivo. Ao final, pergunte se o código versionado com testes produzido poderia ser
compreendido e contestado por alguém que não participou do projeto.
O FUTURO DA PROGRAMAÇÃO COM IA
35 • EDIÇÃO DIGITAL 2026
CAPÍTULO 12 — OBSERVABILIDADE E
OPERAÇÃO
IDEIA CENTRAL
Depois do deploy, métricas e logs mostram se o sistema atende ao contrato. A consequência
prática é que uma solução só faz sentido se melhorar uma tarefa definida. Antes de discutir
fornecedores, imagine duas alternativas: continuar com o procedimento atual ou alterar apenas
uma etapa. A comparação obriga a observar qualidade, tempo e impacto sobre as pessoas, em
vez de presumir que toda automação representa progresso.
COMO O PROCESSO FUNCIONA
Comece pela unidade de análise: cada mudança de software tem entrada, transformação, saída e
consequência. No caso de “observabilidade e operação”, a entrada pode estar incompleta,
contraditória ou fora do padrão; por isso, o equipe de desenvolvimento precisa verificar condições
de uso antes de produzir o código versionado com testes. Uma maneira útil de representar o
processo é desenhar quatro caixas: origem da informação, critérios aplicados, resultado entregue
e verificação posterior. Descreva também o que não deve ser decidido pelo sistema. A fronteira
operacional aqui é revisão, testes e segurança antes de publicar. Sem essa fronteira, o fluxo pode
aparentar eficiência enquanto transfere risco para usuários e equipes de suporte.
Faça a distinção entre três tipos de problema. O primeiro é erro de entrada: os dados não
correspondem à situação real. O segundo é erro de método: mesmo com dados corretos, as
regras ou o modelo não tratam adequadamente a exceção. O terceiro é erro de uso: a saída é
apropriada como sugestão, mas alguém a interpreta como aprovação final. O controle de
qualidade muda para cada situação. Conferência da fonte reduz o primeiro; ensaios com casos
difíceis reduzem o segundo; treinamento, interface clara e responsabilidade definida reduzem o
terceiro. Essa decomposição vale mais do que afirmar genericamente que o sistema “tem
precisão”.
O FUTURO DA PROGRAMAÇÃO COM IA
36 • EDIÇÃO DIGITAL 2026
CASO COMENTADO
Considere esta situação hipotética: Um serviço alerta quando aumenta taxa de erro em consulta.
A equipe não começa pela ferramenta. Primeiro, define o resultado aceitável e reúne exemplos de
rotina, exceções e situações em que não há dados suficientes. Em seguida, alguém executa o
fluxo atual para formar uma referência de comparação. Só então a nova abordagem é aplicada
aos mesmos casos, com registro do que mudou e do que permaneceu igual. O objetivo não é
fabricar uma vitória da tecnologia: é identificar quais partes do trabalho foram realmente
aprimoradas.
Imagine agora que surge considerar entrega como fim do trabalho.. O problema não deve ser
resolvido ocultando o caso ruim da amostra. Registre o ocorrido, classifique a gravidade, preserve
as entradas necessárias para reproduzi-lo sem violar privacidade e defina quem pode corrigir ou
interromper o processo. Se houver impacto externo, a resposta precisa incluir comunicação ao
afetado e reparação proporcionada. Um piloto que aprende com esse episódio tem mais valor do
que uma implantação que só apresenta exemplos bem-sucedidos.
No fechamento do caso, compare duas perguntas diferentes: “o sistema concluiu a tarefa?” e “o
usuário obteve o resultado certo com esforço aceitável?”. Uma resposta pode ser tecnicamente
válida e ainda gerar retrabalho, insegurança ou falta de confiança. Observe o correção e
facilidade de manutenção; registre custos que surgiram fora da equipe central; e evite inferir
qualidade apenas pela satisfação imediata. Usuários podem gostar de uma resposta rápida sem
perceber uma omissão, enquanto profissionais experientes podem notar uma falha crítica em
poucos segundos.
MÉTODO DE IMPLANTAÇÃO
A primeira etapa é delimitar o escopo em uma página: público, objetivo, dados permitidos,
condições para recusar uma resposta, responsável e forma de reversão. A segunda é montar um
conjunto pequeno, porém heterogêneo, de casos: típicos, extremos, incompletos e
deliberadamente adversariais. A terceira é testar sem alterar o padrão de avaliação entre
alternativas. Nesta etapa, a ação recomendada é: definir métricas antes do lançamento. Ela deve
ser executada de modo observável, com data, versão e pessoa responsável.
A quarta etapa é tornar explícito o custo total. Some tempo de preparação, esforço de revisão,
treinamento, licença, infraestrutura, falhas e manutenção. Uma economia em minutos por
mudança de software não se converte automaticamente em economia organizacional: talvez a
equipe precise corrigir dados, acolher reclamações ou reconstruir confiança. A quinta etapa é
instituir revisão regular. À medida que documentos, usuários, processos e tecnologia mudam, o
resultado anterior deixa de representar a situação presente. Guarde uma amostra fixa para
comparação entre versões e complemente-a com ocorrências novas da operação.
A sexta etapa consiste em distribuir autoridade: quem pode alterar regras, quem aprova
exceções, quem acessa informações e quem determina a suspensão. Não basta declarar que há
“humano no circuito” se essa pessoa não tem tempo, informação ou poderpara discordar. A
revisão humana precisa de critérios, exemplos de erro e canal para registrar divergências.
Quando essas condições estão presentes, a tecnologia pode reduzir trabalho mecânico sem
transferir silenciosamente a responsabilidade a quem recebe a saída.
O FUTURO DA PROGRAMAÇÃO COM IA
37 • EDIÇÃO DIGITAL 2026
MEDIDAS QUE IMPORTAM
Use como indicador principal disponibilidade, latência e erro por versão.. Não o leia isoladamente.
Separe os resultados por tipo de caso, contexto, grupo afetado e grau de dificuldade; depois
compare com a linha de base anterior. Se o indicador melhorar apenas em situações simples,
talvez o sistema tenha deslocado o trabalho difícil para pessoas menos visíveis. Acrescente uma
medida de segurança: quantidade de erros graves por amostra auditada. Acrescente ainda uma
medida de custo: esforço total por resultado validado, incluindo correção posterior.
Defina o que conta como sucesso antes do teste. Uma meta que muda depois de observar os
resultados não permite comparação honesta. Analise também os casos de recusa: há situações
em que o melhor resultado é admitir dúvida, interromper a ação ou encaminhar a uma pessoa
competente. Registre falsos positivos e falsos negativos quando houver classificação; use
exemplos concretos para orientar a equipe, não apenas médias. Se a amostra for pequena, diga
explicitamente que o piloto sugere possibilidades e ainda não comprova desempenho estável.
DECISÕES DIFÍCEIS E CONTRAPONTOS
O erro mais tentador é código plausível sem teste. Ele se agrava quando considerar entrega como
fim do trabalho.. A mitigação não é exigir perfeição abstrata, mas reduzir exposição: limitar
alcance, registrar decisões e estabelecer parada segura. Há também uma tensão entre
personalização e padronização. Personalizar pode ajudar a atender contextos diferentes, mas
dificulta reproduzir decisões e explicar tratamentos distintos. Padronizar facilita auditoria, mas
pode ignorar necessidades individuais. A escolha deve ser justificada em função da tarefa, não
pela capacidade da ferramenta.
Outro contraponto é a possibilidade de uma solução sem IA ser melhor. Um formulário claro, uma
lista de verificação, uma regra determinística, uma formação breve ou a correção da base de
dados podem resolver o problema por menos custo e com maior previsibilidade. Use a tecnologia
quando ela acrescentar capacidade demonstrável, não quando for a opção mais fácil de anunciar.
Para decidir, documente alternativa rejeitada, motivo, restrição de orçamento e condição que
faria a equipe rever a escolha.
OFICINA PARA O LEITOR
Exercício 1: descreva, em até seis linhas, uma situação própria relacionada a “observabilidade e
operação”. Identifique uma entrada verificável, uma saída útil e uma pessoa que sofrerá as
consequências de um erro. Exercício 2: elabore três casos normais, dois de borda e um caso em
que a resposta correta é “não sei”. Escreva antes do teste o que considerará resultado aceitável.
Exercício 3: aplique a orientação “definir métricas antes do lançamento.” e registre o que mudou
no processo, não apenas na interface.
Exercício 4: desenhe uma tabela com cinco colunas — caso, resultado esperado, resultado
observado, gravidade e ação corretiva. Preencha a tabela com exemplos reais autorizados ou
fictícios, claramente sinalizados como tal. Exercício 5: apresente a um colega a principal limitação
encontrada, sem defender previamente a ferramenta. Peça que ele formule uma explicação
alternativa para o ganho observado. Esse confronto melhora a avaliação e previne o entusiasmo
seletivo. Ao final, pergunte se o código versionado com testes produzido poderia ser
compreendido e contestado por alguém que não participou do projeto.
O FUTURO DA PROGRAMAÇÃO COM IA
38 • EDIÇÃO DIGITAL 2026
CAPÍTULO 13 — PROGRAMAÇÃO LOW-CODE E
AUTOMAÇÃO
IDEIA CENTRAL
Abstrações ampliam público, mas não removem necessidade de modelar regras e governar
mudanças. Essa afirmação parece simples até que a decisão chega ao contexto de uma equipe, a
um orçamento e a pessoas que dependerão do resultado. É necessário separar mecanismo,
finalidade e limites: o que a tecnologia consegue fazer sob condições controladas não equivale ao
que deve fazer em uma operação real. O capítulo trabalha com uma situação específica, observa
seus pontos de falha e propõe um modo de avaliar resultados sem esconder incertezas.
COMO O PROCESSO FUNCIONA
Comece pela unidade de análise: cada mudança de software tem entrada, transformação, saída e
consequência. No caso de “programação low-code e automação”, a entrada pode estar
incompleta, contraditória ou fora do padrão; por isso, o equipe de desenvolvimento precisa
verificar condições de uso antes de produzir o código versionado com testes. Uma maneira útil de
representar o processo é desenhar quatro caixas: origem da informação, critérios aplicados,
resultado entregue e verificação posterior. Descreva também o que não deve ser decidido pelo
sistema. A fronteira operacional aqui é revisão, testes e segurança antes de publicar. Sem essa
fronteira, o fluxo pode aparentar eficiência enquanto transfere risco para usuários e equipes de
suporte.
Faça a distinção entre três tipos de problema. O primeiro é erro de entrada: os dados não
correspondem à situação real. O segundo é erro de método: mesmo com dados corretos, as
regras ou o modelo não tratam adequadamente a exceção. O terceiro é erro de uso: a saída é
apropriada como sugestão, mas alguém a interpreta como aprovação final. O controle de
qualidade muda para cada situação. Conferência da fonte reduz o primeiro; ensaios com casos
difíceis reduzem o segundo; treinamento, interface clara e responsabilidade definida reduzem o
terceiro. Essa decomposição vale mais do que afirmar genericamente que o sistema “tem
precisão”.
O FUTURO DA PROGRAMAÇÃO COM IA
39 • EDIÇÃO DIGITAL 2026
CASO COMENTADO
Considere esta situação hipotética: Um fluxo automatizado exige revisão de permissões e
exceções. A equipe não começa pela ferramenta. Primeiro, define o resultado aceitável e reúne
exemplos de rotina, exceções e situações em que não há dados suficientes. Em seguida, alguém
executa o fluxo atual para formar uma referência de comparação. Só então a nova abordagem é
aplicada aos mesmos casos, com registro do que mudou e do que permaneceu igual. O objetivo
não é fabricar uma vitória da tecnologia: é identificar quais partes do trabalho foram realmente
aprimoradas.
Imagine agora que surge criar automação invisível sem proprietário.. O problema não deve ser
resolvido ocultando o caso ruim da amostra. Registre o ocorrido, classifique a gravidade, preserve
as entradas necessárias para reproduzi-lo sem violar privacidade e defina quem pode corrigir ou
interromper o processo. Se houver impacto externo, a resposta precisa incluir comunicação ao
afetado e reparação proporcionada. Um piloto que aprende com esse episódio tem mais valor do
que uma implantação que só apresenta exemplos bem-sucedidos.
No fechamento do caso, compare duas perguntas diferentes: “o sistema concluiu a tarefa?” e “o
usuário obteve o resultado certo com esforço aceitável?”. Uma resposta pode ser tecnicamente
válida e ainda gerar retrabalho, insegurança ou falta de confiança. Observe o correção e
facilidade de manutenção; registre custos que surgiram fora da equipe central; e evite inferir
qualidade apenas pela satisfação imediata. Usuários podem gostar de uma resposta rápida sem
perceber uma omissão, enquanto profissionais experientes podem notar uma falha crítica em
poucos segundos.
MÉTODO DE IMPLANTAÇÃO
A primeira etapa é delimitar o escopo em uma página: público, objetivo, dados permitidos,
condições para recusar uma resposta, responsável e forma de reversão. A segunda é montar um
conjunto pequeno, porém heterogêneo, de casos: típicos, extremos, incompletos e
deliberadamente adversariais. A terceira é testar sem alterar o padrão de avaliação entre
alternativas. Nesta etapa, a ação recomendada é: versionar, registrar dono e revisar acesso. Ela
deve ser executadade modo observável, com data, versão e pessoa responsável.
A quarta etapa é tornar explícito o custo total. Some tempo de preparação, esforço de revisão,
treinamento, licença, infraestrutura, falhas e manutenção. Uma economia em minutos por
mudança de software não se converte automaticamente em economia organizacional: talvez a
equipe precise corrigir dados, acolher reclamações ou reconstruir confiança. A quinta etapa é
instituir revisão regular. À medida que documentos, usuários, processos e tecnologia mudam, o
resultado anterior deixa de representar a situação presente. Guarde uma amostra fixa para
comparação entre versões e complemente-a com ocorrências novas da operação.
A sexta etapa consiste em distribuir autoridade: quem pode alterar regras, quem aprova
exceções, quem acessa informações e quem determina a suspensão. Não basta declarar que há
“humano no circuito” se essa pessoa não tem tempo, informação ou poder para discordar. A
revisão humana precisa de critérios, exemplos de erro e canal para registrar divergências.
Quando essas condições estão presentes, a tecnologia pode reduzir trabalho mecânico sem
transferir silenciosamente a responsabilidade a quem recebe a saída.
O FUTURO DA PROGRAMAÇÃO COM IA
40 • EDIÇÃO DIGITAL 2026
MEDIDAS QUE IMPORTAM
Use como indicador principal falhas de fluxo e mudanças não documentadas.. Não o leia
isoladamente. Separe os resultados por tipo de caso, contexto, grupo afetado e grau de
dificuldade; depois compare com a linha de base anterior. Se o indicador melhorar apenas em
situações simples, talvez o sistema tenha deslocado o trabalho difícil para pessoas menos visíveis.
Acrescente uma medida de segurança: quantidade de erros graves por amostra auditada.
Acrescente ainda uma medida de custo: esforço total por resultado validado, incluindo correção
posterior.
Defina o que conta como sucesso antes do teste. Uma meta que muda depois de observar os
resultados não permite comparação honesta. Analise também os casos de recusa: há situações
em que o melhor resultado é admitir dúvida, interromper a ação ou encaminhar a uma pessoa
competente. Registre falsos positivos e falsos negativos quando houver classificação; use
exemplos concretos para orientar a equipe, não apenas médias. Se a amostra for pequena, diga
explicitamente que o piloto sugere possibilidades e ainda não comprova desempenho estável.
DECISÕES DIFÍCEIS E CONTRAPONTOS
O erro mais tentador é código plausível sem teste. Ele se agrava quando criar automação invisível
sem proprietário.. A mitigação não é exigir perfeição abstrata, mas reduzir exposição: limitar
alcance, registrar decisões e estabelecer parada segura. Há também uma tensão entre
personalização e padronização. Personalizar pode ajudar a atender contextos diferentes, mas
dificulta reproduzir decisões e explicar tratamentos distintos. Padronizar facilita auditoria, mas
pode ignorar necessidades individuais. A escolha deve ser justificada em função da tarefa, não
pela capacidade da ferramenta.
Outro contraponto é a possibilidade de uma solução sem IA ser melhor. Um formulário claro, uma
lista de verificação, uma regra determinística, uma formação breve ou a correção da base de
dados podem resolver o problema por menos custo e com maior previsibilidade. Use a tecnologia
quando ela acrescentar capacidade demonstrável, não quando for a opção mais fácil de anunciar.
Para decidir, documente alternativa rejeitada, motivo, restrição de orçamento e condição que
faria a equipe rever a escolha.
OFICINA PARA O LEITOR
Exercício 1: descreva, em até seis linhas, uma situação própria relacionada a “programação
low-code e automação”. Identifique uma entrada verificável, uma saída útil e uma pessoa que
sofrerá as consequências de um erro. Exercício 2: elabore três casos normais, dois de borda e um
caso em que a resposta correta é “não sei”. Escreva antes do teste o que considerará resultado
aceitável. Exercício 3: aplique a orientação “versionar, registrar dono e revisar acesso.” e registre
o que mudou no processo, não apenas na interface.
Exercício 4: desenhe uma tabela com cinco colunas — caso, resultado esperado, resultado
observado, gravidade e ação corretiva. Preencha a tabela com exemplos reais autorizados ou
fictícios, claramente sinalizados como tal. Exercício 5: apresente a um colega a principal limitação
encontrada, sem defender previamente a ferramenta. Peça que ele formule uma explicação
alternativa para o ganho observado. Esse confronto melhora a avaliação e previne o entusiasmo
seletivo. Ao final, pergunte se o código versionado com testes produzido poderia ser
compreendido e contestado por alguém que não participou do projeto.
O FUTURO DA PROGRAMAÇÃO COM IA
41 • EDIÇÃO DIGITAL 2026
CAPÍTULO 14 — CARREIRA DO PROGRAMADOR
IDEIA CENTRAL
O ponto de partida deste capítulo é uma escolha de desenho, não uma corrida por novidade:
fundamentos permitem avaliar ferramentas que inevitavelmente mudarão. Para transformar a
ideia em trabalho confiável, explicite quem solicita, quem executa, de onde vêm os dados,
quando o processo termina e quem pode contestar uma falha. Esse percurso revela custos e
limitações que uma demonstração isolada não mostra.
COMO O PROCESSO FUNCIONA
Comece pela unidade de análise: cada mudança de software tem entrada, transformação, saída e
consequência. No caso de “carreira do programador”, a entrada pode estar incompleta,
contraditória ou fora do padrão; por isso, o equipe de desenvolvimento precisa verificar condições
de uso antes de produzir o código versionado com testes. Uma maneira útil de representar o
processo é desenhar quatro caixas: origem da informação, critérios aplicados, resultado entregue
e verificação posterior. Descreva também o que não deve ser decidido pelo sistema. A fronteira
operacional aqui é revisão, testes e segurança antes de publicar. Sem essa fronteira, o fluxo pode
aparentar eficiência enquanto transfere risco para usuários e equipes de suporte.
Faça a distinção entre três tipos de problema. O primeiro é erro de entrada: os dados não
correspondem à situação real. O segundo é erro de método: mesmo com dados corretos, as
regras ou o modelo não tratam adequadamente a exceção. O terceiro é erro de uso: a saída é
apropriada como sugestão, mas alguém a interpreta como aprovação final. O controle de
qualidade muda para cada situação. Conferência da fonte reduz o primeiro; ensaios com casos
difíceis reduzem o segundo; treinamento, interface clara e responsabilidade definida reduzem o
terceiro. Essa decomposição vale mais do que afirmar genericamente que o sistema “tem
precisão”.
O FUTURO DA PROGRAMAÇÃO COM IA
42 • EDIÇÃO DIGITAL 2026
CASO COMENTADO
Considere esta situação hipotética: Uma pessoa entende transações, tipos e testes e usa IA com
mais autonomia. A equipe não começa pela ferramenta. Primeiro, define o resultado aceitável e
reúne exemplos de rotina, exceções e situações em que não há dados suficientes. Em seguida,
alguém executa o fluxo atual para formar uma referência de comparação. Só então a nova
abordagem é aplicada aos mesmos casos, com registro do que mudou e do que permaneceu
igual. O objetivo não é fabricar uma vitória da tecnologia: é identificar quais partes do trabalho
foram realmente aprimoradas.
Imagine agora que surge competir com modelo em digitação em vez de resolver problemas.. O
problema não deve ser resolvido ocultando o caso ruim da amostra. Registre o ocorrido,
classifique a gravidade, preserve as entradas necessárias para reproduzi-lo sem violar privacidade
e defina quem pode corrigir ou interromper o processo. Se houver impacto externo, a resposta
precisa incluir comunicação ao afetado e reparação proporcionada. Um piloto que aprende com
esse episódio tem mais valor do que uma implantação que só apresenta exemplos
bem-sucedidos.
No fechamento do caso, compare duas perguntas diferentes: “o sistema concluiu a tarefa?” e “o
usuário obteve o resultado certo com esforço aceitável?”. Uma resposta pode ser tecnicamente
válida e ainda gerar retrabalho, insegurançaou falta de confiança. Observe o correção e
facilidade de manutenção; registre custos que surgiram fora da equipe central; e evite inferir
qualidade apenas pela satisfação imediata. Usuários podem gostar de uma resposta rápida sem
perceber uma omissão, enquanto profissionais experientes podem notar uma falha crítica em
poucos segundos.
MÉTODO DE IMPLANTAÇÃO
A primeira etapa é delimitar o escopo em uma página: público, objetivo, dados permitidos,
condições para recusar uma resposta, responsável e forma de reversão. A segunda é montar um
conjunto pequeno, porém heterogêneo, de casos: típicos, extremos, incompletos e
deliberadamente adversariais. A terceira é testar sem alterar o padrão de avaliação entre
alternativas. Nesta etapa, a ação recomendada é: aprender domínio, sistemas e comunicação. Ela
deve ser executada de modo observável, com data, versão e pessoa responsável.
A quarta etapa é tornar explícito o custo total. Some tempo de preparação, esforço de revisão,
treinamento, licença, infraestrutura, falhas e manutenção. Uma economia em minutos por
mudança de software não se converte automaticamente em economia organizacional: talvez a
equipe precise corrigir dados, acolher reclamações ou reconstruir confiança. A quinta etapa é
instituir revisão regular. À medida que documentos, usuários, processos e tecnologia mudam, o
resultado anterior deixa de representar a situação presente. Guarde uma amostra fixa para
comparação entre versões e complemente-a com ocorrências novas da operação.
A sexta etapa consiste em distribuir autoridade: quem pode alterar regras, quem aprova
exceções, quem acessa informações e quem determina a suspensão. Não basta declarar que há
“humano no circuito” se essa pessoa não tem tempo, informação ou poder para discordar. A
revisão humana precisa de critérios, exemplos de erro e canal para registrar divergências.
Quando essas condições estão presentes, a tecnologia pode reduzir trabalho mecânico sem
transferir silenciosamente a responsabilidade a quem recebe a saída.
O FUTURO DA PROGRAMAÇÃO COM IA
43 • EDIÇÃO DIGITAL 2026
MEDIDAS QUE IMPORTAM
Use como indicador principal qualidade, impacto e capacidade de explicar decisões.. Não o leia
isoladamente. Separe os resultados por tipo de caso, contexto, grupo afetado e grau de
dificuldade; depois compare com a linha de base anterior. Se o indicador melhorar apenas em
situações simples, talvez o sistema tenha deslocado o trabalho difícil para pessoas menos visíveis.
Acrescente uma medida de segurança: quantidade de erros graves por amostra auditada.
Acrescente ainda uma medida de custo: esforço total por resultado validado, incluindo correção
posterior.
Defina o que conta como sucesso antes do teste. Uma meta que muda depois de observar os
resultados não permite comparação honesta. Analise também os casos de recusa: há situações
em que o melhor resultado é admitir dúvida, interromper a ação ou encaminhar a uma pessoa
competente. Registre falsos positivos e falsos negativos quando houver classificação; use
exemplos concretos para orientar a equipe, não apenas médias. Se a amostra for pequena, diga
explicitamente que o piloto sugere possibilidades e ainda não comprova desempenho estável.
DECISÕES DIFÍCEIS E CONTRAPONTOS
O erro mais tentador é código plausível sem teste. Ele se agrava quando competir com modelo
em digitação em vez de resolver problemas.. A mitigação não é exigir perfeição abstrata, mas
reduzir exposição: limitar alcance, registrar decisões e estabelecer parada segura. Há também
uma tensão entre personalização e padronização. Personalizar pode ajudar a atender contextos
diferentes, mas dificulta reproduzir decisões e explicar tratamentos distintos. Padronizar facilita
auditoria, mas pode ignorar necessidades individuais. A escolha deve ser justificada em função da
tarefa, não pela capacidade da ferramenta.
Outro contraponto é a possibilidade de uma solução sem IA ser melhor. Um formulário claro, uma
lista de verificação, uma regra determinística, uma formação breve ou a correção da base de
dados podem resolver o problema por menos custo e com maior previsibilidade. Use a tecnologia
quando ela acrescentar capacidade demonstrável, não quando for a opção mais fácil de anunciar.
Para decidir, documente alternativa rejeitada, motivo, restrição de orçamento e condição que
faria a equipe rever a escolha.
OFICINA PARA O LEITOR
Exercício 1: descreva, em até seis linhas, uma situação própria relacionada a “carreira do
programador”. Identifique uma entrada verificável, uma saída útil e uma pessoa que sofrerá as
consequências de um erro. Exercício 2: elabore três casos normais, dois de borda e um caso em
que a resposta correta é “não sei”. Escreva antes do teste o que considerará resultado aceitável.
Exercício 3: aplique a orientação “aprender domínio, sistemas e comunicação.” e registre o que
mudou no processo, não apenas na interface.
Exercício 4: desenhe uma tabela com cinco colunas — caso, resultado esperado, resultado
observado, gravidade e ação corretiva. Preencha a tabela com exemplos reais autorizados ou
fictícios, claramente sinalizados como tal. Exercício 5: apresente a um colega a principal limitação
encontrada, sem defender previamente a ferramenta. Peça que ele formule uma explicação
alternativa para o ganho observado. Esse confronto melhora a avaliação e previne o entusiasmo
seletivo. Ao final, pergunte se o código versionado com testes produzido poderia ser
compreendido e contestado por alguém que não participou do projeto.
O FUTURO DA PROGRAMAÇÃO COM IA
44 • EDIÇÃO DIGITAL 2026
CAPÍTULO 15 — UMA PRÁTICA SUSTENTÁVEL
IDEIA CENTRAL
Velocidade deve ser combinada com responsabilidade técnica e econômica. A consequência
prática é que uma solução só faz sentido se melhorar uma tarefa definida. Antes de discutir
fornecedores, imagine duas alternativas: continuar com o procedimento atual ou alterar apenas
uma etapa. A comparação obriga a observar qualidade, tempo e impacto sobre as pessoas, em
vez de presumir que toda automação representa progresso.
COMO O PROCESSO FUNCIONA
Comece pela unidade de análise: cada mudança de software tem entrada, transformação, saída e
consequência. No caso de “uma prática sustentável”, a entrada pode estar incompleta,
contraditória ou fora do padrão; por isso, o equipe de desenvolvimento precisa verificar condições
de uso antes de produzir o código versionado com testes. Uma maneira útil de representar o
processo é desenhar quatro caixas: origem da informação, critérios aplicados, resultado entregue
e verificação posterior. Descreva também o que não deve ser decidido pelo sistema. A fronteira
operacional aqui é revisão, testes e segurança antes de publicar. Sem essa fronteira, o fluxo pode
aparentar eficiência enquanto transfere risco para usuários e equipes de suporte.
Faça a distinção entre três tipos de problema. O primeiro é erro de entrada: os dados não
correspondem à situação real. O segundo é erro de método: mesmo com dados corretos, as
regras ou o modelo não tratam adequadamente a exceção. O terceiro é erro de uso: a saída é
apropriada como sugestão, mas alguém a interpreta como aprovação final. O controle de
qualidade muda para cada situação. Conferência da fonte reduz o primeiro; ensaios com casos
difíceis reduzem o segundo; treinamento, interface clara e responsabilidade definida reduzem o
terceiro. Essa decomposição vale mais do que afirmar genericamente que o sistema “tem
precisão”.
O FUTURO DA PROGRAMAÇÃO COM IA
45 • EDIÇÃO DIGITAL 2026
CASO COMENTADO
Considere esta situação hipotética: Uma equipe entrega menor escopo com testes e monitora
antes de ampliar. A equipe não começa pela ferramenta. Primeiro, define o resultado aceitável e
reúne exemplos de rotina, exceções e situações em que não há dados suficientes. Em seguida,
alguém executa o fluxo atual para formar uma referência de comparação. Só então a nova
abordagem é aplicada aos mesmos casos, com registro do que mudou e do que permaneceu
igual. O objetivo não é fabricar uma vitória da tecnologia:é identificar quais partes do trabalho
foram realmente aprimoradas.
Imagine agora que surge usar IA para aumentar volume de dívida técnica.. O problema não deve
ser resolvido ocultando o caso ruim da amostra. Registre o ocorrido, classifique a gravidade,
preserve as entradas necessárias para reproduzi-lo sem violar privacidade e defina quem pode
corrigir ou interromper o processo. Se houver impacto externo, a resposta precisa incluir
comunicação ao afetado e reparação proporcionada. Um piloto que aprende com esse episódio
tem mais valor do que uma implantação que só apresenta exemplos bem-sucedidos.
No fechamento do caso, compare duas perguntas diferentes: “o sistema concluiu a tarefa?” e “o
usuário obteve o resultado certo com esforço aceitável?”. Uma resposta pode ser tecnicamente
válida e ainda gerar retrabalho, insegurança ou falta de confiança. Observe o correção e
facilidade de manutenção; registre custos que surgiram fora da equipe central; e evite inferir
qualidade apenas pela satisfação imediata. Usuários podem gostar de uma resposta rápida sem
perceber uma omissão, enquanto profissionais experientes podem notar uma falha crítica em
poucos segundos.
MÉTODO DE IMPLANTAÇÃO
A primeira etapa é delimitar o escopo em uma página: público, objetivo, dados permitidos,
condições para recusar uma resposta, responsável e forma de reversão. A segunda é montar um
conjunto pequeno, porém heterogêneo, de casos: típicos, extremos, incompletos e
deliberadamente adversariais. A terceira é testar sem alterar o padrão de avaliação entre
alternativas. Nesta etapa, a ação recomendada é: priorizar clareza, reversibilidade e
aprendizagem. Ela deve ser executada de modo observável, com data, versão e pessoa
responsável.
A quarta etapa é tornar explícito o custo total. Some tempo de preparação, esforço de revisão,
treinamento, licença, infraestrutura, falhas e manutenção. Uma economia em minutos por
mudança de software não se converte automaticamente em economia organizacional: talvez a
equipe precise corrigir dados, acolher reclamações ou reconstruir confiança. A quinta etapa é
instituir revisão regular. À medida que documentos, usuários, processos e tecnologia mudam, o
resultado anterior deixa de representar a situação presente. Guarde uma amostra fixa para
comparação entre versões e complemente-a com ocorrências novas da operação.
A sexta etapa consiste em distribuir autoridade: quem pode alterar regras, quem aprova
exceções, quem acessa informações e quem determina a suspensão. Não basta declarar que há
“humano no circuito” se essa pessoa não tem tempo, informação ou poder para discordar. A
revisão humana precisa de critérios, exemplos de erro e canal para registrar divergências.
Quando essas condições estão presentes, a tecnologia pode reduzir trabalho mecânico sem
transferir silenciosamente a responsabilidade a quem recebe a saída.
O FUTURO DA PROGRAMAÇÃO COM IA
46 • EDIÇÃO DIGITAL 2026
MEDIDAS QUE IMPORTAM
Use como indicador principal custo de manutenção e frequência de incidentes.. Não o leia
isoladamente. Separe os resultados por tipo de caso, contexto, grupo afetado e grau de
dificuldade; depois compare com a linha de base anterior. Se o indicador melhorar apenas em
situações simples, talvez o sistema tenha deslocado o trabalho difícil para pessoas menos visíveis.
Acrescente uma medida de segurança: quantidade de erros graves por amostra auditada.
Acrescente ainda uma medida de custo: esforço total por resultado validado, incluindo correção
posterior.
Defina o que conta como sucesso antes do teste. Uma meta que muda depois de observar os
resultados não permite comparação honesta. Analise também os casos de recusa: há situações
em que o melhor resultado é admitir dúvida, interromper a ação ou encaminhar a uma pessoa
competente. Registre falsos positivos e falsos negativos quando houver classificação; use
exemplos concretos para orientar a equipe, não apenas médias. Se a amostra for pequena, diga
explicitamente que o piloto sugere possibilidades e ainda não comprova desempenho estável.
DECISÕES DIFÍCEIS E CONTRAPONTOS
O erro mais tentador é código plausível sem teste. Ele se agrava quando usar IA para aumentar
volume de dívida técnica.. A mitigação não é exigir perfeição abstrata, mas reduzir exposição:
limitar alcance, registrar decisões e estabelecer parada segura. Há também uma tensão entre
personalização e padronização. Personalizar pode ajudar a atender contextos diferentes, mas
dificulta reproduzir decisões e explicar tratamentos distintos. Padronizar facilita auditoria, mas
pode ignorar necessidades individuais. A escolha deve ser justificada em função da tarefa, não
pela capacidade da ferramenta.
Outro contraponto é a possibilidade de uma solução sem IA ser melhor. Um formulário claro, uma
lista de verificação, uma regra determinística, uma formação breve ou a correção da base de
dados podem resolver o problema por menos custo e com maior previsibilidade. Use a tecnologia
quando ela acrescentar capacidade demonstrável, não quando for a opção mais fácil de anunciar.
Para decidir, documente alternativa rejeitada, motivo, restrição de orçamento e condição que
faria a equipe rever a escolha.
OFICINA PARA O LEITOR
Exercício 1: descreva, em até seis linhas, uma situação própria relacionada a “uma prática
sustentável”. Identifique uma entrada verificável, uma saída útil e uma pessoa que sofrerá as
consequências de um erro. Exercício 2: elabore três casos normais, dois de borda e um caso em
que a resposta correta é “não sei”. Escreva antes do teste o que considerará resultado aceitável.
Exercício 3: aplique a orientação “priorizar clareza, reversibilidade e aprendizagem.” e registre o
que mudou no processo, não apenas na interface.
Exercício 4: desenhe uma tabela com cinco colunas — caso, resultado esperado, resultado
observado, gravidade e ação corretiva. Preencha a tabela com exemplos reais autorizados ou
fictícios, claramente sinalizados como tal. Exercício 5: apresente a um colega a principal limitação
encontrada, sem defender previamente a ferramenta. Peça que ele formule uma explicação
alternativa para o ganho observado. Esse confronto melhora a avaliação e previne o entusiasmo
seletivo. Ao final, pergunte se o código versionado com testes produzido poderia ser
compreendido e contestado por alguém que não participou do projeto.
O FUTURO DA PROGRAMAÇÃO COM IA
47 • EDIÇÃO DIGITAL 2026
REFERÊNCIAS, LIMITES E CONTINUIDADE
Referências e nota metodológica
Este e-book é educativo e não substitui avaliação profissional, jurídica, de segurança, regulatória ou técnica
específica. O texto combina análise conceitual e exemplos hipotéticos, concebidos para treinamento de
pensamento crítico e não como relato de casos reais. Dados e afirmações amplas sobre mercado de trabalho e
adoção de IA foram balizados por: International Labour Organization, Generative AI and Jobs: A Refined Global
Index of Occupational Exposure (2025); World Economic Forum, Future of Jobs Report 2025; Stanford HAI, AI
Index Report 2025; e GitHub Docs, materiais de uso responsável de assistentes de código. Consulte as versões
oficiais dessas publicações para números e atualizações.
Checklist final para projetos
Antes de adotar uma nova solução, confirme: problema definido; dados permitidos e confiáveis;
critérios de aceitação; casos de exceção; pessoa responsável; medida de qualidade;
procedimento de interrupção; revisão periódica; e documentação suficiente para que outra
pessoa compreenda as decisões. Um projeto só é robusto quando consegue explicar não apenas o
que faz, mas por que faz, para quem e com quais limites.use
exemplos concretos para orientar a equipe, não apenas médias. Se a amostra for pequena, diga
explicitamente que o piloto sugere possibilidades e ainda não comprova desempenho estável.
DECISÕES DIFÍCEIS E CONTRAPONTOS
O erro mais tentador é código plausível sem teste. Ele se agrava quando medir produtividade
apenas por linhas geradas.. A mitigação não é exigir perfeição abstrata, mas reduzir exposição:
limitar alcance, registrar decisões e estabelecer parada segura. Há também uma tensão entre
personalização e padronização. Personalizar pode ajudar a atender contextos diferentes, mas
dificulta reproduzir decisões e explicar tratamentos distintos. Padronizar facilita auditoria, mas
pode ignorar necessidades individuais. A escolha deve ser justificada em função da tarefa, não
pela capacidade da ferramenta.
Outro contraponto é a possibilidade de uma solução sem IA ser melhor. Um formulário claro, uma
lista de verificação, uma regra determinística, uma formação breve ou a correção da base de
dados podem resolver o problema por menos custo e com maior previsibilidade. Use a tecnologia
quando ela acrescentar capacidade demonstrável, não quando for a opção mais fácil de anunciar.
Para decidir, documente alternativa rejeitada, motivo, restrição de orçamento e condição que
faria a equipe rever a escolha.
OFICINA PARA O LEITOR
Exercício 1: descreva, em até seis linhas, uma situação própria relacionada a “código é apenas
uma parte do sistema”. Identifique uma entrada verificável, uma saída útil e uma pessoa que
sofrerá as consequências de um erro. Exercício 2: elabore três casos normais, dois de borda e um
caso em que a resposta correta é “não sei”. Escreva antes do teste o que considerará resultado
aceitável. Exercício 3: aplique a orientação “começar por contrato e cenário de uso.” e registre o
que mudou no processo, não apenas na interface.
Exercício 4: desenhe uma tabela com cinco colunas — caso, resultado esperado, resultado
observado, gravidade e ação corretiva. Preencha a tabela com exemplos reais autorizados ou
fictícios, claramente sinalizados como tal. Exercício 5: apresente a um colega a principal limitação
encontrada, sem defender previamente a ferramenta. Peça que ele formule uma explicação
alternativa para o ganho observado. Esse confronto melhora a avaliação e previne o entusiasmo
seletivo. Ao final, pergunte se o código versionado com testes produzido poderia ser
compreendido e contestado por alguém que não participou do projeto.
O FUTURO DA PROGRAMAÇÃO COM IA
05 • EDIÇÃO DIGITAL 2026
CAPÍTULO 02 — COMO ASSISTENTES GERAM
SUGESTÕES
IDEIA CENTRAL
O ponto de partida deste capítulo é uma escolha de desenho, não uma corrida por novidade:
modelos completam padrões; não possuem garantia de conhecer seu repositório ou versão. Para
transformar a ideia em trabalho confiável, explicite quem solicita, quem executa, de onde vêm os
dados, quando o processo termina e quem pode contestar uma falha. Esse percurso revela custos
e limitações que uma demonstração isolada não mostra.
COMO O PROCESSO FUNCIONA
Comece pela unidade de análise: cada mudança de software tem entrada, transformação, saída e
consequência. No caso de “como assistentes geram sugestões”, a entrada pode estar incompleta,
contraditória ou fora do padrão; por isso, o equipe de desenvolvimento precisa verificar condições
de uso antes de produzir o código versionado com testes. Uma maneira útil de representar o
processo é desenhar quatro caixas: origem da informação, critérios aplicados, resultado entregue
e verificação posterior. Descreva também o que não deve ser decidido pelo sistema. A fronteira
operacional aqui é revisão, testes e segurança antes de publicar. Sem essa fronteira, o fluxo pode
aparentar eficiência enquanto transfere risco para usuários e equipes de suporte.
Faça a distinção entre três tipos de problema. O primeiro é erro de entrada: os dados não
correspondem à situação real. O segundo é erro de método: mesmo com dados corretos, as
regras ou o modelo não tratam adequadamente a exceção. O terceiro é erro de uso: a saída é
apropriada como sugestão, mas alguém a interpreta como aprovação final. O controle de
qualidade muda para cada situação. Conferência da fonte reduz o primeiro; ensaios com casos
difíceis reduzem o segundo; treinamento, interface clara e responsabilidade definida reduzem o
terceiro. Essa decomposição vale mais do que afirmar genericamente que o sistema “tem
precisão”.
O FUTURO DA PROGRAMAÇÃO COM IA
06 • EDIÇÃO DIGITAL 2026
CASO COMENTADO
Considere esta situação hipotética: Uma sugestão usa método obsoleto que parece plausível. A
equipe não começa pela ferramenta. Primeiro, define o resultado aceitável e reúne exemplos de
rotina, exceções e situações em que não há dados suficientes. Em seguida, alguém executa o
fluxo atual para formar uma referência de comparação. Só então a nova abordagem é aplicada
aos mesmos casos, com registro do que mudou e do que permaneceu igual. O objetivo não é
fabricar uma vitória da tecnologia: é identificar quais partes do trabalho foram realmente
aprimoradas.
Imagine agora que surge tratar sintaxe correta como comportamento correto.. O problema não
deve ser resolvido ocultando o caso ruim da amostra. Registre o ocorrido, classifique a gravidade,
preserve as entradas necessárias para reproduzi-lo sem violar privacidade e defina quem pode
corrigir ou interromper o processo. Se houver impacto externo, a resposta precisa incluir
comunicação ao afetado e reparação proporcionada. Um piloto que aprende com esse episódio
tem mais valor do que uma implantação que só apresenta exemplos bem-sucedidos.
No fechamento do caso, compare duas perguntas diferentes: “o sistema concluiu a tarefa?” e “o
usuário obteve o resultado certo com esforço aceitável?”. Uma resposta pode ser tecnicamente
válida e ainda gerar retrabalho, insegurança ou falta de confiança. Observe o correção e
facilidade de manutenção; registre custos que surgiram fora da equipe central; e evite inferir
qualidade apenas pela satisfação imediata. Usuários podem gostar de uma resposta rápida sem
perceber uma omissão, enquanto profissionais experientes podem notar uma falha crítica em
poucos segundos.
MÉTODO DE IMPLANTAÇÃO
A primeira etapa é delimitar o escopo em uma página: público, objetivo, dados permitidos,
condições para recusar uma resposta, responsável e forma de reversão. A segunda é montar um
conjunto pequeno, porém heterogêneo, de casos: típicos, extremos, incompletos e
deliberadamente adversariais. A terceira é testar sem alterar o padrão de avaliação entre
alternativas. Nesta etapa, a ação recomendada é: fornecer contexto mínimo e consultar
documentação oficial. Ela deve ser executada de modo observável, com data, versão e pessoa
responsável.
A quarta etapa é tornar explícito o custo total. Some tempo de preparação, esforço de revisão,
treinamento, licença, infraestrutura, falhas e manutenção. Uma economia em minutos por
mudança de software não se converte automaticamente em economia organizacional: talvez a
equipe precise corrigir dados, acolher reclamações ou reconstruir confiança. A quinta etapa é
instituir revisão regular. À medida que documentos, usuários, processos e tecnologia mudam, o
resultado anterior deixa de representar a situação presente. Guarde uma amostra fixa para
comparação entre versões e complemente-a com ocorrências novas da operação.
A sexta etapa consiste em distribuir autoridade: quem pode alterar regras, quem aprova
exceções, quem acessa informações e quem determina a suspensão. Não basta declarar que há
“humano no circuito” se essa pessoa não tem tempo, informação ou poder para discordar. A
revisão humana precisa de critérios, exemplos de erro e canal para registrar divergências.
Quando essas condições estão presentes, a tecnologia pode reduzir trabalho mecânico sem
transferir silenciosamente a responsabilidade a quem recebe a saída.
O FUTURO DA PROGRAMAÇÃO COM IA
07 • EDIÇÃO DIGITAL 2026
MEDIDAS QUE IMPORTAM
Use como indicador principal erros de compilação, testese revisão.. Não o leia isoladamente.
Separe os resultados por tipo de caso, contexto, grupo afetado e grau de dificuldade; depois
compare com a linha de base anterior. Se o indicador melhorar apenas em situações simples,
talvez o sistema tenha deslocado o trabalho difícil para pessoas menos visíveis. Acrescente uma
medida de segurança: quantidade de erros graves por amostra auditada. Acrescente ainda uma
medida de custo: esforço total por resultado validado, incluindo correção posterior.
Defina o que conta como sucesso antes do teste. Uma meta que muda depois de observar os
resultados não permite comparação honesta. Analise também os casos de recusa: há situações
em que o melhor resultado é admitir dúvida, interromper a ação ou encaminhar a uma pessoa
competente. Registre falsos positivos e falsos negativos quando houver classificação; use
exemplos concretos para orientar a equipe, não apenas médias. Se a amostra for pequena, diga
explicitamente que o piloto sugere possibilidades e ainda não comprova desempenho estável.
DECISÕES DIFÍCEIS E CONTRAPONTOS
O erro mais tentador é código plausível sem teste. Ele se agrava quando tratar sintaxe correta
como comportamento correto.. A mitigação não é exigir perfeição abstrata, mas reduzir
exposição: limitar alcance, registrar decisões e estabelecer parada segura. Há também uma
tensão entre personalização e padronização. Personalizar pode ajudar a atender contextos
diferentes, mas dificulta reproduzir decisões e explicar tratamentos distintos. Padronizar facilita
auditoria, mas pode ignorar necessidades individuais. A escolha deve ser justificada em função da
tarefa, não pela capacidade da ferramenta.
Outro contraponto é a possibilidade de uma solução sem IA ser melhor. Um formulário claro, uma
lista de verificação, uma regra determinística, uma formação breve ou a correção da base de
dados podem resolver o problema por menos custo e com maior previsibilidade. Use a tecnologia
quando ela acrescentar capacidade demonstrável, não quando for a opção mais fácil de anunciar.
Para decidir, documente alternativa rejeitada, motivo, restrição de orçamento e condição que
faria a equipe rever a escolha.
OFICINA PARA O LEITOR
Exercício 1: descreva, em até seis linhas, uma situação própria relacionada a “como assistentes
geram sugestões”. Identifique uma entrada verificável, uma saída útil e uma pessoa que sofrerá
as consequências de um erro. Exercício 2: elabore três casos normais, dois de borda e um caso
em que a resposta correta é “não sei”. Escreva antes do teste o que considerará resultado
aceitável. Exercício 3: aplique a orientação “fornecer contexto mínimo e consultar documentação
oficial.” e registre o que mudou no processo, não apenas na interface.
Exercício 4: desenhe uma tabela com cinco colunas — caso, resultado esperado, resultado
observado, gravidade e ação corretiva. Preencha a tabela com exemplos reais autorizados ou
fictícios, claramente sinalizados como tal. Exercício 5: apresente a um colega a principal limitação
encontrada, sem defender previamente a ferramenta. Peça que ele formule uma explicação
alternativa para o ganho observado. Esse confronto melhora a avaliação e previne o entusiasmo
seletivo. Ao final, pergunte se o código versionado com testes produzido poderia ser
compreendido e contestado por alguém que não participou do projeto.
O FUTURO DA PROGRAMAÇÃO COM IA
08 • EDIÇÃO DIGITAL 2026
CAPÍTULO 03 — ESPECIFICAÇÃO ANTES DA
GERAÇÃO
IDEIA CENTRAL
Uma boa instrução descreve entradas, saída, limites e critérios de aceitação. A consequência
prática é que uma solução só faz sentido se melhorar uma tarefa definida. Antes de discutir
fornecedores, imagine duas alternativas: continuar com o procedimento atual ou alterar apenas
uma etapa. A comparação obriga a observar qualidade, tempo e impacto sobre as pessoas, em
vez de presumir que toda automação representa progresso.
COMO O PROCESSO FUNCIONA
Comece pela unidade de análise: cada mudança de software tem entrada, transformação, saída e
consequência. No caso de “especificação antes da geração”, a entrada pode estar incompleta,
contraditória ou fora do padrão; por isso, o equipe de desenvolvimento precisa verificar condições
de uso antes de produzir o código versionado com testes. Uma maneira útil de representar o
processo é desenhar quatro caixas: origem da informação, critérios aplicados, resultado entregue
e verificação posterior. Descreva também o que não deve ser decidido pelo sistema. A fronteira
operacional aqui é revisão, testes e segurança antes de publicar. Sem essa fronteira, o fluxo pode
aparentar eficiência enquanto transfere risco para usuários e equipes de suporte.
Faça a distinção entre três tipos de problema. O primeiro é erro de entrada: os dados não
correspondem à situação real. O segundo é erro de método: mesmo com dados corretos, as
regras ou o modelo não tratam adequadamente a exceção. O terceiro é erro de uso: a saída é
apropriada como sugestão, mas alguém a interpreta como aprovação final. O controle de
qualidade muda para cada situação. Conferência da fonte reduz o primeiro; ensaios com casos
difíceis reduzem o segundo; treinamento, interface clara e responsabilidade definida reduzem o
terceiro. Essa decomposição vale mais do que afirmar genericamente que o sistema “tem
precisão”.
O FUTURO DA PROGRAMAÇÃO COM IA
09 • EDIÇÃO DIGITAL 2026
CASO COMENTADO
Considere esta situação hipotética: Uma função recebe unidades explícitas e retorna relatório
padronizado. A equipe não começa pela ferramenta. Primeiro, define o resultado aceitável e reúne
exemplos de rotina, exceções e situações em que não há dados suficientes. Em seguida, alguém
executa o fluxo atual para formar uma referência de comparação. Só então a nova abordagem é
aplicada aos mesmos casos, com registro do que mudou e do que permaneceu igual. O objetivo
não é fabricar uma vitória da tecnologia: é identificar quais partes do trabalho foram realmente
aprimoradas.
Imagine agora que surge pedir “faça tudo” e aceitar arquitetura invisível.. O problema não deve
ser resolvido ocultando o caso ruim da amostra. Registre o ocorrido, classifique a gravidade,
preserve as entradas necessárias para reproduzi-lo sem violar privacidade e defina quem pode
corrigir ou interromper o processo. Se houver impacto externo, a resposta precisa incluir
comunicação ao afetado e reparação proporcionada. Um piloto que aprende com esse episódio
tem mais valor do que uma implantação que só apresenta exemplos bem-sucedidos.
No fechamento do caso, compare duas perguntas diferentes: “o sistema concluiu a tarefa?” e “o
usuário obteve o resultado certo com esforço aceitável?”. Uma resposta pode ser tecnicamente
válida e ainda gerar retrabalho, insegurança ou falta de confiança. Observe o correção e
facilidade de manutenção; registre custos que surgiram fora da equipe central; e evite inferir
qualidade apenas pela satisfação imediata. Usuários podem gostar de uma resposta rápida sem
perceber uma omissão, enquanto profissionais experientes podem notar uma falha crítica em
poucos segundos.
MÉTODO DE IMPLANTAÇÃO
A primeira etapa é delimitar o escopo em uma página: público, objetivo, dados permitidos,
condições para recusar uma resposta, responsável e forma de reversão. A segunda é montar um
conjunto pequeno, porém heterogêneo, de casos: típicos, extremos, incompletos e
deliberadamente adversariais. A terceira é testar sem alterar o padrão de avaliação entre
alternativas. Nesta etapa, a ação recomendada é: escrever exemplos positivos, negativos e de
borda. Ela deve ser executada de modo observável, com data, versão e pessoa responsável.
A quarta etapa é tornar explícito o custo total. Some tempo de preparação, esforço de revisão,
treinamento, licença, infraestrutura, falhas e manutenção. Uma economia em minutos por
mudança de software não se converte automaticamente em economia organizacional: talvez a
equipe precise corrigir dados, acolher reclamações ou reconstruir confiança. A quinta etapa é
instituir revisão regular. À medida quedocumentos, usuários, processos e tecnologia mudam, o
resultado anterior deixa de representar a situação presente. Guarde uma amostra fixa para
comparação entre versões e complemente-a com ocorrências novas da operação.
A sexta etapa consiste em distribuir autoridade: quem pode alterar regras, quem aprova
exceções, quem acessa informações e quem determina a suspensão. Não basta declarar que há
“humano no circuito” se essa pessoa não tem tempo, informação ou poder para discordar. A
revisão humana precisa de critérios, exemplos de erro e canal para registrar divergências.
Quando essas condições estão presentes, a tecnologia pode reduzir trabalho mecânico sem
transferir silenciosamente a responsabilidade a quem recebe a saída.
O FUTURO DA PROGRAMAÇÃO COM IA
10 • EDIÇÃO DIGITAL 2026
MEDIDAS QUE IMPORTAM
Use como indicador principal casos de aceite cobertos por teste.. Não o leia isoladamente. Separe
os resultados por tipo de caso, contexto, grupo afetado e grau de dificuldade; depois compare
com a linha de base anterior. Se o indicador melhorar apenas em situações simples, talvez o
sistema tenha deslocado o trabalho difícil para pessoas menos visíveis. Acrescente uma medida
de segurança: quantidade de erros graves por amostra auditada. Acrescente ainda uma medida
de custo: esforço total por resultado validado, incluindo correção posterior.
Defina o que conta como sucesso antes do teste. Uma meta que muda depois de observar os
resultados não permite comparação honesta. Analise também os casos de recusa: há situações
em que o melhor resultado é admitir dúvida, interromper a ação ou encaminhar a uma pessoa
competente. Registre falsos positivos e falsos negativos quando houver classificação; use
exemplos concretos para orientar a equipe, não apenas médias. Se a amostra for pequena, diga
explicitamente que o piloto sugere possibilidades e ainda não comprova desempenho estável.
DECISÕES DIFÍCEIS E CONTRAPONTOS
O erro mais tentador é código plausível sem teste. Ele se agrava quando pedir “faça tudo” e
aceitar arquitetura invisível.. A mitigação não é exigir perfeição abstrata, mas reduzir exposição:
limitar alcance, registrar decisões e estabelecer parada segura. Há também uma tensão entre
personalização e padronização. Personalizar pode ajudar a atender contextos diferentes, mas
dificulta reproduzir decisões e explicar tratamentos distintos. Padronizar facilita auditoria, mas
pode ignorar necessidades individuais. A escolha deve ser justificada em função da tarefa, não
pela capacidade da ferramenta.
Outro contraponto é a possibilidade de uma solução sem IA ser melhor. Um formulário claro, uma
lista de verificação, uma regra determinística, uma formação breve ou a correção da base de
dados podem resolver o problema por menos custo e com maior previsibilidade. Use a tecnologia
quando ela acrescentar capacidade demonstrável, não quando for a opção mais fácil de anunciar.
Para decidir, documente alternativa rejeitada, motivo, restrição de orçamento e condição que
faria a equipe rever a escolha.
OFICINA PARA O LEITOR
Exercício 1: descreva, em até seis linhas, uma situação própria relacionada a “especificação antes
da geração”. Identifique uma entrada verificável, uma saída útil e uma pessoa que sofrerá as
consequências de um erro. Exercício 2: elabore três casos normais, dois de borda e um caso em
que a resposta correta é “não sei”. Escreva antes do teste o que considerará resultado aceitável.
Exercício 3: aplique a orientação “escrever exemplos positivos, negativos e de borda.” e registre o
que mudou no processo, não apenas na interface.
Exercício 4: desenhe uma tabela com cinco colunas — caso, resultado esperado, resultado
observado, gravidade e ação corretiva. Preencha a tabela com exemplos reais autorizados ou
fictícios, claramente sinalizados como tal. Exercício 5: apresente a um colega a principal limitação
encontrada, sem defender previamente a ferramenta. Peça que ele formule uma explicação
alternativa para o ganho observado. Esse confronto melhora a avaliação e previne o entusiasmo
seletivo. Ao final, pergunte se o código versionado com testes produzido poderia ser
compreendido e contestado por alguém que não participou do projeto.
O FUTURO DA PROGRAMAÇÃO COM IA
11 • EDIÇÃO DIGITAL 2026
CAPÍTULO 04 — ARQUITETURA E FRONTEIRAS
IDEIA CENTRAL
Separar domínio, infraestrutura e interface facilita trocar componentes e testar lógica. Essa
afirmação parece simples até que a decisão chega ao contexto de uma equipe, a um orçamento e
a pessoas que dependerão do resultado. É necessário separar mecanismo, finalidade e limites: o
que a tecnologia consegue fazer sob condições controladas não equivale ao que deve fazer em
uma operação real. O capítulo trabalha com uma situação específica, observa seus pontos de
falha e propõe um modo de avaliar resultados sem esconder incertezas.
COMO O PROCESSO FUNCIONA
Comece pela unidade de análise: cada mudança de software tem entrada, transformação, saída e
consequência. No caso de “arquitetura e fronteiras”, a entrada pode estar incompleta,
contraditória ou fora do padrão; por isso, o equipe de desenvolvimento precisa verificar condições
de uso antes de produzir o código versionado com testes. Uma maneira útil de representar o
processo é desenhar quatro caixas: origem da informação, critérios aplicados, resultado entregue
e verificação posterior. Descreva também o que não deve ser decidido pelo sistema. A fronteira
operacional aqui é revisão, testes e segurança antes de publicar. Sem essa fronteira, o fluxo pode
aparentar eficiência enquanto transfere risco para usuários e equipes de suporte.
Faça a distinção entre três tipos de problema. O primeiro é erro de entrada: os dados não
correspondem à situação real. O segundo é erro de método: mesmo com dados corretos, as
regras ou o modelo não tratam adequadamente a exceção. O terceiro é erro de uso: a saída é
apropriada como sugestão, mas alguém a interpreta como aprovação final. O controle de
qualidade muda para cada situação. Conferência da fonte reduz o primeiro; ensaios com casos
difíceis reduzem o segundo; treinamento, interface clara e responsabilidade definida reduzem o
terceiro. Essa decomposição vale mais do que afirmar genericamente que o sistema “tem
precisão”.
O FUTURO DA PROGRAMAÇÃO COM IA
12 • EDIÇÃO DIGITAL 2026
CASO COMENTADO
Considere esta situação hipotética: Um serviço de validação não depende diretamente da janela
gráfica. A equipe não começa pela ferramenta. Primeiro, define o resultado aceitável e reúne
exemplos de rotina, exceções e situações em que não há dados suficientes. Em seguida, alguém
executa o fluxo atual para formar uma referência de comparação. Só então a nova abordagem é
aplicada aos mesmos casos, com registro do que mudou e do que permaneceu igual. O objetivo
não é fabricar uma vitória da tecnologia: é identificar quais partes do trabalho foram realmente
aprimoradas.
Imagine agora que surge acoplar regra de negócio a fornecedor de IA.. O problema não deve ser
resolvido ocultando o caso ruim da amostra. Registre o ocorrido, classifique a gravidade, preserve
as entradas necessárias para reproduzi-lo sem violar privacidade e defina quem pode corrigir ou
interromper o processo. Se houver impacto externo, a resposta precisa incluir comunicação ao
afetado e reparação proporcionada. Um piloto que aprende com esse episódio tem mais valor do
que uma implantação que só apresenta exemplos bem-sucedidos.
No fechamento do caso, compare duas perguntas diferentes: “o sistema concluiu a tarefa?” e “o
usuário obteve o resultado certo com esforço aceitável?”. Uma resposta pode ser tecnicamente
válida e ainda gerar retrabalho, insegurança ou falta de confiança. Observe o correção e
facilidade de manutenção; registre custos que surgiram fora da equipe central; e evite inferir
qualidade apenas pela satisfação imediata. Usuários podem gostar de uma resposta rápida sem
perceber uma omissão, enquanto profissionais experientes podem notar uma falha crítica em
poucos segundos.
MÉTODO DE IMPLANTAÇÃOA primeira etapa é delimitar o escopo em uma página: público, objetivo, dados permitidos,
condições para recusar uma resposta, responsável e forma de reversão. A segunda é montar um
conjunto pequeno, porém heterogêneo, de casos: típicos, extremos, incompletos e
deliberadamente adversariais. A terceira é testar sem alterar o padrão de avaliação entre
alternativas. Nesta etapa, a ação recomendada é: definir interfaces e injetar implementações. Ela
deve ser executada de modo observável, com data, versão e pessoa responsável.
A quarta etapa é tornar explícito o custo total. Some tempo de preparação, esforço de revisão,
treinamento, licença, infraestrutura, falhas e manutenção. Uma economia em minutos por
mudança de software não se converte automaticamente em economia organizacional: talvez a
equipe precise corrigir dados, acolher reclamações ou reconstruir confiança. A quinta etapa é
instituir revisão regular. À medida que documentos, usuários, processos e tecnologia mudam, o
resultado anterior deixa de representar a situação presente. Guarde uma amostra fixa para
comparação entre versões e complemente-a com ocorrências novas da operação.
A sexta etapa consiste em distribuir autoridade: quem pode alterar regras, quem aprova
exceções, quem acessa informações e quem determina a suspensão. Não basta declarar que há
“humano no circuito” se essa pessoa não tem tempo, informação ou poder para discordar. A
revisão humana precisa de critérios, exemplos de erro e canal para registrar divergências.
Quando essas condições estão presentes, a tecnologia pode reduzir trabalho mecânico sem
transferir silenciosamente a responsabilidade a quem recebe a saída.
O FUTURO DA PROGRAMAÇÃO COM IA
13 • EDIÇÃO DIGITAL 2026
MEDIDAS QUE IMPORTAM
Use como indicador principal tempo para testar e mudar dependência.. Não o leia isoladamente.
Separe os resultados por tipo de caso, contexto, grupo afetado e grau de dificuldade; depois
compare com a linha de base anterior. Se o indicador melhorar apenas em situações simples,
talvez o sistema tenha deslocado o trabalho difícil para pessoas menos visíveis. Acrescente uma
medida de segurança: quantidade de erros graves por amostra auditada. Acrescente ainda uma
medida de custo: esforço total por resultado validado, incluindo correção posterior.
Defina o que conta como sucesso antes do teste. Uma meta que muda depois de observar os
resultados não permite comparação honesta. Analise também os casos de recusa: há situações
em que o melhor resultado é admitir dúvida, interromper a ação ou encaminhar a uma pessoa
competente. Registre falsos positivos e falsos negativos quando houver classificação; use
exemplos concretos para orientar a equipe, não apenas médias. Se a amostra for pequena, diga
explicitamente que o piloto sugere possibilidades e ainda não comprova desempenho estável.
DECISÕES DIFÍCEIS E CONTRAPONTOS
O erro mais tentador é código plausível sem teste. Ele se agrava quando acoplar regra de negócio
a fornecedor de IA.. A mitigação não é exigir perfeição abstrata, mas reduzir exposição: limitar
alcance, registrar decisões e estabelecer parada segura. Há também uma tensão entre
personalização e padronização. Personalizar pode ajudar a atender contextos diferentes, mas
dificulta reproduzir decisões e explicar tratamentos distintos. Padronizar facilita auditoria, mas
pode ignorar necessidades individuais. A escolha deve ser justificada em função da tarefa, não
pela capacidade da ferramenta.
Outro contraponto é a possibilidade de uma solução sem IA ser melhor. Um formulário claro, uma
lista de verificação, uma regra determinística, uma formação breve ou a correção da base de
dados podem resolver o problema por menos custo e com maior previsibilidade. Use a tecnologia
quando ela acrescentar capacidade demonstrável, não quando for a opção mais fácil de anunciar.
Para decidir, documente alternativa rejeitada, motivo, restrição de orçamento e condição que
faria a equipe rever a escolha.
OFICINA PARA O LEITOR
Exercício 1: descreva, em até seis linhas, uma situação própria relacionada a “arquitetura e
fronteiras”. Identifique uma entrada verificável, uma saída útil e uma pessoa que sofrerá as
consequências de um erro. Exercício 2: elabore três casos normais, dois de borda e um caso em
que a resposta correta é “não sei”. Escreva antes do teste o que considerará resultado aceitável.
Exercício 3: aplique a orientação “definir interfaces e injetar implementações.” e registre o que
mudou no processo, não apenas na interface.
Exercício 4: desenhe uma tabela com cinco colunas — caso, resultado esperado, resultado
observado, gravidade e ação corretiva. Preencha a tabela com exemplos reais autorizados ou
fictícios, claramente sinalizados como tal. Exercício 5: apresente a um colega a principal limitação
encontrada, sem defender previamente a ferramenta. Peça que ele formule uma explicação
alternativa para o ganho observado. Esse confronto melhora a avaliação e previne o entusiasmo
seletivo. Ao final, pergunte se o código versionado com testes produzido poderia ser
compreendido e contestado por alguém que não participou do projeto.
O FUTURO DA PROGRAMAÇÃO COM IA
14 • EDIÇÃO DIGITAL 2026
CAPÍTULO 05 — TESTES COMO CONTRATO
IDEIA CENTRAL
O ponto de partida deste capítulo é uma escolha de desenho, não uma corrida por novidade:
testes automatizados permitem verificar sugestões sem confiar em aparência. Para transformar a
ideia em trabalho confiável, explicite quem solicita, quem executa, de onde vêm os dados,
quando o processo termina e quem pode contestar uma falha. Esse percurso revela custos e
limitações que uma demonstração isolada não mostra.
COMO O PROCESSO FUNCIONA
Comece pela unidade de análise: cada mudança de software tem entrada, transformação, saída e
consequência. No caso de “testes como contrato”, a entrada pode estar incompleta, contraditória
ou fora do padrão; por isso, o equipe de desenvolvimento precisa verificar condições de uso antes
de produzir o código versionado com testes. Uma maneira útil de representar o processo é
desenhar quatro caixas: origem da informação, critérios aplicados, resultado entregue e
verificação posterior. Descreva também o que não deve ser decidido pelo sistema. A fronteira
operacional aqui é revisão, testes e segurança antes de publicar. Sem essa fronteira, o fluxo pode
aparentar eficiência enquanto transfere risco para usuários e equipes de suporte.
Faça a distinção entre três tipos de problema. O primeiro é erro de entrada: os dados não
correspondem à situação real. O segundo é erro de método: mesmo com dados corretos, as
regras ou o modelo não tratam adequadamente a exceção. O terceiro é erro de uso: a saída é
apropriada como sugestão, mas alguém a interpreta como aprovação final. O controle de
qualidade muda para cada situação. Conferência da fonte reduz o primeiro; ensaios com casos
difíceis reduzem o segundo; treinamento, interface clara e responsabilidade definida reduzem o
terceiro. Essa decomposição vale mais do que afirmar genericamente que o sistema “tem
precisão”.
O FUTURO DA PROGRAMAÇÃO COM IA
15 • EDIÇÃO DIGITAL 2026
CASO COMENTADO
Considere esta situação hipotética: Uma rotina tem testes de unidade, integração e regressão. A
equipe não começa pela ferramenta. Primeiro, define o resultado aceitável e reúne exemplos de
rotina, exceções e situações em que não há dados suficientes. Em seguida, alguém executa o
fluxo atual para formar uma referência de comparação. Só então a nova abordagem é aplicada
aos mesmos casos, com registro do que mudou e do que permaneceu igual. O objetivo não é
fabricar uma vitória da tecnologia: é identificar quais partes do trabalho foram realmente
aprimoradas.
Imagine agora que surge gerar teste que repete o mesmo erro do código.. O problema não deve
ser resolvido ocultando o caso ruim da amostra. Registre o ocorrido, classifique a gravidade,
preserve as entradas necessárias para reproduzi-lo sem violar privacidade e defina quem pode
corrigir ou interromper o processo. Se houver impacto externo,a resposta precisa incluir
comunicação ao afetado e reparação proporcionada. Um piloto que aprende com esse episódio
tem mais valor do que uma implantação que só apresenta exemplos bem-sucedidos.
No fechamento do caso, compare duas perguntas diferentes: “o sistema concluiu a tarefa?” e “o
usuário obteve o resultado certo com esforço aceitável?”. Uma resposta pode ser tecnicamente
válida e ainda gerar retrabalho, insegurança ou falta de confiança. Observe o correção e
facilidade de manutenção; registre custos que surgiram fora da equipe central; e evite inferir
qualidade apenas pela satisfação imediata. Usuários podem gostar de uma resposta rápida sem
perceber uma omissão, enquanto profissionais experientes podem notar uma falha crítica em
poucos segundos.
MÉTODO DE IMPLANTAÇÃO
A primeira etapa é delimitar o escopo em uma página: público, objetivo, dados permitidos,
condições para recusar uma resposta, responsável e forma de reversão. A segunda é montar um
conjunto pequeno, porém heterogêneo, de casos: típicos, extremos, incompletos e
deliberadamente adversariais. A terceira é testar sem alterar o padrão de avaliação entre
alternativas. Nesta etapa, a ação recomendada é: revisar testes e incluir exemplos humanos. Ela
deve ser executada de modo observável, com data, versão e pessoa responsável.
A quarta etapa é tornar explícito o custo total. Some tempo de preparação, esforço de revisão,
treinamento, licença, infraestrutura, falhas e manutenção. Uma economia em minutos por
mudança de software não se converte automaticamente em economia organizacional: talvez a
equipe precise corrigir dados, acolher reclamações ou reconstruir confiança. A quinta etapa é
instituir revisão regular. À medida que documentos, usuários, processos e tecnologia mudam, o
resultado anterior deixa de representar a situação presente. Guarde uma amostra fixa para
comparação entre versões e complemente-a com ocorrências novas da operação.
A sexta etapa consiste em distribuir autoridade: quem pode alterar regras, quem aprova
exceções, quem acessa informações e quem determina a suspensão. Não basta declarar que há
“humano no circuito” se essa pessoa não tem tempo, informação ou poder para discordar. A
revisão humana precisa de critérios, exemplos de erro e canal para registrar divergências.
Quando essas condições estão presentes, a tecnologia pode reduzir trabalho mecânico sem
transferir silenciosamente a responsabilidade a quem recebe a saída.
O FUTURO DA PROGRAMAÇÃO COM IA
16 • EDIÇÃO DIGITAL 2026
MEDIDAS QUE IMPORTAM
Use como indicador principal cobertura relevante e defeitos escapados.. Não o leia isoladamente.
Separe os resultados por tipo de caso, contexto, grupo afetado e grau de dificuldade; depois
compare com a linha de base anterior. Se o indicador melhorar apenas em situações simples,
talvez o sistema tenha deslocado o trabalho difícil para pessoas menos visíveis. Acrescente uma
medida de segurança: quantidade de erros graves por amostra auditada. Acrescente ainda uma
medida de custo: esforço total por resultado validado, incluindo correção posterior.
Defina o que conta como sucesso antes do teste. Uma meta que muda depois de observar os
resultados não permite comparação honesta. Analise também os casos de recusa: há situações
em que o melhor resultado é admitir dúvida, interromper a ação ou encaminhar a uma pessoa
competente. Registre falsos positivos e falsos negativos quando houver classificação; use
exemplos concretos para orientar a equipe, não apenas médias. Se a amostra for pequena, diga
explicitamente que o piloto sugere possibilidades e ainda não comprova desempenho estável.
DECISÕES DIFÍCEIS E CONTRAPONTOS
O erro mais tentador é código plausível sem teste. Ele se agrava quando gerar teste que repete o
mesmo erro do código.. A mitigação não é exigir perfeição abstrata, mas reduzir exposição:
limitar alcance, registrar decisões e estabelecer parada segura. Há também uma tensão entre
personalização e padronização. Personalizar pode ajudar a atender contextos diferentes, mas
dificulta reproduzir decisões e explicar tratamentos distintos. Padronizar facilita auditoria, mas
pode ignorar necessidades individuais. A escolha deve ser justificada em função da tarefa, não
pela capacidade da ferramenta.
Outro contraponto é a possibilidade de uma solução sem IA ser melhor. Um formulário claro, uma
lista de verificação, uma regra determinística, uma formação breve ou a correção da base de
dados podem resolver o problema por menos custo e com maior previsibilidade. Use a tecnologia
quando ela acrescentar capacidade demonstrável, não quando for a opção mais fácil de anunciar.
Para decidir, documente alternativa rejeitada, motivo, restrição de orçamento e condição que
faria a equipe rever a escolha.
OFICINA PARA O LEITOR
Exercício 1: descreva, em até seis linhas, uma situação própria relacionada a “testes como
contrato”. Identifique uma entrada verificável, uma saída útil e uma pessoa que sofrerá as
consequências de um erro. Exercício 2: elabore três casos normais, dois de borda e um caso em
que a resposta correta é “não sei”. Escreva antes do teste o que considerará resultado aceitável.
Exercício 3: aplique a orientação “revisar testes e incluir exemplos humanos.” e registre o que
mudou no processo, não apenas na interface.
Exercício 4: desenhe uma tabela com cinco colunas — caso, resultado esperado, resultado
observado, gravidade e ação corretiva. Preencha a tabela com exemplos reais autorizados ou
fictícios, claramente sinalizados como tal. Exercício 5: apresente a um colega a principal limitação
encontrada, sem defender previamente a ferramenta. Peça que ele formule uma explicação
alternativa para o ganho observado. Esse confronto melhora a avaliação e previne o entusiasmo
seletivo. Ao final, pergunte se o código versionado com testes produzido poderia ser
compreendido e contestado por alguém que não participou do projeto.
O FUTURO DA PROGRAMAÇÃO COM IA
17 • EDIÇÃO DIGITAL 2026
CAPÍTULO 06 — REVISÃO DE CÓDIGO
IDEIA CENTRAL
Revisão verifica intenção, legibilidade, segurança e consequências além de compilar. A
consequência prática é que uma solução só faz sentido se melhorar uma tarefa definida. Antes de
discutir fornecedores, imagine duas alternativas: continuar com o procedimento atual ou alterar
apenas uma etapa. A comparação obriga a observar qualidade, tempo e impacto sobre as
pessoas, em vez de presumir que toda automação representa progresso.
COMO O PROCESSO FUNCIONA
Comece pela unidade de análise: cada mudança de software tem entrada, transformação, saída e
consequência. No caso de “revisão de código”, a entrada pode estar incompleta, contraditória ou
fora do padrão; por isso, o equipe de desenvolvimento precisa verificar condições de uso antes de
produzir o código versionado com testes. Uma maneira útil de representar o processo é desenhar
quatro caixas: origem da informação, critérios aplicados, resultado entregue e verificação
posterior. Descreva também o que não deve ser decidido pelo sistema. A fronteira operacional
aqui é revisão, testes e segurança antes de publicar. Sem essa fronteira, o fluxo pode aparentar
eficiência enquanto transfere risco para usuários e equipes de suporte.
Faça a distinção entre três tipos de problema. O primeiro é erro de entrada: os dados não
correspondem à situação real. O segundo é erro de método: mesmo com dados corretos, as
regras ou o modelo não tratam adequadamente a exceção. O terceiro é erro de uso: a saída é
apropriada como sugestão, mas alguém a interpreta como aprovação final. O controle de
qualidade muda para cada situação. Conferência da fonte reduz o primeiro; ensaios com casos
difíceis reduzem o segundo; treinamento, interface clara e responsabilidade definida reduzem o
terceiro. Essa decomposição vale mais do que afirmar genericamente que o sistema “tem
precisão”.
O FUTURO DA PROGRAMAÇÃO COM IA
18 • EDIÇÃO DIGITAL 2026
CASO COMENTADO
Considere esta situação hipotética: Uma pull request explica risco e estratégia de reversão. A
equipe nãocomeça pela ferramenta. Primeiro, define o resultado aceitável e reúne exemplos de
rotina, exceções e situações em que não há dados suficientes. Em seguida, alguém executa o
fluxo atual para formar uma referência de comparação. Só então a nova abordagem é aplicada
aos mesmos casos, com registro do que mudou e do que permaneceu igual. O objetivo não é
fabricar uma vitória da tecnologia: é identificar quais partes do trabalho foram realmente
aprimoradas.
Imagine agora que surge aceitar bloco grande que ninguém entende.. O problema não deve ser
resolvido ocultando o caso ruim da amostra. Registre o ocorrido, classifique a gravidade, preserve
as entradas necessárias para reproduzi-lo sem violar privacidade e defina quem pode corrigir ou
interromper o processo. Se houver impacto externo, a resposta precisa incluir comunicação ao
afetado e reparação proporcionada. Um piloto que aprende com esse episódio tem mais valor do
que uma implantação que só apresenta exemplos bem-sucedidos.
No fechamento do caso, compare duas perguntas diferentes: “o sistema concluiu a tarefa?” e “o
usuário obteve o resultado certo com esforço aceitável?”. Uma resposta pode ser tecnicamente
válida e ainda gerar retrabalho, insegurança ou falta de confiança. Observe o correção e
facilidade de manutenção; registre custos que surgiram fora da equipe central; e evite inferir
qualidade apenas pela satisfação imediata. Usuários podem gostar de uma resposta rápida sem
perceber uma omissão, enquanto profissionais experientes podem notar uma falha crítica em
poucos segundos.
MÉTODO DE IMPLANTAÇÃO
A primeira etapa é delimitar o escopo em uma página: público, objetivo, dados permitidos,
condições para recusar uma resposta, responsável e forma de reversão. A segunda é montar um
conjunto pequeno, porém heterogêneo, de casos: típicos, extremos, incompletos e
deliberadamente adversariais. A terceira é testar sem alterar o padrão de avaliação entre
alternativas. Nesta etapa, a ação recomendada é: limitar mudanças e pedir justificativa clara. Ela
deve ser executada de modo observável, com data, versão e pessoa responsável.
A quarta etapa é tornar explícito o custo total. Some tempo de preparação, esforço de revisão,
treinamento, licença, infraestrutura, falhas e manutenção. Uma economia em minutos por
mudança de software não se converte automaticamente em economia organizacional: talvez a
equipe precise corrigir dados, acolher reclamações ou reconstruir confiança. A quinta etapa é
instituir revisão regular. À medida que documentos, usuários, processos e tecnologia mudam, o
resultado anterior deixa de representar a situação presente. Guarde uma amostra fixa para
comparação entre versões e complemente-a com ocorrências novas da operação.
A sexta etapa consiste em distribuir autoridade: quem pode alterar regras, quem aprova
exceções, quem acessa informações e quem determina a suspensão. Não basta declarar que há
“humano no circuito” se essa pessoa não tem tempo, informação ou poder para discordar. A
revisão humana precisa de critérios, exemplos de erro e canal para registrar divergências.
Quando essas condições estão presentes, a tecnologia pode reduzir trabalho mecânico sem
transferir silenciosamente a responsabilidade a quem recebe a saída.
O FUTURO DA PROGRAMAÇÃO COM IA
19 • EDIÇÃO DIGITAL 2026
MEDIDAS QUE IMPORTAM
Use como indicador principal defeitos por revisão e tempo de manutenção.. Não o leia
isoladamente. Separe os resultados por tipo de caso, contexto, grupo afetado e grau de
dificuldade; depois compare com a linha de base anterior. Se o indicador melhorar apenas em
situações simples, talvez o sistema tenha deslocado o trabalho difícil para pessoas menos visíveis.
Acrescente uma medida de segurança: quantidade de erros graves por amostra auditada.
Acrescente ainda uma medida de custo: esforço total por resultado validado, incluindo correção
posterior.
Defina o que conta como sucesso antes do teste. Uma meta que muda depois de observar os
resultados não permite comparação honesta. Analise também os casos de recusa: há situações
em que o melhor resultado é admitir dúvida, interromper a ação ou encaminhar a uma pessoa
competente. Registre falsos positivos e falsos negativos quando houver classificação; use
exemplos concretos para orientar a equipe, não apenas médias. Se a amostra for pequena, diga
explicitamente que o piloto sugere possibilidades e ainda não comprova desempenho estável.
DECISÕES DIFÍCEIS E CONTRAPONTOS
O erro mais tentador é código plausível sem teste. Ele se agrava quando aceitar bloco grande que
ninguém entende.. A mitigação não é exigir perfeição abstrata, mas reduzir exposição: limitar
alcance, registrar decisões e estabelecer parada segura. Há também uma tensão entre
personalização e padronização. Personalizar pode ajudar a atender contextos diferentes, mas
dificulta reproduzir decisões e explicar tratamentos distintos. Padronizar facilita auditoria, mas
pode ignorar necessidades individuais. A escolha deve ser justificada em função da tarefa, não
pela capacidade da ferramenta.
Outro contraponto é a possibilidade de uma solução sem IA ser melhor. Um formulário claro, uma
lista de verificação, uma regra determinística, uma formação breve ou a correção da base de
dados podem resolver o problema por menos custo e com maior previsibilidade. Use a tecnologia
quando ela acrescentar capacidade demonstrável, não quando for a opção mais fácil de anunciar.
Para decidir, documente alternativa rejeitada, motivo, restrição de orçamento e condição que
faria a equipe rever a escolha.
OFICINA PARA O LEITOR
Exercício 1: descreva, em até seis linhas, uma situação própria relacionada a “revisão de código”.
Identifique uma entrada verificável, uma saída útil e uma pessoa que sofrerá as consequências de
um erro. Exercício 2: elabore três casos normais, dois de borda e um caso em que a resposta
correta é “não sei”. Escreva antes do teste o que considerará resultado aceitável. Exercício 3:
aplique a orientação “limitar mudanças e pedir justificativa clara.” e registre o que mudou no
processo, não apenas na interface.
Exercício 4: desenhe uma tabela com cinco colunas — caso, resultado esperado, resultado
observado, gravidade e ação corretiva. Preencha a tabela com exemplos reais autorizados ou
fictícios, claramente sinalizados como tal. Exercício 5: apresente a um colega a principal limitação
encontrada, sem defender previamente a ferramenta. Peça que ele formule uma explicação
alternativa para o ganho observado. Esse confronto melhora a avaliação e previne o entusiasmo
seletivo. Ao final, pergunte se o código versionado com testes produzido poderia ser
compreendido e contestado por alguém que não participou do projeto.
O FUTURO DA PROGRAMAÇÃO COM IA
20 • EDIÇÃO DIGITAL 2026
CAPÍTULO 07 — SEGURANÇA POR PADRÃO
IDEIA CENTRAL
Código gerado pode expor segredo, validar mal entrada ou usar dependência insegura. Essa
afirmação parece simples até que a decisão chega ao contexto de uma equipe, a um orçamento e
a pessoas que dependerão do resultado. É necessário separar mecanismo, finalidade e limites: o
que a tecnologia consegue fazer sob condições controladas não equivale ao que deve fazer em
uma operação real. O capítulo trabalha com uma situação específica, observa seus pontos de
falha e propõe um modo de avaliar resultados sem esconder incertezas.
COMO O PROCESSO FUNCIONA
Comece pela unidade de análise: cada mudança de software tem entrada, transformação, saída e
consequência. No caso de “segurança por padrão”, a entrada pode estar incompleta, contraditória
ou fora do padrão; por isso, o equipe de desenvolvimento precisa verificar condições de uso antes
de produzir o código versionado com testes. Uma maneira útil de representar o processo é
desenhar quatro caixas: origem da informação, critérios aplicados, resultado entregue e
verificação posterior. Descreva também o que não deve ser decidido pelo sistema. A fronteira
operacional aqui é revisão, testes e segurança antes de publicar. Sem essa fronteira, o fluxo pode
aparentareficiência enquanto transfere risco para usuários e equipes de suporte.
Faça a distinção entre três tipos de problema. O primeiro é erro de entrada: os dados não
correspondem à situação real. O segundo é erro de método: mesmo com dados corretos, as
regras ou o modelo não tratam adequadamente a exceção. O terceiro é erro de uso: a saída é
apropriada como sugestão, mas alguém a interpreta como aprovação final. O controle de
qualidade muda para cada situação. Conferência da fonte reduz o primeiro; ensaios com casos
difíceis reduzem o segundo; treinamento, interface clara e responsabilidade definida reduzem o
terceiro. Essa decomposição vale mais do que afirmar genericamente que o sistema “tem
precisão”.
O FUTURO DA PROGRAMAÇÃO COM IA
21 • EDIÇÃO DIGITAL 2026
CASO COMENTADO
Considere esta situação hipotética: Um endpoint rejeita dados inesperados e registra tentativa. A
equipe não começa pela ferramenta. Primeiro, define o resultado aceitável e reúne exemplos de
rotina, exceções e situações em que não há dados suficientes. Em seguida, alguém executa o
fluxo atual para formar uma referência de comparação. Só então a nova abordagem é aplicada
aos mesmos casos, com registro do que mudou e do que permaneceu igual. O objetivo não é
fabricar uma vitória da tecnologia: é identificar quais partes do trabalho foram realmente
aprimoradas.
Imagine agora que surge colar chave de API em prompt ou repositório.. O problema não deve ser
resolvido ocultando o caso ruim da amostra. Registre o ocorrido, classifique a gravidade, preserve
as entradas necessárias para reproduzi-lo sem violar privacidade e defina quem pode corrigir ou
interromper o processo. Se houver impacto externo, a resposta precisa incluir comunicação ao
afetado e reparação proporcionada. Um piloto que aprende com esse episódio tem mais valor do
que uma implantação que só apresenta exemplos bem-sucedidos.
No fechamento do caso, compare duas perguntas diferentes: “o sistema concluiu a tarefa?” e “o
usuário obteve o resultado certo com esforço aceitável?”. Uma resposta pode ser tecnicamente
válida e ainda gerar retrabalho, insegurança ou falta de confiança. Observe o correção e
facilidade de manutenção; registre custos que surgiram fora da equipe central; e evite inferir
qualidade apenas pela satisfação imediata. Usuários podem gostar de uma resposta rápida sem
perceber uma omissão, enquanto profissionais experientes podem notar uma falha crítica em
poucos segundos.
MÉTODO DE IMPLANTAÇÃO
A primeira etapa é delimitar o escopo em uma página: público, objetivo, dados permitidos,
condições para recusar uma resposta, responsável e forma de reversão. A segunda é montar um
conjunto pequeno, porém heterogêneo, de casos: típicos, extremos, incompletos e
deliberadamente adversariais. A terceira é testar sem alterar o padrão de avaliação entre
alternativas. Nesta etapa, a ação recomendada é: usar cofres, análise estática e revisão de
permissões. Ela deve ser executada de modo observável, com data, versão e pessoa responsável.
A quarta etapa é tornar explícito o custo total. Some tempo de preparação, esforço de revisão,
treinamento, licença, infraestrutura, falhas e manutenção. Uma economia em minutos por
mudança de software não se converte automaticamente em economia organizacional: talvez a
equipe precise corrigir dados, acolher reclamações ou reconstruir confiança. A quinta etapa é
instituir revisão regular. À medida que documentos, usuários, processos e tecnologia mudam, o
resultado anterior deixa de representar a situação presente. Guarde uma amostra fixa para
comparação entre versões e complemente-a com ocorrências novas da operação.
A sexta etapa consiste em distribuir autoridade: quem pode alterar regras, quem aprova
exceções, quem acessa informações e quem determina a suspensão. Não basta declarar que há
“humano no circuito” se essa pessoa não tem tempo, informação ou poder para discordar. A
revisão humana precisa de critérios, exemplos de erro e canal para registrar divergências.
Quando essas condições estão presentes, a tecnologia pode reduzir trabalho mecânico sem
transferir silenciosamente a responsabilidade a quem recebe a saída.
O FUTURO DA PROGRAMAÇÃO COM IA
22 • EDIÇÃO DIGITAL 2026
MEDIDAS QUE IMPORTAM
Use como indicador principal vulnerabilidades e segredos detectados.. Não o leia isoladamente.
Separe os resultados por tipo de caso, contexto, grupo afetado e grau de dificuldade; depois
compare com a linha de base anterior. Se o indicador melhorar apenas em situações simples,
talvez o sistema tenha deslocado o trabalho difícil para pessoas menos visíveis. Acrescente uma
medida de segurança: quantidade de erros graves por amostra auditada. Acrescente ainda uma
medida de custo: esforço total por resultado validado, incluindo correção posterior.
Defina o que conta como sucesso antes do teste. Uma meta que muda depois de observar os
resultados não permite comparação honesta. Analise também os casos de recusa: há situações
em que o melhor resultado é admitir dúvida, interromper a ação ou encaminhar a uma pessoa
competente. Registre falsos positivos e falsos negativos quando houver classificação; use
exemplos concretos para orientar a equipe, não apenas médias. Se a amostra for pequena, diga
explicitamente que o piloto sugere possibilidades e ainda não comprova desempenho estável.
DECISÕES DIFÍCEIS E CONTRAPONTOS
O erro mais tentador é código plausível sem teste. Ele se agrava quando colar chave de API em
prompt ou repositório.. A mitigação não é exigir perfeição abstrata, mas reduzir exposição: limitar
alcance, registrar decisões e estabelecer parada segura. Há também uma tensão entre
personalização e padronização. Personalizar pode ajudar a atender contextos diferentes, mas
dificulta reproduzir decisões e explicar tratamentos distintos. Padronizar facilita auditoria, mas
pode ignorar necessidades individuais. A escolha deve ser justificada em função da tarefa, não
pela capacidade da ferramenta.
Outro contraponto é a possibilidade de uma solução sem IA ser melhor. Um formulário claro, uma
lista de verificação, uma regra determinística, uma formação breve ou a correção da base de
dados podem resolver o problema por menos custo e com maior previsibilidade. Use a tecnologia
quando ela acrescentar capacidade demonstrável, não quando for a opção mais fácil de anunciar.
Para decidir, documente alternativa rejeitada, motivo, restrição de orçamento e condição que
faria a equipe rever a escolha.
OFICINA PARA O LEITOR
Exercício 1: descreva, em até seis linhas, uma situação própria relacionada a “segurança por
padrão”. Identifique uma entrada verificável, uma saída útil e uma pessoa que sofrerá as
consequências de um erro. Exercício 2: elabore três casos normais, dois de borda e um caso em
que a resposta correta é “não sei”. Escreva antes do teste o que considerará resultado aceitável.
Exercício 3: aplique a orientação “usar cofres, análise estática e revisão de permissões.” e
registre o que mudou no processo, não apenas na interface.
Exercício 4: desenhe uma tabela com cinco colunas — caso, resultado esperado, resultado
observado, gravidade e ação corretiva. Preencha a tabela com exemplos reais autorizados ou
fictícios, claramente sinalizados como tal. Exercício 5: apresente a um colega a principal limitação
encontrada, sem defender previamente a ferramenta. Peça que ele formule uma explicação
alternativa para o ganho observado. Esse confronto melhora a avaliação e previne o entusiasmo
seletivo. Ao final, pergunte se o código versionado com testes produzido poderia ser
compreendido e contestado por alguém que não participou do projeto.
O FUTURO DA PROGRAMAÇÃO COM IA
23 • EDIÇÃO DIGITAL 2026
CAPÍTULO 08 — DEPENDÊNCIAS E LICENÇAS
IDEIA CENTRAL
O ponto de partida deste capítulo é uma escolha de desenho, não uma corrida por novidade:
bibliotecas aceleram desenvolvimento, mas trazem manutenção e obrigações. Para transformar a
ideia em trabalho confiável, explicite quem solicita, quem executa, de onde vêm os dados,
quando o processo terminae quem pode contestar uma falha. Esse percurso revela custos e
limitações que uma demonstração isolada não mostra.
COMO O PROCESSO FUNCIONA
Comece pela unidade de análise: cada mudança de software tem entrada, transformação, saída e
consequência. No caso de “dependências e licenças”, a entrada pode estar incompleta,
contraditória ou fora do padrão; por isso, o equipe de desenvolvimento precisa verificar condições
de uso antes de produzir o código versionado com testes. Uma maneira útil de representar o
processo é desenhar quatro caixas: origem da informação, critérios aplicados, resultado entregue
e verificação posterior. Descreva também o que não deve ser decidido pelo sistema. A fronteira
operacional aqui é revisão, testes e segurança antes de publicar. Sem essa fronteira, o fluxo pode
aparentar eficiência enquanto transfere risco para usuários e equipes de suporte.
Faça a distinção entre três tipos de problema. O primeiro é erro de entrada: os dados não
correspondem à situação real. O segundo é erro de método: mesmo com dados corretos, as
regras ou o modelo não tratam adequadamente a exceção. O terceiro é erro de uso: a saída é
apropriada como sugestão, mas alguém a interpreta como aprovação final. O controle de
qualidade muda para cada situação. Conferência da fonte reduz o primeiro; ensaios com casos
difíceis reduzem o segundo; treinamento, interface clara e responsabilidade definida reduzem o
terceiro. Essa decomposição vale mais do que afirmar genericamente que o sistema “tem
precisão”.
O FUTURO DA PROGRAMAÇÃO COM IA
24 • EDIÇÃO DIGITAL 2026
CASO COMENTADO
Considere esta situação hipotética: Um projeto substitui pacote abandonado antes de lançar
funcionalidade. A equipe não começa pela ferramenta. Primeiro, define o resultado aceitável e
reúne exemplos de rotina, exceções e situações em que não há dados suficientes. Em seguida,
alguém executa o fluxo atual para formar uma referência de comparação. Só então a nova
abordagem é aplicada aos mesmos casos, com registro do que mudou e do que permaneceu
igual. O objetivo não é fabricar uma vitória da tecnologia: é identificar quais partes do trabalho
foram realmente aprimoradas.
Imagine agora que surge copiar código sem entender licença e origem.. O problema não deve ser
resolvido ocultando o caso ruim da amostra. Registre o ocorrido, classifique a gravidade, preserve
as entradas necessárias para reproduzi-lo sem violar privacidade e defina quem pode corrigir ou
interromper o processo. Se houver impacto externo, a resposta precisa incluir comunicação ao
afetado e reparação proporcionada. Um piloto que aprende com esse episódio tem mais valor do
que uma implantação que só apresenta exemplos bem-sucedidos.
No fechamento do caso, compare duas perguntas diferentes: “o sistema concluiu a tarefa?” e “o
usuário obteve o resultado certo com esforço aceitável?”. Uma resposta pode ser tecnicamente
válida e ainda gerar retrabalho, insegurança ou falta de confiança. Observe o correção e
facilidade de manutenção; registre custos que surgiram fora da equipe central; e evite inferir
qualidade apenas pela satisfação imediata. Usuários podem gostar de uma resposta rápida sem
perceber uma omissão, enquanto profissionais experientes podem notar uma falha crítica em
poucos segundos.
MÉTODO DE IMPLANTAÇÃO
A primeira etapa é delimitar o escopo em uma página: público, objetivo, dados permitidos,
condições para recusar uma resposta, responsável e forma de reversão. A segunda é montar um
conjunto pequeno, porém heterogêneo, de casos: típicos, extremos, incompletos e
deliberadamente adversariais. A terceira é testar sem alterar o padrão de avaliação entre
alternativas. Nesta etapa, a ação recomendada é: manter inventário e atualização controlada. Ela
deve ser executada de modo observável, com data, versão e pessoa responsável.
A quarta etapa é tornar explícito o custo total. Some tempo de preparação, esforço de revisão,
treinamento, licença, infraestrutura, falhas e manutenção. Uma economia em minutos por
mudança de software não se converte automaticamente em economia organizacional: talvez a
equipe precise corrigir dados, acolher reclamações ou reconstruir confiança. A quinta etapa é
instituir revisão regular. À medida que documentos, usuários, processos e tecnologia mudam, o
resultado anterior deixa de representar a situação presente. Guarde uma amostra fixa para
comparação entre versões e complemente-a com ocorrências novas da operação.
A sexta etapa consiste em distribuir autoridade: quem pode alterar regras, quem aprova
exceções, quem acessa informações e quem determina a suspensão. Não basta declarar que há
“humano no circuito” se essa pessoa não tem tempo, informação ou poder para discordar. A
revisão humana precisa de critérios, exemplos de erro e canal para registrar divergências.
Quando essas condições estão presentes, a tecnologia pode reduzir trabalho mecânico sem
transferir silenciosamente a responsabilidade a quem recebe a saída.
O FUTURO DA PROGRAMAÇÃO COM IA
25 • EDIÇÃO DIGITAL 2026
MEDIDAS QUE IMPORTAM
Use como indicador principal dependências desatualizadas e riscos de licença.. Não o leia
isoladamente. Separe os resultados por tipo de caso, contexto, grupo afetado e grau de
dificuldade; depois compare com a linha de base anterior. Se o indicador melhorar apenas em
situações simples, talvez o sistema tenha deslocado o trabalho difícil para pessoas menos visíveis.
Acrescente uma medida de segurança: quantidade de erros graves por amostra auditada.
Acrescente ainda uma medida de custo: esforço total por resultado validado, incluindo correção
posterior.
Defina o que conta como sucesso antes do teste. Uma meta que muda depois de observar os
resultados não permite comparação honesta. Analise também os casos de recusa: há situações
em que o melhor resultado é admitir dúvida, interromper a ação ou encaminhar a uma pessoa
competente. Registre falsos positivos e falsos negativos quando houver classificação; use
exemplos concretos para orientar a equipe, não apenas médias. Se a amostra for pequena, diga
explicitamente que o piloto sugere possibilidades e ainda não comprova desempenho estável.
DECISÕES DIFÍCEIS E CONTRAPONTOS
O erro mais tentador é código plausível sem teste. Ele se agrava quando copiar código sem
entender licença e origem.. A mitigação não é exigir perfeição abstrata, mas reduzir exposição:
limitar alcance, registrar decisões e estabelecer parada segura. Há também uma tensão entre
personalização e padronização. Personalizar pode ajudar a atender contextos diferentes, mas
dificulta reproduzir decisões e explicar tratamentos distintos. Padronizar facilita auditoria, mas
pode ignorar necessidades individuais. A escolha deve ser justificada em função da tarefa, não
pela capacidade da ferramenta.
Outro contraponto é a possibilidade de uma solução sem IA ser melhor. Um formulário claro, uma
lista de verificação, uma regra determinística, uma formação breve ou a correção da base de
dados podem resolver o problema por menos custo e com maior previsibilidade. Use a tecnologia
quando ela acrescentar capacidade demonstrável, não quando for a opção mais fácil de anunciar.
Para decidir, documente alternativa rejeitada, motivo, restrição de orçamento e condição que
faria a equipe rever a escolha.
OFICINA PARA O LEITOR
Exercício 1: descreva, em até seis linhas, uma situação própria relacionada a “dependências e
licenças”. Identifique uma entrada verificável, uma saída útil e uma pessoa que sofrerá as
consequências de um erro. Exercício 2: elabore três casos normais, dois de borda e um caso em
que a resposta correta é “não sei”. Escreva antes do teste o que considerará resultado aceitável.
Exercício 3: aplique a orientação “manter inventário e atualização controlada.” e registre o que
mudou no processo, não apenas na interface.
Exercício 4: desenhe uma tabela com cinco colunas — caso, resultado esperado, resultado
observado, gravidade e ação corretiva. Preencha a tabela com exemplos reais autorizados ou
fictícios, claramente sinalizados