DEV Community: Taina Costa

Estamos treinando nossa própria substituição (e ninguém tem um plano B)

Taina Costa — Tue, 10 Nov 2026 20:44:26 +0000

Semana passada passei três horas debugando um bug que o Copilot gerou. Não foi a primeira vez. E provavelmente não será a última. O que me fez pensar: estamos mesmo construindo ferramentas para nos substituir, ou apenas mudando o tipo de problema que resolvemos?

A promessa que não chegou

Lembra de 2022? GPT-3 saindo, todo mundo dizendo que programadores iam virar "prompt engineers" e que código ia sumir. Três anos depois, continuo escrevendo código. Muito código. Só que agora também corrijo o que a IA gera.

A verdade é que IA não está nos substituindo — está redistribuindo nosso tempo. Menos tempo escrevendo boilerplate, mais tempo fazendo code review de máquina. Menos tempo no Stack Overflow, mais tempo refinando prompts. O trabalho mudou, não sumiu.

O que realmente acontece no código

Vou te mostrar um exemplo real. Pedi para o GPT-4 gerar um hook React para debounce de busca:

// O que o GPT-4 gerou
function useDebounce(value, delay) {
  const [debouncedValue, setDebouncedValue] = useState(value);

  useEffect(() => {
    const handler = setTimeout(() => {
      setDebouncedValue(value);
    }, delay);

    return () => {
      clearTimeout(handler);
    };
  }, [value, delay]);

  return debouncedValue;
}

Funciona. Até funciona bem para 80% dos casos. O problema está nos 20% que a IA não vê:

// O que você realmente precisa em produção
function useDebounce(value, delay, options = {}) {
  const [debouncedValue, setDebouncedValue] = useState(value);
  const { leading = false, maxWait } = options;

  useEffect(() => {
    if (leading && !maxWait) {
      setDebouncedValue(value);
    }

    const handler = setTimeout(() => {
      setDebouncedValue(value);
    }, delay);

    const maxHandler = maxWait ? setTimeout(() => {
      setDebouncedValue(value);
    }, maxWait) : null;

    return () => {
      clearTimeout(handler);
      if (maxHandler) clearTimeout(maxHandler);
    };
  }, [value, delay, leading, maxWait]);

  return debouncedValue;
}

Isso você não consegue com um prompt simples. Você precisa saber que existe leading, que pode precisar de maxWait, que há edge cases em formulários complexos. A IA gera código que compila — você adiciona código que sobrevive em produção.

O jogo mudou, não acabou

Converso com desenvolvedores sênior e a história se repete: ninguém foi substituído, mas todo mundo mudou de função. O junior que antes copiava do Stack Overflow agora copia do ChatGPT (e continua não entendendo closure). O pleno que antes escrevia CRUD manualmente agora revisa CRUD gerado. O sênior que antes arquitetava sistemas agora também valida se a arquitetura sugerida pela IA faz sentido no contexto real.

Três habilidades que cresceram em importância:

1. Code review virou skill primária

Antes você revisava código de humanos duas vezes por semana. Agora revisa código de IA vinte vezes por dia. E código de IA é traiçoeiro — parece certo, tem a estrutura certa, usa os padrões certos, mas tem sutilezas erradas.

// IA adora gerar isso
const data = await fetch('/api/users')
  .then(res => res.json())
  .catch(err => console.error(err));

// Mas você precisa disso
const data = await fetch('/api/users')
  .then(res => {
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    return res.json();
  })
  .catch(err => {
    logger.error('Failed to fetch users', { error: err });
    throw err; // re-throw ou trate, não engula
  });

A IA não sabe que seu logger customizado existe. Não sabe que você trata 4xx diferente de 5xx. Não sabe que console.error não chega no seu monitoring. Você sabe.

2. Context é o novo código

Quanto melhor você documenta intenção, requisitos, constraints, melhor a IA performa. Aprendi a escrever comentários melhores não para humanos, mas para aumentar a chance da IA gerar algo útil:

/**
 * Busca usuários com debounce de 300ms.
 * 
 * CONSTRAINTS:
 * - Não fazer request se query < 3 chars
 * - Cancelar requests pendentes (AbortController)
 * - Logar falhas no Sentry, não no console
 * - Retornar [] em caso de erro, nunca null
 * 
 * CONTEXT: usado em autocomplete, usuário pode digitar rápido,
 * API tem rate limit de 10 req/s por IP.
 */

Isso não é documentação — é prompt engineering disfarçado de comentário.

3. Conhecer limites da ferramenta

IA é ótima para: boilerplate, conversão de formato, testes unitários simples, refatoração mecânica.

IA é péssima para: decisões de arquitetura, trade-offs de performance, integrações complexas, qualquer coisa que dependa de context não-escrito.

