Primeiro, utilizaram o ChatGPT para reduzir os custos. Depois, contrataram-nos para limpar a dívida técnica do AI

Philip Tihonovich

29 de maio de 2025 10 min de leitura

Ficaria surpreendido com o número de empresas que o fazem atualmente.

Como indicam os relatórios de toda a indústria, existe agora um sector especializado em crescimento para engenheiros que se concentram na correção de erros de código gerados pelo AI.

O padrão tornou-se notavelmente consistente. As empresas recorrem ao ChatGPT para gerar scripts de migração, integrações ou funcionalidades completas, na esperança de poupar tempo e reduzir custos. Afinal de contas, a tecnologia parece ser rápida e acessível.

Depois os sistemas falham.

E eles telefonam-nos.

Recentemente, temos recebido cada vez mais pedidos deste género. Não para lançar um novo produto, mas para desfazer qualquer confusão que tenha ficado para trás depois de alguém ter confiado num modelo de linguagem com o seu código de produção.

Neste momento, está a começar a parecer um nicho de indústria próprio. A correção de erros gerados pelo AI é agora um serviço a faturar. E, nalguns casos, muito caro.

Relatório 2024 da GitClear confirma o que temos visto com os clientes: As ferramentas de codificação AI estão a acelerar a entrega, mas também a alimentar a duplicação, a reduzir a reutilização e a inflacionar os custos de manutenção a longo prazo.

Num caso, um cliente procurou-nos depois de uma migração gerada pelo AI ter deixado cair dados críticos do cliente. Nós gastámos 30 horas a recuperar o que se perdeu, a reescrever a lógica de raiz e a limpar o pipeline. A parte irónica é que teria sido mais barato ter um programador sénior a escrevê-lo à moda antiga.

No entanto, sejamos claros, não estamos "contra o AI". Nós também o usamos. E é útil no contexto certo, com as protecções certas. Mas o que me frustra na confiança excessiva no AI e nas suas implicações generalizadas - e provavelmente a si também - é o pensamento mágico. A ideia de que um modelo linguístico pode substituir o verdadeiro trabalho de engenharia.

Não pode. E como diz o ditado, a prova está no pudim. Quando as empresas fingem o contrário, acabam por pagar a alguém como nós para o limpar.

Então, como é que é um destes trabalhos de limpeza? Eis o que os AI-afficionados não vos dizem quando se trata de tempo perdido e dinheiro desperdiçado.

Qual o aspeto de um pedido típico

A mensagem normalmente vem assim:

"Ei, podes dar uma vista de olhos a um microserviço que construímos? Usámos o ChatGPT para gerar a primeira versão. Enviámo-la para o staging e agora a nossa fila RabbitMQ está completamente inundada."

Começa sempre por algo pequeno. Uma tarefa que parecia demasiado aborrecida ou demorada. Algo como analisar um CSV, reescrever um cron job ou ligar um simples webhook. Então, entregam-na a um modelo de linguagem e esperam pelo melhor.

Mas o que se passa é que os sintomas aparecem muito mais tarde. Por vezes, dias mais tarde. E quando aparecem, raramente é óbvio que a causa raiz foi o código gerado pelo AI. Parece apenas que... algo está errado.

"Não se pode subcontratar o pensamento arquitetónico a um modelo de linguagem. O AI pode acelerar as coisas, mas ainda são necessários engenheiros para construir sistemas que não se desmoronem sob pressão."

Dmitry Nazarevich

Diretor Técnico

Após uma dúzia destes casos, começam a surgir padrões:

Sem testes. De todo. Nem sequer um "hello-world assert". Apenas código bruto e especulativo que nunca foi exercitado corretamente.
Sem consciência dos limites do sistema. Já vimos scripts ChatGPT que consultam três microsserviços de forma síncrona, ignoram timeouts e explodem toda a cadeia de chamadas na primeira falha.
Utilização abusiva das transacções. Um cliente utilizou SQL gerada pelo AI com transacções aninhadas dentro de um serviço Node.js utilizando o Knex. Funcionou, até que não funcionou, e metade das escritas falharam silenciosamente.
Condições subtis da corrida. Especialmente em bases de código multithreaded ou async-heavy. O tipo de bugs que não aparecem no desenvolvimento, mas que destroem a produção em escala.

E, claro, quando tudo se desmorona, o AI não deixa um comentário a dizer: "A propósito, estou a adivinhar".

Essa parte é por tua conta.

Caso 1: O script de migração que deixou cair silenciosamente os dados dos clientes

Esta veio de uma empresa de fintech em rápido crescimento.

