Estamos no Futuro: Carros voam e não temos mais que fazer HTML/CSS

São mais de duas da manhã e eu ainda tava acordado porque acabei de ver ao vivo o Tesla Roadster novo subir uma rampa vertical, parar de cabeça pra baixo e, noutro passe, girar no ar e pousar inteiro. Eu esperava um carro rápido. Não esperava dez bocais de propulsão a ar comprimido, tecnologia derivada da SpaceX, e um sistema de sucção embaixo que, segundo o Musk, puxa até 2 G.

A Tesla não divulgou o protocolo da medição, papo reto. A demonstração inteira tá na transmissão oficial. A Road and Track mediu e descreveu as manobras. A TechCrunch detalhou as três versões: Performance com aerodinâmica ativa e sucção, Thrust com propulsores traseiros, e Rocket com dez bocais e um assento só.

Mexendo em site. Trabalho mundano, pequeno, e ainda assim o pedaço que importa pra quem vive de software. Antes do evento da Tesla eu passei o dia inteiro redesenhando seis sites: o AI Lair, o ai-memory, o ai-jail, a newsletter The M.Akita Chronicles, o arquivo dela e este blog, o AkitaOnRails. Todos tinham começado com variação daquele tema padrão que o Claude entrega.

Funciona. Também ficou tão comum que você bate o olho e lê site feito pelo Claude antes de ler o título. Eu já tinha pedido design diferente. Ele trocava a cor, mexia no cartão e devolvia a mesma gramática visual. Publiquei umas telas e o resultado da mudança no Twitter. Eu não sou web designer e, por um tempo, aceitei o funciona. Ontem cansei.

Transforma instrução e imagem em interface editável e código de front-end. A primeira versão veio em 2025 em cima do Gemini. A atual virou uma tela de design com agente, protótipo e exportação de um DESIGN.md que outros agentes conseguem seguir. Criei a conta, peguei o token da API e comecei. O Stitch gerava direção visual. Claude Code e Codex levavam isso pros repositórios reais.

Romântico não. Estagiário humano pede férias. Os seis sites saem de cinco repositórios. Olhando tudo lado a lado, uma coisa ficou clara: o Stitch responde muito melhor quando recebe uma metáfora concreta, o público e o que aquele produto precisa comunicar. O ai-memory virou um arquivo de memória. O ai-jail, uma prisão cinematográfica. O AI Lair adotou uma feira mundial dos anos 1950 e 1960, puxada pela capa do meu livro.

O protótipo é a parte fácil, tá ligado? O trabalho só termina quando a linguagem visual chega nas páginas internas, no artigo, no leitor do livro, no e-mail, nas páginas legais, nos estados de erro e no celular. Foi isso que os agentes fizeram nos repositórios. No ai-memory, a verificação cobriu mais de cem páginas em seis idiomas, nos temas claro e escuro, em desktop e celular.

Foram várias rodadas de protótipo em cada site. Algumas ficaram horrorosas. Outras tinham uma ideia boa cercada de decisão ruim. Eu mandava descartar, preservar um pedaço, misturar com outra tentativa e recomeçar. Código ficou barato, então não existe motivo pra se apaixonar pela primeira versão. O resultado não vai ganhar prêmio. Um designer profissional ainda acharia centenas de coisas pra melhorar.

Vamos manter a proporção. São sites pequenos, a maioria landing e página de conteúdo. Ninguém vai recriar o conjunto inteiro da Amazon num dia. O experimento mostra quanto trabalho repetitivo já saiu da frente, dentro de um escopo que uma pessoa experiente consegue entender e revisar. Projeto grande continua grande: regra privada, integração antiga, estado estranho e decisão que não cabe num prompt.

Onde ela se perde, qual promessa parece suspeita, se consegue completar uma tarefa sem já conhecer o produto. No ai-jail usei duas sessões isoladas. Uma era um engenheiro cético que aprova todo prompt e nunca tinha ouvido falar do projeto. A outra, gerente de oito desenvolvedores, sem ser engenheira, tentando decidir se aprovava a ferramenta na empresa.