Saber quando usar é mais importante que saber usar.

O que não te contam

Três verdades inconvenientes que descobri trabalhando com IA no dia a dia:

Débito técnico gerado por IA é mais difícil de pagar. Quando você escreve código ruim, você sabe onde está ruim. Quando a IA gera código "quase certo", você demora mais para achar o problema porque parece profissional.

IA padroniza para a mediana. Todo código gerado parece código de tutorial. Isso é ótimo para começar, terrível para escalar. Você acaba com 50 arquivos que seguem o mesmo padrão genérico, quando seu caso de uso pedia algo específico.

O custo cognitivo não sumiu, mudou de lugar. Antes: pensar em como escrever o código. Agora: pensar em como descrever o que você quer, validar se o que veio é o que você pediu, debugar quando não é. Diferente, não mais fácil.

Então qual é o plano?

Se você está começando agora: aprenda a programar de verdade antes de usar IA como muleta. Você precisa ser capaz de ler o código que a máquina gera e saber se está certo. Isso exige base.

Se você já programa: invista em habilidades que IA não replica fácil. Entender o domínio do negócio. Comunicação com stakeholders. Debugging de sistemas distribuídos. Arquitetura de longo prazo. Code review criterioso.

Se você lidera: repense suas contratações. Junior que só sabe usar Copilot não é junior, é risco. Sênior que ignora IA também é risco. Procure quem entende código E sabe usar ferramentas.

TL;DR

IA não está substituindo desenvolvedores, está mudando o tipo de trabalho que fazemos
Código gerado por IA funciona, mas raramente está pronto para produção sem ajustes
Code review virou habilidade primária — você revisa máquina mais que humano
Contexto e documentação viraram ferramentas de produtividade (são prompts disfarçados)
Débito técnico de IA é mais traiçoeiro que débito humano
O plano: aprender fundamentos, dominar code review, focar em skills que IA não replica

Palestrar em conferências: o que ninguém te conta antes de você subir no palco

Taina Costa — Tue, 27 Oct 2026 19:15:27 +0000

Você já assistiu uma talk incrível e pensou "eu também quero fazer isso"? Eu pensei. Mandei minha primeira proposta, foi aceita, e descobri que palestrar é 20% glamour e 80% trabalho invisível que ninguém menciona.

Por que todo mundo fala disso agora

O mercado tech brasileiro cresceu, eventos voltaram presencial, e comunidades estão desesperadas por conteúdo local. CFPs (Call for Papers) pipocam todo mês no LinkedIn. Parece o momento perfeito pra estrear como speaker. E é — se você souber no que está se metendo.

A promessa é tentadora: networking, autoridade técnica, talvez uma viagem paga. A realidade inclui reescrever slides às 2h da manhã, lidar com perguntas que você não sabe responder, e descobrir que o projetor não lê seu formato de arquivo.

A parte que você não vê

Palestrar não é "pegar um assunto que você domina e falar por 40 minutos". É mais como: escolher um ângulo que caiba no tempo, validar que ainda é relevante quando o evento rolar (3 meses depois), montar uma narrativa que funcione pra quem nunca viu o assunto e pra quem já usa em produção, ensaiar até decorar as transições, e torcer pra tech não falhar.

Aqui está o fluxo real, do jeito que ninguém documenta:

const speakerJourney = {
  week_minus_12: {
    action: "escrever abstract de 300 caracteres",
    realidade: "reescrever 47 vezes porque não cabe"
  },
  week_minus_10: {
    action: "proposta aceita 🎉",
    realidade: "pânico porque agora tem que fazer"
  },
  week_minus_6: {
    action: "montar outline dos slides",
    realidade: "mudar de ideia 3 vezes sobre a abordagem"
  },
  week_minus_2: {
    action: "finalizar apresentação",
    realidade: "refazer metade porque saiu uma breaking change"
  },
  day_zero: {
    action: "subir no palco",
    realidade: "microfone com feedback + esqueceu a segunda demo"
  }
};

Como estruturar sua proposta (pra ser aceita)

Organizadores de evento recebem 200+ propostas e aprovam 20. O que passa:

Título que entrega valor, não buzzword:

❌ "O Futuro da Web: Uma Jornada Transformadora"
✅ "Como migramos 80 rotas de REST pra tRPC sem derrubar produção"

Abstract com problema + solução + resultado:

# Estrutura que funciona (120-250 palavras)

1. Contexto (1 frase)
   "Nossa API REST tinha 80 endpoints, tipos duplicados e zero type-safety."

2. O que você tentou (2-3 frases)
   "Avaliamos GraphQL, jsonapi, e tRPC. Precisávamos de migração incremental
   e DX que não exigisse reescrever clients."

