IA escreve código. Mas quem é responsável pelo software?
Nos últimos anos, uma mudança importante aconteceu no desenvolvimento de software.
A Inteligência Artificial deixou de ser apenas uma ferramenta experimental e passou a escrever código, criar testes, sugerir arquiteturas, explicar erros, gerar APIs, criar interfaces e até estruturar aplicações inteiras.
E isso é fantástico.
Mas existe uma discussão que, na minha opinião, está sendo deixada em segundo plano:
Até onde podemos confiar em um software que foi produzido por IA quando quem o colocou em produção não possui conhecimento suficiente para avaliar o que foi gerado?
Essa não é uma discussão contra a Inteligência Artificial.
Muito pelo contrário.
A IA veio para ficar.
A questão é outra:
quem está usando a ferramenta precisa entender aquilo que está colocando em produção.
A IA consegue escrever código. Isso não significa que ela saiba o que é responsabilidade.
Imagine alguém pedindo para uma IA:
"Crie uma API em Ruby on Rails com autenticação, banco PostgreSQL, Redis e processamento assíncrono."
Em poucos minutos, podemos ter uma aplicação funcionando.
Rotas.
Models.
Controllers.
Services.
Jobs.
Testes.
Docker.
CI/CD.
Tudo aparentemente organizado.
O problema começa quando fazemos uma pergunta simples:
Por que essa arquitetura foi escolhida?
Se a resposta for:
"Porque a IA fez assim."
Temos um problema.
Software não é apenas código que compila.
Software envolve decisões.
E decisões possuem consequências.
O código pode funcionar e ainda assim estar errado
Esse talvez seja um dos pontos mais perigosos da utilização indiscriminada de IA.
Um código pode:
- compilar;
- passar nos testes;
- responder corretamente;
- funcionar em homologação;
- funcionar com dez usuários;
e ainda assim estar completamente inadequado para produção.
Imagine, por exemplo, uma aplicação que consulta um serviço externo.
A IA cria uma chamada HTTP simples.
Funciona.
O desenvolvedor testa.
Funciona.
Publica.
Também funciona.
Até que o serviço externo fica indisponível.
Agora começam os problemas.
As requisições ficam presas.
Os workers começam a acumular tarefas.
O banco recebe novas consultas.
O Redis cresce.
A aplicação começa a consumir memória.
O tempo de resposta aumenta.
E, eventualmente, o sistema inteiro começa a apresentar instabilidade.
O código original não estava necessariamente "errado".
O problema estava na decisão arquitetural.
Talvez fosse necessário timeout.
Retry controlado.
Circuit Breaker.
Backoff.
Fila.
Observabilidade.
Limitação de concorrência.
Fallback.
Ou simplesmente uma estratégia diferente.
A IA pode sugerir tudo isso.
Mas alguém precisa saber quando usar, por que usar e quais são as consequências.
O perigo das chaves de segurança "esquecidas"
Existe outro problema ainda mais preocupante.
Imagine que alguém peça:
"Configure minha aplicação para acessar o banco."
A IA pode gerar algo semelhante a:
DATABASE_URL = "postgres://usuario:senha@servidor:5432/producao"
Funciona.
Mas agora temos uma credencial dentro do código.
E se esse código for enviado para o Git?
Temos uma credencial exposta.
E se o repositório for público?
Temos um incidente de segurança.
E se a senha for reutilizada em outro ambiente?
O problema pode ficar ainda maior.
O desenvolvedor experiente normalmente pensa em:
- variáveis de ambiente;
- Secret Manager;
- rotação de credenciais;
- permissões mínimas;
- separação entre ambientes;
- credenciais diferentes para desenvolvimento, homologação e produção;
- auditoria;
- proteção do pipeline de CI/CD.
A IA também pode produzir uma solução segura.
Mas ela precisa ser orientada corretamente e, principalmente, o resultado precisa ser revisado.
O problema não é a IA não saber criar segurança.
O problema é acreditar que o código gerado automaticamente dispensa revisão humana.
"Mas a IA encontra esses problemas"
Sim.
E isso é justamente o que torna a discussão mais interessante.
A mesma IA que pode gerar uma vulnerabilidade também pode encontrar a vulnerabilidade.
Ela pode revisar código.
Pode sugerir melhorias.
Pode analisar dependências.
Pode criar testes.
Pode explicar uma arquitetura.
Pode encontrar problemas que um desenvolvedor não percebeu.
Pode até ser excelente como uma segunda camada de revisão.
Mas existe uma diferença fundamental:
usar IA para aumentar a capacidade técnica é diferente de usar IA para substituir o conhecimento técnico.
Arquitetura não é copiar uma lista de tecnologias
Outro fenômeno que estamos começando a observar é a criação de sistemas baseados em palavras bonitas.
Microservices.
Kafka.
RabbitMQ.
Redis.
Kubernetes.
Docker.
Event-driven.
CQRS.
DDD.
Circuit Breaker.
Clean Architecture.
Observabilidade.
Tudo parece moderno.
Mas uma arquitetura não se torna boa porque utiliza tecnologias sofisticadas.
Às vezes, uma aplicação Rails com PostgreSQL e Redis resolve o problema perfeitamente.
Em outras situações, precisamos de mensageria, processamento distribuído, múltiplos serviços e mecanismos de tolerância a falhas.
A pergunta não deveria ser:
"Qual tecnologia está na moda?"
A pergunta deveria ser:
"Qual problema precisamos resolver?"
Arquitetura é consequência do problema.
Não uma coleção de ferramentas.
O problema não é criar 100% com IA
Aqui está uma distinção importante.
Não acredito que seja necessário demonizar quem utiliza IA para construir software.
Também não acredito que seja impossível criar uma aplicação praticamente inteira com auxílio de IA.
É possível.
E cada vez será mais comum.
O problema começa quando alguém confunde:
"A IA conseguiu produzir o software."
com:
"Eu sei produzir software porque consegui pedir para a IA produzir."
São coisas completamente diferentes.
A velocidade também aumenta os riscos
Antes da IA, um desenvolvedor iniciante poderia levar semanas para construir determinada funcionalidade.
Com IA, talvez consiga fazer em algumas horas.
Isso é excelente.
Mas existe um efeito colateral.
Se antes ele produzia dez decisões ruins por semana, agora talvez consiga produzir cem.
A IA não apenas aumenta a produtividade.
Ela aumenta a velocidade da execução.
E velocidade sem conhecimento pode significar simplesmente:
errar mais rápido.
Esse talvez seja um dos maiores desafios da nova geração de desenvolvimento assistido por IA.
O verdadeiro diferencial pode deixar de ser escrever código
Durante muito tempo, uma parte importante da profissão de desenvolvedor foi escrever código.
Agora estamos entrando em uma realidade onde escrever código está ficando cada vez mais barato.
A IA consegue gerar:
CRUD
API
Controller
Model
Testes
Dockerfile
CI/CD
SQL
Frontend
Documentação
Então surge uma pergunta interessante:
Se escrever código ficou mais fácil, o que passa a valer mais?
Conhecimento.
Experiência.
Capacidade de análise.
Modelagem.
Arquitetura.
Segurança.
Entendimento de negócio.
Observabilidade.
Capacidade de investigar problemas.
Capacidade de tomar decisões.
E, principalmente:
capacidade de saber quando o código gerado está errado.
O desenvolvedor não desaparece. O papel muda.
Talvez o desenvolvedor do futuro escreva menos código manualmente.
Isso não significa necessariamente que ele será menos importante.
Pode significar justamente o contrário.
Ele terá que compreender ainda mais profundamente o sistema.
Em vez de passar horas escrevendo um CRUD, poderá passar mais tempo pensando:
- Como esse domínio funciona?
- Onde estão os riscos?
- Como os dados serão protegidos?
- O que acontece quando esse serviço cai?
- Como escalar essa operação?
- Como recuperar o sistema?
- Como auditar essa informação?
- O que acontece em uma condição de corrida?
- Como evitar inconsistências?
- Como monitorar esse componente?
- Qual é o impacto dessa decisão daqui a dois anos?
A IA pode ajudar a implementar as respostas.
Mas alguém precisa formular as perguntas certas.
A IA não precisa ser nossa adversária
Existe uma tendência de transformar essa discussão em uma guerra:
programadores versus IA.
Acho que esse é o caminho errado.
Essa guerra provavelmente já nasceu perdida.
A IA continuará evoluindo.
Modelos ficarão melhores.
Ferramentas ficarão mais integradas às IDEs.
Agentes poderão modificar dezenas de arquivos.
Testes poderão ser executados automaticamente.
Pull requests poderão ser analisados por agentes.
Deploys poderão ser automatizados.
Isso não precisa ser visto como uma ameaça.
Pode ser uma das maiores evoluções da história do desenvolvimento de software.
Mas precisamos entender uma coisa:
Ferramenta poderosa exige operador preparado.
Um avião moderno possui sistemas extremamente sofisticados.
Isso não significa que qualquer pessoa deveria pilotá-lo.
Uma calculadora consegue fazer cálculos muito mais rapidamente do que nós.
Isso não elimina a necessidade de entender matemática.
Um compilador consegue transformar código em linguagem de máquina.
Isso não significa que precisamos ignorar como o software funciona.
A IA segue a mesma lógica.
O maior risco talvez não seja a IA errar
Talvez o maior risco seja ninguém perceber que ela errou.
Esse é o ponto central.
Um desenvolvedor experiente olha para um código e começa a fazer perguntas.
Por que esse índice existe?
Por que essa transação está aqui?
Por que esse método faz três coisas?
Por que esse serviço possui essa responsabilidade?
Por que existe um retry de cinco vezes?
Por que essa informação está no Redis?
Por que essa API possui acesso direto a essa tabela?
Por que essa chave está nesse arquivo?
Por que esse usuário possui essa permissão?
Por que esse job pode ser executado simultaneamente?
Essas perguntas não aparecem necessariamente no código.
Elas aparecem na cabeça de quem entende o sistema.
IA + conhecimento é diferente de IA sem conhecimento
Talvez essa seja a síntese de toda essa discussão.
IA + conhecimento = potencialização.
IA sem conhecimento = risco de automatizar erros.
Não precisamos escolher entre desenvolvimento tradicional e Inteligência Artificial.
Podemos utilizar os dois.
Podemos deixar a IA escrever código.
Podemos deixar a IA criar testes.
Podemos pedir para ela revisar nosso código.
Podemos utilizar agentes.
Podemos gerar documentação.
Podemos automatizar tarefas repetitivas.
Podemos construir sistemas muito mais rapidamente.
Mas precisamos manter uma coisa que nenhuma ferramenta deveria substituir:
responsabilidade técnica.
No final, alguém ainda precisa responder
Quando uma aplicação estiver funcionando perfeitamente, provavelmente ninguém perguntará quem escreveu cada linha.
Mas quando ocorrer um vazamento de dados?
Quando uma informação financeira desaparecer?
Quando uma transação for processada duas vezes?
Quando uma credencial for exposta?
Quando uma fila parar?
Quando o banco ficar indisponível?
Quando uma vulnerabilidade for explorada?
Quando uma decisão arquitetural provocar milhões em prejuízo?
Alguém precisará responder.
E provavelmente a resposta não será:
"Foi a IA que escreveu."
A responsabilidade continuará sendo humana.
Por isso, talvez a pergunta mais importante da era da Inteligência Artificial não seja:
"A IA consegue desenvolver software?"
A resposta já sabemos.
Consegue.
A pergunta realmente importante é:
"Nós temos conhecimento suficiente para assumir a responsabilidade pelo software que estamos pedindo para a IA construir?"
Porque gerar código está ficando cada vez mais fácil.
Entender o código continua sendo difícil.
E talvez seja justamente por isso que conhecimento técnico nunca tenha sido tão importante.
E talvez esse seja o verdadeiro caminho
Vejo pessoas usando a IA para corrigir textos, melhorar a escrita, aprender uma nova linguagem, entender um conceito ou simplesmente organizar uma ideia.
E isso não precisa significar deixar de pensar.
Podemos fazer exatamente o contrário.
Podemos usar a IA para ler mais.
Para estudar mais.
Para questionar mais.
Para conhecer assuntos que antes pareciam difíceis.
Podemos pedir uma explicação, discordar dela, pesquisar, testar, comparar e construir nosso próprio entendimento.
Se usamos uma IA para corrigir nosso texto, podemos observar a correção e aprender com ela.
Se usamos para programar, podemos perguntar por que aquela solução foi escolhida.
Se usamos para estudar, podemos ir além da resposta e tentar compreender o raciocínio.
A tecnologia não precisa atrofiar nossa capacidade de pensar.
Ela pode ampliar essa capacidade.
Talvez o grande desafio dessa nova era não seja impedir que a IA faça coisas por nós.
Talvez seja aprender a utilizá-la sem deixar de fazer aquilo que nos torna humanos: pensar, questionar, aprender, criar e assumir responsabilidade pelas nossas decisões.
Porque a IA pode escrever o código.
Pode sugerir a arquitetura.
Pode encontrar um erro.
Pode explicar um conceito.
Pode até nos ajudar a construir sistemas que antes exigiriam equipes enormes.
Mas ainda precisamos de alguém para perguntar:
"Isso realmente faz sentido?"
E talvez seja justamente aí que esteja o nosso papel.
Não precisamos entrar em uma guerra contra a IA.
Essa seria uma guerra perdida antes mesmo de começar.
Precisamos aprender a trabalhar com ela.
Precisamos aprender a questioná-la.
Precisamos aprender com ela.
E, principalmente, precisamos continuar pensando.
Afinal, talvez o futuro não seja sobre humanos contra máquinas.
Talvez seja sobre humanos usando máquinas para fazer coisas que antes pareciam impossíveis.
E quem sabe, com bastante conhecimento, criatividade e algumas boas doses de IA...
a gente finalmente construa a nossa própria SKYNET. 😄
Só espero que, dessa vez, alguém lembre de colocar um bom Circuit Breaker.
