KnightX — logotipo oficialKnightX
Voltar para o inícioKnightX Blog

Como eu vejo os próximos anos

AIDesenvolvimento PessoalOtimização

Você já viveu aquela cena: a solução tá inteira na sua cabeça, você enxerga o fluxo, as responsabilidades, os possíveis resultados… e aí você começa a digitar. No meio do caminho, uma notificação, uma reunião surpresa, algum nada haver com aquela ideia aparece, e quando você volta, aquela solução que tava “viva” na mente virou fumaça.

O gargalo nunca foi “saber a sintaxe”. Foi conseguir manter várias abstrações ativas ao mesmo tempo, enquanto o mundo tenta te arrancar do flow. Em alguns anos, escrever código manualmente pode deixar de ser o centro da profissão. Não porque “acabou programador”, mas porque o “trabalho braçal” (digitar, navegar IDE, micro-habilidades) tende a ser automatizado, e sobra o que sempre separou gente boa de gente excelente: raciocínio, modelagem e coordenação.

1) A dor real: quando digitar vira um imposto cognitivo

Um ponto que muita gente sente mas não sabe nomear:

  • Programar é criar e manipular modelos mentais.
  • Esses modelos têm camadas: regra de negócio, invariantes, fluxo de dados, contratos, falhas, concorrência, observabilidade, rollout, rollback…
  • Quando você digita devagar (ou fica “quebrando o flow”), você paga um imposto: perde contexto.

A analogia do xadrez funciona porque é isso: você não “pensa uma jogada”. Você pensa um conjunto de linhas, e o cérebro não segura tudo com a mesma estabilidade por muito tempo.

A partir daí, uma consequência importante:

O programador sênior não é o rei da sintaxe ou o melhor digitador

É o que consegue não deixar o modelo mental quebrar enquanto a solução toma forma.


2) IA tira o gargalo errado e expõe o gargalo certo

Quando você coloca agentes (Claude, Codex, Gemini, etc.) no loop, a digitação deixa de ser o limitador. Beleza.

Só que isso não resolve “programação”. Isso resolve transcrição.

A partir do momento que o código é “barato”, o que fica caro é:

  • especificar bem
  • evitar ambiguidade
  • manter coerência entre partes
  • gerenciar mudanças e reversões
  • integrar decisões sem conflito

Ou seja: o gargalo muda de “teclar” para orquestrar.

E aí aparece a virada mais importante:

O trabalho continua sendo “criar código”, mas agora criar código parece mais com gerenciar um pipeline de agentes do que com “digitar arquivos”.

3) Aprofundamento: trabalhar com agentes é engenharia de sistemas, não “prompt bonitinho”

Quando você faz “spawn de múltiplos agentes”, usa worktree, compara implementações e decide a melhor, você não tá só “usando IA”.

Você tá aplicando uma habilidade bem clássica de engenharia:

3.1. Decomposição de sistema (arquitetura)

Você separa o problema em partes com fronteiras claras:

  • planejamento (estratégia)
  • execução (implementação)
  • UX/UI (produto e usabilidade)

Isso é arquitetura aplicada.

3.2. Concorrência e conflito (coordenação)

Dois agentes mexendo em coisas parecidas podem:

  • duplicar lógica
  • divergir contrato
  • quebrar invariantes
  • gerar implementações “certas” isoladamente, mas incoerentes juntas

Isso é o mesmo problema de times grandes, só que agora o “time” inclui agentes.

3.3. Controle de versão como sistema de segurança

Rollback, histórico, comparação de branches… vira parte do “motor” do desenvolvimento com IA.

Se antes Git era “ferramenta”, agora Git vira:

  • trilho de auditoria
  • mecanismo de contenção de dano
  • base de avaliação de qualidade (diffs pequenos, decisões rastreáveis)

4) Exemplo prático realista: como esse setup vira fluxo de trabalho

Um fluxo que dá pra usar no dia a dia.

Cenário

Você precisa implementar uma feature com impacto de arquitetura + UI:

  • envolve regra de negócio (backend/bff)
  • envolve refatoração (tech debt)
  • envolve UI/UX (layout e acessibilidade)

Fluxo multi-agente com worktree

  1. Worktree A — Planejamento (Claude/Opus)
      • define objetivos e restrições
      • lista riscos e decisões (trade-offs)
      • sugere arquitetura e checkpoints de validação
  2. Worktree B — Execução (Codex)
      • implementa a primeira versão seguindo o plano
      • mantém mudanças pequenas por commit
      • deixa rastros claros (mensagens, TODOs, testes)
  3. Worktree C — UI/UX (Gemini)
      • propõe layout, estados, empty states, loading, erros
      • garante consistência visual e interação
  4. Merge guiado por comparação
      • você não “aceita” o que um agente fez
      • você compara abordagens
      • escolhe a melhor parte de cada uma
      • garante coerência de contratos

O ponto aqui: você vira o integrador. O “programador” vira mais próximo de um arquiteto + editor + revisor técnico com capacidade de execução acelerada.


5) Erros comuns e armadilhas nesse futuro

5.1. Virar “gerente de prompt” sem modelo mental

Se você não entende o sistema, você só troca texto com IA.

Quando der bug, você não sabe nem onde procurar.

5.2. Especificações vagas geram código “convincente” e frágil

Agente preenche lacuna com suposição.

O código compila, passa em happy path, mas implode em borda.

5.3. Multi-agente sem contrato = Frankenstein

Se não existe:

  • contratos claros
  • limites de responsabilidade
  • invariantes

Você ganha velocidade local e perde estabilidade global.

5.4. Custo de tokens vira dívida técnica

Hoje muita gente mede produtividade por “quanto gerou”.

Amanhã vai medir por:

  • quanto gerou com o mínimo
  • quanta reexecução evitou
  • quanta ambiguidade eliminou na fonte

6) Boas práticas e recomendações (pra começar agora)

6.1. Treine abstrações, não sintaxe

  • escreva “modelos” em texto: regras, invariantes, contratos
  • force clareza: “o que nunca pode acontecer?”

6.2. Trabalhe com checkpoints

Em vez de pedir “faz a feature inteira”, peça:

  • passo 1: contrato e tipos
  • passo 2: fluxo e estados
  • passo 3: testes de borda
  • passo 4: observabilidade (logs/metrics)
  • passo 5: polimento

Isso reduz conflito e economiza tokens.

6.3. Use IA como “gerador de opções”, não de verdade

O melhor uso hoje é:

  • gerar 2-3 abordagens
  • você escolher e consolidar

6.4. Versionamento vira parte do design

  • commits pequenos
  • diffs legíveis
  • mensagens que expliquem decisão
  • rollback fácil

6.5. Ensine a IA do jeito que você faria

  • contexto, restrições, exemplos
  • “o que não pode”
  • “como eu valido que tá certo”

Se você consegue explicar bem, você consegue usar agentes bem.


7) Conclusão: a profissão não vai acabar — ela vai ficar mais honesta

Em alguns anos não vai fazer sentido avaliar dev por:

  • atalhos de IDE
  • velocidade de digitação
  • “decorar framework”

Vai fazer sentido avaliar por:

  • capacidade de manter abstrações
  • coordenação e integração
  • clareza de especificação
  • arquitetura e trade-offs
  • eficiência (inclusive de tokens)