DEV Community: Taina Costa

Por que você deveria parar de chamar tudo de "agente de IA"

Taina Costa — Tue, 08 Sep 2026 17:47:36 +0000

Se você trabalha com IA há mais de seis meses, já deve ter notado: todo mundo virou "agente". Chatbot com duas funções? Agente. Script que chama GPT em loop? Agente autônomo. Marketing de produto SaaS? "Nossa plataforma usa agentes inteligentes."

Esse fenômeno tem até nome: agent washing. Mas por baixo do hype, existe uma mudança real acontecendo — e se você vai construir sistemas desse tipo (ou apenas entender o que seu colega de trabalho está propondo na sprint), vale a pena separar o que é buzzword do que é arquitetura.

O que separa um agente de um chatbot

A diferença não está no modelo. Está no loop.

Um chatbot tradicional funciona assim:

const response = await llm.chat("Me ajude com isso");
console.log(response);

Um agente faz isso:

let goal = "Encontre todos os bugs críticos no repositório";
let done = false;

while (!done) {
  const action = await agent.decide(goal, context);
  const result = await execute(action); // pode ser grep, API call, etc
  context.push(result);
  done = await agent.checkIfGoalReached(context);
}

A diferença está no agent loop: o sistema age, observa o resultado, decide o próximo passo. Repete até atingir o objetivo ou bater em um limite (tokens, tempo, tentativas).

Não é "IA que responde". É "IA que faz".

Tool calling: a primitiva que muda tudo

Se você usou Claude, GPT ou Gemini recentemente, já viu tool calling em ação — mesmo sem perceber.

Antes, quando você perguntava "Quanto é 127 * 843?", o modelo adivinhava. Agora ele faz isso:

{
  "role": "assistant",
  "tool_calls": [
    {
      "name": "calculator",
      "arguments": { "expression": "127 * 843" }
    }
  ]
}

Você executa a função, devolve o resultado, o modelo continua. Simples, mas é isso que permite que agentes usem ferramentas reais em vez de alucinar respostas.

A sacada: tool calling não é "o agente". É a interface que permite construir um.

Agent harness: a infraestrutura invisível

Se o LLM é o cérebro, o agent harness é o corpo. É tudo que fica em volta:

Gerenciamento de ferramentas (quais o agente pode usar, quando, com quais permissões)
Controle de estado (memória entre iterações)
Tratamento de erro (quando a API falha, quando o modelo trava, quando ele tenta algo proibido)
Limites (budget de tokens, timeout, retry policy)

Você raramente vê isso documentado porque é código de infraestrutura — mas é onde 80% do trabalho está. O modelo decide o que fazer. O harness decide se deixa.

Exemplo real: um agente tenta rodar rm -rf / porque interpretou mal uma instrução. O harness bloqueia, loga, e devolve "permission denied" pro modelo tentar outra coisa.

Guardrails são a parte do harness que impõe regras: não pode acessar certos arquivos, não pode gastar mais de X tokens, não pode tomar ação Y sem aprovação humana.

Context engineering: o timing importa mais que o volume

Você tem 10 mil linhas de documentação relevante. Joga tudo no prompt?

Má ideia. O modelo vai gastar atenção (literal — attention mechanism) em partes irrelevantes, e você vai estourar o contexto antes de terminar.

Context engineering é a arte de dar a informação certa na hora certa:

// Ruim: joga tudo logo no início
const prompt = `${todaADocumentacao}\n\n${perguntaDoUsuario}`;

// Melhor: busca o que é relevante sob demanda
const question = "Como funciona autenticação?";
const relevantDocs = await searchDocs(question, topK=3);
const prompt = `${relevantDocs}\n\n${question}`;

Em sistemas multi-agente, isso fica ainda mais crítico. Você não quer que o agente de frontend veja os logs do backend a cada iteração. Quer que ele peça quando precisar.

MCP: porque cada ferramenta não deveria ser um caso especial

Se você já integrou um LLM com ferramentas externas, sabe o problema: cada API é um floco de neve. OAuth aqui, API key ali, webhook acolá. Você acaba com um Frankenstein de integrações.

Model Context Protocol (MCP) é uma tentativa da Anthropic de padronizar isso. A ideia:

[Agente] <--MCP--> [Servidor de Ferramentas] <--> [GitHub, Jira, DB, etc]

O agente fala MCP. O servidor expõe ferramentas via MCP. Você troca de ferramenta sem reescrever o agente.

Ainda está em adoção (e tem concorrência), mas a direção é essa: ferramentas como protocolo, não como código custom.

Agentic RAG: quando o agente escolhe o que buscar

RAG tradicional:

const docs = await vectorDB.search(query);
const answer = await llm.generate(docs, query);

Agentic RAG:

let findings = [];
while (!satisfied) {
  const nextQuery = await agent.decideWhatToSearchNext(findings);
  const docs = await vectorDB.search(nextQuery);
  findings.push(docs);
  satisfied = await agent.hasEnoughInfo(findings);
}
const answer = await agent.synthesize(findings);

O agente dirige a busca. Se a primeira query não trouxe o que ele precisa, ele refina, tenta outro ângulo, cruza fontes.

Útil quando a pergunta é complexa e você não sabe de antemão qual chunk vai ter a resposta.

Multi-agente: quando um não basta

Você tem um sistema que precisa:

Ler issues do GitHub
Analisar o código relacionado
Gerar um report técnico
Postar no Slack

Opção A: um agente faz tudo. Opção B: quatro agentes especializados, com um orchestrator coordenando.

const issues = await githubAgent.fetchCriticalIssues();
const analysis = await codeAgent.analyze(issues);
const report = await reportAgent.generate(analysis);
await slackAgent.post(report);

Cada agente tem ferramentas, contexto e prompt próprios. O orchestrator gerencia a pipeline.

Desvantagem: complexidade. Vantagem: cada agente fica pequeno, testável, e você pode trocar um sem quebrar os outros.

Human-in-the-loop: o freio de mão

HITL é simples: antes de fazer algo crítico, o agente pede aprovação.

if (action.isDestructive) {
  const approved = await askHuman(action);
  if (!approved) return;
}
await execute(action);

Parece óbvio, mas você ficaria surpreso com quantos "agentes autônomos" em produção não têm isso. Até o sistema estar maduro (e mesmo depois), HITL é sua rede de segurança.

Evals: porque "parece funcionar" não é teste

Como você testa um agente? Rodar uma vez e ver se deu certo?

Evals (evaluations) são datasets de casos de teste onde você sabe o resultado esperado:

const testCases = [
  {
    goal: "Encontre o arquivo de config",
    expectedTool: "grep",
    expectedResult: "config.json"
  },
  // ...
];

for (const test of testCases) {
  const result = await agent.run(test.goal);
  assert(result.tool === test.expectedTool);
  assert(result.output.includes(test.expectedResult));
}

Você roda evals antes de deploy, depois de mudar o prompt, depois de trocar de modelo. É a única forma de saber se você quebrou algo.

Computer use: quando não existe API

Última fronteira: agentes que controlam interfaces visuais. Tipo Selenium, mas dirigido por IA.

// Pseudo-código
await agent.openBrowser("https://example.com");
await agent.click("Login");
await agent.type("#username", "user");
await agent.type("#password", "pass");
await agent.click("Submit");
const data = await agent.extractTable(".results");

Útil quando você precisa integrar com sistemas legados que não têm API. Frágil (qualquer mudança de UI quebra), lento, mas às vezes é a única opção.

Anthropic lançou isso como computer use (literalmente "uso do computador"). Outros estão seguindo.

Quando não usar agentes

Agora a parte que ninguém fala: a maioria dos problemas não precisa de um agente.

Se você pode resolver com:

Uma chamada de LLM (llm.generate(prompt))
Um script determinístico
Uma pipeline de dados tradicional

...use isso. Agentes são caros (tokens, latência, complexidade), imprevisíveis, e difíceis de debugar.

Use agentes quando:

O problema é aberto (você não sabe os passos de antemão)
Precisa de adaptação (o próximo passo depende do resultado anterior)
Ferramentas variadas são necessárias

Caso contrário, você está usando uma britadeira pra pendurar um quadro.

TL;DR

