Programar com IA Não É Jogar no ChatGPT: Por Que Contexto É a Diferença Entre um Amador e um Engenheiro

TL;DR: A qualidade do output que você extrai de uma IA é diretamente proporcional à qualidade do contexto que você fornece. Engenheiros que entendem isso estão sendo amplificados. Os que não entendem, estão entregando código que funciona na demo e quebra em produção.

O problema que ninguém está nomeando corretamente
Tem uma narrativa perigosa circulando: "agora qualquer um pode programar com IA". Tecnicamente verdade. Praticamente, um desastre silencioso.
O que está acontecendo na prática é uma enxurrada de soluções frágeis, arquiteturas improvisadas e sistemas que passam no happy path e colapsam no primeiro edge case real. A IA não é culpada. O problema é a ausência de contexto de engenharia na interação.
Existe um abismo entre usar IA como gerador de snippets e utilizá-la como extensão da sua capacidade de engenharia. Esse abismo se chama contexto.

O que é contexto de engenharia (e por que importa)
Contexto de engenharia não é um prompt mais longo. É o conjunto estruturado de informações que permite que a IA compreenda:

O domínio do problema — regras de negócio, invariantes, casos que não podem falhar
A stack real — não "Node.js", mas Node 20 + Express 5 + TypeScript strict mode
O ambiente de execução — local vs. Kubernetes com HPA, stateful vs. stateless
As restrições não-funcionais — SLO de latência, limite de memória por pod, compliance com LGPD
Os padrões do projeto — arquitetura hexagonal? CQRS? Event sourcing? A IA precisa saber
O que já existe — quais abstrações estão disponíveis, quais libs estão banidas
Os edge cases esperados — o que acontece quando o downstream está lento? Quando o usuário é anônimo? Quando o payload está malformado?

Sem isso, a IA resolve um problema genérico. O seu problema raramente é genérico.

Exemplo concreto: rate limiting
Dois desenvolvedores precisam implementar rate limiting em uma API REST.
Dev sem contexto de engenharia:
"como implementar rate limiting em Node.js?"
Recebe: exemplo com express-rate-limit e store in-memory. Funciona localmente. Em produção com 4 réplicas no Kubernetes, cada pod tem seu próprio contador — o rate limit efetivo vira 4x o configurado. Silenciosamente errado.

Engenheiro com contexto:
Stack: Node 20, Express 5, TypeScript
Infra: Kubernetes, 3-6 réplicas via HPA, Redis 7 cluster mode
Requisito: rate limit distribuído por usuário autenticado (JWT sub claim),
não por IP
Algoritmo: sliding window (fixed window permite burst no boundary)
Erros: RFC 7807 Problem Details
Headers de resposta: X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After
Middleware de auth já injeta req.user.id
Libs disponíveis: ioredis já está no projeto
Recebe: implementação que resolve o problema real — distribuída, com o algoritmo correto, integrada à abstração existente, com os headers certos e tratamento de erro padronizado.

A diferença não é a ferramenta. É o operador.

O paradoxo da amplificação
As ferramentas de IA democratizaram o acesso à programação. E paradoxalmente amplificaram a vantagem competitiva de quem já sabe.
Por quê? Três razões:

1. Você precisa saber o que pedir
   Para mencionar sliding window, você precisa conhecer a diferença entre sliding e fixed window. Para especificar cluster mode do Redis, você precisa entender como isso afeta operações atômicas via Lua scripts. Para pedir RFC 7807, você precisa saber que o problema existe.
   O conhecimento técnico profundo não se tornou obsoleto — ele se tornou o pré-requisito para usar a IA de forma eficaz.
2. Você precisa avaliar o que recebe
   A IA produz código com a mesma confiança quando está certa e quando está errada. Um profissional experiente consegue identificar:

Race conditions em código assíncrono (especialmente com Promise.all + escrita compartilhada)
Vulnerabilidades clássicas: SQL injection, SSRF, insecure deserialization, path traversal
Violações de padrões arquiteturais do projeto (IA não sabe que você tem uma regra de não acessar o banco diretamente de handlers HTTP)
N+1 queries em ORMs
Memory leaks em closures ou event listeners
Dependências desnecessárias ou com vulnerabilidades conhecidas

Aceitar o output sem revisão crítica é construir sobre areia.
3. Você conduz um diálogo, não faz uma pergunta
Engenheiros profissionais tratam a interação com IA como pair programming com um dev muito produtivo que não conhece seu projeto. Você define o problema, explica as restrições, questiona as sugestões, pede alternativas, exige justificativa para as decisões de design.
É iterativo. É dialógico. Não é copiar e colar.

Framework: anatomia de um contexto profissional
Se você quer extrair valor real de IAs de programação, estruture seu contexto em quatro dimensões:
Contexto do Projeto

• Tipo de sistema: monolito modular / microsserviços / serverless
• Stack completa com versões exatas
• Ambiente: cloud provider, runtime, orquestração
• Escala atual e projetada (RPS, usuários, volume de dados)
  Contexto do Problema
• O que precisa ser construído (funcionalidade)
• Por que existe (motivação de negócio)
• Restrições: latência máxima, uso de memória, custo por request
• Onde se integra no sistema existente
  Contexto de Qualidade
• Convenções de código (nomenclatura, estrutura de diretórios)
• Estratégia de testes esperada (unit + integration? coverage mínimo?)
• Requisitos de observabilidade (structured logging, métricas, traces)
• Padrão de tratamento de erros do projeto
  Contexto de Restrições
• Libs proibidas ou deprecadas no projeto
• Limitações de licença (GPL? AGPL? não pode entrar no produto)
• Budget computacional (não pode alocar mais de X MB por request)
• Compatibilidade retroativa necessária
  Quanto mais completo, melhor o resultado. Não existe "contexto demais".

O que isso significa para formação técnica
Se contexto de engenharia é o diferencial, a conclusão é direta: fundamentos técnicos ficaram mais importantes, não menos.

Você não consegue especificar algoritmos se não os conhece
Você não consegue revisar código gerado se não entende os patterns e anti-patterns
Você não consegue arquitetar contexto de restrições se não sabe quais restrições existem

Paralelamente, comunicação técnica precisa virou uma habilidade de engenharia de primeira classe. A capacidade de articular um problema com exatidão, sem ambiguidade, com todas as restrições relevantes — isso determina a qualidade do trabalho quando se colabora com IA.

A pergunta errada e a certa
A pergunta errada: "IA vai substituir programadores?"
A pergunta certa: "programadores que sabem usar IA bem vão substituir os que não sabem?"
Para essa segunda, a resposta já está acontecendo.
O ciclo é virtuoso e assimétrico: quanto mais você sabe → mais rico é o contexto que você constrói → melhor é o resultado que você extrai → mais rápido você entrega → mais você aprende com o feedback → mais você sabe.
Quem está do outro lado desse ciclo — copiando output sem entender — está acumulando débito técnico que eventualmente vence.

Conclusão
A IA não veio substituir o engenheiro de software. Veio separar, com uma clareza nunca antes vista, quem realmente entende o que está construindo de quem apenas sabe copiar e colar.
Use IA. Use bem. Invista nos fundamentos que tornam o uso da IA efetivo. E pare de chamar de "programar" o ato de jogar um problema no chat e aceitar a primeira resposta.

Feedbacks e discordâncias nos comentários — especialmente se você tem experiências concretas sobre como contexto (ou falta dele) afetou projetos reais.