DEV Community: Taina Costa

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!