Agent loop: agir → observar → decidir → repetir. Isso que separa agentes de chatbots.
Tool calling: primitiva que permite agentes usarem funções reais em vez de alucinarem.
Agent harness: toda a infraestrutura invisível (permissões, retry, logging, limites).
Context engineering: informação certa na hora certa, não tudo de uma vez.
MCP: protocolo pra padronizar como agentes falam com ferramentas.
Agentic RAG: agente dirige a busca de informação, não só recebe resultado pronto.
Multi-agente: vários agentes especializados coordenados por um orchestrator.
HITL: aprovação humana antes de ações críticas. Sempre.
Evals: testes automatizados pra garantir que o agente ainda funciona.
Computer use: agente controla UI visual quando não tem API.
Regra de ouro: se dá pra resolver sem agente, resolva sem agente.

Produtividade que parece errada (mas funciona para dev)

Taina Costa — Tue, 25 Aug 2026 14:43:41 +0000

Semana passada cancelei três reuniões, commitei código com TODOs de propósito e fechei o VS Code às 15h numa terça-feira. Entreguei mais naquela semana do que no mês anterior.

Por que isso importa agora

O burnout em tech está em alta. A cultura do "sempre produtivo" nos empurra pra fazer mais code review, mais commits, mais horas. O problema? Produtividade não é linearmente proporcional a esforço. Às vezes, fazer menos é o atalho.

Aqui vão sete táticas que usei e que soam completamente erradas — mas que mudaram como entrego software.

1. Commite código ruim (de propósito)

Não estou falando de commitar qualquer porcaria em main. Mas parar de buscar o commit perfeito logo de cara libera momentum.

// First pass - just make it work
function processUserData(users) {
  let result = []
  for (let i = 0; i < users.length; i++) {
    if (users[i].active === true) {
      result.push({
        id: users[i].id,
        name: users[i].name,
        // TODO: add email normalization
        email: users[i].email
      })
    }
  }
  return result
}

Commita isso. Funciona. Depois você refatora:

// Second pass - clean it up
const processUserData = (users) => 
  users
    .filter(u => u.active)
    .map(({ id, name, email }) => ({
      id,
      name,
      email: normalizeEmail(email)
    }))

Tentar escrever a versão "certa" de primeira paralisa. O código ruim te dá tração. Refatoração vem depois.

2. Batch seu code review (não faça na hora)

Toda notificação de PR é uma context switch. Eu costumava revisar na hora — achava que era ser "bom colega de time". Resultado? Zero deep work.

Agora tenho dois slots de code review por dia: 11h e 16h. Reviso tudo de uma vez. Meu time sabe disso. Urgências vão pro Slack.

// .github/workflows/review-reminder.yml
# Automation: remind me only at review time
on:
  schedule:
    - cron: '0 11,16 * * 1-5'  # 11 AM and 4 PM, Mon-Fri
jobs:
  notify:
    runs-on: ubuntu-latest
    steps:
      - name: Check pending PRs
        run: gh pr list --assignee @me

Batch processing reduz sobrecarga cognitiva. Você entra no "modo revisor" e sai dele — não fica pingando entre contextos.

3. Não resolva o bug agora

Achei um bug no meio de uma feature? Anoto e não conserto. Parece irresponsável, mas:

// Instead of fixing immediately:
function calculateTotal(items) {
  // BUG: breaks with empty array - fix in #1234
  return items.reduce((sum, item) => sum + item.price, 0)
}

Crio uma issue, linko no comentário, volto pra feature. Consertar bugs no meio de outra coisa é garantia de:

Commit misturado (feature + bugfix)
Perder o fio da meada na feature
Gastar 20min num rabbit hole

A não ser que seja critical, o bug espera. Foco > multitarefa.

4. Deixe TODOs no código (intencionalmente)

TODOs têm má fama. Mas eu uso como marcador de iteração:

// components/UserProfile.tsx
export function UserProfile({ userId }: Props) {
  const { data } = useUser(userId)

  // TODO: add loading skeleton
  // TODO: add error boundary
  // TODO: add avatar upload

  return (
    <div>
      <h1>{data.name}</h1>
      <p>{data.email}</p>
    </div>
  )
}

Entrego a versão mínima funcionando. Os TODOs viram tasks depois. Isso evita over-engineering na primeira passada. Você descobre o que realmente precisa quando a feature está rodando.

Automatizo a coleta:

# List all TODOs in current branch
git diff main --name-only | xargs grep -n "TODO" || echo "No TODOs"

5. Não leia a doc inteira (scan até achar o exemplo)

Gastei anos lendo documentação de ponta a ponta. Descobri que 80% do que preciso está num example de quickstart.

Quando preciso integrar uma API nova:

Vou direto pro "Getting Started"
Copio o exemplo
Rodo
Quebrou? Aí leio a seção específica do erro

// I don't read all of Stripe docs. I copy this:
const stripe = require('stripe')(process.env.STRIPE_KEY)

const paymentIntent = await stripe.paymentIntents.create({
  amount: 2000,
  currency: 'brl',
})
// Then I iterate from here

Aprender fazendo > aprender lendo. Você absorve a doc conforme precisa, não antes.

6. Faça menos reuniões (mesmo as "importantes")

Cancelei standups assíncronos. Trocamos por thread no Slack:

📅 Daily async - 24/08
@channel drop your update:
✅ Done yesterday
🚧 Doing today  
🚨 Blockers

Leva 2min pra escrever vs. 15min de call. Eu leio quando quero. Time remoto agradece.

Reunião só quando precisa de decisão síncrona ou pair programming. O resto? Assíncrono.

7. Pare de trabalhar no meio (não no final limpo)

Parece contra-intuitivo, mas parar no meio de uma função facilita retomar:

function migrateUserData(users) {
  const validated = users.filter(u => u.email && u.name)

  // STOPPED HERE - next: transform to new schema
  // const transformed = validated.map(u => ...)

  return validated
}

Quando volto no dia seguinte, sei exatamente onde estava. Se paro num "ponto limpo", gasto 10min relembrando contexto.

Hemingway fazia isso com escrita. Funciona com código também.

Caveats

Essas táticas não são universais:

Código ruim intencional não funciona se você não tem disciplina pra refatorar depois
Batch review só rola se o time concorda com a latência
Bugs adiados precisam de tracking (senão somem)
TODOs viram dívida técnica se ninguém cobra
Pular doc é arriscado em sistemas complexos (tipo OAuth flows)
Menos reunião exige comunicação assíncrona forte
Parar no meio não funciona em pair programming ou prazos apertados

TL;DR

Commite código ruim primeiro, refatora depois — tração > perfeição
Faça code review em batch (2x/dia) pra preservar deep work
Não conserte bugs no meio de features — anote e volte depois
Use TODOs como marcadores de iteração, não vergonha
Scan docs até achar exemplo, aprenda fazendo
Troque reuniões por async quando possível
Pare de trabalhar no meio pra facilitar retomada no dia seguinte

Por que comunidades de dev importam (e o que você está perdendo)

Taina Costa — Tue, 18 Aug 2026 14:32:28 +0000

DEV acabou de anunciar Jem Young como Community Program Coordinator. Pode parecer só mais uma contratação, mas diz muito sobre onde o ecossistema de desenvolvimento está indo: comunidades estruturadas, com pessoas dedicadas full-time a fazer elas funcionarem.

Se você ainda trata comunidade como "aquele lugar onde eu copio código do Stack Overflow", está deixando muito valor na mesa.

Por que isso importa agora

Desenvolvimento web virou um jogo de ritmo insano. Frameworks mudam a cada trimestre, padrões evoluem, melhores práticas de ontem são antipadrões de hoje. Você não consegue acompanhar sozinho.

Comunidades estruturadas — DEV, fóruns especializados, Discords focados — viraram infraestrutura crítica. Não só para tirar dúvidas, mas para:

Entender contexto que docs oficiais não dão (por que essa lib existe, qual problema real resolve)
Ver código em produção de gente que já quebrou a cara
Antecipar mudanças antes de virarem trending topic no Twitter
Networking real com quem contrata, ensina, ou está resolvendo problemas parecidos com os seus

O DEV colocar alguém full-time nisso é sinal: comunidade não é chat bagunçado, é produto.

Como comunidades estruturadas funcionam

Uma comunidade que funciona tem três camadas invisíveis:

1. Moderação consistente

Regras claras, aplicadas sem viés. Código de conduta não é decoração — define se o espaço vai ser construtivo ou tóxico.

2. Programas de engajamento

Challenges, AMAs, série de artigos temáticos. Algo que transforma lurking passivo em participação ativa.

