SaaT: Software as a Toy

Vi o termo num vídeo de humor e não consegui mais desver: SaaT, Software as a Toy. Não lembro de quem era o vídeo (se você souber, me avisa que o crédito entra aqui). Era piada. Só que é daquelas piadas que continuam rindo de você no dia seguinte.

A ideia é simples. Com LLM, agente, harness e tudo que veio junto, fazer um SaaS deixou de ser projeto e virou passatempo de fim de semana. O contador faz, o pessoal do RH faz, seu cunhado faz. E o dev com quinze anos de estrada faz também, que eu sei.

A justificativa oficial é sempre a mesma: renda extra, empreendedorismo, liberdade. Aham. Conta quantos desses projetos têm um cliente pagando. Agora conta quantos têm tela de login, dark mode e página de preços com três planos. O povo tá vibecodando porque é gostoso.

E tudo bem. Quando o Karpathy criou o termo vibe coding, ele mesmo disse que aquilo servia para projeto descartável de fim de semana. A gente é que resolveu chamar o brinquedo de startup.

Não vou discutir se vibe coding é seguro ou se o código presta. Essa briga já tem gente demais. O que me pegou foi outra coisa.

A pergunta que incomoda

Você, dev das antigas: qual foi o último problema real que você resolveu com IA?

Real. Daqueles que alguém sentiu quando sumiu. Pode ser na empresa, por ordem da chefia. Pode ser no projeto pessoal. Vale qualquer um, menos o app que ninguém pediu.

Enquanto isso, a pessoa da operação joga outro jogo. Ela não precisa descobrir onde dói. Ela passou três anos preenchendo a mesma planilha toda sexta às seis da tarde. Quando ela senta na frente de uma IA, já chega com o problema pronto, o usuário pronto e a raiva pronta.

Nós chegamos pelo outro lado. A gente se apaixona pela arquitetura, escolhe a fila de mensagens antes de saber se existe mensagem, e resolve com elegância uma dor que ninguém tinha.

Mas isso não é novo, né!?

Não é. O dev que escuta o problema, entende o negócio e devolve algo melhor do que o cliente pediu sempre se destacou do que anotava o pedido e executava sem questionar.

O que mudou foi quem depende de quem.

Antes, a pessoa do negócio com uma boa ideia precisava de um dev. Entrava na fila, brigava por prioridade, esperava a sprint. Essa fila era o nosso emprego. Hoje ela abre uma aba e sai com algo funcionando antes do almoço. Tosco, sem teste, inseguro, e resolvendo a dor dela.

Claro que o brinquedo dela quebra. Quebra no primeiro pico de uso, no primeiro dado sensível, no dia em que ela sai de férias. Aí chamam a gente. Mas repara no papel que sobra nessa história: consertar a ideia dos outros.

Brinquedo por brinquedo, o dela pelo menos nasceu de um problema.

E o seu?