O maior problema de construir software com IA não é gerar código. É impedir a IA de quebrar o que já funciona. · TransferIQ

Durante os últimos meses, construí um produto FinTech real usando IA como principal ferramenta de desenvolvimento.

Não sou engenheiro de software.

Minha experiência profissional é principalmente em operações, produto, fintech e cripto. Mesmo assim, consegui construir uma aplicação mobile, uma versão web, integrar dados, criar lógica de comparação, preparar builds Android e avançar até o processo de publicação.

No começo, eu pensava que o maior desafio seria:

"Como fazer a IA escrever o código certo?"

Hoje penso diferente.

O problema mais perigoso é:

Como impedir a IA de destruir silenciosamente algo que já estava funcionando?

E demorei bastante para entender isso.

1. A IA resolve um problema e pode recriar outro antigo

Um exemplo real do meu projeto.

Eu estava trabalhando em uma lógica para estimar spreads em corredores internacionais de câmbio.

Em alguns mercados emergentes e valores altos, como operações acima de 10.000, o sistema estava subestimando o spread.

Então implementei uma matriz chamada:

CORRIDOR_SPREAD_FLOOR

A ideia era aplicar um piso mínimo de spread dependendo de fatores como:

tipo de corredor
mercado
faixa de valor
comportamento do provedor

Isso resolveu um problema importante.

Depois, pedi para a IA trabalhar em outra parte do aplicativo.

O novo problema foi resolvido.

Mas surgiu uma dúvida:

A lógica anterior ainda existe?

Essa pergunta mudou meu processo de trabalho.

Porque uma IA pode editar um arquivo grande, reorganizar funções, substituir blocos e, no processo, remover silenciosamente algo que você levou horas para validar.

O código continua compilando.

A interface continua abrindo.

Mas uma regra de negócio pode simplesmente ter desaparecido.

2. Código compilando não significa produto correto

Esse talvez tenha sido um dos aprendizados mais importantes.

Em um produto financeiro, existem pelo menos três níveis diferentes:

O aplicativo abre?
O código funciona?
O resultado continua correto?

São perguntas completamente diferentes.

Meu aplicativo podia abrir normalmente.

Podia não apresentar nenhum erro visível.

Podia até gerar um build Android com sucesso.

E mesmo assim uma lógica importante de cálculo podia ter sido alterada.

Em outro caso real, trabalhei na exibição de rotas de off-ramp de cripto para moeda local.

Por exemplo:

USDT → BRL

A lógica deveria mostrar exchanges locais relevantes.

Depois de algumas alterações, alguns campos começaram a aparecer como:

undefined

O problema não era simplesmente "a interface está quebrada".

O problema estava no mapeamento entre estruturas de dados diferentes.

A solução exigiu criar uma camada de adaptação chamada:

adaptOffRampRow

Ela passou a converter os campos para o formato esperado pelo componente de renderização.

Funcionou.

Mas novamente surgiu o mesmo risco:

Na próxima grande alteração feita pela IA, essa adaptação continuará existindo?

3. Foi aí que parei de confiar apenas na conversa com a IA

No início, meu processo era aproximadamente assim:

Eu descrevia o problema
↓
A IA alterava o código
↓
Eu testava visualmente
↓
Se funcionasse, continuava

Hoje considero isso perigoso.

Meu processo ficou mais próximo disto:

Definir o problema
↓
Identificar quais regras atuais não podem desaparecer
↓
Alterar o código
↓
Verificar a presença das funções críticas
↓
Testar cenários concretos
↓
Comparar o resultado com dados reais
↓
Só depois gerar o build

Parece óbvio quando escrevemos assim.

Mas trabalhando rápido com IA, é muito fácil cair na armadilha de aceitar:

"Pronto, corrigi."

como prova de que o sistema está realmente correto.

Não é.

4. Comecei a usar verificações extremamente simples

Uma das técnicas mais úteis não foi sofisticada.

Foi simplesmente procurar no código se determinadas estruturas críticas ainda existiam.

Antes de gerar um novo build Android, por exemplo, passei a verificar elementos como:

CORRIDOR_SPREAD_FLOOR
adaptOffRampRow
links de parceiros que não poderiam desaparecer

No Windows, algo simples como:

findstr /C:"CORRIDOR_SPREAD_FLOOR" App.js

findstr /C:"adaptOffRampRow" App.js

já cria uma proteção mínima contra regressões silenciosas.

Não é um sistema perfeito.

Não substitui testes automatizados.

Mas para alguém construindo um produto praticamente sozinho, usando IA intensivamente, isso já reduz bastante o risco.

A ideia principal é:

Não verificar apenas se o novo código entrou. Verificar também se o código antigo importante não saiu.

5. Depois do código, passei a validar cenários de negócio

Outra mudança importante foi parar de testar apenas botões.

Hoje eu defino cenários concretos.

Por exemplo:

Cenário 1: USDT → BRL

Verificar se exchanges locais aparecem corretamente.

