No fim de agosto a OpenAI publicou o caso da loveholidays, uma agência de viagens online da Inglaterra, com um título que diz tudo: "fazendo de todo mundo um construtor". A ideia é que gente do marketing, do financeiro e do atendimento use o Codex pra criar as próprias ferramentas, sem esperar a fila da TI. Eu li e a primeira reação foi: acho ótimo. A segunda foi: sei exatamente onde isso dá errado.
Porque eu vejo isso de perto. Cliente que chega com uma automação que o sobrinho fez no fim de semana com IA. Funciona. Até o dia em que para de funcionar, e aí ninguém sabe por quê, nem o sobrinho.
Então quero dividir esse assunto em duas partes: o que faz muito sentido a sua equipe construir sozinha, e onde passa a linha.
O que mudou de verdade
Dois anos atrás, pedir "um relatório que cruza a planilha de vendas com a de estoque" era abrir chamado pra TI. Fila, prazo, prioridade. Hoje um analista com acesso a uma ferramenta dessas descreve o que quer e tem o relatório em uma hora.
A fila da TI sempre foi o gargalo de toda empresa, e a IA derrubou uma parte dela. O que antes era ticket virou coisa que a pessoa resolve no mesmo dia. Isso é bom pra todo mundo, inclusive pra quem desenvolve, que para de gastar tempo com relatório e volta pro que precisa de engenharia de verdade.
Só que "a pessoa consegue construir" e "a empresa deveria depender disso" são frases diferentes. É aí que a conversa fica interessante.
O que faz sentido a sua equipe construir
- Ferramenta de uso próprio. Script que renomeia arquivos, planilha que se atualiza sozinha, painel com os números da semana. Se quebrar, quem construiu conserta ou joga fora. Ninguém mais sente.
- Protótipo pra explicar uma ideia. Em vez de descrever uma tela em reunião, mostra a tela. Isso vale ouro pra alinhar o que se quer antes de contratar de verdade. Muito melhor que um briefing de três páginas.
- Automação de tarefa chata e de baixo risco. Copiar dado de um lugar pro outro, gerar um resumo, avisar no grupo quando algo acontece. Coisa que hoje alguém faz na mão e odeia.
A regra que junta as três: se der errado, o estrago fica na própria mesa. Ninguém de fora percebe, nenhum cliente é afetado, nenhum número errado chega no financeiro.
Onde passa a linha
- Coisa que mexe com dinheiro. Cobrança, pagamento, nota fiscal, comissão. Erro aqui não é bug, é prejuízo. Às vezes é problema com a Receita.
- Coisa que outras pessoas dependem. No momento em que três setores usam a ferramenta que o João fez, ela virou sistema da empresa. E quando o João sair de férias? E quando ele sair da empresa?
- Coisa que guarda dado de cliente. LGPD. Uma planilha de clientes exportada "só pra testar uma ferramenta" já é um vazamento em potencial, e a empresa responde por ele, não o João.
- Coisa que precisa continuar funcionando daqui a um ano. É o argumento do post sobre os 80%: eles saem rápido, os 20% finais é que custam. Ferramenta de mesa não precisa dos 20%. Sistema precisa.
Ferramenta que só você usa pode ser gambiarra. Sistema que a empresa depende, não pode.
O perigo não está em nenhum dos dois lados. Está na passagem de um pro outro, que acontece sem ninguém perceber. A planilha automatizada que era só do analista vira a fonte oficial do número de vendas. O script do estagiário vira a integração com a transportadora. E ninguém decidiu isso. Aconteceu.
Três sinais de que a ferramenta virou sistema
Como a passagem é silenciosa, vale ter um radar. Eu uso três sinais, e basta um deles pra acender a luz:
- Alguém de outro setor reclama quando ela para. Se o financeiro liga pro marketing perguntando "cadê o relatório de hoje?", aquilo deixou de ser ferramenta de mesa. Tem gente dependendo.
- O número que sai dela vai pra uma reunião. No momento em que um dado gerado por aquele script entra numa decisão, ele precisa estar certo. E "precisa estar certo" é a definição de sistema.
- Alguém pede login. Quando uma segunda pessoa quer usar, aparecem perguntas que a gambiarra não responde: quem pode ver o quê, o que acontece se dois mexerem ao mesmo tempo, onde fica o histórico.
Nenhum desses sinais significa que a ferramenta é ruim. Significa que ela cresceu e merece ser tratada de acordo.
Como fazer funcionar sem virar bagunça
O que eu recomendo pra quem quer liberar a equipe e dormir tranquilo:
- Deixa claro o que pode e o que não pode. Uma página, não um manual. Pode: ferramenta pra você, protótipo, automação sem dado de cliente. Não pode: dinheiro, dado pessoal, coisa que outro setor vai depender.
- Tem alguém técnico olhando de longe. Não pra aprovar cada coisa. Pra perceber quando uma ferramenta de mesa virou sistema e precisa passar a ser tratada como tal.
- Quando virar sistema, formaliza. Código num repositório da empresa, acesso controlado, alguém responsável, um mínimo de teste. É nessa hora que a gente costuma entrar, e é muito mais barato entrar cedo do que reconstruir depois que a gambiarra virou coluna do prédio.
- Não deixa a fila da TI ser o motivo. Se a equipe está construindo por fora porque a TI nunca responde, o problema é a fila, não a IA. A IA só deixou o problema visível.
Eu gosto desse movimento. Quanto mais gente na empresa entende o que é possível construir, melhor fica a conversa na hora de construir algo de verdade. E é essa conversa que a gente tem aqui: você fala direto com quem desenvolve, chega com o protótipo que a sua equipe montou, e a gente decide junto o que daquilo vira produto e o que continua sendo ferramenta de mesa. Sem ninguém no meio dizendo que "isso aí precisa refazer tudo" só pra justificar a proposta.