3. Incentivos para contribuir

Badges, destaque, ou só reconhecimento público. Parece bobo, mas gamification funciona quando bem feita.

O DEV já tinha 1 e 3. Trazer um coordinator de programa sugere que vão investir pesado em 2 — mais estrutura, menos caos.

Como participar (de verdade)

Tem jeito certo e jeito inútil de estar em comunidades. Jeito inútil: lurking eterno, esperando alguém resolver seu problema exato. Jeito certo: contribuir antes de pedir.

Aqui está um padrão que funciona:

Semana 1-2: Observe o tom

Leia por uma semana. Entenda que tipo de pergunta funciona, como as pessoas respondem, qual o nível de profundidade esperado.

// ❌ Pergunta que vai ser ignorada
"Alguém sabe React?"

// ✅ Pergunta que vai ter resposta
"Estou tentando fazer lazy loading de um componente que depende de 
context externo. Quando envolvo com Suspense, o context vem undefined. 
Alguém já resolveu isso sem mover o provider pra dentro do Suspense?"

Semana 3-4: Contribua primeiro

Responda uma pergunta que você sabe. Compartilhe um artigo relevante. Comente em algo que te ajudou. Construa reputação antes de pedir ajuda complexa.

Depois: Seja consistente

Apareça regularmente. Comunidades funcionam por reciprocidade. Se você some por três meses e volta só quando precisa, ninguém vai te conhecer.

O que evitar

FOMO induzido por comunidade

Você vai ver gente usando 15 libs que você nunca ouviu falar. Resista ao impulso de sair instalando tudo. A maioria não vai sobreviver seis meses.

Toxic positivity

Comunidades às vezes viram câmara de eco. "Adorei esse framework!" sem crítica nenhuma. Procure espaços onde as pessoas falam dos tradeoffs, não só das vantagens.

Participação performática

Postar por postar, só pra ter presença. Ninguém ganha nada com isso. Qualidade > frequência.

Esquecer que humanos existem do outro lado

Você não está conversando com usernames. Tem gente real lendo. Seja direto, mas não seja grosso.

TL;DR

DEV contratou coordinator de comunidade full-time — sinal de que comunidades viraram infraestrutura crítica
Comunidades estruturadas têm moderação consistente, programas de engajamento, e incentivos para contribuir
Participar bem: observe o tom → contribua primeiro → seja consistente
Evite FOMO, toxic positivity, e participação performática
Comunidade não é rede social — é ferramenta de trabalho. Use como tal.

TypeScript 7 "foi nativo" — o que isso significa de verdade

Taina Costa — Tue, 11 Aug 2026 14:56:37 +0000

Todo mundo já ouviu: o TypeScript "foi nativo". E aí vem a conclusão errada: "Oba, agora o navegador roda TypeScript direto!" Não. Seu código continua sendo transpilado pra JavaScript. O que mudou foi quem faz a checagem de tipos.

Antes, o compilador tsc era um programa JavaScript rodando no Node.js. Agora ele foi reescrito em Go e compila pra um binário nativo. A pipeline ficou assim:

// Antes: TypeScript 7
seus arquivos .ts → compilador JS no Node → erros de tipo + JS

// Depois: TypeScript 7
seus arquivos .ts → binário nativo em Go → mesmos erros + mesmo JS

A entrada e a saída são idênticas. Só o meio mudou.

O que ganhou performance

Os benchmarks são agressivos. A codebase do VS Code caiu de 125.7s pra 10.6s de type-check. Isso é 11.9x mais rápido. A Slack cortou o tempo de CI de 7.5 minutos pra 1.25 minuto.

De onde vem essa diferença?

Código nativo elimina JIT warmup e garbage collection. Node.js precisa aquecer a V8 e pausar pra coleta de lixo. O binário Go não tem esse overhead.
Paralelização real com threads e memória compartilhada. Você pode rodar tsc --checkers 8 em CI com máquinas potentes e distribuir a checagem entre workers simultâneos.

Isso não é otimização marginal — é mudança de categoria.

O que não mudou

Navegador ainda não roda TypeScript direto
Node.js ainda precisa de transpilação
O build step continua existindo
O JavaScript gerado é idêntico ao da versão 6
As regras do sistema de tipos não mudaram

Se você tinha um erro de tipo antes, vai ter o mesmo erro agora. Se tsc emitia um .js específico, continua emitindo o mesmo código.

Impacto prático no seu dia a dia

1. Editor mais responsivo

Abrir projeto grande no VS Code era sinônimo de "Initializing TypeScript..." travado por minutos. Agora isso cai pra segundos. Autocomplete, go-to-definition, verificação inline — tudo fica instantâneo.

2. CI mais rápida

Pipelines onde o gargalo era tsc --noEmit agora correm em fração do tempo. Menos espera, mais deploy.

3. Workarounds podem ser descontinuados

Muita gente ativou skipLibCheck: true só pra aliviar a performance, mesmo sabendo que isso desliga checagens importantes. Agora dá pra voltar atrás sem penalidade de velocidade.

Migração

TypeScript 7.0 saiu em 8 de julho de 2026. A API estável do compilador vem na 7.1, e aí o ecossistema (typescript-eslint, checadores de framework) migra de vez. Até lá, times podem rodar as duas versões em paralelo.

No fim: quem prometeu "TypeScript nativo no navegador" mentiu. Mas quem prometeu performance brutal entregou.

TL;DR

O compilador foi reescrito em Go e compila pra binário nativo
Seu código TypeScript continua virando JavaScript, nada mudou aí
Performance ganhou 10-12x em projetos grandes (VS Code, Slack)
Paralelização real com --checkers pra CI potente
Editor e pipeline de CI ficam drasticamente mais rápidos
Navegador ainda não roda .ts direto — esse nunca foi o plano

A IA quebrou o pipeline de devs juniores (e ninguém tá falando disso)

Taina Costa — Tue, 04 Aug 2026 16:11:33 +0000

Nos últimos dois anos, vi três empresas brasileiras congelarem contratações de júnior. Não por crise — os times seniors estavam contratando. O motivo? "Com Copilot, um pleno faz o trabalho de dois juniores." Parece eficiência. Mas se você parar pra pensar cinco minutos, percebe que acabamos de serrar o galho onde a gente tá sentado.

O problema não é a ferramenta, é o modelo mental

A IA de fato multiplica produtividade de quem já sabe o que tá fazendo. Um senior com ChatGPT escreve testes mais rápido, scaffolding vira commodity, refactor massivo acontece em minutos. Mas o pulo do gato é justamente esse "já sabe o que tá fazendo".

Um júnior não sabe. E as tasks que ele fazia pra aprender — ajustes de CSS, bugs óbvios de lógica, escrever CRUD pela décima vez até virar músculo — agora são delegadas pra IA. O problema: essas tasks chatas eram o tutorial do mundo real.

O que a gente perdeu no caminho

Quando eu comecei (2018, React 16 era novidade), passei seis meses só fazendo forms. Parecia perder tempo. Mas foi ali que internalizei:

Estado local vs global
Side effects (aprendi useEffect errando, não lendo doc)
Como lidar com async sem travar a UI
Performance (renderizações desnecessárias doem quando você causa elas)

// Meu primeiro form "de verdade" — parece simples, mas tinha
// que entender controlled components, validação, submit assíncrono
function LoginForm() {
  const [email, setEmail] = useState('');
  const [loading, setLoading] = useState(false);

  const handleSubmit = async (e) => {
    e.preventDefault();
    setLoading(true);

    try {
      await api.login({ email });
      // Como lidar com sucesso? Redirect? Toast? Context?
      // Essas perguntas só aparecem quando você tá fazendo.
    } catch (err) {
      // E erro? Mostrar onde? Como?
    } finally {
      setLoading(false);
    }
  };

  return (
    <form onSubmit={handleSubmit}>
      <input 
        value={email} 
        onChange={e => setEmail(e.target.value)}
        disabled={loading}
      />
      <button disabled={loading}>
        {loading ? 'Carregando...' : 'Entrar'}
      </button>
    </form>
  );
}

Hoje, um júnior pede pro Copilot e recebe isso pronto. Ele comita. Funciona. Mas ele não sabe por que funciona. E quando quebra em produção (loading state não reseta após erro de rede), ele não tem o mapa mental pra debugar.

O que acontece quando pulamos o tutorial