Eles estavam a lançar uma nova versão do seu modelo de dados de clientes, dividindo um grande campo JSONB no Postgres em várias tabelas normalizadas. Coisas bastante comuns. Mas com prazos apertados e sem mãos suficientes, um dos programadores decidiu "acelerar as coisas" pedindo ao ChatGPT para gerar um script de migração.

Parecia bom à primeira vista. O script analisou o JSON, extraiu as informações de contato e as inseriu em um novo user_contacts mesa.

Por isso, eles fizeram-no.

Não há ensaio. Sem backup. Diretamente para a fase de preparação, que, como se verificou, partilhava dados com a produção através de uma réplica.

Algumas horas mais tarde, o apoio ao cliente começou a receber mensagens de correio eletrónico. Os utilizadores não estavam a receber notificações de pagamento. Outros tinham números de telefone em falta nos seus perfis. Foi então que nos telefonaram.

O que correu mal

O problema foi detectado no guião. Ele fez a extração básica, mas fez três suposições fatais:

Não tratou de NULL valores ou chaves em falta na estrutura JSON.
Introduziu registos parciais sem validação.
Utilizou ON CONFLICT DO NOTHING, pelo que quaisquer inserções falhadas foram silenciosamente ignoradas.

Resultado: sobre 18% dos dados de contacto foi perdido ou corrompido. Não há registos. Não há mensagens de erro. Apenas perda de dados silenciosa.

O que foi necessário para corrigir

Designámos uma pequena equipa para resolver a confusão. Eis o que fizemos:

Diagnóstico e reprodução (4 horas) Recriámos o script num ambiente sandbox e executámo-lo contra um instantâneo da base de dados. Foi assim que confirmámos o problema e identificámos exatamente o que faltava.
Auditoria forense de dados (8 horas) Comparámos o estado quebrado com as cópias de segurança, identificámos todos os registos com dados em falta ou parciais e comparámo-los com os registos de eventos para identificar quais as inserções que falharam e porquê.
Reescrever a lógica da migração (12 horas) Reescrevemos todo o script em Python, adicionámos uma lógica de validação completa, criámos um mecanismo de reversão e integrámo-lo no pipeline de CI do cliente. Desta vez, ele incluiu testes e suporte a dry-run.
Recuperação manual de dados (6 horas) Alguns registos não podiam ser recuperados das cópias de segurança. Extraímos os campos em falta de sistemas externos (as APIs do CRM e do fornecedor de correio eletrónico) e restaurámos manualmente os restantes.

Tempo total: 30 horas de engenharia

Dois engenheiros, três dias. Custo para o cliente: cerca de $4,500 in service fees.

But the bigger hit came from customer fallout. Failed notifications led to missed payments and churn. The client told us they spent at least $10,000 on support tickets, SLA compensation, and goodwill credits over that one botched script.

The ironic thing is that a senior developer could’ve written the correct migration in maybe four hours. But the promise of AI speed ended up costing them two weeks of cleanup and reputation damage.

Nós consertamos o que o ChatGPT quebrou - e construímos o que ele não conseguiu.

Caso 2: O cliente API que ignorou os limites de taxa e interrompeu a produção

Esta veio de uma startup de tecnologia jurídica que estava a criar uma plataforma de gestão de documentos para escritórios de advogados. Uma das suas principais caraterísticas era a integração com um serviço de notificação eletrónica do governo - uma API REST de terceiros com OAuth 2.0 e uma limitação rigorosa da taxa: 50 pedidos por minuto, sem excepções.

Em vez de atribuir a integração a um programador de backend experiente, alguém da equipa decidiu fazer um "protótipo" utilizando o ChatGPT. Introduziram a especificação OpenAPI, pediram um cliente Python e obtiveram um script de aspeto limpo com requests, lógica de repetição utilizando tenacity, e atualização do token.

Parecia sólido no papel. Por isso, enviaram-no.

O que correu mal

No início, tudo parecia estar bem. O cliente tratava corretamente os pedidos individuais, passava a autenticação e até tentava novamente em caso de falha. Mas durante a utilização real, especialmente sob carga, a plataforma começou a comportar-se de forma imprevisível.

Eis o que aconteceu de facto:

Não respeita os limites das tarifas. O código gerado não lia nem interpretava X-RateLimit-Remaining ou Retry-After cabeçalhos. Continuava a enviar pedidos às cegas.
As repetições pioraram a situação. Quando começaram a aparecer 429 erros, o decorador tenacity tentou-os novamente de forma automática. Sem jitter. Sem filas de espera. Apenas uma enxurrada de pedidos de acompanhamento.
O fornecedor da API bloqueou temporariamente o seu IP. Durante 3 horas, ninguém na plataforma conseguiu sincronizar documentos. Sem registos, sem alertas. Apenas uma falha silenciosa.

