IA como copiloto

Existe uma leitura de que a IA tornou aprender código inútil. Ela erra o alvo por pouco, e o pouco importa.

O que a IA tirou de valor foi digitar. Escrever a função, lembrar a sintaxe, procurar como se faz aquilo no Stack Overflow. Isso hoje leva três segundos.

O que ela não faz é decidir se o espaçamento respira, se o componente aguenta o próximo caso de uso, se a interface funciona com teclado, ou se aquele estado vazio faz sentido pra quem chegou ali pela primeira vez. Isso continua sendo trabalho de designer, e ficou mais caro justamente porque o resto ficou barato.

Só tem um pedágio: pra dirigir a IA você precisa entender o que ela devolveu. Sem isso, você não está usando um copiloto, está apostando.

O que ela faz bem e o que ela erra

Depois de bastante uso, o padrão é consistente.

Faz bem: converter um layout descrito em flexbox ou grid, escrever a função de formatação, montar a estrutura de um componente, explicar um trecho de código que você não entendeu, traduzir de uma sintaxe pra outra, e escrever o caso feliz de qualquer coisa.

Erra com frequência: inventar propriedade de biblioteca que não existe, ignorar acessibilidade a menos que você peça, cravar valor no lugar de token, esquecer os estados que não são o caso feliz, e usar uma versão antiga da ferramenta com toda a confiança do mundo.

Repare que a lista do que ela erra é quase inteira a sua lista. Não é coincidência: são as decisões que dependem de contexto que ela não tem.

Como pedir

A diferença entre um resultado ruim e um bom quase nunca é a ferramenta. É o quanto de contexto e restrição você deu.

Um pedido ruim:

faz um card de produto em react

Um pedido que funciona:

Componente React de card de produto, com Tailwind. Recebe as props: nome, preço em centavos, imagem e uma prop aoClicar. Usa <article> e o preço formatado em real com toLocaleString. O card inteiro é clicável e precisa funcionar com teclado. Espaçamento e raio vindos das classes de escala do Tailwind, sem valor arbitrário. Me mostra também o estado de carregando.

O segundo pedido tem quatro coisas que o primeiro não tem: as props (o contrato), a tag semântica, a exigência de teclado e o estado que não é o caso feliz.

Isso é uma especificação de componente. É o que você já escreve num handoff, só que agora o leitor executa na hora.

O que sempre vale colar no pedido

• a stack e a versão: "Next.js 16, App Router, Tailwind v4". Sem isso ela chuta, e costuma chutar a versão de dois anos atrás
• o contrato: quais props entram, o que sai
• as restrições que você não abre mão: semântica, teclado, contraste, tokens em vez de valores soltos
• um exemplo do seu código: colar um componente que já existe no projeto ensina o padrão da casa melhor que qualquer descrição
• os estados: vazio, carregando, erro. Se você não pedir, não vem

O checklist de revisão

Aqui é onde o seu olho vale mais que o modelo. Sete perguntas, na ordem em que costumam falhar:

1. A tag está certa? Botão é <button>, link é <a>, região é <nav> ou <main>. Se está tudo em <div>, peça de novo pedindo semântica
2. Dá pra usar de teclado? Todo controle recebe Tab, tem foco visível, e responde a Enter
3. Os valores vêm de token? padding: 17px e #3b82f6 cravados são dívida. var(--espaco-m) ou a classe da escala, não
4. Os quatro estados existem? Vazio, carregando, erro, sucesso. A IA entrega o quarto e esquece os três
5. Aguenta conteúdo real? Nome de 40 caracteres, preço de seis dígitos, lista com um item só, lista com duzentos
6. Funciona estreito? Diminui a janela até 320px. Nada pode rolar na horizontal
7. A biblioteca existe mesmo? Se ela importou algo que você nunca viu, confere se o pacote existe antes de acreditar

Os itens 1, 2, 4, 5 e 6 são leitura de interface, não de código. Você já sabe fazer todos.

Uma armadilha específica

A IA é boa demais em soar segura. Ela vai explicar com convicção uma propriedade que não existe, e o texto vai parecer documentação.

O antídoto é barato: se ela citou uma propriedade ou função que você não conhece, roda o código. Se quebrar, quebra em dois segundos no seu computador, e não em produção na terça-feira.

E vale a regra que serve pra tudo nesta trilha: se você não consegue explicar o que aquele trecho faz, ele ainda não é seu. Pede pra ela explicar linha por linha antes de aceitar. Esse é o uso mais subestimado da ferramenta, e é o único que te deixa mais capaz em vez de mais dependente.

O projeto final

Fecha a trilha construindo alguma coisa pequena e sua. Pequena de verdade:

• um site de uma página com o seu trabalho
• uma página de documentação de um componente do seu design system, com os estados todos
• uma calculadora de escala tipográfica ou de contraste
• um glossário dos termos internos do seu time

Os requisitos que fazem o projeto valer:

1. está no ar, com endereço público (deploy na Vercel)
2. o código está no Git
3. passa nas sete perguntas do checklist
4. você consegue explicar cada arquivo

O ponto não é o portfólio. É que atravessar uma vez o caminho inteiro, do arquivo em branco até o link funcionando, muda de forma permanente como você conversa com engenharia. Estimativa deixa de ser abstrata, "isso é simples" deixa de ser chute, e o "não dá" passa a ter uma pergunta seguinte.

Sobre posicionamento

Duas coisas que ajudam na hora de falar disso.

Primeiro, recorte o que você faz. "Eu construo a camada de interface e converso com o time sobre a resto" é preciso e sustentável. "Eu programo" convida uma conversa que você não quer ter na entrevista, porque estado, dados, performance e arquitetura continuam sendo outro ofício.

Segundo, o valor não está em você digitar código. Está em você ser a pessoa que decide e que consegue verificar. Num time onde qualquer um gera componente em três segundos, quem sabe olhar o resultado e dizer o que está errado vira o gargalo mais valioso da mesa.

O que fazer hoje

Pega o último componente que você entregou em Figma e escreve o pedido dele pra IA, com as quatro partes: stack, contrato, restrições, estados.

Roda, e passa o resultado pelas sete perguntas. Vai falhar em pelo menos duas, e as duas vão ser exatamente as que você teria apontado numa revisão de design.

Essa é a trilha inteira em um exercício: você não virou desenvolvedor, você virou a pessoa que sabe pedir e sabe conferir. E isso, no momento em que a gente está, é o cargo mais difícil de substituir.