Como Cursor Criou um Protótipo em Três Dias por $180 Que Dividiu o Time de Desenvolvimento

Como Cursor em três dias e $180 criou um protótipo que dividiu o time de desenvolvimento

Em uma grande empresa de TI, um experimento com Cursor rapidamente se transformou em uma disputa sobre o que é mais importante: velocidade de entrega ou gerenciabilidade do código. Um arquiteto de sistemas gastou $180 em três dias e mostrou ao negócio um resultado clicável, enquanto o time passou três meses construindo um módulo tipado e com testes.

Três dias contra três meses

A história começou como um piloto típico de ferramenta de IA. O time tinha cinco desenvolvedores, e a empresa concordou em reembolsar a assinatura do Cursor de $20 por mês para cada funcionário. Depois de um mês, os números pareciam calmos: três funcionários juntos gastaram $60.

Mas então descobriu-se que o arquiteto de sistemas havia gasto $180 em apenas três dias. Ele usou o modo Agent, carregou um layout do Figma no editor, um componente antigo e um prompt em texto, e depois quase nunca escreveu código à mão. O Cursor gerou interfaces por si só, leu erros no terminal, corrigiu-os e executou a compilação novamente.

No outro extremo estava o time que passou três meses construindo seu módulo pelas regras clássicas. Eles tinham TypeScript, code review, Storybook, JSDoc e cerca de 300 testes unitários com cobertura não menor que 85%. O arquiteto no mesmo tempo conseguiu um protótipo clicável com muitos recursos, mas em Vanilla JS e com aproximadamente cinco testes.

Quando ambas as opções foram colocadas lado a lado, o negócio não viu disciplina de desenvolvimento, mas dois tempos de entrega diferentes: lento e confiável contra rápido e eficaz.

Por que o protótipo venceu

A decisão foi tomada em uma reunião com analistas de negócios e gerência. Para o time de engenharia, sua versão parecia madura: correspondia à stack, aos padrões e poderia ser mantida por qualquer desenvolvedor. Mas para o negócio, o critério decisivo era diferente — um resultado visível agora. O protótipo do arquiteto podia ser clicado, rolado e mostrado como um produto quase pronto. O módulo do time era de melhor qualidade por dentro, mas parecia menos impressionante por fora, porque a maioria do esforço foi para a fundação, não para recursos de demonstração.

"Os testes podem ser adicionados depois, o mercado não vai esperar."

Essa lógica se tornou o ponto de ruptura. O time não quis transferir seu trabalho para a solução do arquiteto: tem uma stack diferente, quase nenhuma documentação e muito poucas verificações. O arquiteto, por outro lado, acreditava que os colegas estavam complicando o processo e perdendo tempo, embora uma forma funcional já existisse. Como resultado, duas soluções paralelas para uma mesma tarefa apareceram em um projeto. Formalmente há progresso, mas a empresa agora tem não uma arquitetura unificada, mas um conflito entre velocidade, padrões e responsabilidade pela manutenção futura.

O lado negativo da velocidade de IA

O principal risco nesta história não é apenas débito técnico, mas o que os autores chamam de débito de IA. Em uma pressa regular, o time pelo menos entende o que precisará ser reescrito depois. Aqui o problema é mais profundo: o código é gerado tão rapidamente que o próprio autor pode não entender os detalhes da implementação. Se um bug aparecer depois ou uma regra de negócio mudar, a manutenção terá que ser delegada novamente ao modelo, esperando que ele restaure corretamente o contexto e não comece a alucinar sobre o código já gerado.

• Nenhuma stack unificada e tipagem em que o time confia
• Quase nenhum teste e documentação, então a previsibilidade das mudanças cai
• Bus factor tende para um: o suporte depende de um autor e da mesma ferramenta
• Qualquer novo requisito aumenta o risco de quebrar código que ninguém realmente entende

Os autores do caso não pedem que o Cursor seja proibido. Pelo contrário, sua conclusão é prática: o problema não está na ferramenta, mas na falta de regras antes de começar o trabalho. Se o time tivesse antecipadamente fixado a stack obrigatória, o conjunto mínimo de testes e o formato de revisão para código gerado por IA, a disputa poderia não ter surgido. O Cursor pode ser usado como um acelerador para encontrar soluções, rascunhos e protótipos, mas não como substituição do pensamento de engenharia. Caso contrário, o desenvolvedor começa não a escrever o sistema, mas a observar como o sistema se escreve sozinho.

O que isso significa

A história do Cursor mostra que a IA já está mudando não apenas a velocidade do desenvolvimento, mas também a política interna dos times. Aqueles que vencerão em tais disputas não serão aqueles com um modelo mais forte, mas aqueles que primeiro chegarem a um acordo sobre os limites: onde um protótipo rápido é aceitável, e onde código sem testes, tipagem e uma stack comum simplesmente não pode ser considerado pronto.