3. O que você escolheu e por quê (2 frases)
   "tRPC permitiu coexistência com REST via adapter e inferência automática
   de tipos no frontend."

4. Como foi (3-4 frases, aqui mora o valor)
   "Migramos endpoint por endpoint em 6 sprints. Bugs de tipo caíram 90%.
   Developer experience melhorou: autocomplete em query e mutation, sem
   codegen. Vou mostrar a estratégia de migração, armadilhas de cache, e
   como convencer o time a adotar."

5. Pra quem é (1 frase)
   "Útil pra quem mantém APIs REST grandes e quer type-safety sem big bang."

O que você NÃO precisa:

Bio estendida (organizador lê depois)
Todos os slides prontos (outline basta)
Ser referência mundial no assunto (experiência real > autoridade)

Preparação: quanto tempo você vai gastar de verdade

Primeira talk: 40-60 horas. Não, eu não estou exagerando.

Research + validação: 8h (ler docs, confirmar que o approach ainda é atual)
Outline + narrativa: 6h (estruturar história, decidir o que cortar)
Slides: 12-20h (fazer, refazer, simplificar, refazer de novo)
Demos: 10-15h (montar, testar, ter plano B pra quando falhar)
Ensaio: 8-12h (sozinho, pra alguém, cronometrado, ajustar ritmo)

E isso assumindo que você já domina o assunto. Se for algo que você aprendeu recentemente "pra poder palestrar sobre", adicione mais 20h de estudo.

// Calculadora honesta de horas
function horasReaisPraPalestrar(experiencia, complexidade) {
  const base = experiencia === 'primeira' ? 50 : 25;
  const demoCost = complexidade === 'live-coding' ? 15 : 5;
  const ansiolitico = 10; // horas perdidas reescrevendo por insegurança

  return base + demoCost + ansiolitico;
}

horasReaisPraPalestrar('primeira', 'live-coding'); // 75h
// É um projeto paralelo de médio porte. Planeje.

O que pode dar errado (e vai)

Tech vai falhar. Sempre. Projetor não aceita seu USB-C, Wi-Fi cai no meio da demo, microfone apita. Solução: slides exportados em PDF, demos gravadas como fallback, hotspot no celular.

Você vai esquecer uma parte. Ensaiei 8 vezes, esqueci a transição do slide 12 pro 13 toda vez. No dia, pulei sem perceber. Ninguém notou (exceto eu). Audiência não tem o roteiro na cabeça.

Perguntas que você não sabe responder. Acontece. "Ótima pergunta, não testamos esse cenário. Me passa teu contato que eu valido e te retorno" é resposta válida. Inventar na hora é pior.

Tempo. Você ensaiou em 35 minutos, no palco levou 28 (nervosismo acelera) ou 48 (alguém perguntou no meio). Marque os slides de "corte opcional" antes.

Por que fazer mesmo assim

Porque quando funciona, funciona muito. Você força a si mesmo a organizar conhecimento que tava disperso. Conhece gente que resolve problemas parecidos. E sim, tem empresa que contrata porque viu sua talk.

Mas principalmente: você contribui pra comunidade de um jeito que post no blog não consegue. Tem algo em assistir alguém vivo, errando, se corrigindo, respondendo perguntas, que cria conexão.

Só não espere que seja fácil.

TL;DR

Proposta boa tem problema concreto + solução validada + resultado mensurável
Prepare 50-75h pra primeira talk, 25-40h pras seguintes
Tech vai falhar: PDF, demo gravada, hotspot são obrigatórios
Esqueceu algo no palco? Audiência não percebe se você não fizer cara de pânico
"Não sei, me passa teu contato" é resposta aceitável
Vale a pena, mas não é glamour — é trabalho

Por que seu portfólio web ainda importa (mesmo que a IA escreva o código por você)

Taina Costa — Tue, 13 Oct 2026 20:06:49 +0000

Você já viu aqueles vídeos onde alguém pede para o ChatGPT ou Cursor construir um site inteiro e em 5 minutos está no ar? Eu vi. E não é impressionante pela técnica — é impressionante porque expõe uma verdade desconfortável: a parte difícil de ter um portfólio nunca foi escrever o HTML.

O hard skill de montar um site virou commodity. Mas o que você coloca nele? Como você conta sua história sem parecer mais um template genérico? Isso nenhuma IA resolve por você.

O problema não é fazer, é decidir o que mostrar

Em 2026, qualquer pessoa pode gerar um portfólio responsivo, acessível e otimizado em minutos. O Cursor autocompleta seus componentes React. O v0 da Vercel monta layouts a partir de prompts. O GitHub Copilot praticamente escreve o CSS por você.