Conheci um dev recém-formado que usava IA pra tudo. Brilhante, rápido, entregava. Até o dia que o Copilot sugeriu um useEffect sem array de dependências. Ele aceitou. O componente entrou em loop infinito. Ele não entendia por quê — afinal, "a IA sempre funciona".

// Copilot sugeriu isso (e tá sintaticamente correto!)
function UserProfile({ userId }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetchUser(userId).then(setUser);
    // ⚠️ Falta o array de dependências. Isso dispara a cada render.
    // Que causa um setUser. Que causa outro render. Loop infinito.
  });

  return <div>{user?.name}</div>;
}

Um pleno vê isso e corrige no code review. Mas se você nunca causou esse bug sozinho, nunca debugou um componente travando o browser, você não desenvolve o reflexo. Vira conhecimento teórico, não operacional.

A ilusão da senioridade precoce

A IA cria uma falsa sensação de domínio. Você entrega código que parece profissional porque a IA escreve bem. Mas quando precisa:

Decidir entre Context API, Zustand ou Redux (a IA gera qualquer um)
Otimizar um re-render pesado (a IA mostra useMemo, mas onde?)
Arquitetar um sistema novo (a IA segue padrões genéricos, não o seu contexto)

...você empaca. Porque essas decisões exigem ter errado antes. Ter escolhido Context pra tudo e visto o app virar spaghetti. Ter esquecido useMemo e visto a lista de 10k itens travar.

O que fazer? (spoiler: não é "parar de usar IA")

Três coisas que tenho visto funcionar:

1. Code review como mentoria explícita

Não aceite "funciona" como métrica. Pergunte: "Por que você usou useCallback aqui? O que acontece se tirar?" Se a resposta for "o Copilot sugeriu", é red flag. O júnior precisa re-implementar do zero pra entender.

2. Tasks intencionalmente sem IA

Reserve bugs pequenos e peça: "resolve sem IA, manda perguntas no Slack". Parece cruel. Mas é nesses 40 minutos debugando um undefined que você internaliza como runtime funciona.

3. Pair programming assíncrono

Grave sua tela enquanto codifica. Mostra o processo: como você lê a stack trace, que log você adiciona, por que testou aquele edge case. Júnior copia o processo, não só o código.

# Exemplo: meu flow de debug que eu gravo e compartilho
# 1. Reproduzir o bug localmente
npm run dev
# abrir devtools, Network tab

# 2. Adicionar logs estratégicos (não console.log aleatório)
// antes do fetch
console.log('fetchUser called with:', userId);
// depois do fetch
console.log('fetchUser returned:', data);

# 3. Ver o que tá diferente do esperado
# 4. Formar hipótese ("tá chamando duas vezes?")
# 5. Validar hipótese (adicionar breakpoint)
# 6. Fixar

Esse flow não sai de prompt do ChatGPT. Vem de repetição.

O elefante na sala: vagas

A parte incômoda: empresas de fato precisam de menos juniores agora. Mas se todo mundo parar de contratar, de onde vêm os seniors de 2030? Não existe dev senior que não foi júnior antes.

A solução não é romantizar sofrimento ("na minha época fazíamos tudo na mão"). É reconhecer que aprender a programar é diferente de aprender a usar ferramentas. A IA é uma ferramenta absurda. Mas se você nunca aprendeu a programar sem ela, você não programa — você delega.

TL;DR

IA multiplica produtividade de quem já sabe; não ensina quem não sabe.
Tasks "chatas" de júnior eram o tutorial do mundo real — e sumiram.
Copilot gera código correto, mas não te ensina por que tá correto.
Sem os bugs de júnior, você não desenvolve reflexos de debug.
Solução: code review educativo, tasks sem IA, pair programming gravado.
Se ninguém treina júnior, de onde vêm os seniors de amanhã?

IA no desenvolvimento web: de escrever código para orquestrar sistemas

Taina Costa — Tue, 07 Jul 2026 14:18:12 +0000

Passei os últimos meses integrando APIs de IA em projetos reais e percebi uma mudança que ninguém está falando: não é sobre substituir desenvolvedores, é sobre mudar fundamentalmente o que a gente faz no dia a dia.

O que mudou de verdade

Todo mundo fala de ChatGPT escrevendo código. Mas o que importa mesmo é que agora você pode adicionar capacidades cognitivas nas suas aplicações tão facilmente quanto você adiciona um banco de dados. Precisa classificar texto? Gerar conteúdo? Extrair estrutura de dados não estruturados? Antes você treinava um modelo ou usava regex insanos. Hoje você chama uma API.

Isso muda o jogo porque você para de escrever lógica complexa e começa a orquestrar comportamentos. É arquitetura, não algoritmo.

O padrão que você vai usar toda hora

Aqui está o código que eu mais escrevo ultimamente - uma edge function que pega input do usuário e retorna JSON estruturado:

// app/api/analyze/route.ts
import { Anthropic } from '@anthropic-ai/sdk';

export async function POST(req: Request) {
  const { content } = await req.json();
  const anthropic = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY });

  const message = await anthropic.messages.create({
    model: 'claude-3-5-sonnet-20241022',
    max_tokens: 1024,
    messages: [{
      role: 'user',
      content: `Extract key points from this text as JSON with keys: topic, sentiment, actionItems. Text: ${content}`
    }]
  });

  const result = JSON.parse(message.content[0].text);
  return Response.json(result);
}

Simples, mas repara: você não escreveu nenhuma lógica de análise. Você descreveu o que queria e a IA fez. Isso funciona para 80% dos casos de processamento de texto que você encontra.

Streaming: a parte que ninguém mostra

O problema do código acima? Latência. Modelos de IA demoram. A mágica moderna é streaming - você vai renderizando a resposta conforme ela chega:

export async function POST(req: Request) {
  const { prompt } = await req.json();
  const anthropic = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY });

  const stream = await anthropic.messages.stream({
    model: 'claude-3-5-sonnet-20241022',
    max_tokens: 1024,
    messages: [{ role: 'user', content: prompt }]
  });

  const encoder = new TextEncoder();
  const readable = new ReadableStream({
    async start(controller) {
      for await (const chunk of stream) {
        if (chunk.type === 'content_block_delta' && chunk.delta.type === 'text_delta') {
          controller.enqueue(encoder.encode(chunk.delta.text));
        }
      }
      controller.close();
    }
  });

  return new Response(readable, {
    headers: { 'Content-Type': 'text/plain; charset=utf-8' }
  });
}

No frontend, você consome com um loop simples:

const response = await fetch('/api/analyze', {
  method: 'POST',
  body: JSON.stringify({ prompt: userInput })
});

const reader = response.body.getReader();
const decoder = new TextDecoder();

while (true) {
  const { done, value } = await reader.read();
  if (done) break;
  const text = decoder.decode(value);
  setContent(prev => prev + text); // React state update
}

Isso transforma a experiência. Em vez de spinner por 5 segundos, o usuário vê a resposta se formando. Parece detalhe, mas é a diferença entre "lento" e "mágico".

O padrão de composição que você precisa dominar

Aqui está onde fica interessante. Você não chama IA uma vez - você compõe chamadas. Exemplo real que implementei: um sistema de sugestões de código que primeiro analisa o contexto, depois gera sugestões, depois filtra as irrelevantes:

async function generateContextualSuggestions(code: string, cursor: number) {
  // Step 1: Understand context
  const context = await anthropic.messages.create({
    model: 'claude-3-5-haiku-20241022', // fast model for analysis
    max_tokens: 512,
    messages: [{
      role: 'user',
      content: `What is the user trying to do at cursor position ${cursor}? Code: ${code}`
    }]
  });

  const intent = JSON.parse(context.content[0].text);

  // Step 2: Generate suggestions based on intent
  const suggestions = await anthropic.messages.create({
    model: 'claude-3-5-sonnet-20241022', // powerful model for generation
    max_tokens: 2048,
    messages: [{
      role: 'user',
      content: `Generate 5 code completions for: ${intent.description}`
    }]
  });

  return suggestions.content[0].text;
}

Repara que usei Haiku para análise (mais rápido, mais barato) e Sonnet para geração (mais capaz). Você orquestra modelos diferentes para partes diferentes do problema. É como escolher entre PostgreSQL e Redis - cada ferramenta tem seu uso.

Os problemas que você vai enfrentar

