Think outside the bot: como devs usam IA sem perder o julgamento

Por que a estreia do Eduardo Endo no Olhar Digital me chamou atenção

Vi a notícia no Olhar Digital sobre o Eduardo Endo assumir a coluna “Entre o código e o conselho” e travei no título. “Entre o código e o conselho” é exatamente a tensão que eu vivo todo dia como dev sênior: metade do meu tempo escrevendo código, a outra metade explicando para produto, liderança e cliente por que determinada decisão técnica é a certa. Endo promete discutir IA, inovação, educação, liderança e transformação digital a partir de experiências práticas — e isso, vindo de quem é pesquisador e professor, tem peso diferente de mais um textão de LinkedIn.

O que me interessou mesmo foi o texto de estreia, “Think outside the bot”. A tese central é um soco no estômago de quem trabalha com IA em 2026: ferramentas generativas ficaram tão boas em responder qualquer coisa que começamos a substituir pensamento crítico por confiança cega nas respostas. Endo defende que a IA amplia o que já existe — não substitui conhecimento, experiência nem julgamento. Vou aprofundar isso na prática, porque é um tema que eu vejo dando errado em time inteiro.

O paradoxo que Endo identificou (e que eu vejo acontecer todo dia)

Em 2026, qualquer dev júnior consegue abrir o Cursor, o Claude Code ou o GitHub Copilot e gerar uma API inteira em segundos. O output parece bom. Compila. Passa nos testes básicos. Entra em produção. E três meses depois, vira um passivo técnico que ninguém quer tocar.

Não é culpa da ferramenta. É culpa de quem tratou resposta de modelo como decisão de engenharia. O LLM não sabe o que você não sabe. Ele sabe o que está no corpus de treino, ponderado pelo seu prompt. Se o seu prompt é raso, a resposta é rasa — só que vem com formatação bonita e tom de voz confiante.

Segundo Endo, a tecnologia de verdade acontece quando o hype termina e alguém precisa entregar resultado. Traduzindo para o meu cotidiano: a tecnologia de verdade acontece quando o PR foi mergeado, o incidente caiu às 3h da manhã e ninguém lembra mais do prompt bonito que gerou aquele código.

Na Prática: onde o “pensar fora do bot” muda o resultado

Deixa eu mostrar um caso real. Semana passada um dev do meu time pediu para o Copilot gerar uma função de rate limiting em Node.js. A sugestão veio assim:

// Sugestão do Copilot —看起来 bonita, perigosa em produção
const rateLimit = (req, res, next) => {
  const ip = req.ip;
  const now = Date.now();

  if (!global.requestCounts) global.requestCounts = {};

  if (!global.requestCounts[ip]) {
    global.requestCounts[ip] = { count: 1, resetTime: now + 60000 };
    return next();
  }

  const record = global.requestCounts[ip];
  if (now > record.resetTime) {
    record.count = 1;
    record.resetTime = now + 60000;
    return next();
  }

  if (record.count >= 100) {
    return res.status(429).json({ error: 'Too many requests' });
  }

  record.count++;
  return next();
};

O código compila. Roda. Parece fazer sentido. Mas qualquer dev sênior olha e vê pelo menos cinco problemas:

Estado global em processo: global.requestCounts não escala horizontalmente. Em três instâncias atrás de um load balancer, cada uma tem seu próprio contador.
Memory leak garantido: IPs nunca são limpos. Um atacante mandando requests de 10 mil IPs derruba o processo.
IP sozinho não basta: clientes atrás de proxy corporativo compartilham IP. Você bloqueia gente inocente.
Algoritmo ingênuo: sliding window ou token bucket são o padrão da indústria. Fixed window de 1 minuto permite burst de 200 reqs em 2 segundos.
Sem observabilidade: você não sabe quem está sendo limitado, nem qual header retornar (Retry-After, X-RateLimit-Remaining).

O LLM não errou por ser “burro”. Ele errou porque o prompt era “faz um rate limiter” e o conjunto de treino tem mil implementações ingênuas desse mesmo problema. Pensar fora do bot aqui significa saber o que perguntar e, mais importante, saber o que a resposta não está te dizendo.

A versão que eu pedi para refatorar, depois de pensar no problema:

// Pensando fora do bot: Redis + sliding window + headers RFC 6585
import Redis from 'ioredis';
import rateLimit from 'express-rate-limit';
import RedisStore from 'rate-limit-redis';

const redis = new Redis({
  host: process.env.REDIS_HOST,
  port: 6379,
  enableOfflineQueue: false, // falha rápido se Redis cair
});