Mas aqui está o ponto: 100 desenvolvedores usando as mesmas ferramentas vão produzir 100 sites parecidos — a menos que tenham algo único para dizer.

O portfólio não é uma prova de que você sabe fazer um site. É a prova de que você sabe o que vale a pena mostrar.

O que mudou (e o que não mudou)

Antes, o portfólio era um sinal técnico: "Veja, eu sei CSS Grid. Veja, eu sei fazer um fade suave." Hoje, todo mundo sabe — ou pelo menos tem acesso a quem sabe (a IA).

O que não mudou:

Curadoria. Você tem 8 projetos no GitHub. Qual deles conta a melhor história? Qual mostra que você entende o problema do usuário, não só a solução técnica?
Contexto. Um link para o repo não explica por que você tomou aquela decisão de arquitetura, ou como você lidou com aquela limitação do cliente.
Priorização. O recrutador vai gastar 30 segundos no seu site. O que você quer que ele veja primeiro?

A IA pode montar a estrutura, mas essas decisões são suas.

Um portfólio que funciona em 2026

Aqui está o que eu coloco no meu (e o que eu procuro quando estou contratando):

1. Casos, não catálogo

Não liste todos os seus projetos. Escolha 3-4 e explique o problema que você resolveu, não a stack que você usou.

Exemplo ruim:

E-commerce em React

Frontend em React, backend em Node, deploy na Vercel.

Exemplo bom:

Checkout em 2 cliques para loja de nicho

Reduzi o abandono de carrinho de 68% para 34% removendo campos desnecessários e implementando autofill inteligente. React + Stripe. Ver case

A diferença é que o segundo mostra impacto. Stack é footnote.

2. Code samples que você comentaria em code review

Se você vai mostrar código, mostre o tipo de código que você escreveria em produção, não um exercício de algoritmo.

// ❌ Não mostre isso
function reverseString(str) {
  return str.split('').reverse().join('');
}

// ✅ Mostre isso
export function validateCPF(cpf) {
  // Remove não-dígitos
  const cleaned = cpf.replace(/\D/g, '');

  // CPF deve ter 11 dígitos
  if (cleaned.length !== 11) return false;

  // Rejeita sequências conhecidas (111.111.111-11, etc)
  if (/^(\d)\1{10}$/.test(cleaned)) return false;

  // Valida dígitos verificadores
  const digits = cleaned.split('').map(Number);
  const validators = [
    calcValidator(digits.slice(0, 9), 10),
    calcValidator(digits.slice(0, 10), 11)
  ];

  return validators[0] === digits[9] && validators[1] === digits[10];
}

function calcValidator(slice, weight) {
  const sum = slice.reduce((acc, d, i) => acc + d * (weight - i), 0);
  const remainder = sum % 11;
  return remainder < 2 ? 0 : 11 - remainder;
}

Esse segundo exemplo mostra que você pensa em edge cases, documenta com comentários úteis (não redundantes), e escreve código que outro dev consegue ler. Isso vale mais do que saber inverter uma string.

3. Um link que funciona

Parece óbvio, mas metade dos portfólios que eu vejo tem projetos com links quebrados, repos privados ou deploys que expiraram.

Se o projeto não está mais no ar, coloque um screenshot ou um vídeo. Se o repo é privado, escreva um README público explicando o contexto. Não force o recrutador a adivinhar.

O que a IA não faz (e você precisa fazer)

A IA pode gerar o código, mas ela não vai:

Decidir que aquele projeto freelance de 2023 é mais relevante que o bootcamp de 2021
Escrever o parágrafo explicando por que você escolheu SSR em vez de CSR naquele caso específico
Remover aquele projeto "to-do list em Vue" que todo mundo tem e que não te diferencia de ninguém
Atualizar o portfólio quando você aprender algo novo ou mudar de direção

O portfólio é um documento vivo. A IA pode acelerar a parte braçal, mas a curadoria é humana.

Quando você realmente não precisa de um

Honestamente? Se você está aplicando para uma vaga júnior e tem um GitHub ativo com READMEs bem escritos, talvez você não precise. O GitHub é o portfólio.

Mas se você está:

Procurando vaga remota internacional (onde o recrutador não te conhece e precisa de contexto rápido)
Transicionando de carreira (e precisa explicar o gap ou a mudança de área)
Freelancer (e precisa mostrar que você entende o problema do cliente, não só código)

Então sim, você precisa de um lugar onde você controla a narrativa. E esse lugar é o seu site.

Como eu fiz o meu (com ajuda da IA, claro)

Usei o Astro para geração estática, Tailwind para estilo, e deploy na Cloudflare Pages. O Cursor escreveu ~70% do código. Eu escrevi 100% do conteúdo.

