Blog

A IA mudou a velocidade. Não mudou as leis da engenharia.

Recentemente, finalizamos a construção de dois produtos do zero. Somados, eles passam de 60.000 linhas de código — e não foram 60.000 linhas “de tutorial”. Foi produto real: decisões, trade-offs, deploy, edge-cases, bugs, prazos, risco e custo.

A gente operou no estado da arte de IA: Cursor, Claude Code e experimentos com o Antigravity. No stack, escolhas pragmáticas de performance e fluidez: Vite, Vercel e Convex. O resultado é inevitável: a sensação de velocidade é fascinante. Em certos dias, parece que você colocou um turbo na equipe.

Só que o turbo não muda a física.

Em algum ponto, a complexidade deixa de ser “um detalhe que a gente resolve depois” e vira o centro do problema. Foi aí que percebemos um padrão que o mercado de hype costuma ignorar — e que esse gráfico (que traduz muito bem o que vivemos) captura com precisão.

A leitura é simples:

• O eixo X é complexidade (do “feature isolada” ao “sistema vivo”).
• O eixo Y é produtividade real (o quanto você consegue entregar e sustentar).
• As curvas mudam conforme o repertório: Sênior, Pleno, Júnior, Não-técnico.

O que muda não é só velocidade. É alcance. É o ponto em que a curva quebra.

O que você vai tirar deste texto

• Um mapa honesto do que a IA acelera de verdade — e do que ela acelera para o lugar errado.
• Por que a produtividade cai quando o produto começa a “virar produto”.
• Como evitar o “Frankenstein funcional” e construir um ativo que não apodrece.
• Um playbook prático (e não glamouroso) para sustentar velocidade com controle.

Cena 1: o pico de alavancagem

A primeira fase é viciante.

Você descreve um objetivo, a IA devolve uma estrutura, você ajusta, roda, vê funcionando. Em horas você tem:

• rotas, páginas e componentes saindo do chão;
• integrações iniciais com serviços;
• validações, máscaras, formulários;
• endpoints e handlers com cara de “quase pronto”;
• testes “rascunho” que parecem um baita avanço.

Para um dev sênior, isso é alavancagem pura: a IA vira uma “impressora de boilerplate” e um acelerador de iteração. Para um pleno, vira um multiplicador de throughput. Para um júnior, vira uma espécie de exoesqueleto — e, para um perfil não-técnico, parece um superpoder.

Nesse momento, o produto não tem história. Não tem cicatriz. Não tem contratos implícitos. Não tem dívida acumulada.

A IA brilha porque o terreno ainda está limpo.

Cena 2: o contexto vira inimigo

A queda não acontece de uma vez. Ela começa com sinais pequenos:

• pequenas inconsistências de padrão (“em uma tela usa X, em outra usa Y”);
• regressões bobas em pontos que “nem foram mexidos”;
• código que funciona hoje, mas amanhã fica instável (o famoso “funciona, mas não confio”);
• mudanças que exigem mexer em 6 arquivos porque nada tem limite claro;
• decisões arquiteturais que parecem ótimas em cada prompt, mas horríveis no conjunto.

E então vem o sintoma mais perigoso:

Você passa mais tempo explicando contexto do que resolvendo o problema.

A IA começa a lutar contra o contexto que ela mesma ajudou a gerar. O que era “entrega” vira “negociação”: você pede A, ela responde A+3 coisas; você corrige, ela corrige e desmonta um detalhe crítico; você pede consistência, ela introduz um novo padrão “melhor”.

É a hora em que a curva despenca.

A ilusão mais cara: “gerar código” ≠ “sustentar software”

Aqui está o ponto que separa um protótipo de um ativo:

Software em produção não é código que funciona.
É código que continua funcionando quando o mundo muda.

E o mundo sempre muda:

• requisito muda;
• volume muda;
• regra de negócio muda;
• dado entra sujo;
• dependência externa falha;
• time muda;
• urgência muda.

A diferença entre “gerar” e “sustentar” é onde mora o ROI. É aí que o hype quebra.

Porque a IA pode acelerar a escrita. Mas o custo total está na manutenção: no diagnóstico, no refactor, nos testes, na observabilidade, no risco, na previsibilidade.

O abismo da complexidade (e por que ele existe)

Tem uma explicação técnica e uma explicação operacional.

A explicação técnica

LLMs não “entendem” um codebase do jeito que um humano entende. Elas trabalham com contexto disponível e padrões estatísticos. Quando o projeto cresce, o que importa fica distribuído:

• contratos implícitos (o “jeito certo” de fazer);
• invariantes (o que não pode quebrar);
• dependências cruzadas;
• efeitos colaterais (o que muda quando você toca em X).

Você vê isso na prática quando qualquer mudança simples vira uma cadeia de impactos.

E, nesse cenário, “saber o que está acontecendo” vale mais do que “conseguir gerar mais linhas”.

A explicação operacional

Complexidade não é “código demais”. Complexidade é:

• conformidade (precisar se encaixar no que já existe),
• acoplamento (um ponto puxa outro),
• invisibilidade (não dá pra ver tudo de uma vez),
• mudança (tudo está sempre em movimento).

Quando o produto entra nessa fase, a velocidade só se sustenta com disciplina. E disciplina não é opcional. É o preço.

A falsa sensação de capacidade (principalmente para Júnior e Não-Técnico)

O gráfico é cruel com um motivo: ele mostra um risco real.