export const apiLimiter = rateLimit({
  windowMs: 60 * 1000,
  limit: (req) => {
    // tiered: usuário autenticado tem mais quota
    if (req.user?.plan === 'pro') return 600;
    if (req.user) return 120;
    return 60; // anônimo: IP-based com caveat
  },
  standardHeaders: 'draft-7', // RateLimit headers padronizados
  legacyHeaders: false,
  store: new RedisStore({
    sendCommand: (...args) => redis.call(...args),
  }),
  keyGenerator: (req) =>
    req.user?.id
      ? `user:${req.user.id}`
      : `ip:${req.ip}:${req.headers['user-agent']?.slice(0, 50) ?? 'unknown'}`,
  handler: (req, res) => {
    res.status(429).json({
      error: 'rate_limited',
      retryAfter: Math.ceil(req.rateLimit.resetTime.getTime() - Date.now()) / 1000,
    });
  },
});

Mesma intenção. Resultado completamente diferente. A diferença não é a IA — é o julgamento de quem revisou.

Erros comuns que devs cometem quando delegam o pensamento à IA

Depois de uns 4 anos usando LLMs em fluxo de produção, mapeei os padrões que mais aparecem em code review:

1. Aceitar a primeira resposta sem revisar contexto

O modelo sempre dá uma resposta. Sempre. Se você não gostar, ele reformula com o mesmo viés. O trabalho do dev é levar a resposta para o domínio do problema real: qual é a SLA? Quem consome? Qual o custo de uma falha? Isso não está no prompt, está na sua cabeça.

2. Tratar sugestão como verdade absoluta

“O GPT disse que é assim” não é argumento técnico. Já vi PR com Math.random() para gerar token de sessão porque o modelo sugeriu. Já vi SQL com SELECT * em tabela de 200 milhões de linhas. A IA não carrega o contexto do seu banco, da sua escala, do seu compliance.

3. Ignorar o que o código não faz

Modelos generativos são péssimos em declarar o que não está coberto. Eles te dão uma função de validação de CPF que parece completa, mas esquece de validar dígitos repetidos (111.111.111-11 passa). Tem que pensar fora do bot — testar os casos que o modelo não pensou.

4. Misturar conselho de carreira com código de produção

A coluna do Endo se chama “Entre o código e o conselho” justamente porque as duas coisas se misturam. Decisão técnica sempre é decisão de negócio. Escolher MongoDB em vez de Postgres é sobre o time que vai manter, não sobre qual banco é “melhor”. A IA não tem essa dimensão.

5. Esquecer que o modelo não envelhece bem

Stack muda. API muda. Padrão muda. O que o modelo te ensinou em 2024 pode estar deprecated em 2026. Dev que terceiriza o “saber o que é atual” para o LLM acaba mantendo código obsoleto com confiança de quem acabou de aprender.

Por que essa coluna pode ser relevante para você

Se você é dev, trabalha com IA ou lidera time técnico, o que o Endo está propondo é o tipo de leitura que falta no ecossistema brasileiro. A maioria do conteúdo tech em PT-BR hoje ou é tutorial superficial ou é hype descritivo. “Entre o código e o conselho” promete o terceiro caminho: opinião fundamentada vinda de quem está no campo, no mercado e na academia ao mesmo tempo.

A frase dele na apresentação é boa demais para não parafrasear: “A tecnologia de verdade acontece quando o hype termina e alguém precisa entregar resultado.” É isso. Todo dev sênior vive esse momento. Todo CTO vive esse momento. Ter um espaço dedicado a discutir isso em português, com profundidade, é raro.

FAQ — Perguntas que devs reais fazem sobre IA e pensamento crítico

IA vai substituir programadores?
Não no sentido que as pessoas vendem. IA substitui a parte mecânica da programação — boilerplate, conversão de tipos, testes repetitivos. O que ela amplifica é a capacidade de quem sabe o que está fazendo. Quem não sabe é substituído por alguém que sabe usar IA melhor. É diferente de “ser substituído pela IA”.

Dev júnior deveria usar IA para aprender ou evita?
Usa, mas com método. Não copie a resposta — peça explicação. Não peça “faça X” — peça “me explique como X funciona e depois me guie na implementação”. OLLM como tutor funciona. Como ghostwriter, atrofia.

Como saber se estou confiando demais na IA?
Teste simples: feche o chat e tente explicar o código que você aceitou para um colega. Se você não consegue defender cada linha em termos de porquê, você confiou demais. Outra: rode testes adversariais no código. Se você não sabe que casos testar, tem problema maior que a IA.

Qual a diferença entre usar IA como ferramenta e usar como muleta?
Ferramenta você sabe o resultado esperado e usa a IA para chegar mais rápido. Muleta você delega a decisão. No primeiro caso, você poderia fazer sem. No segundo, você não sabe fazer sem. Em 2026, todo dev precisa saber fazer sem — caso contrário, quando o modelo alucinar ou cair, ninguém entrega.

Vale a pena ler a estreia do Endo?
Na minha leitura, sim. “Think outside the bot” se posiciona contra o que o próprio mercado dele vende, e isso tem valor. Discordo de algumas coisas (a defesa é mais radical do que eu pratico), mas é exatamente o tipo de debate que faz o ecossistema amadurecer. Quem é dev e está em 2026 usando IA em produção precisa ler texto assim.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.