.png)
A mágica
Com a ascensão dos grandes modelos de linguagem, nunca foi tão fácil tirar uma ideia da cabeça e transformá-la em algo que roda. Em teoria, isso deveria ser bom. Mas depois de passar os últimos meses usando essas ferramentas e construindo muitas das coisas que sempre quis construir, já não tenho tanta certeza.
Existe algo genuinamente mágico nisso. Refatorar uma aplicação inteira num único dia parece mágica. Depurar uma base de código que levaria semanas para entender parece mágica. Transformar uma ideia antiga num protótipo funcionando num fim de semana parece mágica. Mas, quando o assunto são projetos paralelos, fico me perguntando: isso é sempre bom?
O custo de entregar rápido demais
Nos últimos meses, construí projeto atrás de projeto. Coisas que antes levariam meses, talvez até anos, de repente ficavam prontas em dias. O estranho é que muitas vezes eu terminava sem aprender muito, sem compartilhar muito e, às vezes, sem nem querer continuar. Num certo sentido, isso pode ser útil. Não passei anos descobrindo que uma ideia não era viável. Descobri em poucos dias.
Ainda assim, isso me incomodou. Se um projeto paralelo não tem peso real, nenhuma complexidade significativa e nenhuma exigência de que eu permaneça no processo, o que eu estou realmente tirando dele? Ter um projeto terminado sem ter aprendido quase nada com ele não me parece especialmente valioso.
Nossa cultura atual tende a tratar produtividade como o único atributo que importa no trabalho. Conhecimento e ofício ainda importam, claro, mas principalmente quando vêm atrelados a resultado. E quando digo produtividade, a implicação desconfortável costuma ser acúmulo de capital. Isso é meio deprimente. Nossos antepassados sonhavam com sabedoria, imortalidade e grandeza. Hoje, muitas vezes sonhamos em transformar produtividade em dinheiro.
Desacelerando de propósito
Esse pensamento me deu vontade de desacelerar. Não quero parar de construir, mas quero parar de tratar velocidade como o objetivo. Quero passar mais tempo em projetos que me ajudem a aprofundar meu entendimento de design systems, arquitetura e aplicações intensivas em dados. Estou lendo Designing Data-Intensive Applications devagar e planejando um projeto flexível onde eu possa aplicar essas ideias aos poucos, com cuidado.
Não estou rejeitando as ferramentas de vibe coding. Eu nunca seria contra a modernidade só por ser, e seria perda de tempo escrever cada pedaço de boilerplate à mão só para me sentir virtuoso. Mas quero usar essas ferramentas de um jeito mais guiado por especificação. Arquitetura e design de software preparado para trabalho intensivo em dados ainda é algo que quero desenvolver no meu próprio repertório.
Então estou tentando aprender em vez de só produzir rápido. Espero que não seja a aposta errada. Veremos.