Qualquer pessoa consegue fazer o mesmo. Sobe a aplicação local ou abre um deploy de preview, começa sessão nova e dá a cada agente uma tarefa concreta. Eu prefiro três sessões independentes a uma mesa-redonda. Se um lê o relatório do outro, começa a concordar por inércia. Depois uma sessão separada consolida o que se repetiu, descarta gosto pessoal e confere cada afirmação contra o código e a documentação.

Posicionamento, ordem da informação, caminho até a primeira ação e confiança. Teste automático tradicional continua cuidando de link quebrado, contraste, acessibilidade, overflow e estado de erro. A persona mostra que o botão tecnicamente acessível apareceu cinco telas depois de onde a pessoa precisava dele. Isso teste de contraste não pega.

Concordaram que o site demorava pra mostrar o risco concreto e falava cedo demais como documentação de engenheiro. A ameaça de uma página envenenada foi puxada pra logo depois do hero. Entraram as seções O que muda no primeiro dia e Para quem precisa aprovar isto, com custo operacional, limite e as chaves que uma empresa realmente expõe. A revisão também achou uma afirmação tecnicamente errada repetida em várias páginas.

No ai-memory o relatório encontrou permissão descrita de formas contraditórias, promessa de privacidade absoluta demais e a explicação básica soterrada por feature avançada. Na segunda rodada, os perfis viram que a instrução de acesso remoto mandava usar HTTP antes de exigir TLS, que um curl sem autenticação prometia a resposta errada, e que escolha importante aparecia tarde demais no celular.

No redesign do AI Lair, a revisão pra leitor novo reorganizou o caminho de entrada. Uma revisão seguinte deixou explícito que o meu setup com vários agentes e dois monitores é configuração madura, não requisito pra começar. Uma pessoa, um projeto e um agente bastam. Também surgiu um roteiro de piloto pra gerente: tarefa reversível, dado não sensível, critério de aceitação, prazo, orçamento e medição.

Carrega o mesmo vício do modelo, pode concordar com o prompt e nunca sente a irritação de quem perdeu vinte minutos, nem assume o risco de colocar o próprio cartão de crédito. Os relatórios servem como hipótese. Um usuário real sempre encontra o caso que eu, o agente e a suíte de teste não imaginaram. Só que, antes do primeiro usuário existir, a alternativa costuma ser nenhuma revisão.

Durante anos eu vi gente fazendo ginástica danada pra defender que HTML é linguagem de programação e, portanto, quem escreve HTML é programador. HTML é marcação: descreve a estrutura de um documento. CSS descreve apresentação. Isso tem valor, exige conhecimento e pode ficar terrivelmente complexo. Complexidade acidental não transforma marcação em programação.

E não há vergonha nenhuma nisso. Comecei a fazer site nos anos 1990. Recebia um layout feito no Photoshop e transformava aquilo em HTML. Recortava imagem, montava tabela, ajustava pixel, abria em vários navegadores, voltava e tentava de novo. Foi trabalho honesto e pagou minhas contas. Também era trabalho basicamente mecânico: copiar, colar, ajustar, olhar, repetir. Exatamente a categoria que computador deveria automatizar.

A bolha atrasou a automação. Durante boa parte dos anos 2010, os juros americanos ficaram perto de zero. Dinheiro barato irrigou fundo, startup e empresa grande. Contratar mais gente era fácil, e o mercado absorvia qualquer quantidade de trabalho manual disfarçado de engenharia. Juro baixo não explica sozinho a expansão da tecnologia, mas uma área em recorde de contratação tem pouco incentivo pra eliminar o próprio trabalho repetitivo.

Quem assistiu às minhas palestras em evento de tecnologia nos anos 2010 deve lembrar de Restrição igual igual Inovação. O nome correto era com dois sinais de igual mesmo. Apresentei isso na DevConf 2019, os slides estão no meu SlideShare, mais de oitenta. E eu já tinha escrito a mesma tese em 2013, em Restrições são libertadoras: menos é mais. Necessidade é mãe da invenção. Restrição obriga a escolher, e escolha obriga a priorizar.