// src/content/config.ts
import { defineCollection, z } from 'astro:content';

const projects = defineCollection({
  schema: z.object({
    title: z.string(),
    description: z.string(),
    impact: z.string(), // <- isso a IA não preenche
    stack: z.array(z.string()),
    url: z.string().url().optional(),
    featured: z.boolean().default(false),
  }),
});

export const collections = { projects };

Cada projeto é um markdown file em src/content/projects/. O Astro gera as páginas. A IA escreveu o layout. Eu decidi o que colocar em impact.

Caveats

Não caia na armadilha do over-engineering. Seu portfólio não precisa de animações em Three.js ou um sistema de design customizado. Precisa carregar rápido e contar sua história. Se você gastou mais tempo no site do que nos projetos dentro dele, repense.

Não minta. A IA facilitou inflar o portfólio com projetos que você "supervisionou" (leia-se: pediu para o ChatGPT fazer). Qualquer tech lead com 2 anos de experiência identifica isso em 30 segundos de conversa técnica.

Não esqueça de atualizar. Um portfólio de 2022 com skills de 2022 é pior do que não ter portfólio. Se você não vai manter, melhor só o LinkedIn + GitHub.

TL;DR

A IA democratizou a construção de sites, mas não a curadoria do que mostrar
Portfólio em 2026 é sobre contexto e impacto, não sobre provar que você sabe HTML
Mostre 3-4 casos bem explicados, não 15 repos sem contexto
Code samples devem parecer código de produção, não exercício de leetcode
Se você não vai manter atualizado, só GitHub + LinkedIn já resolve
Use IA para acelerar o código, mas escreva o conteúdo você mesmo

Como virei blogueira sem querer (e por que você deveria fazer o mesmo)

Taina Costa — Tue, 06 Oct 2026 19:20:15 +0000

Eu não acordei um dia pensando "vou virar tech writer". Na verdade, comecei escrevendo para mim mesma — anotações de bugs que resolvi, comandos que sempre esqueço, aquele padrão React que usei três vezes e na quarta vez já não lembrava mais.

Três meses depois, essas anotações viraram artigos. Seis meses depois, recrutadores começaram a me achar pelo que eu escrevi, não pelo currículo. Um ano depois, eu tinha construído uma reputação que nenhum bootcamp ou certificado me daria.

Se você programa, você já tem metade do trabalho pronto. Vou te mostrar como a outra metade acontece sozinha.

O truque está na ferramenta errada

A maioria dos devs que tentam blogar começam abrindo o Medium ou o dev.to e encarando a página em branco. Erro. Você não começa a escrever para internet — você começa escrevendo enquanto trabalha.

Eu uso um repo privado no GitLab chamado dev-notes. Estrutura básica:

dev-notes/
├── bugs/
│   ├── 2026-09-react-effect-loop.md
│   └── 2026-10-postgres-deadlock.md
├── snippets/
│   ├── debounce-hook.js
│   └── redis-rate-limit.js
└── til/ # Today I Learned
    ├── 2026-09-28-optional-chaining.md
    └── 2026-10-02-css-has-selector.md

Cada arquivo é markdown puro. Quando resolvo um bug irritante, abro bugs/YYYY-MM-problema.md e escrevo:

## Problema
useEffect rodando em loop infinito mesmo com array de dependências

## Causa
O objeto `config` estava sendo recriado a cada render:
const config = { theme: userTheme } // novo objeto toda vez

## Solução

js
const config = useMemo(
() => ({ theme: userTheme }),
[userTheme]
)


## Por que funcionou
Identidade referencial. Arrays/objetos literais sempre falham `===`.

markdown

Pronto. Levou 2 minutos. Não é um artigo — é documentação funcional do meu dia.

De nota privada para post público

Dois meses depois, topo com o mesmo loop em outro projeto. Abro minhas notas, acho a solução em 10 segundos. Economia de 40 minutos de debug.

Aí vem o pulo: se salvou seu tempo duas vezes, vai salvar o tempo de outra pessoa. Esse é o momento de publicar.

Pego aquele markdown, adiciono contexto (por que alguém bateria nesse problema?) e exemplos (como reproduzir?). Vira isso:

# useEffect em loop: o problema da identidade de objetos

Você já viu seu componente React renderizar infinitamente mesmo
com `useEffect` tendo dependências declaradas? O culpado costuma
ser um objeto ou array recriado a cada render.

## Reproduzindo o bug

js
function Dashboard() {
const [data, setData] = useState(null)

const config = { theme: 'dark' } // ← problema aqui

useEffect(() => {
fetchData(config).then(setData)
}, [config]) // loop infinito

return

{data?.title}
}


