Vibe Coding, Shadow IT e a conta que ninguém viu chegar: IA acelera o desenvolvimento e quem fica com a sustentação?

Escrito por Dani M. | May 25, 2026 3:40:21 PM

 Sistemas internos criados em uma tarde com IA são uma vitória. Até alguém perguntar quem mantém aquilo no ar. 

Nos últimos meses, virou cena comum nas empresas: um analista de operações abre uma conversa com uma IA, descreve em português o que precisa, e antes do café acabar tem um sistema interno funcionando. Resolve um problema real. Anima a área inteira. Em poucas semanas, áreas que sequer faziam parte do mundo da tecnologia estão criando suas próprias ferramentas.

Isso ganhou nome —
vibe coding — foi eleita a palavra do ano de 2025 pelo Dicionário Collins, e está mudando a forma como o software entra nas empresas. A boa notícia: produtividade dispara, ideias viram protótipo no mesmo dia, áreas de negócio param de esperar na fila do TI. A notícia menos comentada: alguém vai precisar manter aquilo. E é aí que a conta começa a ser calculada.

Quando todo mundo virou desenvolvedor (e ninguém pensou em sustentação)

O ganho de produtividade é real e não dá para negar. O problema começa quando o número de "sisteminhas" passa de cinco, dez, vinte — espalhados em planilhas, painéis, automações e integrações criadas por pessoas que estava resolvendo um problema legítimo, mas que nunca foi engenheira de software.

Esse fenômeno tem outro nome: shadow IT. Segundo dados da Gartner citado em diversas análises do setor, 41% das organizações já reportam o uso de soluções de tecnologia fora do controle da TI. Com vibe coding, esse número tende a crescer rápido.

O que parece ágil hoje vira problema amanhã por três motivos bem específicos:

  • Dívida técnica acumulada: o sistema resolve agora, mas ninguém entende exatamente como. Quando precisar mudar, a equipe descobre que o código não tem testes, não tem documentação e, às vezes, nem o autor original lembra o que fez.
  • Risco de compliance: aplicações criadas fora da governança raramente consideram LGPD, logs de auditoria, controle de acesso ou tratamento adequado de dados sensíveis.
  • Acoplamento silencioso: planilhas e ferramentas internas viram dependência crítica de processos sem que ninguém perceba. O dia em que aquilo cai, descobre-se que metade do fechamento mensal passava por lá.

A frase que melhor resume o momento: velocidade só é vantagem quando vem acompanhada de governança.

O ponto de inflexão: a hora em que a liderança precisa decidir

Em algum momento — geralmente entre o terceiro e o décimo "sisteminha" — alguém na liderança faz a pergunta que precisa ser feita: quem é dono disso aqui?

Essa é a pergunta de inflexão. E ela costuma vir embrulhada em outras três, mais difíceis:

  1. Criamos uma área de TI dedicada? Faz sentido para empresas onde tecnologia é cada vez mais central, mas custa caro, leva tempo para amadurecer e exige liderança técnica que o mercado não tem em abundância.
  2. Terceirizamos a sustentação? Faz sentido reduzir o "custo de manter" e ganhar previsibilidade — especialmente quando o core business da empresa não é tecnologia.
  3. Adotamos um modelo híbrido com governança? A resposta mais comum entre empresas que escalaram bem: um núcleo interno enxuto que define padrões e arquitetura, somado a um parceiro de sustentação que cuida do dia a dia operacional.

Não existe resposta única. Existe a resposta certa para o seu momento de maturidade, tamanho de operação e nível de dependência tecnológica do negócio.

O que muda quando você trata software como produto, não como projeto

A maior virada conceitual aqui é entender que software, depois que nasce, não acaba. Ele vive. Precisa de atualização, monitoramento, correção, evolução e segurança contínuas.

Tratar cada sistema interno como "projeto" — algo que tem fim — é a origem de boa parte da dor que as empresas estão sentindo agora. Tratar como "produto" — algo que tem ciclo de vida — obriga a decidir, desde o primeiro dia:

  • Quem responde pela disponibilidade quando algo quebrar às 22h de uma sexta?
  • Como esse sistema é monitorado e medido?
  • Qual a política para mudanças, deploy e rollback?
  • Que padrão mínimo de código, segurança e documentação ele precisa seguir?

Essas perguntas não precisam virar burocracia. Precisam virar acordo. A diferença entre sustentável e insustentável mora exatamente aqui.

Don't panic: o caminho prático para sair do caos

O problema não é a IA gerando código — esse trem não volta para a estação. O problema é a ausência de uma estrutura mínima que torne esse código sustentável depois.

A boa notícia é que essa estrutura não precisa ser pesada. Em geral, ela cabe em quatro decisões:

  1. Inventário. Saber o que existe. Antes de qualquer política de governança, é preciso mapear todos os sistemas, planilhas críticas e ferramentas internas em operação. Você só governa o que enxerga.
  2. Classificação. Nem tudo merece o mesmo nível de cuidado. Um relatório interno semanal é diferente de um sistema que toca dados de cliente. Critérios claros poupam meses de discussão.
  3. Padrões mínimos. Definir o básico não-negociável (versionamento, backup, autenticação, log de auditoria) e separar do que pode ser opcional.
  4. Responsabilidade clara. Cada sistema tem dono. Cada dono tem um caminho conhecido para pedir manutenção, evolução ou aposentadoria.

Quatro decisões. Não doze. Não um framework de cinquenta páginas. O suficiente para transformar caos em sistema — e sistemas em ativos.

Quem somos diante disso tudo? A quatrodois

Nossa referência é o livro O Guia do Mochileiro das Galáxias. No livro, "42" é a resposta para a vida, o universo e tudo mais — só que ninguém ali sabia exatamente qual era a pergunta.

Essa é a virada: somos nós que fazemos as perguntas certas. A maior parte dos projetos de software não trava no código — trava no diagnóstico mal feito. Quem é dono desse sistema? Quanto custa mantê-lo por três anos? Que problema ele resolve daqui a dois? Que parte disso é dívida disfarçada de funcionalidade?

O papel de uma consultoria de verdade não é chegar com a resposta pronta. É fazer as perguntas que ninguém estava fazendo, e a partir delas construir a solução certa. Por isso o nome se escreve junto, em minúsculo: quatrodois.

A IA não vai parar de acelerar o desenvolvimento de software. A pergunta que importa, daqui pra frente, é se a sua estrutura de sustentação está acelerando junto.

 — Equipe quatrodois