A sua mensagem foi enviada.
Processaremos o seu pedido e contactá-lo-emos logo que possível.
O formulário foi enviado com sucesso.
Encontrará mais informações na sua caixa de correio.
Selecionar a língua
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.
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.
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."
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."
Diretor Técnico
Após uma dúzia destes casos, começam a surgir padrões:
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.
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 problema foi detectado no guião. Ele fez a extração básica, mas fez três suposições fatais:
NULL
valores ou chaves em falta na estrutura JSON.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.
Designámos uma pequena equipa para resolver a confusão. Eis o que fizemos:
Dois engenheiros, três dias. Custo para o cliente: cerca de $4,500 em taxas de serviço.
Mas o maior impacto veio das consequências para os clientes. As notificações falhadas levaram à perda de pagamentos e ao abandono do serviço. O cliente disse-nos que gastou pelo menos $10,000 em bilhetes de suporte, compensação de SLA e créditos de boa vontade por causa de um script mal feito.
O mais irónico é que um programador sénior poderia ter escrito a migração correta em talvez quatro horas. Mas a promessa de velocidade AI acabou por custar-lhes duas semanas de limpeza e danos à reputaçã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.
Eis o que aconteceu de facto:
X-RateLimit-Remaining
ou Retry-After
cabeçalhos. Continuava a enviar pedidos às cegas.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.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.
A parte assustadora não é o facto de estas coisas correrem mal. É o facto de se estar a tornar tudo tão previsível.
Cada um destes incidentes segue o mesmo padrão. Um programador pede ao ChatGPT um excerto de código. Ele devolve algo que funciona bem o suficiente para não dar erros. O programador insere-o no sistema, talvez o limpe um pouco, e envia-o, assumindo que se compila e corre, deve ser seguro.
Mas aqui está o senão: Os grandes modelos linguísticos não conhecem o seu sistema.
Não sabem como os seus serviços interagem.
Eles não conhecem seu orçamento de latência, seu pipeline de implantação, sua configuração de observabilidade ou seus padrões de tráfego de produção.
Geram o código mais provável com base em padrões nos seus dados de treino. É só isso. Não há consciencialização. Não há garantias. Nenhuma intuição para o design do sistema.
E os resultados reflectem-no frequentemente:
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.
Como mencionámos anteriormente, também utilizamos o AI. Praticamente todos os engenheiros da nossa equipa têm uma configuração do tipo Copilot a funcionar localmente. É rápido, útil e, honestamente, uma óptima maneira de saltar as partes aborrecidas.
Mas aqui está a diferença: nada chega ao ramo principal sem passar por um engenheiro sénior e, na maioria dos casos, por um pipeline de CI que sabe o que procurar.
Os LLMs são óptimos em:
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:
Usado corretamente, poupa tempo. Usado às cegas, é uma bomba-relógio.
Não estamos aqui para vos dizer que devem proibir as ferramentas AI. Esse navio já partiu.
Mas dar acesso a um modelo linguístico? Isso é pedir para ter problemas.
Eis o que recomendamos em vez disso:
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.
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.
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.
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.
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.
O AI pode ajudá-lo a mover-se mais rapidamente. Mas não pode pensar por si.
Não compreende a sua arquitetura. Não sabe o que significa "feito" no seu contexto. E, definitivamente, não se importa se o seu pipeline de dados se avaria silenciosamente numa sexta-feira à noite.
É por isso que, como CTOs, precisamos de nos concentrar na resiliência do sistema e não apenas na velocidade.
É tentador deixar o AI tratar das partes aborrecidas. E, por vezes, isso é ótimo. Mas todo atalho tem uma contrapartida. Quando o código gerado pelo AI não é verificado, muitas vezes ele se torna uma dívida técnica do AI. Do tipo que não se vê até a equipa de operações estar a combater o fogo na produção.
Se já se deparou com essa barreira, não está sozinho. Já ajudámos equipas a recuperar de tudo, desde migrações falhadas a desastres de API. Não nos limitamos a refatorar o código. Ajudamos a refatorar o pensamento por trás dele.
Porque, no fim de contas, é isso que torna os sistemas fiáveis.
A sua mensagem foi enviada.
Processaremos o seu pedido e contactá-lo-emos logo que possível.
Ao inscrever-se, o utilizador concorda com a nossa Política de privacidadeincluindo a utilização de cookies e a transferência das suas informações pessoais.