Custo. Cada chamada custa dinheiro. Você precisa cachear agressivamente. Eu uso um padrão simples: hash do input como chave de cache, TTL de 24h para respostas determinísticas:

const cacheKey = createHash('sha256').update(content).digest('hex');
const cached = await redis.get(cacheKey);
if (cached) return JSON.parse(cached);

// ... make API call ...

await redis.setex(cacheKey, 86400, JSON.stringify(result));

Latência. Mesmo com streaming, é mais lento que lógica tradicional. Use IA para o que humanos fariam devagar (análise de contexto, geração criativa), não para o que código faz rápido (validação, cálculos).

Consistência. LLMs não são determinísticos. Se você precisa de output previsível toda vez, passe temperature: 0 e valide o schema da resposta:

const result = JSON.parse(response);
if (!result.topic || !Array.isArray(result.actionItems)) {
  throw new Error('Invalid response format');
}

O que isso significa para você

Seu trabalho está mudando de "implementar algoritmos" para "desenhar fluxos". Você vai passar mais tempo decidindo quando usar IA (caro, lento, flexível) vs quando usar código tradicional (barato, rápido, rígido).

A skill que importa agora é arquitetura de sistemas: saber decompor problemas, escolher as ferramentas certas para cada parte, e fazer tudo funcionar junto. O código em si? Cada vez menos importante.

Não é sobre IA escrever seu código. É sobre você usar IA como mais uma ferramenta na stack - junto com banco de dados, cache, filas, e tudo mais que você já orquestra.

TL;DR

IA em produção não é sobre substituir devs, é adicionar capacidades cognitivas via API
O padrão fundamental: edge function + LLM API + streaming para UX fluida
Componha múltiplas chamadas com modelos diferentes (rápido vs poderoso) para cada etapa
Cache agressivo, valide schemas, use temperature: 0 quando precisar de consistência
Seu trabalho está virando orquestração de sistemas, não escrita de algoritmos

Legacy code não envelhece como vinho: quanto mais espera, pior fica

Taina Costa — Wed, 24 Jun 2026 15:35:46 +0000

Semana passada eu passei três horas debugando um bug que deveria levar 20 minutos. O problema? Um módulo de validação escrito em 2019 que ninguém mexe "porque funciona". Spoiler: não funcionava mais, e quando finalmente abri o arquivo, encontrei um // TODO: refactor this datado de 2020.

Por que legacy vira bola de neve

A indústria trata código legado como se fosse dívida técnica opcional — algo que você paga "quando tiver tempo". Mas código legado se comporta mais como mofo: se espalha, contamina áreas adjacentes, e quanto mais você ignora, mais cara fica a limpeza.

O ciclo é previsível: você herda um projeto ou feature antiga, vê que está "meio bagunçado mas roda", adiciona sua feature com um if a mais, e segue em frente. Seis meses depois, outra pessoa faz o mesmo. Um ano depois, aquele arquivo tem 800 linhas, cinco níveis de if aninhados, e zero testes. Ninguém mais entende o fluxo completo, então cada mudança vira uma sessão de especulação: "se eu mexer aqui, quebra ali?"

O custo real de esperar

Esse código "que funciona" tem um custo oculto que aparece em três formas:

Velocidade de desenvolvimento despenca. Features que deveriam levar dois dias levam uma semana porque você passa mais tempo entendendo o contexto do que escrevendo código novo.

Bugs aumentam exponencialmente. Código sem testes e com lógica embolada é um gerador de regressões. Você corrige um edge case e quebra outro que nem sabia que existava.

Onboarding vira tortura. Novo dev no time? Boa sorte explicando por que aquele service tem três formas diferentes de fazer autenticação, ou por que a mesma validação está copiada em sete lugares.

Sinais de que você está sentado em cima de uma bomba

Nem todo código antigo é legacy tóxico. Aqui estão os red flags que indicam que você precisa agir agora:

// Red flag #1: comentários mentirosos ou inúteis
function processPayment(order) {
  // Process the payment
  const user = order.user;  // TODO: fix this later

  // HACK: don't touch this, breaks prod
  if (user.country === 'BR') {
    // ...
  }
}

// Red flag #2: lógica de negócio duplicada
// arquivo A
const validCPF = cpf => cpf.length === 11 && /^\d+$/.test(cpf);

// arquivo B (outro módulo)
const isCPFValid = doc => doc.replace(/\D/g, '').length === 11;

// arquivo C (mais outro)
function checkCPF(value) {
  return value.match(/\d{11}/) !== null;
}

// Red flag #3: dependências circulares e acoplamento absurdo
import { UserService } from './user';
import { OrderService } from './order';
// OrderService importa UserService
// UserService importa OrderService
// Ambos importam shared state global

Se você leu esse código e pensou "isso parece familiar", você já está pagando juros.

Estratégia incremental: você não precisa reescrever tudo

A boa notícia: você não precisa parar o mundo para arrumar legacy. Reescritas completas falham 80% das vezes porque você gasta seis meses reconstruindo funcionalidade existente enquanto o negócio continua pedindo features novas.

A abordagem que funciona é refactoring incremental com testes de caracterização. A ideia é:

Capture o comportamento atual (mesmo que estranho) em testes
Refatore sem mudar comportamento
Repita até o código ficar legível
Só então mude comportamento, com testes reais

Exemplo prático. Você tem esse monstro:

function calculateTotal(items, user, coupon) {
  let total = 0;
  for (let i = 0; i < items.length; i++) {
    if (items[i].category === 'book') {
      total += items[i].price * 0.9;
    } else {
      total += items[i].price;
    }
  }
  if (user.isPremium) {
    total = total * 0.95;
  }
  if (coupon && coupon.valid) {
    total = total - coupon.value;
  }
  return total;
}

Primeiro, você captura o comportamento atual com testes de caracterização:

describe('calculateTotal (caracterização)', () => {
  it('aplica 10% desconto em livros', () => {
    const items = [{ category: 'book', price: 100 }];
    expect(calculateTotal(items, {}, null)).toBe(90);
  });

  it('aplica desconto premium antes de coupon', () => {
    const items = [{ category: 'other', price: 100 }];
    const user = { isPremium: true };
    const coupon = { valid: true, value: 10 };
    // 100 * 0.95 - 10 = 85 (não 90 * 0.95)
    expect(calculateTotal(items, user, coupon)).toBe(85);
  });
});

Esses testes documentam bugs e edge cases que você nem sabia que existiam (tipo a ordem de aplicação dos descontos). Agora você pode refatorar com segurança:

const applyBookDiscount = price => price * 0.9;
const applyPremiumDiscount = total => total * 0.95;
const applyCoupon = (total, coupon) => 
  coupon?.valid ? total - coupon.value : total;

function calculateTotal(items, user, coupon) {
  const subtotal = items.reduce((sum, item) => {
    const price = item.category === 'book' 
      ? applyBookDiscount(item.price)
      : item.price;
    return sum + price;
  }, 0);

  let total = user.isPremium 
    ? applyPremiumDiscount(subtotal)
    : subtotal;

  return applyCoupon(total, coupon);
}

Os testes continuam passando, mas agora o código é legível e as funções são reutilizáveis. Você pode até descobrir bugs (tipo aquela ordem de desconto esquisita) e decidir se corrige agora ou documenta como comportamento legado intencional.

Caveats: quando NÃO mexer

Refatorar legacy tem armadilhas:

Não refatore sem testes. Se você não consegue escrever testes de caracterização porque o código é intratável (muitos side effects, dependências globais), primeiro isole a lógica. Extraia funções puras antes de tentar refatorar a orquestração.

Cuidado com "melhorias" que mudam comportamento. Aquele bug pode ser uma feature não documentada que algum cliente depende. Se não tem teste cobrindo, não mude.

Legacy que ninguém toca pode ficar quieto. Se é um módulo que não mudou em três anos e não causa problemas, deixa lá. Foque em código que você precisa mexer frequentemente.

TL;DR

Código legado piora exponencialmente: cada mudança sem refactor aumenta complexidade e risco
Red flags: comentários inúteis, lógica duplicada, dependências circulares, zero testes
Não reescreva tudo: use refactoring incremental com testes de caracterização
Capture comportamento atual primeiro, refatore sem mudar semântica, depois melhore
Não mexa em código que está quieto e não incomoda
Quanto mais espera, mais caro fica — escolha suas batalhas, mas não ignore todas

Por que todo dev deveria participar de um writing challenge (e como vencer)

