Faz muito tempo que estou calado sobre Inteligência Artificial.
Mas não cheguei nesse assunto ontem.
Codifico desde 2015 e, em 2018, já trabalhava com IA na HOP, quando Inteligência Artificial ainda estava muito longe do hype que vemos hoje. Naquela época, nosso trabalho chegou a ser reconhecido com uma premiação da IBM.
Foram vários projetos, grandes empresas, multinacionais, mas também projetos menores. De lá pra cá, vi muita coisa mudar.
Cloud amadureceu. Microsserviços viraram tendência. DevOps se consolidou. APIs passaram a conectar praticamente tudo. Containers, Kubernetes, CI/CD, observabilidade e arquiteturas distribuídas entraram de vez no mundo corporativo.
Já tínhamos aplicações com Machine Learning, Deep Learning, Visão computacional...
E agora chegou a explosão da IA generativa. ChatGPT,Gemini, LLMs, RAG, agentes, copilotos, automações e, mais recentemente, o chamado “vibe coding”.
Tudo isso é incrível.
Mas também estou vendo muito hype e muito charlatanismo.
Gente vendendo IA como solução mágica.
Gente prometendo substituir equipes inteiras de desenvolvimento.
Gente construindo uma aplicação em algumas horas e confundindo isso com engenharia de software.
E talvez esteja na hora de falar mais sobre isso.
Porque fazer funcionar é apenas o começo.
Engenharia de software também é segurança, arquitetura, qualidade, testes, escalabilidade, observabilidade, disponibilidade, performance, manutenção e corretude.
É entender que tecnologia não é religião.
Não existe linguagem perfeita.
Existe linguagem adequada para determinado problema.
Java e C#, por exemplo, possuem tipagem estática, ecossistemas extremamente maduros e são muito utilizados em ambientes corporativos. Em sistemas grandes, domínios complexos, aplicações críticas, sensíveis e projetos mantidos durante anos por grandes equipes, contratos mais explícitos e ferramentas consolidadas podem trazer vantagens importantes.
Mas isso não significa que uma startup começando hoje precise necessariamente dessa mesma estrutura.
Node.js, Ruby e outras tecnologias podem proporcionar enorme produtividade, menor cerimônia e ciclos rápidos de desenvolvimento.
Para uma startup tentando descobrir se alguém realmente quer comprar seu produto, velocidade pode ser muito mais importante do que construir antecipadamente uma arquitetura preparada para milhões de usuários que talvez nunca existam.
Engenharia é contexto e trade-off.
E isso vale para praticamente tudo.
SQL ou NoSQL?
Monólito ou microsserviços?
AWS, Azure, Google Cloud ou infraestrutura própria?
REST, eventos ou mensageria?
Java, C#, Node.js, Python, Ruby, Go?
PostgreSQL, SQL Server, MongoDB, Redis?
Não existe uma resposta universal.
Um monólito bem construído pode ser muito melhor do que uma arquitetura de microsserviços criada apenas porque microsserviços estão na moda. Ainda mais se seu time for pequeno e você precisa correr pra lançar.
Assim como uma arquitetura extremamente sofisticada pode ser um enorme desperdício para uma empresa que ainda nem validou seu produto.
E agora estamos cometendo o mesmo erro com Inteligência Artificial.
A primeira pergunta virou:
“Dá para colocar IA nisso?”
Quando deveria existir uma série de perguntas antes e depois dela.
Qual problema estamos tentando resolver?
Os dados podem ser enviados para um modelo externo?
Existem dados pessoais ou sensíveis envolvidos?
Como LGPD, privacidade e governança estão sendo tratadas?
Onde esses dados ficam armazenados?
Quem possui acesso?
O modelo pode alucinar?
Qual é o impacto se ele entregar uma resposta errada?
Precisamos de RAG?
Precisamos realmente de um agente ou uma automação tradicional resolveria melhor?
Como avaliamos a qualidade das respostas?
Existe human-in-the-loop quando necessário?
Existe auditoria?
Logs?
Métricas?
Tracing?
Monitoramento?
Fallback?
Controle de acesso?
Testes?
Como fazemos deploy?
Como fazemos rollback?
Como sabemos que a versão nova ficou melhor e não simplesmente diferente?
E quando milhares de pessoas começarem a utilizar isso simultaneamente?
Quanto vai custar?
Porque uma POC funcionar no notebook de um desenvolvedor não significa que existe um produto pronto para produção.
Esse é outro ponto que o boom da IA está deixando de lado: código é apenas uma parte de um sistema.
Software sério precisa de engenharia ao redor dele.
Precisa de testes automatizados.
Pipeline de CI/CD.
Versionamento.
Revisão de código.
Gestão de secrets.
Controle de permissões.
Observabilidade.
Backup.
Recuperação de desastre.
Monitoramento.
Gestão de dependências.
Políticas de segurança.
Documentação.
E pessoas capazes de entender o que acontece quando alguma coisa dá errado.
IA também mudou profundamente a maneira como programamos.
Hoje um desenvolvedor consegue produzir em horas aquilo que alguns anos atrás poderia levar dias.
Isso é uma evolução extraordinária.
Eu uso IA e acredito profundamente no potencial dela.
Mas existe uma diferença enorme entre utilizar IA para acelerar engenharia e utilizar IA para substituir conhecimento de engenharia.
Esse talvez seja um dos maiores riscos do chamado “vibe coding”.
Você descreve o que quer.
A IA gera.
Você executa.
Funcionou.
Ótimo.
Mas quem entende aquele código?
Quem sabe quais dependências foram adicionadas?
Quem percebe uma vulnerabilidade?
Quem identifica uma query que funcionará com 500 registros, mas destruirá o banco quando existirem 50 milhões?
Quem percebe um problema de concorrência?
Quem entende por que aquela arquitetura não escala?
Quem verifica se existe uma falha de autorização expondo dados de outro usuário?
Quem assume quando a IA gerou algo aparentemente correto, mas conceitualmente errado?
Código que compila não é necessariamente código correto. Ele pode ter efeitos colaterais ainda assim.
E código correto hoje não é necessariamente um sistema sustentável amanhã.
É aí que entra algo que nenhuma ferramenta deveria substituir: fundamento técnico e capacidade de decisão.
Saber programar não é decorar sintaxe.
É entender estruturas de dados, algoritmos, bancos de dados, redes, concorrência, segurança, arquitetura, sistemas distribuídos e, principalmente, saber analisar problemas.
As ferramentas mudam.
Os frameworks mudam.
As linguagens mudam.
A infraestrutura muda.
Agora até a maneira como escrevemos código está mudando.
Mas os fundamentos continuam extremamente importantes.
E existe ainda outro problema silencioso: débito técnico.
IA consegue gerar código em uma velocidade absurda.
Consequentemente, também consegue gerar dívida técnica em uma velocidade absurda.
Uma empresa pode acreditar que está economizando porque entregou algo em três semanas em vez de três meses.
Até descobrir, meses depois, que ninguém consegue evoluir o sistema sem quebrar alguma coisa.
Velocidade sem arquitetura pode virar retrabalho.
Escalabilidade sem necessidade pode virar custo.
Segurança tratada depois pode virar incidente.
IA sem governança pode virar risco.
E transformação digital sem engenharia pode virar apenas uma demonstração bonita.
Por isso decidi começar a falar mais sobre esses assuntos.
Depois de anos trabalhando com software e acompanhando IA desde muito antes dessa explosão recente, quero compartilhar conhecimento sobre Inteligência Artificial, desenvolvimento, arquitetura, cloud, segurança, dados e transformação digital.
Sem demonizar tecnologia nova.
Sem defender tecnologia antiga apenas porque é antiga.
E principalmente sem vender mágica.
Estou disposto a ajudar desenvolvedores, gestores e empresas a entenderem onde IA realmente gera valor e onde estão apenas colocando IA porque alguém disse que precisam colocar.
Porque acredito muito no que está acontecendo.
A IA vai transformar profundamente a maneira como construímos software e como empresas operam.
Só que transformação digital séria precisa ser construída com segurança, qualidade, escalabilidade, governança e corretude.
A IA está tornando cada vez mais fácil criar software.
E isso é fantástico.
Mas talvez justamente por isso nunca tenha sido tão importante entender a diferença entre:
gerar código
e
fazer engenharia de software.
Top comments (0)