A cada render, `config` é um objeto *novo* (referência diferente),
então `[config]` nunca é igual ao array anterior. React dispara
o effect de novo, que causa render, que recria `config`...

## A solução: useMemo para identidade estável

js
const config = useMemo(
() => ({ theme: 'dark' }),
[] // só cria uma vez
)


Agora `config` mantém a mesma referência entre renders, e o loop para.

## Quando NÃO usar

Se `theme` vem de props/state, declare como dependência:

js
const config = useMemo(
() => ({ theme: userTheme }),
[userTheme] // recria só quando theme muda
)


## TL;DR
- Objetos literais em dependências do useEffect causam loops
- Use `useMemo` para manter identidade referencial
- Liste as dependências reais do objeto no array do `useMemo`

Esse artigo levou 15 minutos. Não porque escrevi rápido — porque a parte difícil (entender o problema e testar a solução) já estava feita quando eu resolvi o bug pela primeira vez.

O sistema que funciona sem esforço

Meu fluxo hoje:

Trabalho normal: resolvo bugs, implemento features, topo com comportamento inesperado
Anoto: 2 minutos no dev-notes, formato problema-causa-solução
Reviso semanal: abro o repo, vejo o que anotei nos últimos 7 dias
Publico o útil: se usei a nota duas vezes, expando para artigo e posto no dev.to

Zero planejamento de conteúdo. Zero bloqueio criativo. Escrevo sobre o que já fiz, não sobre o que vou fazer.

Os efeitos colaterais (bons)

Três coisas que não esperava:

Entrevistas técnicas ficaram fáceis. Quando você documenta problemas reais que resolveu, não precisa inventar resposta na hora. "Me fala de um bug difícil" → abro mental o índice de bugs/ e escolho um caso.

Recrutadores te acham. Dois dos últimos três trabalhos que recebi vieram de gente que leu algo que escrevi. Não porque o artigo era genial — porque provava que eu faço o que digo que sei.

Você aprende melhor. Forçar seu cérebro a explicar em texto expõe buracos no entendimento. Se não consigo escrever "por que X funciona", é porque não entendi X direito.

Caveats reais

Escrever demais logo no início. Eu comecei querendo postar 3x por semana, queimei em um mês. O sistema que funciona é postar quando tem o que dizer, não por cota.

Achar que precisa ser original. 90% dos meus posts são sobre problemas comuns. Não importa — sua explicação, seu exemplo, seu contexto são únicos. Alguém vai bater no seu artigo e entender do seu jeito.

Não linkar código real. Snippets inventados na hora costumam ter bugs. Eu sempre copio de código que roda, mesmo que simplifique depois. Se o exemplo não compila, perde credibilidade.

TL;DR

Comece com notas privadas, não com blog público
Use um repo git simples: markdown + estrutura por tipo (bugs, TIL, snippets)
Publique só o que você reutilizou pelo menos duas vezes
Formato problema-causa-solução é suficiente — não precisa de narrativa elaborada
Recrutadores e entrevistas ficam mais fáceis quando você tem portfólio escrito
Qualidade > frequência: poste quando tiver algo real, não por cota semanal

Agentes de IA que nunca saem do navegador

Taina Costa — Tue, 29 Sep 2026 19:08:42 +0000

Você já se cansou de copiar e colar dados entre tabs porque sua ferramenta de IA
não consegue "ver" o sistema que você está usando? WebMCP resolve isso deixando
sites exporem ferramentas que agentes podem chamar — sem sair do browser, sem
mandar seus dados pra nuvem.

Por que isso importa agora

A maioria dos agentes de IA hoje funciona assim: você descreve o que quer,
o agente manda o pedido pra um servidor na nuvem, processa, e te devolve
uma resposta genérica. Se o agente precisa interagir com um app web que você
está usando, ele não consegue — a menos que você exponha uma API pública
ou construa integrações customizadas.

WebMCP (Model Context Protocol para a Web) vira esse modelo de cabeça pra baixo:
sites podem declarar explicitamente quais ações um agente pode executar,
e agentes locais — rodando direto no seu navegador — conseguem chamar essas
ferramentas sem round-trip pra nuvem.

A ideia central

WebMCP é uma API experimental que permite que sites exponham tools que agentes
descobrem e chamam. A diferença crítica pro MCP tradicional: tudo acontece
no contexto do browser. O site precisa estar aberto, você precisa estar logado,
e o agente opera sobre o estado atual da página.

Um exemplo concreto: um simulador de startup com métricas (caixa, receita mensal,
quantidade de funcionários, felicidade do time, nível de hype). Você pode
interagir clicando nos botões normalmente, ou pode dizer pro agente
"contrata 5 pessoas e adota IA no produto". O agente descobre as ferramentas
disponíveis (hireEmployees, adoptAI) e executa a sequência.