Não basta a tela abrir.

Preciso confirmar que nomes como Mercado Bitcoin ou Bitso aparecem corretamente e que nenhum campo crítico mostra undefined.

Cenário 2: Crypto → KRW

Verificar se uma exchange local aparece como rota direta e não como P2P quando a lógica do mercado exige negociação local.

Cenário 3: 10.000 USD → BRL

Comparar a estimativa com valores reais observados.

Se o mercado real indica uma faixa aproximada e meu sistema apresenta algo muito distante, o código pode estar "funcionando", mas o produto está errado.

Essa diferença é enorme.

6. Isso não é um exemplo hipotético

Todo esse processo nasceu enquanto eu construía o TransferIQ.

O produto compara rotas de transferência internacional, estimativas de recebimento, provedores tradicionais, rotas cripto e opções de off-ramp.

Em vez de mostrar apenas uma interface bonita, eu precisava lidar com problemas reais como:

diferenças de spread
faixas de valor
mercados emergentes
exchanges locais
rotas P2P
mapeamento de dados
estimativas que podem parecer tecnicamente corretas, mas economicamente erradas

Foi justamente por isso que comecei a perceber a diferença entre:

gerar software com IA

manter um produto real funcionando com IA

Para quem quiser ver o produto real por trás desses exemplos, deixo aqui:

TransferIQ: https://transferiq.org

Dá para testar diretamente no navegador e comparar diferentes rotas e mercados.

O produto ainda está evoluindo, então feedback técnico ou de UX é muito bem-vindo.

7. A IA me fez programar mais rápido, mas também criou uma nova categoria de dívida técnica

Antes, eu pensava em dívida técnica principalmente como:

código mal organizado
funções duplicadas
falta de documentação
arquitetura improvisada

Agora adicionaria outra categoria:

Dívida de contexto gerada por IA.

Ela aparece quando:

uma decisão antiga não está documentada
uma correção importante existe apenas dentro de uma conversa
uma função foi criada por uma IA, mas outra IA não entende por que ela existe
um arquivo grande é reescrito e regras antigas desaparecem
o desenvolvedor aceita uma alteração sem revisar os efeitos colaterais

Isso é especialmente perigoso em projetos construídos com múltiplos modelos ou agentes.

Um modelo resolve uma parte.

Outro modelo refatora.

Outro corrige um bug.

Outro melhora a interface.

Depois de dezenas de interações, ninguém possui uma visão perfeita do histórico completo.

Nem mesmo a IA.

8. Passei a tratar certas funções como "ativos protegidos"

Hoje, quando uma lógica foi difícil de construir e validar, eu mentalmente a classifico como algo que não pode ser alterado sem verificação.

Por exemplo:

lógica de spread
mapeamento de off-ramp
links de parceiros
regras específicas por mercado
filtros de P2P
cálculo de recebimento estimado

Antes de uma alteração grande, preciso saber:

O que estamos mudando?

O que não pode mudar?

Como vou verificar isso depois?

Essa abordagem parece muito mais importante do que simplesmente escrever um prompt melhor.

9. Meu maior aprendizado: prompts não substituem processo

Existe muita discussão sobre:

prompt perfeito
melhor modelo
melhor agente
melhor IDE com IA
vibe coding
context window

Tudo isso importa.

Mas, depois de construir um produto real, minha conclusão é outra:

Um processo ruim continua ruim, mesmo com uma IA excelente.

Você pode usar o melhor modelo disponível.

Ainda assim, se não souber:

o que validar
o que comparar
o que preservar
quais cenários testar
quais resultados são aceitáveis

a IA pode simplesmente ajudá-lo a cometer erros mais rápido.

10. Para mim, a IA não eliminou a engenharia. Ela mudou onde está a dificuldade.

Eu continuo não sendo engenheiro de software.

Ainda existem muitas áreas técnicas que estou aprendendo.

Mas construir um produto real me ensinou algo importante:

O gargalo não é mais apenas escrever sintaxe.

A IA consegue gerar muito código.

O desafio passa a ser:

definir corretamente o problema
preservar regras de negócio
controlar regressões
validar resultados
manter contexto
distinguir código funcional de produto correto

Talvez essa seja uma das maiores diferenças entre criar um protótipo com IA e manter um produto real com IA.

Um protótipo precisa funcionar uma vez.

Um produto precisa continuar funcionando depois da próxima alteração.

E da próxima.

Hoje, antes de comemorar quando a IA diz:

"Corrigido com sucesso."

eu faço outra pergunta:

O que ela pode ter quebrado enquanto corrigia isso?

Curiosamente, essa pergunta simples melhorou muito mais meu processo do que tentar escrever prompts cada vez mais sofisticados.

Estou curioso para saber como outras pessoas que usam IA intensivamente no desenvolvimento lidam com esse problema.

Vocês já tiveram casos em que a IA resolveu um bug e silenciosamente recriou outro que já estava corrigido?