Não se tratava de uma correção de uma linha. Foi um mal-entendido sobre como os sistemas de produção se comportam. E é um ótimo exemplo do que os LLMs não sabem; não porque eles estão quebrados, mas porque eles não têm consciência do tempo de execução.

Pare de corrigir o código gerado pelo AI no prod - traga-nos antes que ele quebre.

Como o corrigimos

Detetar e isolar a falha (6 horas) Adicionámos middleware para inspecionar o tráfego de saída e confirmámos o fluxo de pedidos durante o pico de utilização. Também recriámos a falha na preparação para compreender totalmente o padrão de ativação.
Reconstruir o cliente API (10 horas) Reescrevemos o cliente usando httpx.AsyncClient, implementou um acelerador baseado em semáforo, adicionou backoff exponencial com jitter e tratou corretamente Retry-After e cabeçalhos de limite de débito.
Teste de esforço e validação (6 horas) Simulámos a utilização no mundo real com milhares de pedidos em simultâneo utilizando o Locust, testámos o rate throttling em diferentes cenários de burst e confirmámos zero 429s sob carga sustentada.
Adicionar monitorização e alertas (4 horas) Configurámos métricas Prometheus personalizadas para controlar a utilização da API por minuto e adicionámos alertas para notificar a equipa caso se aproximasse dos limites de taxa.

Tempo total: 26 horas

Dois engenheiros, distribuídos por dois dias e meio. Custo para o cliente: cerca de $3,900.

O maior problema foi o facto de o seu maior cliente - um escritório de advogados com processos urgentes - ter perdido duas janelas de apresentação em tribunal devido à falha de energia. O cliente teve de fazer controlo de danos e oferecer um desconto para manter a conta.

Tudo porque um modelo de linguagem não entendia a diferença entre "código de trabalho" e "código pronto para produção". E, sem mais nem menos, outra camada de dívida técnica AI foi discretamente adicionada à pilha.

Porque é que isto continua a acontecer

The scary part isn’t that these things go wrong. It’s how predictable it’s all becoming.

Every one of these incidents follows the same pattern. A developer asks ChatGPT for a code snippet. It returns something that works just well enough not to throw errors. They wire it into the system, maybe clean it up a little, and ship it, assuming that if it compiles and runs, it must be safe.

But here’s the catch: Large language models don’t know your system.
They don’t know how your services interact.
They don’t know your latency budget, your deployment pipeline, your observability setup, or your production traffic patterns.

They generate the most likely-looking code based on patterns in their training data. That’s all. There’s no awareness. No guarantees. No intuition for system design.

And the output often reflects that:

Código que funciona uma vez, mas falha sob carga
Sem programação defensiva, sem segurança contra falhas
Fraca compreensão das restrições do mundo real, como limites de taxa, tempos limite ou eventual consistência
Absolutamente nenhum sentido de intenção arquitetónica

O pior é que o código parece correto. É sintaticamente limpo. Passa nos linters. Pode até ser coberto por um teste básico. Mas está a faltar a única coisa que realmente importa: o contexto.

É por isso que estes erros não aparecem de imediato. Esperam pelas implementações de sexta-feira à noite, por janelas com muito tráfego, por casos raros. Essa é a natureza da dívida técnica do AI - é invisível até quebrar algo crítico.

Quando o AI ajuda de facto

As we mentioned earlier, we use AI too. Pretty much every engineer on our team has a Copilot-like setup running locally. It’s fast, helpful, and honestly, a great way to skip the boring parts.

But here’s the difference: nothing makes it into the main branch without going through a senior engineer, and in most cases, a CI pipeline that knows what to look for.

LLMs are great at:

um modelo de andaimes para novos serviços ou pontos de extremidade de API,
gerar cobertura de teste para a lógica existente,
ajudar na refacção repetitiva em grandes bases de código,
traduzindo simples scripts de shell em modelos de infraestrutura como código,
ou mesmo comparando abordagens algorítmicas que já compreendemos.

O que são não bom é o design. Ou contexto. Ou em predefinições seguras.

É por isso que criámos os nossos fluxos de trabalho para tratar os resultados do LLM como sugestões e não como fonte de verdade. Aqui está o que isso parece na prática:

Marcamos todos os commits gerados pelo AI para que sejam fáceis de rastrear e revisar.
Os nossos editores têm avisos em linha, mas com ganchos de pré-compromisso que bloqueiam qualquer coisa sem testes ou documentação.
Nosso CI inclui regras de análise estática que sinalizam padrões inseguros que já vimos antes em LLMs: coisas como tentativas não protegidas, timeouts sem escopo, análise ingênua de JSON ou manipulação insegura de SQL.
Cada pedido pull com código gerado pelo LLM passa por uma revisão humana obrigatória, normalmente por alguém sénior que compreende a lógica do domínio e a superfície de risco.