// Site expõe ferramentas via WebMCP
const tools = {
  hireEmployees: {
    description: "Hire new employees",
    parameters: { count: "number" },
    consequentialHint: "medium" // aviso de impacto
  },
  adoptAI: {
    description: "Adopt AI in product",
    consequentialHint: "high"
  }
};

O agente roda localmente via extensão Chrome. Três modos de provider:

Google Prompt API — Gemini Nano gerenciado pelo próprio Chromium, inferência 100% local
Ollama — execução local (testado com Llama 3.1)
Cloud fallback — Gemini Flash quando os anteriores não estão disponíveis

Loop de execução: recebe intenção do usuário → checa ferramentas WebMCP
disponíveis → chama as apropriadas → recebe resultados → decide próximos passos.
Por padrão, máximo 10 iterações.

Hands-on: safety em ações consequentes

WebMCP não é anarquia. Ferramentas podem declarar consequentialHint (low,
medium, high). A extensão intercepta chamadas marcadas como high e pede
confirmação manual antes de executar.

Cenário real no demo: você pede "corta custos agressivamente". O agente identifica
fireEmployees como ferramenta relevante, mas antes de demitir metade do time,
um modal aparece: "Agent wants to fire 10 employees. Confirm?"

Isso mantém controle humano sobre decisões irreversíveis, mesmo em fluxos
totalmente automatizados.

// Antes de executar ação consequente
if (tool.consequentialHint === 'high') {
  const confirmed = await showConfirmationModal(tool, params);
  if (!confirmed) return { status: 'cancelled' };
}

Caveats

Não é revolucionário. A própria autora do post chama isso de "faster horses" —
uma melhoria incremental, não uma mudança arquitetural. Você continua precisando
de uma UI tradicional; WebMCP só adiciona uma camada de acesso programático.

Requer que o site coopere. Se o app não expõe ferramentas WebMCP, o agente
não funciona. Não é scraping, não é automação genérica tipo Playwright — é um
contrato explícito entre site e agente.

Privacidade tem tradeoffs. Rodar Gemini Nano localmente é ótimo pra dados
sensíveis, mas modelos pequenos erram mais. Ollama te dá controle total, mas
você precisa instalar e gerenciar. Cloud funciona sempre, mas manda tudo pra fora.

Suporte limitado. É experimental. Google Prompt API ainda não está disponível
em todos os browsers/regiões. Ollama exige setup local. Pra produção hoje,
você provavelmente vai acabar no fallback cloud.

TL;DR

WebMCP permite que sites exponham ferramentas que agentes de IA chamam, direto no browser, sem servidor intermediário
Extensão Chrome roda agentes localmente via Gemini Nano, Ollama ou cloud fallback
Ações de alto impacto exigem confirmação manual via consequentialHint
Não substitui UI tradicional — adiciona camada de automação sobre apps existentes
Útil pra regiões com conectividade limitada ou casos que exigem privacidade local

IA escreve código melhor que você — e daí?

Taina Costa — Tue, 15 Sep 2026 17:58:27 +0000

Tem um debate rolando que eu acho meio desonesto: "IA já programa melhor que a maioria dos devs". É verdade. Mas estamos medindo a coisa errada.

Pega o ChatGPT, Claude, Copilot — todos conseguem cuspir um componente React funcional, um CRUD em Express, uma query SQL otimizada. Melhor que um dev júnior? Provavelmente. Melhor que um pleno distraído numa sexta às 17h? Com certeza. Mas se você acha que isso muda alguma coisa sobre o que faz alguém ser um bom desenvolvedor, você não entendeu o trabalho.

O que a IA faz bem (e você deveria deixar)

Vou ser direta: se o seu valor como dev é escrever um for loop bonitinho ou lembrar a sintaxe de Array.prototype.reduce, você já era substituível antes da IA chegar.

A IA é excelente em:

1. Boilerplate e código repetitivo

// Você descreve o que quer
// "Create a React hook for debounced search with abort controller"

import { useState, useEffect, useRef } from 'react';

export function useDebouncedSearch(callback, delay = 300) {
  const [query, setQuery] = useState('');
  const abortControllerRef = useRef(null);

  useEffect(() => {
    if (!query.trim()) return;

    const timeoutId = setTimeout(() => {
      // Cancel previous request
      if (abortControllerRef.current) {
        abortControllerRef.current.abort();
      }

      abortControllerRef.current = new AbortController();

      callback(query, abortControllerRef.current.signal);
    }, delay);

    return () => {
      clearTimeout(timeoutId);
      if (abortControllerRef.current) {
        abortControllerRef.current.abort();
      }
    };
  }, [query, delay, callback]);

  return [query, setQuery];
}

