Você descreve o que quer, aperta enter, e sai um app funcionando, completo, de primeira. Não é assim que funciona. Pelo menos não pra nada real.

Eu construí o Kanario, um gerador de thumbnails pra blog que puxa um rascunho do WordPress, passa por uma LLM pra gerar prompts de imagem, e gera capas. Tem CLI, bot no Discord, dois backends de LLM, dois backends de geração de imagem, criptografia de credenciais por usuário, deploy no Cloud Run e pipeline completo de CI/CD. Com desenvolvimento assistido por IA, levou quatro dias. Uma estimativa tradicional colocaria entre 7 e 11 semanas pra um dev senior sozinho.

Isso é um ganho de 4-6x. Mas aconteceu num lugar bem específico.

Geração de código ficou rápida. O resto ficou igual.

Todo boilerplate: hierarquias de classes de erro, mocks de teste, parsing de argumentos CLI, handling de interações do Discord, Dockerfile, YAML do GitHub Actions. Foi de horas pra minutos. São coisas onde você sabe exatamente o que quer, mas digitar é tedioso. A IA remove essa fricção.

APIs desconhecidas foram outro grande ganho. Ao invés de gastar uma hora lendo a doc de async polling do RunPod ou tentando entender a verificação de assinatura Ed25519 do Discord, eu descrevia a intenção e iterava no resultado. O ciclo de exploração que costumava ser “lê doc, tenta algo, lê mais doc, conserta” comprimiu pra “descreve o que preciso, ajusta a saída.”

Escrever testes ficou muito mais rápido também. Uma vez que os padrões estavam estabelecidos (mock de HttpClient, mocks a nível de módulo com variáveis substituíveis, Fastify inject pra rotas HTTP), eu descrevia um novo caso de teste e recebia um teste funcionando em segundos.

Mas arquitetura? Toda decisão sobre como o sistema deveria ser estruturado exigiu pensar. Injeção de dependência do HttpClient. O schema compartilhado do gerador de prompts entre Gemini e Claude. A camada de workflow que permite CLI e Discord usarem a mesma lógica. A hierarquia de erros com hints acionáveis por código de erro do WordPress.

A IA não acelerou essas decisões porque o gargalo nunca foi digitar o código. Era descobrir a abstração certa.

Os bugs que a IA não enxerga sozinha

Prompt engineering foi todo manual. Quando o Qwen começou a renderizar a palavra “robot” como uma cópia do personagem mascote, nenhuma ferramenta de IA poderia ter me avisado. Eu tive que olhar as imagens geradas, notar o problema, levantar a hipótese de que a palavra “robot” estava conflitando com a imagem de referência, testar com “bot buddy” no lugar, e verificar a correção em múltiplas gerações.

Claro, IAs conseguem “ver” imagens hoje. Depois de identificar o problema, eu montei um smoke test onde o Claude analisava as imagens geradas e comparava com o que era esperado. Funcionou. Mas alguém precisou notar o problema primeiro, formular a hipótese, e montar a validação. A IA executou o teste. Eu defini o que testar.

Mesma coisa com o bug de balanceamento de quota da LLM. O gerador de prompts produzia exatamente 3 cenas com mascote e 1 diorama sem mascote, sempre. Estava balanceando internamente, tentando me dar uma “mistura legal.”

Corrigir exigiu entender que a formulação do system prompt estava incentivando isso sem eu perceber, e reescrever pra dizer “decida independentemente por cena.” A IA não pegou isso. Eu peguei porque a saída parecia errada.

Onde isso nos deixa

O multiplicador é real. 4-6x nesse projeto. Mas vem de eliminar as partes mecânicas do desenvolvimento: traduzir decisões em sintaxe, escrever padrões repetitivos, conectar APIs que você entende conceitualmente mas não decorou.

As decisões em si, o que construir, como estruturar, quando algo parece errado, continuam sendo suas. E se você tenta pular elas, se deixa a IA tomar decisões de arquitetura por você, acaba com uma codebase que funciona inicialmente mas briga com você toda vez que precisa mudar algo. A IA não conhece suas restrições nem seus usuários. Ela conhece sintaxe.

O pensamento continua sendo o trabalho. A digitação é que ficou mais barata.

Por hoje é só.