Usado corretamente, poupa tempo. Usado às cegas, é uma bomba-relógio.

O que recomendamos aos CTOs

We’re not here to tell you to ban AI tools. That ship has sailed.

But giving a language model commit access? That’s just asking for trouble.

Here’s what we recommend instead:

1. Tratar os LLM como ferramentas e não como engenheiros

Deixe-os ajudar com código repetitivo. Deixe-os propor soluções. Mas não lhes confiar decisões críticas. Qualquer código gerado pelo AI deve ser revisto por um engenheiro sénior, sem excepções.

2. Tornar o código gerado pelo LLM rastreável

Quer se trate de etiquetas de confirmação, metadados ou comentários no código, tornar claro quais as peças provenientes do AI. Isto facilita a auditoria, a depuração e a compreensão do perfil de risco mais tarde.

3. Definir uma política de geração

Decidir em equipa onde é aceitável utilizar os LLM e onde não é. Modelo? Claro. Fluxos de autenticação? Talvez. Sistemas transaccionais? Absolutamente não sem revisão. Tornar a política explícita e parte das vossas normas de engenharia.

4. Adicionar monitorização ao nível do DevOps

Se está a deixar o código gerado pelo AI entrar em produção, tem de assumir que algo acabará por falhar. Adicione verificações sintéticas. Monitores de limite de taxa. Controlo de dependências. Tornar visível o invisível, especialmente quando o autor original não é humano.

5. Construir para a capacidade de recuperação

As maiores falhas causadas pelo AI que vimos não vieram de código "ruim". Elas vieram de erros silenciosos - dados ausentes, filas quebradas, tempestades de tentativas - que passaram despercebidos por horas. Investir em observabilidade, lógica de recurso e reversões. Especialmente se estiver a deixar o ChatGPT escrever migrações.

Em suma, o AI pode poupar tempo à sua equipa, mas não pode assumir a responsabilidade.

Isso continua a ser um trabalho humano.

Pensamentos finais: AI ≠ engenheiros de software

AI can help you move faster. But it can’t think for you.

It doesn’t understand your architecture. It doesn’t know what “done” means in your context. And it definitely doesn’t care if your data pipeline silently breaks on a Friday night.

That’s why, as CTOs, we need to stay focused on system resilience, not just speed.

It’s tempting to let AI handle the boring parts. And sometimes that’s fine. But every shortcut comes with a tradeoff. When AI-generated code slips through unchecked, it often becomes AI technical debt. The kind you don’t see until your ops team is firefighting in production.

If you’ve already run into that wall, you’re not alone. We’ve helped teams recover from everything from broken migrations to API disasters. We don’t just refactor code. We help refactor the thinking behind it.

Because in the end, that’s what actually makes systems reliable.

Philip Tikhanovich

Chefe do departamento Python, Big Data, ML/DS/AI

O Philip dá uma atenção especial a tudo o que diz respeito a dados e ao AI. É ele que faz as perguntas certas desde o início, define uma forte visão técnica e garante que não estamos apenas a construir sistemas inteligentes - estamos a construir os sistemas certos, para um verdadeiro valor comercial.

Ler mais

Índice

Contactar-nos

Marcar uma chamada ou preencha o formulário abaixo e entraremos em contacto consigo assim que tivermos processado o seu pedido.

Nome

Empresa

Correio electrónico

Telefone

Mensagem

Envie-nos uma mensagem de voz

Anexar documentos

Enviar ficheiro

Pode anexar um ficheiro com um máximo de 2MB. Formatos de ficheiro válidos: pdf, jpg, jpeg, png.

Ao clicar em Enviar, o utilizador autoriza a Innowise a processar os seus dados pessoais de acordo com a nossa Política de privacidade para lhe fornecer informações relevantes. Ao enviar o seu número de telefone, o utilizador aceita que o possamos contactar através de chamadas de voz, SMS e aplicações de mensagens. Poderão ser aplicadas tarifas de chamadas, mensagens e dados.

Pode também enviar-nos o seu pedido
para contact@innowise.com

O que é que acontece a seguir?

Assim que recebermos e processarmos o seu pedido, entraremos em contacto consigo para necessidades do seu projeto e assinar um NDA para garantir a confidencialidade.

Depois de analisarmos os seus desejos, necessidades e expectativas, a nossa equipa elaborará uma proposta de projeto proposta de projeto com o âmbito do trabalho, dimensão da equipa, tempo e estimativas de custos.

Marcaremos uma reunião consigo para discutir a oferta e acertar os pormenores.

Por fim, assinaremos um contrato e começaremos a trabalhar no seu projeto imediatamente.