Taina Costa — Tue, 16 Jun 2026 18:28:37 +0000

Acabei de ver os vencedores do Google I/O 2026 Writing Challenge no dev.to. Enquanto scrollava os artigos premiados, percebi um padrão: os que ganharam não são necessariamente os devs mais seniors ou com mais seguidores — são os que sabem transformar conceitos complexos em narrativas que grudam na cabeça.

Por que writing challenges importam agora

O mercado está saturado de tutoriais genéricos gerados por IA. Documentação oficial melhorou muito, mas ainda falta o "como eu uso isso de verdade". Challenges de escrita forçam você a:

Provar que entende o que está usando (não dá pra enrolar)
Construir portfólio público (recrutadores leem, sim)
Solidificar conhecimento — você só entende de verdade quando consegue explicar

Três devs da minha timeline conseguiram job offers depois de artigos viralizarem. Não é sobre viralizar, mas sobre demonstrar que você pensa, não só copia.

O que funciona (com exemplos reais)

Analisei 15 artigos vencedores de challenges anteriores. O padrão:

Estrutura vencedora:

# Título: promessa específica, não vaga
"Como evitei 3 horas de debug com React DevTools"
vs
"Guia completo de React DevTools" ❌

## Problema real primeiro
Mostre o erro, o stack trace, a dor.

## Solução progressiva
Do jeito errado → melhor → ideal
Cada passo explica *por que*, não só *como*

## Code que roda
Sem `// ... resto do código`
Sem `import { magicFunction } from 'somewhere'`

## TL;DR brutal
3-5 bullets, zero fluff

Exemplo prático — antes vs depois:

Antes (genérico):

// Use async/await para chamadas assíncronas
async function getData() {
  const data = await fetch('/api/data');
  return data;
}

Depois (mostra o problema real):

// ❌ Isso quebra silenciosamente em prod quando a API retorna 404
async function getData() {
  const data = await fetch('/api/data');
  return data.json(); // TypeError se response.ok === false
}

// ✅ Agora você sabe *quando* explode
async function getData() {
  const response = await fetch('/api/data');

  if (!response.ok) {
    throw new Error(`API error: ${response.status}`);
  }

  return response.json();
}

Comentários em código ficam em inglês (padrão da indústria), mas a explicação ao redor é pt-BR.

Armadilhas que matam suas chances

1. Code sem contexto
Você colou um snippet de 50 linhas sem explicar o setup. Ninguém vai copiar pro projeto deles só pra testar se funciona.

Solução: crie um repo mínimo ou use CodeSandbox/StackBlitz embeddable. Link no artigo.

2. "Aqui está tudo sobre X"
Artigos que tentam cobrir tudo ficam superficiais. Melhor: pegue UM caso de uso, vá fundo.

Exemplo:

❌ "Guia completo de React Hooks"
✅ "useCallback está te deixando mais lento — veja quando NÃO usar"

3. Escrever pra impressionar, não pra ensinar
Jargão técnico sem necessidade. Abstrações sem exemplo concreto. Se você precisa de 3 parágrafos pra chegar no código, corte 2.

4. Ignorar o "por que agora"
Challenges normalmente pedem artigos sobre features recentes. Se você escrever sobre React Server Components, tem que mencionar:

Por que isso existe (Suspense, data fetching, bundle size)
O que mudou da última versão
Quando você não deve usar

Como eu abordo um writing challenge

Meu processo quando decido participar:

Leio a documentação oficial da feature + issues no GitHub

Issues revelam dores reais, edge cases, o que confunde as pessoas.
Reproduzo o problema antes da solução

Crio um repo pequeno, quebro tudo, documento cada erro. Isso vira a primeira seção do artigo.
Escrevo o TL;DR primeiro

Se não consigo resumir em 5 bullets, o artigo não tem foco suficiente.
Code funcional, sempre

Testo cada snippet. Se não roda standalone, adiciono o setup mínimo. npm create vite@latest, instala dependências, mostra onde colar o código.
Releio como se fosse um dev com pressa

Você tem 2 minutos antes da daily. O artigo resolve seu problema ou você fecha a aba?

Ferramentas que uso

Grammarly (tem versão pt-BR) pra pegar typos que passam no revisor
Carbon ou ray.so pra screenshots de código bonitinhos
Excalidraw pra diagramas rápidos quando preciso explicar fluxo
StackBlitz pra embeds interativos — leitor testa sem sair do artigo

TL;DR

Challenges premiam clareza + código funcional, não firulas
Estrutura vencedora: problema real → código progressivo → caveats
Uma ideia funda > dez ideias rasas
Code sem contexto de setup = artigo que ninguém usa
TL;DR no final (estilo este) fecha bem e facilita skimming

webMCP: você vai anotar HTML para agentes de IA

Taina Costa — Tue, 09 Jun 2026 16:32:38 +0000

Há alguns anos, você adaptou seu site para mobile. Depois, para acessibilidade. Agora o Google está sugerindo que você adapte para agentes de IA — e o webMCP (Web Model Context Protocol) é a proposta experimental que pode mudar como construímos interfaces para serem consumidas por LLMs.

O problema que resolve

Quando um agente de IA tenta usar um site hoje, ele faz o mesmo que um usuário humano: inspeciona o DOM, tenta adivinhar o que cada botão faz, clica, analisa o resultado, repete. Essa dança custosa desperdiça tokens e é pouco confiável — um layout redesenhado pode quebrar toda a lógica do agente.

O webMCP inverte essa lógica: em vez de forçar o agente a deduzir o que é possível fazer, você declara diretamente no HTML ou via JavaScript.

Como funciona (versão declarativa)

Você anota seus elementos com metadados que descrevem a intenção, não só a aparência:

<button 
  data-mcp-action="checkout" 
  data-mcp-params='{"cartId": "abc123"}'>
  Finalizar compra
</button>

O agente lê a anotação, entende que aquele botão dispara uma ação de checkout com o parâmetro cartId, e interage diretamente — sem precisar interpretar CSS ou localização visual.

Pense nisso como ARIA para agentes: você já adiciona role="button" e aria-label para screen readers; webMCP é o mesmo conceito estendido para LLMs.

Versão imperativa (JavaScript)

Se você prefere controle programático, pode registrar ferramentas (tools) via MCP:

window.mcp.registerTool('hireDevelopers', {
  description: 'Contrata desenvolvedores para o time',
  parameters: { count: 'number', skills: 'string[]' },
  handler: async ({ count, skills }) => {
    // lógica de contratação
    return { hired: count, roles: skills }
  }
})

O agente descobre as tools disponíveis, lê os schemas, e chama as funções diretamente — sem clicar em nada.

O que muda na prática

Antes: você escreve testes E2E com Playwright que simulam cliques. O agente faz a mesma coisa, mas sem os testes salvos.

Depois: você expõe um contrato explícito de ações possíveis. O agente consome esse contrato como consumiria uma REST API.

A diferença é menos sobre capacidade nova e mais sobre confiabilidade e custo. Um agente que lê anotações usa 10× menos tokens do que um que precisa fazer scraping visual.

Caveats

Experimental: só funciona no Chrome Canary/Beta com flags habilitadas. Não é standard da web (ainda).
Manutenção dupla: você vai manter UI para humanos + anotações para agentes. Isso pode ficar fora de sincronia.
Segurança: expor actions via MCP é expor superfície de ataque. Validação de entrada vira ainda mais crítica.
Adoção: se só o Google empurrar isso, pode morrer na praia. Web standards exigem consenso.

Quando vale a pena

Se você já tem uma aplicação que seria útil para agentes (dashboards, admin panels, ferramentas internas), adicionar webMCP pode torná-la consumível por LLMs sem construir uma API separada.

Se você está começando um produto novo voltado para automação, considere desenhar com anotações MCP desde o início — especialmente se o use case inclui usuários técnicos que vão querer scripting.

TL;DR

webMCP permite que sites declarem suas ações possíveis via HTML ou JS, em vez de forçar agentes a adivinhar clicando.
Funciona como progressive enhancement: usuários humanos não veem diferença, agentes ganham um contrato explícito.
Reduz custo de tokens e aumenta confiabilidade quando LLMs interagem com seu site.
Ainda experimental (Chrome Canary), mas sinaliza um futuro onde "otimizar para IA" vira padrão, assim como mobile e acessibilidade.
Vale considerar se seu produto já é target de automação ou scraping por agentes.

