IN+IA (Inteligência Natural mais Inteligência Artificial)

Estes últimos dias me deparei conversando e estudando mais sobre aplicabilidades reais de IA, tentando (quase lutando) para sair da bolha superficial e oportunista. E acabai caindo no vídeo do pessoal do Código Fonte TV: ANTHROPIC MOSTRA REALIDADE NO USO DE IA NA PROGRAMAÇÃO. Esse vídeo me inspirou a colocar alguns dos meus pensamentos aqui.

Começando tudo, estava experiementando algumas formas de usar melhor as capacidades dos modelos de IA (principalmente o Claude Opus 4.6) em desenvolvimento de sistemas, famoso IA para DEV. Neste momento tenso eu acabei me inspirando em alguns artigos do Fabio Akita.

O mais interessante é que o uso mais divulgado é que a IA faz tudo para você, entrega software em minutos, e que não precisa mais de TI. Porém sendo mais pragmático e mais cético, não acredito muito nisso. Acredito em um balanço entre o 100% I.A. e 100% I.N.

Imagina um sistema simples, algo que você que não será perene, é uma hipótese, é algo que será descartado. Não precisa dizer que algo descartável não pode ser caro, demorado ou burocrático. Porém quando nós entramos em ambientes um pouco mais complexo, onde temos Leis (LGPD, por exemplo), ambientes altamentes regulados ou ambientes onde a falha custa alguns milhares/milhões de Reais, o descartável não é mais aceito.

Entro aqui não como o do contra IA, mas sim como um apresentador de prós e contras. Assim vamos pensar em fluxo de desenvolvimento, e aqui temos o primeiro ponto. Onde começa o fluxo de desenvolvimento? Onde o Time pega a task? Onde Negócio pede ou tem ideia? Para fins de não ter um artigo tão grande quando o valor da fatura do uso de tokens (sad, but true), vou focar no fluxo onde um time recebe a Task, então o fluxo de criar algo a partir de uma demanda. Ciclo seria:

Análise: ou como alguns dizem o discovery técnico, este momento que estudamos o impacto desta tarefa no código que vamos mexer;
Desenvolvimento
Testes ou Homologação
Subida para Produção.

A partir daqui estou expressando a minha opnião, e a minha vivência, nos últimos 6 meses, utilizando o GitCopilot em projetos reais da empresa (Build to Earn) e um pouco do Antigravity em estudos pessoais (Build To Learn).

Um dos pontos muito bons no uso da IA é ela como um Par de Programação (Pair Programming do XP). Ela tem uma capacidade muito maior de trabalhar com toneladas de dados, e usá-la como um analista de código já um ganho extremo.

Um exemplo real, estava olhando uma tarefa de melhoria de performance em um front end que foi criado em 2022, e nestes casos o que eu faria como Humano:

Olharia as referências de bibliotecas que o projeto está utilizando, pesquisaria quais seriam as melhores alternativas (upgrade ou substituição);
Revisaria o código na tentativa de reduzir os Big Os
E depois alguma forma de caches para reduzir tempo de acesso ao backend.

Resumindo, gastaria pelo menos umas 16-20h analisando. Então solicitei para que o Claudinho (nome carinhoso do Claude Opus) fizesse isso. Pois bem, ele me entregou um report detalhado com fases de implementação e possiveis ganhos em 15 minutos.

Aqui está o pulo do gato, eu não pedi para ele fazer a implementação, eu pedi que ele analisasse o código existente, considerando as Instruções básicas que temos no .github/copilot-instructions.md e trouxesse as melhores práticas para a melhoria de performance. Eu sou o responsável pelo Go/No Go, e o mais interessante foi que ele me trouxe alterações que eu não pensaria, pois são detalhes minunciosos do framework que utilizamos. Aqui eu gastei mais uns minutos e fechei a etapa de Análise. Ganhos de 16h para 30 minutos.

Em desenvolvimento, aqui tem um ponto que nem sempre é tão otimizado, pois como estou falando de um código existente e que já tem muitos anos, não posso simplesmente jogar a IA no meio disso. Então inicia-se outra estratégia do XP o TDD. Normalmente eu solicito que ela crie os casos de testes, e com deles, eu entendo o "raciocínio" que ela está tendo sobre a alteração. Caso ela se engane, eu explico o que deveria ser feito, como um funcionário recém chegado, para que ela tenha mais conhecimento do projeto.

Após esta etapa, vamos para o código, onde estas iterações são curtas e rápidas, nunca solicito a criação de um módulo inteiro do sistema, fatio as solicitações de forma granular, para sempre avaliar e gerar o feedback para a IA. Em muitos casos eu altero coisas e vou refazendo o planejamento das próximas atividades. Ganhos de 3-4 dias para 10-16h.

Em Homologação, normalmente não incluo a IA, ainda. Pois não implementamos testes de UIneste projeto, apenas testes unitários.

Mas ainda tem o Deploy, e aqui existe um mar de possíbilidade, que acredito que em breve estarei explorando.

Concluindo, o uso de IA, não como a bala de prata que resolve todos os problemas, mas como uma "Armadura" que aprimora seus sentidos é um caminho que vejo mais razoável para trazer o ganho de performance dos devs, mas sem transformar o DEV em um Zumbi.