Dinheiro financia pesquisa cara, compra equipamento e dá tempo pra experimentar. Sobra de dinheiro sem pressão por resultado esconde ineficiência com força bruta. Não precisa automatizar, simplificar nem descobrir solução melhor enquanto ainda der pra contratar mais gente e aumentar a planilha. Abundância demais transforma problema técnico em despesa operacional e empurra a decisão difícil pra depois.

É mole? Foi assim que a gente passou uma década recriando o mesmo painel administrativo e chamando de inovação. Toda semana aparecia a próxima salvação do front-end: React, Angular, Vue, Svelte, outro bundler, outro framework em cima do framework. São ferramentas úteis nos seus contextos. Nenhuma atacava a pergunta óbvia: por que um ser humano ainda está escrevendo à mão a milésima variação do mesmo formulário?

Qualquer tarefa que consiste em copiar padrão, adaptar exemplo, rodar, olhar o erro e tentar de novo já está no alcance desses agentes. Front-end é o alvo mais visível porque acumulou uma quantidade absurda desse trabalho. O resto da programação não está protegido por aura mística. Tem muito back-end que é CRUD, cola entre APIs e configuração repetida. Também será automatizado. Pra mim, ótimo. Programar nunca foi digitar código. Programar é fazer um computador executar algo útil.

Primeiro você ligava fio e chave. Depois perfurava cartão. Depois escrevia Assembly, C, linguagem de alto nível, framework e configuração. Cada geração olhou pra anterior e automatizou uma camada de trabalho manual. Ninguém em sã consciência defenderia hoje que operar uma perfuradora de cartão era a essência da ciência da computação. Era a interface disponível. Digitar cada tag e cada regra de CSS no VS Code também era a interface disponível.

Sem fundamento eu nem saberia dizer se o agente entregou uma solução ou uma bomba-relógio bonita. Ainda preciso entender como navegador, rede, cache, acessibilidade, semântica, responsividade e SEO funcionam. Continua tudo aí. Foi embora a desculpa pra eu mesmo escrever o flexbox. Hoje, todos os modelos Tier A que eu testo, de Claude a Kimi, executam com confiabilidade o trabalho mecânico de front-end que apareceu nesses seis projetos.

Isso cobre uma parcela enorme do trabalho e deixa justamente a parte de maior valor. Alguém ainda precisa conhecer prós e contras do framework, entender o browser, escolher a arquitetura, perceber quando a biblioteca está sendo usada contra o próprio desenho e descobrir por que uma solução aparentemente correta quebra numa combinação específica de aparelho, idioma, estado e dado real. O agente escreve o código. Um profissional experiente dá direção, limita o estrago e assume o resultado.

O mercado fica menor e mais seletivo, com os melhores produzindo mais. A meta continua a mesma de sempre: chegar perto do topo, onde julgamento e experiência ainda fazem diferença. E isso não para no browser. Escolha o framework: Android com Flutter ou Kotlin, iOS com Swift e SwiftUI, desktop com Rust e Tauri, Flutter, C Sharp ou Electron. Em geral, agentes modernos conhecem componente, ferramenta de build, teste e peculiaridade dessas plataformas.

O FrankYomik tem cliente Flutter pra Android e Linux, além do servidor e da extensão. O Frank Sherlock é um app desktop em Rust e Tauri que gera AppImage pra Linux, DMG pra macOS e instalador exe pra Windows. Também fiz o Frank Karaoke em Flutter pra Android e o FRANK MANGA mais em Rust e Tauri pra desktop. Tem vários outros no meu GitHub. Nenhum saiu perfeito no primeiro prompt.

Depois de testar web, Android e desktop em stacks diferentes, tô muito satisfeito. O padrão se repete: trabalho mecânico virou trabalho de agente. Às duas da manhã eu tinha agentes fazendo os últimos ajustes neste blog sem perder o ritmo. É disso que eu preciso. Pessoa extra copiando componente não me serve.

Havia espaço real pra experimentar. Era feio muitas vezes, pesado quase sempre, mas tinha criação acontecendo. O iPhone abriu outra janela em 2007. De repente tudo precisava caber numa tela pequena, responder ao toque e funcionar sem mouse. Vieram anos de experimentação até o mercado formar uma gramática razoavelmente estável de navegação, gesto, formulário e conteúdo.