Game Jams no Browser: Você Não Precisa de Unity

Taina Costa — Mon, 08 Jun 2026 12:32:18 +0000

Se você já fez algum front-end interativo, já tem 80% do que precisa pra fazer um jogo simples. Game jams como a June Solstice são desculpa perfeita pra testar isso — três semanas, tema aberto, e você descobre que canvas + requestAnimationFrame levam longe.

Por Que Desenvolvedores Web Deviam Fazer Game Jams

A maioria dos devs que conheço nunca tentou fazer um jogo porque acha que precisa aprender Unity ou Unreal. Mas se você já mexeu com animações CSS, state management ou physics simulators básicos pra UI, você já cruzou metade da ponte. Game jams forçam escopo pequeno — você não vai fazer Elden Ring em três semanas, vai fazer um Snake com twist. E isso cabe perfeitamente no que o browser oferece.

Além disso, jogos web rodam em qualquer lugar. Sem instalador, sem App Store review, sem build pra cinco plataformas. Você manda um link e qualquer um joga. Pra um jam onde o pessoal precisa testar dezenas de jogos rápido, isso importa.

Canvas API: Seu Motor Gráfico Embutido

O <canvas> existe desde 2010 e faz exatamente o que você precisa: desenhar pixels, shapes e imagens num loop de 60fps. A estrutura básica de qualquer jogo 2D cabe em 30 linhas:

const canvas = document.querySelector('canvas');
const ctx = canvas.getContext('2d');

const gameState = {
  player: { x: 50, y: 50, speed: 2 },
  enemies: []
};

function update(deltaTime) {
  // Input handling
  if (keys['ArrowRight']) gameState.player.x += gameState.player.speed;
  if (keys['ArrowLeft']) gameState.player.x -= gameState.player.speed;

  // Game logic
  gameState.enemies.forEach(enemy => {
    enemy.x += Math.sin(Date.now() / 1000) * 0.5;
  });
}

function render() {
  ctx.clearRect(0, 0, canvas.width, canvas.height);

  // Draw player
  ctx.fillStyle = '#00ff00';
  ctx.fillRect(gameState.player.x, gameState.player.y, 20, 20);

  // Draw enemies
  gameState.enemies.forEach(enemy => {
    ctx.fillStyle = '#ff0000';
    ctx.fillRect(enemy.x, enemy.y, 15, 15);
  });
}

let lastTime = 0;
function gameLoop(currentTime) {
  const deltaTime = currentTime - lastTime;
  lastTime = currentTime;

  update(deltaTime);
  render();
  requestAnimationFrame(gameLoop);
}

requestAnimationFrame(gameLoop);

Esse padrão — update() pra lógica, render() pra desenho, gameLoop() amarrando tudo — é o mesmo de engines profissionais. A diferença é escala, não conceito.

Colisões e Física Sem Biblioteca

A parte que pega mais gente é detecção de colisão. Mas pra um jogo simples tipo jam, AABB (Axis-Aligned Bounding Box) resolve 90% dos casos:

function checkCollision(rectA, rectB) {
  return rectA.x < rectB.x + rectB.width &&
         rectA.x + rectA.width > rectB.x &&
         rectA.y < rectB.y + rectB.height &&
         rectA.y + rectA.height > rectB.y;
}

// No update()
gameState.enemies.forEach(enemy => {
  if (checkCollision(gameState.player, enemy)) {
    gameState.lives -= 1;
    enemy.x = -100; // Remove offscreen
  }
});

Física básica também é só Newton. Quer gravidade? player.velocityY += 0.5; player.y += player.velocityY;. Quer bounce? Inverte a velocidade quando bater no chão. Você não precisa de Box2D pra um platformer de jam.

Quando Usar um Framework

Canvas puro é divertido pra aprender, mas se você quer algo mais sólido, Phaser 3 é o meio-termo perfeito. Ele abstrai o canvas mas te deixa no controle:

import Phaser from 'phaser';

class GameScene extends Phaser.Scene {
  create() {
    this.player = this.physics.add.sprite(100, 100, 'player');
    this.cursors = this.input.keyboard.createCursorKeys();
  }

  update() {
    if (this.cursors.left.isDown) {
      this.player.setVelocityX(-160);
    } else if (this.cursors.right.isDown) {
      this.player.setVelocityX(160);
    } else {
      this.player.setVelocityX(0);
    }
  }
}

const config = {
  type: Phaser.AUTO,
  width: 800,
  height: 600,
  physics: { default: 'arcade' },
  scene: GameScene
};

new Phaser.Game(config);

Phaser dá física de graça, sprite sheets, tilemaps, tween animations. Você pula as 200 linhas de boilerplate e vai direto pro gameplay. Pra um jam de três semanas, isso é a diferença entre terminar e não terminar.

Caveats que Aprendi na Prática

Performance: Canvas 2D aguenta uns 1000 sprites antes de engasgar. Se você precisa de mais, WebGL direto ou PixiJS. Mas honestamente, se o seu jogo de jam tem mil objetos na tela, o problema não é técnico — é design.

Mobile: Touch events não mapeiam direto pra teclado. Você vai precisar de botões virtuais ou gestures. E testa no celular cedo — Chrome DevTools não mostra quão lento o seu loop roda num Android médio.

Asset pipeline: Não existe importador automático de sprites. Você carrega tudo na mão (new Image()). Dá pra fazer um loader simples com Promises, mas se você tem muitos assets, Phaser ou uma build tool que processa imagens salva tempo.

Audio: <audio> funciona, mas latência mata jogos de ritmo. Web Audio API é mais complexa mas necessária se timing importa. Ou usa Howler.js e não pensa nisso.

Não reinvente tudo: Se você nunca fez um jogo, copie a estrutura de um exemplo de Phaser e ajuste. Jams recompensam execução, não pureza arquitetural. Você pode refatorar depois se quiser continuar o projeto.

TL;DR

Desenvolvedores web já sabem o suficiente pra fazer jogos 2D simples — Canvas + game loop é tudo.
AABB collision detection resolve a maioria dos casos sem física engine.
Canvas puro ensina os fundamentos; Phaser 3 acelera produção sem esconder a mecânica.
Performance de Canvas 2D é boa até ~1000 sprites; depois disso, WebGL.
Game jams são escopo perfeito pra testar: três semanas, um mechanic core, ship algo jogável.

Spoiler: escrever código é só 20% do trabalho

Taina Costa — Wed, 03 Jun 2026 16:03:33 +0000

Lembro da minha primeira semana como dev. Tinha acabado de ganhar meu primeiro freela, estava terminando a faculdade, me sentindo pronta. Pensei: "agora sim, vou passar o dia inteiro escrevendo código bonito". Duas semanas depois, percebi que tinha passado mais tempo no Slack, no Figma e no Google Docs do que no VS Code. E isso me deixou meio perdida — será que eu estava fazendo algo errado?

Por que ninguém te prepara pra isso

Os bootcamps e a faculdade ensinam algoritmos, estruturas de dados, frameworks. Você sai achando que o trabalho é: pegar uma task, abrir o editor, codar, commitar, próxima task. Mas a realidade é outra. Você gasta tempo entendendo por que aquele botão precisa existir, discutindo se a API deve retornar um array ou um objeto, explicando pra PM por que aquela feature vai levar 3 sprints e não 2 dias. O código é quase uma consequência — a parte final de um processo que começa muito antes de você abrir o arquivo.

E não é que você esteja fazendo errado. É que o trabalho mudou, e ninguém atualiza a descrição da vaga.

A anatomia real de uma task

Pega uma feature qualquer. Vou usar um exemplo que vivi: "adicionar filtro de data no dashboard de vendas". Parece simples, certo? Aqui está o que realmente aconteceu:

// O código final foi isso aqui:
const [dateRange, setDateRange] = useState({ start: null, end: null });

const filteredSales = sales.filter(sale => {
  if (!dateRange.start || !dateRange.end) return true;
  return sale.date >= dateRange.start && sale.date <= dateRange.end;
});

Quinze linhas. Levou 8 horas. Por quê?

1h alinhando com o time de produto: o filtro reseta quando muda de página? Salva no localStorage? Funciona com timezone do cliente ou do servidor?
2h investigando por que o componente de datepicker da lib que a gente usa não funciona no Safari 15 (spoiler: Intl.DateTimeFormat com timezone UTC quebra em alguns casos)
1h escrevendo testes (sim, até pra isso tem teste)
30min documentando no Notion o comportamento decidido
1h no code review explicando por que não usei a lib X (porque ela adiciona 40kb no bundle)
O resto: escrevendo o código

