Como o Cursor criou, em três dias e por US$ 180, um protótipo que dividiu uma equipe de desenvolvimento

Em uma grande empresa de TI, um experimento com o Cursor virou rapidamente uma disputa sobre o que pesa mais: a velocidade de entrega ou a manutenibilidade do código. Um arquiteto de sistemas gastou US$ 180 em três dias e mostrou ao negócio um resultado clicável, enquanto a equipe passou três meses construindo um módulo tipado e coberto por testes.

Três dias contra três meses

Tudo começou como um piloto comum de ferramenta de IA. A equipe tinha cinco desenvolvedores, e a empresa concordou em reembolsar a cada um a assinatura do Cursor, de US$ 20 por mês. Após um mês, os números pareciam tranquilos: três funcionários haviam gasto US$ 60 no total. Mas depois se descobriu que o arquiteto de sistemas tinha consumido US$ 180 em apenas três dias.

Ele usou o modo Agent, carregou no editor um layout do Figma, um componente antigo e um prompt de texto, e daí em diante quase não escreveu código à mão. O Cursor gerava as interfaces, lia os erros do terminal, corrigia e rodava o build de novo.

No outro extremo estava a equipe, que levou três meses para fazer seu módulo seguindo as regras clássicas. Eles tinham TypeScript, code review, Storybook, JSDoc e cerca de 300 testes unitários, com cobertura de pelo menos 85%. No mesmo período, o arquiteto obteve um protótipo clicável com mais funções, mas em Vanilla JS e com cerca de cinco testes.

Quando as duas versões foram colocadas lado a lado, o negócio não viu disciplina de desenvolvimento, e sim dois ritmos de entrega: lento e confiável contra rápido e vistoso.

Por que o protótipo venceu

A decisão foi tomada em uma reunião com analistas de negócio e a diretoria. Para a equipe de engenharia, sua versão parecia madura: seguia a stack e os padrões e podia ser mantida por qualquer desenvolvedor. Mas, para o negócio, o critério decisivo foi outro: resultado visível agora.

O protótipo do arquiteto podia ser clicado, rolado e apresentado como um produto quase pronto. O módulo da equipe era melhor por dentro, mas por fora impressionava menos, porque a maior parte do esforço foi para a fundação, e não para funções de demonstração.

"Os testes a gente escreve depois, o mercado não vai esperar."

Essa lógica foi o ponto de ruptura. A equipe não quis migrar seu trabalho para a solução do arquiteto: outra stack, quase nenhuma documentação e verificações de menos. O arquiteto, por sua vez, achava que os colegas complicavam o processo e perdiam tempo, já que uma versão funcional existia.

Como resultado, um mesmo projeto passou a ter duas soluções paralelas para a mesma tarefa. No papel, há progresso, mas a empresa agora não tem uma arquitetura única, e sim um conflito entre velocidade, padrões e responsabilidade pela manutenção futura.

O outro lado da velocidade da IA

O principal risco dessa história não é apenas dívida técnica, mas o que os autores chamam de dívida de IA. Na correria comum, a equipe ao menos sabe o que terá de reescrever depois. Aqui o problema é mais profundo: o código é gerado tão rápido que o próprio autor pode não entender os detalhes da implementação. Se mais tarde surgir um bug ou mudar uma regra de negócio, a manutenção terá de ser delegada de novo ao modelo, na esperança de que ele reconstrua o contexto corretamente e não comece a alucinar sobre um código já gerado.

• Não há stack nem tipagem comuns com os quais a equipe possa contar
• Testes e documentação quase não existem, então as mudanças ficam menos previsíveis
• O bus factor tende a um: a manutenção depende de um único autor e da mesma ferramenta
• Qualquer novo requisito aumenta o risco de quebrar um código que ninguém entende direito

Os autores do caso não pedem a proibição do Cursor. A conclusão deles é prática: o problema não está na ferramenta, mas na falta de regras antes do início do trabalho. Se a equipe tivesse definido de antemão uma stack obrigatória, um conjunto mínimo de testes e um formato de revisão para código gerado por IA, a disputa poderia não ter surgido. O Cursor pode servir para acelerar a busca de soluções, rascunhos e protótipos, mas não para substituir o raciocínio de engenharia. Caso contrário, o desenvolvedor deixa de escrever um sistema e passa a observar o sistema se escrever sozinho.

O que isso significa

O caso do Cursor mostra que a IA já muda não só a velocidade do desenvolvimento, mas também a política interna das equipes. Nessas disputas, vencerá não quem tem o modelo mais forte, e sim quem primeiro combinar os limites: onde um protótipo rápido é aceitável e onde um código sem testes, sem tipagem e sem uma stack comum simplesmente não pode ser considerado pronto.