O trabalho mais valioso continua existindo: entender o produto, a pessoa que vai usá-lo, as restrições e o que merece aparecer primeiro. O trabalho de converter uma decisão pronta em centenas de linhas previsíveis virou candidato perfeito à automação. Ponto. O resto é nostalgia de ferramenta.

Operadores de cartão perfurado digitavam dado e programa em papel. Telefonistas conectavam chamada fisicamente. Datilógrafos mantinham escritório funcionando. Linotipistas montavam linha de metal quente pra imprimir jornal. A tecnologia reduziu ou eliminou essas ocupações em escala. A lista atual de profissões em maior declínio do Bureau of Labor Statistics ainda inclui digitador, datilógrafo e operador de telefonia. Ninguém propõe voltar a elas pra proteger emprego.

A história real é menos limpa do que a caricatura. A OIT mostra que a tecnologia costuma automatizar tarefas sem necessariamente eliminar ocupações inteiras. Algumas funções encolhem, outras mudam e trabalhos novos aparecem. Esse consolo não resolve a vida de quem ficou pra trás agora. A pessoa precisa reagir antes que a média da economia reaja por ela. Compare 2026 com 1926, três anos antes do crash de 1929. Parece outro planeta, embora um século seja muito pouco na escala da história.

Vai ficar mais difícil. A escada antiga começava com alguém pagando um iniciante pra montar tela simples, corrigir CSS e copiar componente. O agente faz boa parte disso mais rápido e barato. Empresa nenhuma tem obrigação de preservar trabalho ineficiente como programa de treinamento. O iniciante vai ter que construir a própria escada com projeto real e problema pelo qual ele seja responsável.

Se o estágio for copiar botão, o agente já se formou e não pede vale. Construir a própria escada inclui ler o código que o agente gerou, quebrar e consertar, estudar documentação e código-fonte, escrever teste e contribuir com projeto aberto. O agente dá a qualquer estudante acesso a uma quantidade de prática que antes exigia uma equipe. Quem usar isso só pra gerar código que não entende vai continuar júnior por muito tempo. O mercado vai premiar quem fizer esse esforço extra. Sempre premiou.

A vaga fácil, com salário crescente e pouca cobrança, foi uma distorção da bolha. Adaptar-se inclui aceitar que a entrada ficou mais competitiva. Não tô nem aí pra quem quer o atalho de 2021 de volta. Aquilo não era normal. Era juro zero disfarçado de meritocracia.

No Akitando sobre SAP eu conto parte dessa fase em que precisei aprender um mundo completamente diferente do que fazia antes. Atravessei o crash das pontocom, a crise de 2008 e o fim da bolha de juro zero. Sobrevivi porque nunca tratei a minha função do momento como identidade permanente. Continuei estudando, acumulando experiência e mudando de direção. Uma carreira produtiva não deveria consistir em repetir a mesma tarefa mecânica por décadas.

Essa é a receita mais rápida pra ficar obsoleto. Faça o trabalho de curto prazo, mas estude além dele. Aprenda as coisas que parecem inúteis agora. Fundamentos, sistemas operacionais, redes, bancos de dados, negócio, economia, história. Você não sabe qual combinação vai salvar sua carreira daqui a cinco anos. Eu passei anos falando disso no Akitando. Reveja as playlists Eu Avisei e Que curso devo fazer. Se tiver que começar por um vídeo, comece pelo Guia DEFINITIVO de Aprendendo a Aprender.

Portanto eu não vou lamentar que o pacote desses seis sites pequenos, que antes tomaria semanas ou meses, tenha cabido em cerca de um dia. Tô feliz pra cacete. Ganhei tempo pra pensar no que construir, experimentar mais e jogar fora versão ruim sem desperdiçar semanas de vida. Hoje eu vi um carro girar no ar e pousar. Em cerca de um dia, coloquei seis sites com visual novo em produção sem escrever a maior parte do HTML e do CSS.