O código foi 20% do tempo. O resto foi comunicação, investigação, decisão, documentação.

As habilidades invisíveis

Aqui está o que eu uso no dia a dia e que nenhum curso ensinou direito:

1. Ler contexto em threads do Slack

Você recebe uma task: "O botão de checkout não funciona". Aí você vai no canal, sobe 150 mensagens, descobre que na verdade funciona, mas só em produção, só pra usuários logados, só se o carrinho tem menos de 10 itens. Essa skill de garimpar contexto é essencial.

2. Traduzir tech pra não-tech (e vice-versa)

// PM: "Precisa ser em tempo real"
// Dev brain: WebSocket? SSE? Long polling? Qual a latência aceitável?

// O que eu respondo:
"Tempo real tipo chat (mensagem chega em 1s) ou tipo painel 
(atualiza a cada 30s)? Isso muda bastante a arquitetura."

Saber fazer essa ponte economiza retrabalho.

3. Debugar o bug invisível

O código funciona na sua máquina. Quebra em staging. Você passa 2 horas descobrindo que é a versão do Node no Docker que trata BigInt diferente. O código que você escreve pra resolver:

// Antes
const total = sales.reduce((sum, sale) => sum + sale.amount, 0);

// Depois (pra garantir que funciona em Node 16 e 18)
const total = sales.reduce((sum, sale) => 
  Number(sum) + Number(sale.amount), 0
);

Três caracteres de diferença. Duas horas de investigação.

4. Dizer não (com contexto)

"Dá pra adicionar essa feature até sexta?"

Não é só falar "não". É explicar: "Dá, mas vamos ter que adiar os testes automatizados, e isso significa que a cada nova feature vamos gastar mais tempo testando manual. Prefere assim ou deixa pra sprint que vem com testes inclusos?"

Os trade-offs que ninguém te conta

Agora a parte que dói: algumas dessas habilidades competem com escrever código.

Quanto mais você participa de calls de alinhamento, menos tempo tem pra codar (mas menos retrabalho)
Quanto mais você documenta decisões, menos features você entrega na sprint (mas menos gente te interrompe com dúvida)
Quanto mais você revisa PR dos outros, menos avança no seu (mas o código da base melhora)

Não tem resposta certa. Depende do momento do projeto, do time, da senioridade. Mas é importante saber que esse trade-off existe. Quando você vê um dev senior que "não escreve tanto código", muitas vezes é porque ele está resolvendo os problemas antes de virarem código.

E quando você só quer codar?

Olha, eu entendo. Tem dias que eu só queria pegar uma task bem definida, colocar fone, e passar 4 horas refatorando aquele componente gigante. E tá tudo bem querer isso.

Algumas estratégias que funcionam pra mim:

Blocos de deep work: combina com o time 2h de "não me chama" por dia
Pegar tasks técnicas: refatoração, performance, migração de versão — geralmente exigem menos alinhamento
Projetos paralelos: onde você controla 100% do escopo e só programa

Mas se você está num time, numa empresa, trabalhando em produto real, vai ter que aceitar: escrever código é uma parte do trabalho, não o trabalho inteiro.

TL;DR

Desenvolvimento de software é 20% código, 80% contexto, comunicação e decisão
As habilidades mais usadas no dia a dia: ler contexto, traduzir tech↔︎não-tech, debugar o invisível, negociar escopo
Há trade-offs reais entre codar e outras atividades — e tá tudo bem
Devs seniors "escrevem menos código" porque resolvem problemas antes deles virarem código
Se você quer focar em código puro: negocie blocos de deep work ou escolha projetos/empresas que permitam isso

O que é uma API REST? Entenda em 5 minutos com exemplos do dia a dia

Taina Costa — Thu, 21 May 2026 11:42:16 +0000

Um guia visual e sem complicação para quem está começando agora na programação

Se você está começando a programar, já deve ter ouvido a palavra "API" umas mil vezes — em vídeos, vagas de emprego, documentações. E provavelmente pensou: "ok, mas o que isso significa, na prática?"

Neste artigo vou te explicar o que é uma API REST usando exemplos do mundo real, sem termos técnicos desnecessários. No final, você vai entender o conceito que está por trás de praticamente todo aplicativo que você usa todo dia.

A analogia do garçom

Imagine que você está em um restaurante. Você não vai até a cozinha pegar sua comida, certo? Você fala com o garçom, que leva seu pedido pra cozinha e traz a comida de volta pra mesa.

Uma API funciona exatamente assim. Ela é o garçom entre dois sistemas:

Você (ou um aplicativo) faz um pedido
A API leva esse pedido pra um servidor (a "cozinha")
O servidor processa o pedido e devolve uma resposta
A API entrega a resposta de volta pra você

Toda vez que o app do iFood mostra restaurantes perto de você, ele está fazendo isso através de uma API. Toda vez que o Instagram carrega o feed, é uma API que entrega os posts. Quando você paga com Pix, três ou quatro APIs conversam entre si nos bastidores.

O que significa "REST"?

REST é um conjunto de regras sobre como essa "conversa" entre sistemas deve acontecer. Pense nisso como o protocolo de etiqueta do garçom: ele sempre vai te perguntar de uma certa forma, anotar de um certo jeito, e trazer a resposta seguindo um padrão.

As principais regras do REST são:

Tudo é um recurso. Um usuário, um produto, uma foto — cada coisa tem um endereço próprio
A conversa é sem memória. Cada pedido é independente, o servidor não "lembra" do pedido anterior
Usa os métodos do HTTP. Aqueles verbos: GET, POST, PUT, DELETE

Os 4 verbos que você precisa conhecer

Esses são os "tipos de pedido" que você pode fazer pra uma API REST:

Verbo	O que faz	Exemplo
`GET`	Buscar informação	"Me mostra os meus posts"
`POST`	Criar algo novo	"Cria um post novo"
`PUT`	Atualizar algo existente	"Muda o título desse post"
`DELETE`	Apagar algo	"Apaga esse post"

Um exemplo prático

Vamos supor que existe uma API de uma rede social fictícia. Pra buscar todos os posts de um usuário, você faria uma requisição assim:

GET https://api.redesocial.com/usuarios/123/posts

Lendo da esquerda pra direita:

GET — quero buscar informação
https://api.redesocial.com — endereço da API
/usuarios/123/posts — quero os posts do usuário de ID 123

A API responderia algo parecido com isso (em formato JSON, que é o jeito mais comum de organizar dados na web):


json
[
  {
    "id": 1,
    "titulo": "Meu primeiro post",
    "data": "2026-05-15"
  },
  {
    "id": 2,
    "titulo": "Aprendendo APIs",
    "data": "2026-05-20"
  }
]
Pronto. Isso é uma resposta de API REST. Seu aplicativo recebe esses dados e mostra na tela como uma lista de posts.

Como testar uma API de verdade (sem programar)
Você pode testar APIs públicas direto do navegador. Tente abrir esse link agora:


https://api.github.com/users/torvalds
Você vai ver os dados do perfil do Linus Torvalds (criador do Linux) no GitHub. Isso é uma resposta de API REST em formato JSON.

Outras APIs públicas que valem a pena explorar:

PokeAPI — dados de Pokémon (https://pokeapi.github.io/)
ViaCEP — consulta de CEP brasileiro (https://viacep.com.br/)
JSONPlaceholder — API fake pra testes (https://jsonplaceholder.typicode.com/)
Próximos passos
Agora que você entendeu o conceito, sugiro:

Testar a ViaCEP abrindo https://viacep.com.br/ws/01310100/json/ no navegador
Estudar JSON — é o formato em que as APIs respondem
Aprender sobre fetch (JavaScript) ou a biblioteca requests (Python) — são as ferramentas pra fazer chamadas de API em código
Conclusão
API REST não é um bicho de sete cabeças. É só uma forma padronizada de dois sistemas conversarem pela internet. Toda vez que você usa qualquer aplicativo moderno, dezenas de APIs estão trabalhando nos bastidores pra que ele funcione.

Se esse conteúdo te ajudou, deixa um ❤️ aí embaixo. E se quiser que eu escreva sobre algum outro conceito de programação explicado de forma simples, comenta o tema!