Perfis júnior e não-técnicos conseguem chegar rápido no “parece pronto”. E isso é perigoso porque cria uma narrativa interna:

“Se eu cheguei até aqui, eu consigo terminar.”

Só que a curva deles é curta. Eles batem na complexidade antes do produto ser minimamente viável para produção — e normalmente sem perceber que bateram.

O resultado típico é um Frankenstein:

• funcional o suficiente para uma demo;
• instável o suficiente para dar prejuízo;
• impossível de manter sem reescrever;
• caro o suficiente para matar o ROI.

Não é culpa do perfil. É física do sistema.

E é por isso que o “gap” mais importante hoje não é entre “saber programar” e “não saber programar”.

É entre:

• gerar código
  vs
• exercer discernimento sobre o código.

Por que a IA não substitui repertório — ela o torna indispensável

A conclusão estratégica é simples:

A IA não substitui o repertório; ela o torna indispensável.

Na mão de quem não entende de arquitetura, a IA vira uma máquina de produzir dívida técnica em alta velocidade.

Na mão de quem tem visão operacional e diagnóstica, ela permite que um time enxuto entregue como uma estrutura muito maior — desde que você saiba navegar a descida da curva.

O sênior não é só “mais rápido”. Ele é mais resistente.

Ele tem três vantagens que não aparecem no prompt:

• Cria limites (interfaces, módulos, contratos, padrões).
• Detecta cheiro de risco (o bug que ainda não existe, mas vai existir).
• Sabe pagar o custo certo (refactor hoje para não sangrar amanhã).

Um playbook prático para sustentar velocidade com IA

Se você quer usar IA para construir produto de verdade (não só demo), aqui está o que funcionou melhor para nós — e o que virou regra de sobrevivência.

1) IA começa na especificação, não no código

Antes de pedir implementação, peça:

• escopo e não-escopo;
• contratos de interface;
• fluxos e estados;
• casos extremos;
• critérios de aceitação;
• “o que pode quebrar”.

Quando você força o pensamento antes da execução, a IA deixa de ser geradora de entulho e vira aceleradora de clareza.

2) Trabalhe em fatias pequenas (e versionadas)

Quanto maior o “lote” de mudança:

• menor a rastreabilidade,
• maior o risco,
• maior o custo de diagnóstico.

IA adora commits grandes. Engenharia odeia.

3) Defina invariantes e deixe elas visíveis

Invariantes são leis locais: “isso nunca pode acontecer”.

Se elas não estão claras (em tipos, testes, validações, docs curtas), a IA vai quebrar sem perceber — e você só vai ver quando virar incidente.

4) Teste o que dá confiança, não o que dá sensação

IA gera testes com facilidade — mas isso não significa que ela gera os testes certos.

Prefira testes que protegem:

• contrato de API;
• regras de negócio;
• edge-cases;
• fluxo crítico de dinheiro/dados.

O resto é espuma.

5) Observe o sistema como um produto, não como um repositório

Se você não mede:

• erros,
• latência,
• taxa de falha,
• logs úteis,
• comportamento anômalo,

você está dirigindo no escuro. E IA aumenta a velocidade — então dirigir no escuro fica pior.

6) Tenha um “momento de engenharia” explícito

Todo ciclo precisa de um ponto em que o objetivo não é “entregar feature”, é:

• limpar acoplamento,
• consolidar padrão,
• reduzir complexidade,
• pagar principal.

Sem isso, você só está acumulando juros.

7) Lembre do axioma da produção

Quando quebra em produção:

• não é a IA que entra na call,
• não é a IA que responde para o cliente,
• não é a IA que carrega o pager.

A responsabilidade continua humana. E isso muda tudo.

O que essas 60 mil linhas viraram para a HiveAgent

Para nós, essas 60 mil linhas não são “um experimento legal”.

Elas são laboratório e método.

Elas nos ensinaram onde a IA realmente paga — e onde ela só antecipa custo. Nosso foco é garantir que tanto as nossas soluções quanto as de nossos clientes não fiquem presas no pé da curva, onde o custo de manutenção engole o lucro da automação e a dívida técnica inviabiliza o negócio.

A IA mudou a velocidade. Mas não mudou as leis da engenharia e do ROI.

O controle precisa ser estratégico, não apenas algorítmico.

Pergunta honesta (pra fechar)

Você já sentiu que a produtividade da sua operação caiu à medida que a solução com IA ficou mais complexa?

Se sim, em que ponto a curva quebrou: no código, nos testes, na arquitetura, no deploy… ou no entendimento do time sobre o que foi construído?

PS: A imagem do gráfico eu vi circulando em trends (Twitter/Reddit) e não consegui rastrear o autor original. Se você souber, vale incluir o crédito.

Fontes e leituras

• Experimento controlado com 95 devs medindo ganho de velocidade com GitHub Copilot (inclui o resultado “~55% mais rápido” em uma tarefa específica). The GitHub Blog
• “Lost in the Middle” (limitações de LLMs ao usar contextos longos; degradação quando a informação relevante está “no meio” do contexto — útil para entender por que contexto grande é frágil). ACL Anthology
• Dívida técnica como metáfora de “juros” (o custo extra de evoluir um sistema quando a qualidade interna se deteriora). martinfowler.com
• “No Silver Bullet”, Fred Brooks (por que a complexidade essencial permanece e não existe salto mágico único que simplifique tudo). Worrydream
• Vibe coding vs engenharia assistida por IA (defesa de spec-first, revisão e guardrails para produção). Medium