A maioria dos sites novos está com a mesma cara. Botão de um tamanho numa página e de outro na seguinte, card com padding demais ao lado de card sem ar, container sem margem, título quebrado, cada rota com um design solto. Nada necessariamente “quebrado” — o layout até fecha. O que some é a identidade. E o ponto em comum que eu vejo nesses projetos não é “a IA não sabe CSS”. É o Tailwind CSS entrar como escolha automática no momento em que quem escreve o código deixou de ser a pessoa o dia inteiro no HTML.
O Tailwind não é o vilão. Ele ficou popular porque, no código manual, poupa vai-e-volta entre HTML e CSS. Com IA gerando tela após tela, cada elemento ganha o próprio pacote de utilities e a consistência se perde sem ninguém decidir um padrão. Um CSS global com variáveis e classes de componente deixa a decisão num lugar só. Continue no Tailwind se o projeto já é grande, se a equipe vive nisso ou se existe design system com regra que a IA não pode inventar valor.
- Problema real
- Telas geradas uma a uma, cada uma com um conjunto diferente de classes
- Antídoto
- Decisão visual num CSS global, variável e classe de componente
- Tailwind ainda cabe
- Código legado, time alinhado ou design system fechado
Sites com cara de IA e o motivo de o Tailwind ter bombado
Antes de alguém se irritar: eu não estou dizendo que o Tailwind é ruim. Ele ficou popular por um motivo honesto. Quem programa na mão cria o elemento e controla tamanho, espaço, cor e alinhamento sem ficar pulando entre o HTML e o arquivo de estilo. Para quem digitava isso o dia inteiro, o ganho era tempo. Havia também escala pré-definida: dava para manter um site coerente e ainda improvisar.
A variável nova é a IA. Qualquer pedido de página, ela costuma puxar Tailwind. Pede uma tela, vem. Pede outra, vem de novo. O framework virou o reflexo padrão do gerador, não uma decisão do projeto. Aí a pergunta deixa de ser “o Tailwind é competente?” e passa a ser “ele ainda precisa ser a escolha automática de qualquer repositório?”
Onde a IA quebra a consistência — e por que utility piora isso
O problema aparece depois de algumas rodadas de alteração. Uma página tem cabeçalho de um tamanho, a outra de outro. Um card tem espaço interno, o vizinho não tem. Botões com alturas diferentes. Nada explode, porque o Tailwind já nasceu para não quebrar o layout no sentido de “classe inválida”. O projeto é que perde o fio: cada tela parece ter sido desenhada sozinha.
Isso não é defeito exclusivo do Tailwind. CSS puro também leva vacilo da IA. O que o utility acelera é a granularidade. Cada elemento pode receber o próprio conjunto de classes. A IA resolve aquela tela e não percebe que acabou de criar uma variação do card que já existia em outro componente. A menos que o pedido diga “reproduza exatamente o sistema visual daquele card”, ela não olha o irmão.
O mesmo deslize no CSS puro vira estilo inline na div. Aí o arquivo global fica obsoleto e o HTML fica tão poluído e verboso quanto um bloquinho de utilities. A decisão visual continua espalhada. Ferramentas e skills de design — no vídeo eu citei o Impeccable, que eu recomendo — ajudam a puxar o visual de volta, seja Tailwind, CSS puro ou outro framework. Mesmo com isso, uso errado da IA deixa o design deteriorar. No Tailwind ainda tem efeito colateral de peso: a IA resolve “usar todas as classes possíveis”, o CSS gerado incha, e o site carrega estilo que ninguém escolheu de propósito.
O outro efeito é cultural. Quase todo mundo que faz o tal vibe coding cai no Tailwind. Os sites ficam parecidos uns com os outros, com a mesma paleta, o mesmo raio de borda, o mesmo botão. CSS puro não é garantia de originalidade — a IA também copia padrão de cor e espaço —, mas pelo menos você não começa o projeto já dentro da mesma caixa de utilities que o modelo viu em mil tutoriais.
CSS global versus estilo colado em cada componente
A vantagem de um arquivo de CSS global, no projeto em que a IA escreve, é brutalmente simples: existe um lugar só onde a decisão é tomada. Cabeçalho, card, botão, lista. A regra mora no seletor. Quando cada componente carrega o próprio novelo de classes, uma alteração global obriga a IA a achar vários arquivos, entender como cada um foi montado e torcer para não esquecer um. O Tailwind deixa o HTML verboso. No CSS puro você pode ter uma classe por componente e variáveis para cor, espaço e tipo. HTML e CSS ficam legíveis: isto é um cabeçalho, isto é um card, isto é um menu. O visual mora em outro arquivo.
Não vou afirmar que CSS puro sempre gasta menos tokens, nem que Tailwind sempre gasta mais. Essa conta depende do projeto. A regra que faz sentido com IA é outra: quanto menos espalhada estiver a decisão de design, mais fácil manter consistência. Vale para qualquer tecnologia. Se a IA precisa adivinhar padding em dezessete componentes, ela vai inventar dezessete paddings.
- Variáveis no :root para cor, espaço, raio e tipo — a IA altera o token, não o componente solto.
- Uma classe por peça visual (header, card, button) em vez de quinze utilities no mesmo elemento.
- Estilo de componente isolado só quando a peça realmente é uma exceção, não o padrão do site.
- Pedido explícito para reutilizar o padrão que já existe, em vez de “melhora esse card” no vazio.
Antes da IA o Tailwind fazia sentido. O CSS de hoje também não é o de 2015.
Escrever CSS na mão dava trabalho. Inventar nome de classe, organizar arquivo, repetir propriedade, lembrar o valor do espaço. Uma ferramenta que cortava esse trabalho manual tinha mercado. Foi por isso que o Tailwind existiu e cresceu. Agora quem escreve grande parte do código é uma IA. Ela não perde tempo trocando de aba no editor, nem tentando lembrar se a classe é p-4 ou p-5. Mandar a IA editar um styles.css não é mais o gargalo. Dependência de framework, para esse trabalho, deixa de ser economia de digitação e vira custo de consistência.
O CSS de hoje também não é margem, padding e sofrimento. Desde o lançamento do Tailwind entrou Flexbox de verdade no cotidiano, Grid, variáveis, clamp(), cascade layers, container queries, subgrid, nesting e scope. Dá para descrever um layout inteiro sem achar que o arquivo de estilo é punição. O que me incomoda no Tailwind, na prática, é abrir um elemento e encontrar uma sentença de classes misturada na estrutura da página. Eu prefiro ler o HTML como documento: cabeçalho, card, menu, botão. A parte visual fica no CSS.
O que usar no lugar: CSS puro, Pico, Open Props e Uno
A primeira opção é a óbvia. CSS puro moderno, principalmente em site, ferramenta pequena, blog, landing e projeto que não precisa de uma arquitetura gigante. Você define variável, regra e componente; a IA implementa. Se estiver em Vue, o estilo scoped do próprio componente isola a peça. Vuetify existe para quem quer biblioteca de UI no Vue sem passar pelo Tailwind.
Se quiser ainda menos decisão visual no começo, o Pico CSS aplica uma aparência básica e decente em HTML semântico, com poucas classes. O Open Props entrega valores prontos — cor, espaço, sombra — sem obrigar um sistema inteiro de utilities. Quem gosta da filosofia do Tailwind e só quer trocar a ferramenta pode olhar o Uno CSS: continua utility, muda o motor. Não resolve sozinho o problema da IA inventar valor. Só evita a dependência específica do Tailwind.
Quando o Tailwind ainda vale — e o que “você não precisa” quer dizer
Se o projeto já é grande e já está em Tailwind, eu não removeria. Migração cosmética por princípio é desperdício. Se a equipe trabalha bem com isso, também não vejo motivo para largar. Se existe design system definido, componente reutilizado e regra clara que impede a IA de inventar um espaçamento novo a cada tela, o Tailwind funciona. Se você simplesmente gosta de escrever assim, ótimo. O ponto não é abandonar o framework. É parar de usá-lo no reflexo.
A pergunta útil é: eu realmente preciso do Tailwind neste repositório? Ele ajudou milhares de pessoas nesses dez anos. Eu, pessoalmente, sou anti-frameworks. Evito. Já gravei o mesmo recado sobre Supabase e sobre Next.js, e a série vai continuar. Não é para diminuir a ferramenta. É para mostrar que dá para fazer o trabalho com menos camada e menos dor quando a camada não está resolvendo um problema que o projeto tem.
Você não precisa largar o Tailwind. Você não precisa adotá-lo. CSS puro já resolve a maior parte do site que a IA está gerando hoje. Conhecer Pico, Open Props ou Uno serve, no mínimo, para o visual não nascer idêntico ao do vizinho que pediu a mesma página no mesmo modelo. Essa é a recomendação. Não é uma cruzada.
Na sequência
- Antes de aceitar Tailwind no projeto novo, pergunte se alguém da equipe realmente trabalha no dia a dia com utilities.
- Coloque cor, espaço e tipo em variáveis globais, mesmo que ainda exista algum utility pontual.
- Peça à IA para reutilizar a classe do card existente em vez de estilizar a tela isolada.
- Abra duas páginas lado a lado e compare cabeçalho, botão e espaçamento — a inconsistência aparece aí.
- Se o HTML de um elemento passou de uma linha de classes, extraia uma classe de componente.
- Não migre um projeto Tailwind grande só para “ficar puro”; mude a regra daqui para a frente.
Onde isso quebra
Deixar a IA escolher padding, altura de botão e tamanho de título em cada tela, sem token compartilhado.
Achar que CSS puro imuniza o projeto: estilo inline na div reproduz o mesmo caos do utility.
Medir qualidade só por “o layout não quebrou”, ignorando que as páginas não parecem o mesmo site.
Remover Tailwind de um código legado só porque a opinião da vez é anti-framework.
Perguntas frequentes
O Tailwind ficou ruim porque a IA existe?
Não. Ele continua conveniente para quem escreve na mão e para times com design system. O que mudou é o custo de cada elemento poder ter o próprio pacote de classes quando quem escreve não revisa o padrão global.
CSS puro gasta menos tokens com IA?
Não dá para afirmar isso no geral. O ganho visível é outro: a decisão visual fica num arquivo só, então a IA altera o padrão em vez de inventar uma variação por componente.
Pico CSS ou Open Props substituem um design system?
Não. Pico cobre uma aparência inicial com HTML semântico. Open Props entrega tokens. Design system é regra, componente e restrição — com ou sem Tailwind.
E se eu gosto de utility class?
Use. Uno CSS mantém a filosofia se a questão for só a ferramenta. O cuidado continua o mesmo: a IA não pode soltar um valor novo em cada tela.
Vale tirar o Tailwind de um site grande já no ar?
Eu não tiraria. O custo da migração costuma ser maior do que o ganho. Trave o padrão com variáveis e componentes reutilizados; deixe a troca de stack para projeto novo.
Como impedir a IA de destoar o visual nas próximas telas?
Documente as classes de componente, aponte o arquivo global no pedido e recuse tela que não reutiliza o card, o botão e o cabeçalho que já existem. Skill de design ajuda, mas não substitui a regra no repositório.