Isso funciona. É limpo. Eu não teria escrito melhor na primeira tentativa — e você provavelmente também não. E tá tudo bem.

2. Tradução entre paradigmas

"Converte esse callback hell pra async/await" — a IA faz isso dormindo. Refatorar de class components pra hooks? Mesma coisa. Ela não cansa, não esquece edge cases óbvios, não mistura estilos por acidente.

3. Código que você sabe que precisa mas não quer escrever

Validação de formulário. Parsing de CSV. Retry logic com exponential backoff. É aquele código chato, testado mil vezes pela humanidade, que você copia do Stack Overflow mesmo. A IA só automatizou o ctrl+C ctrl+V.

O que a IA não faz (e é onde você importa)

Agora a parte que separa um script kiddie de um engenheiro de verdade:

1. Entender o problema antes de escrever código

A IA vai te dar código. Sempre. Você pediu? Ela entrega. Mas ela não vai te perguntar:

"Esse endpoint realmente precisa ser real-time ou você só quer feedback instantâneo no UI?"
"Você tá tentando resolver latência de rede ou problema de UX?"
"Por que você tá fazendo cache no client se o dado muda a cada 10 segundos?"

Eu já vi dev júnior (e LLM) implementar websockets pra uma feature que um setInterval de 30 segundos resolveria. O código tava perfeito. A solução tava errada.

2. Fazer tradeoffs conscientes

// Option A: Cache agressivo, UX rápida, risco de dados stale
const CACHE_TTL = 5 * 60 * 1000; // 5 min

// Option B: Sempre busca fresh data, UX mais lenta, sempre correto
const CACHE_TTL = 0;

// Option C: Optimistic UI + background revalidation (SWR pattern)
const CACHE_TTL = Infinity;
// but: revalidate on focus, revalidate on interval

A IA não escolhe. Ela te dá a opção A porque é a que aparece mais em exemplos de blog. Você precisa saber que pro seu caso específico — um dashboard financeiro — a opção C é a única aceitável.

3. Debugar problemas de integração

IA é ótima pra debugar um algoritmo isolado. Mas quando o bug é:

Request tá sendo enviado duas vezes porque o React renderiza em StrictMode no dev
CORS só quebra em produção porque nginx tá strippando o header
Race condition que só acontece em mobile 3G

...você precisa de contexto do sistema inteiro, conhecimento de infra, experiência com "já vi isso antes". A IA não tem nada disso. Ela vai te dar 10 sugestões genéricas e você vai perder uma tarde.

4. Comunicar com não-técnicos

O PM pede "um filtro avançado". Você precisa:

Descobrir se é autocomplete, multi-select, range slider ou busca full-text
Explicar que "tempo real" vai custar 10x mais de infra
Negociar MVP: "e se a gente lançar com 3 filtros agora e adiciona os outros depois conforme uso?"

IA não senta numa call. IA não lê a cara do stakeholder e percebe que ele não entendeu. IA não fala "essa feature vai atrasar o lançamento em 2 sprints, vale a pena?".

O desenvolvedor que a IA substitui

Se a sua rotina é:

Pegar ticket do Jira
Implementar exatamente o que tá escrito
Fazer passar no CI
Jogar pra QA

...você já tá competindo com ferramentas. E vai perder.

A IA substitui o dev que é executor. Ela não substitui quem é arquiteto de soluções, mesmo que a arquitetura seja "decidir usar Postgres em vez de MongoDB porque os relacionamentos são óbvios".

O que eu faço diferente agora

Eu uso IA todo dia. Mas mudei como eu trabalho:

Antes: Pensava no código enquanto escrevia código

Agora: Penso no problema, esboço a solução em comentários, deixo a IA escrever a primeira versão

// Fetch user posts with:
// - pagination (cursor-based, not offset)
// - filter by status (draft | published)
// - include author data (join, not N+1)
// - cache per user (5min TTL)

// [IA escreve isso em 10 segundos]

Antes: Escrevia testes depois (quando lembrava)

Agora: Peço pra IA gerar testes baseado no código que ela escreveu — e eu reviso se os cenários fazem sentido

Antes: Gastava tempo refatorando syntax

Agora: Foco em refatorar arquitetura — extrair abstrações, separar responsabilidades, nomear coisas direito

TL;DR

IA escreve código sintático melhor que 70% dos devs — e isso não importa
O trabalho de verdade é: entender problema, fazer tradeoffs, debugar sistemas, comunicar com pessoas
Se você se sente ameaçado pela IA, você tá medindo seu valor pela métrica errada
Use IA pra acelerar execução; use seu cérebro pra decidir o quê executar e por quê
O dev que só escreve código sempre foi substituível — a IA só tornou isso óbvio

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