Antes da Era da IA Generativa: Por que Alguns Desenvolvedores Tinham Sucesso e Outros Falhavam

Muitos desenvolvedores e empresas desistiam de projetos, reescreviam o código várias vezes, nunca obtinham resultados ou viviam um pesadelo mantendo softwares onde cada alteração causava novos bugs.

Por que isso acontecia? Analise estes cenários.

Porque eles faziam over-engineering (engenharia excessiva) ou código espaguete.

Era comum ver programadores sendo demitidos por problemas de desempenho em projetos onde havia um "herói do conhecimento" que adicionava múltiplas camadas de abstração, e apenas ele mesmo entendia aquele ambiente caótico de engenharia.

E então, ao abrir o esquema do banco de dados, os nomes das colunas tinham dois ou quatro caracteres e não havia nenhuma documentação explicando o que significavam.

Ou você via aquela base de código espaguete, com engenheiros chamados de "seniores" criando classes com 6 mil linhas e métodos com centenas de linhas.

Você abria o código e a carga cognitiva explodia.

Alterava uma linha e quebrava a lógica em todos os lugares.

Difícil de entender. Difícil de alterar. Geralmente, sem nenhuma documentação útil para o desenvolvimento.

Se a empresa perdesse os desenvolvedores fundadores, o projeto simplesmente morria, e as pessoas decidiam reescrevê-lo.

Como eu percebi isso?

Quando comecei a trabalhar, comecei como freelancer.

Eu não tinha oportunidades de emprego.

Eu não tinha um mentor.

A única coisa que eu sabia era fazer funcionar, então eu sou culpado: eu fazia código espaguete porque era a única forma que conhecia, e muitas pessoas também eram desenvolvedores de código espaguete.

Depois, comecei a trabalhar como programador web em uma agência web e, mais tarde, como programador em uma startup.

Entrei em bases de código de onde 5 ou 6 programadores já tinham pedido demissão, um após o outro um verdadeiro êxodo nerd.

Eu costumava trabalhar de 10 a 13 horas por dia apenas para conseguir pequenos resultados.

O código era uma bagunça:

• Classes Deus (God classes)
• Abstrações desnecessárias
• Código fortemente acoplado
• Métodos gigantescos
• Dependências ocultas

Você mudava uma coisa e muitas outras quebravam.

Eu também produzi projetos horríveis em algum momento; eles eram funcionais, o usuário clicava no botão e gerava o que queria, mas cheios de bugs devido a casos extremos (edge cases). Era o que eu era capaz de fazer na época.

Quando estudei Ciência da Computação, tive aulas de cálculo, matemática, redes, LISP, C, e nada explicava como produzir software corretamente nem qualquer outro curso.

Foi então que tive meu primeiro mentor de verdade.

Isso aconteceu quando entrei em uma empresa; o chefe queria que eu estudasse muito sobre alguns tópicos durante metade do meu dia para que eu pudesse continuar na empresa dele.

Ele me deu livros como Código Limpo (Clean Code) e Arquitetura Limpa (Clean Architecture), uma conta da Udemy com cursos de engenharia de software, vídeos sobre paradigmas e exercícios o tempo todo.

"Divida essa classe gigante em classes menores aplicando o Princípio da Responsabilidade Única."

"Refatore este método até que ele fique legível."

"Escreva testes."

Ele me cobrou muito para usar o Desenvolvimento Guiado por Testes (TDD).

Nossos pipelines tinham algo entre 3 mil e 8 mil testes.

Então, eu percebi uma coisa.

Éramos mais lentos no início, enfrentando curvas de aprendizado, dificuldades e bloqueios, mas quase nada quebrava depois. Continuávamos avançando, com tempo para fazer projetos paralelos em vez de apenas corrigir bugs, e até jogávamos videogame durante o expediente.

Anos mais tarde, alterávamos o código e nada explodia porque as coisas eram fracamente acopladas. O tempo para fazer alterações permaneceu consistente ao longo do tempo, e a integração (onboarding) de novos membros era rápida.

Quando eu precisava mudar algo, geralmente era:

• Uma classe pequena
• Um método pequeno
• Um nome de método legível
• Variáveis fortemente tipadas com nomes significativos
• Nenhum código repetido
• Resumos e comentários que realmente fornecem contexto
• Implementações simples que vem do mindset KISS
• Ter um botão de "executar testes" na IDE e saber imediatamente se algo quebrou após uma alteração

Aquele foi o momento em que percebi:

Este é o caminho para projetos de longo prazo.

Porque pessoas como Uncle Bob e Kent Beck vêm fazendo isso há mais tempo do que eu estou vivo.

Se eles chegaram a essas conclusões após décadas, provavelmente havia uma razão.

E, honestamente, os resultados foram bons.

O mais importante de tudo:

Era uma maneira mais saudável de construir software.

Menos estresse.

Menos pânico.

Você consegue ir à academia e viver melhor, sem xingar por causa de crises de raiva quando a produção quebra e o cliente diz publicamente o quão insatisfeito está.

Minha conclusão sobre como fazer software é fazer bem o básico da engenharia.

Exemplos

• Escrever testes E2E para a interface
• Testes unitários para o domínio
• Testcontainers para os repositórios
• YAGNI
• KISS
• Domain-Driven Design Tático
• Separar o acesso a dados com o padrão Repository
• Fazer bem a camada de domínio

O verdadeiro desafio no software é a mudança e a manutenção a longo prazo.

Escrevemos sistemas que podem viver por 20 anos ou mais.

A maioria de nós nem verá o fim daquilo que construiu.

Agora, o novo espaguete é o "vibe coding"

Vamos relacionar essa experiência com agentes de IA como o Codex e o Claude

Fabio Akita disse algo que eu gostei muito:

"A IA vai revelar quem você é."

O que isso significa?

Se a sua mentalidade sempre foi:

"Apenas faça funcionar e siga em frente."

Sem se importar com a estrutura do código, legibilidade, design do banco de dados, testes ou manutenibilidade, a IA vai amplificar isso em 10 vezes.

Mas se você realmente acredita em boas práticas, a IA se torna um multiplicador na direção certa.

Você:

• Escreve arquivos .md com padrões
• Aprende engenharia de prompt
• Fornece contexto e direciona os agentes para a documentação
• Usa o modo de planejamento (planning mode)
• Analisa o código gerado em vez de aceitá-lo cegamente
• Continua iterando os prompts para refatorar o código
• Mantém a cultura de revisão por pares (peer review), Git flow e testes

Dessa forma, a qualidade permanece a mesma.

Só que mais rápido.

Por que as empresas estão contratando desenvolvedores juniores novamente e falhando com IA?

Porque códigos ruins, sistemas criados via "vibe coding" espaguete, falta de limites claros, ausência de testes e documentação precária exigem contexto demais e geram custos absurdos de tokens.

Variáveis, classes, métodos, esquemas de banco de dados e terminologias de negócios não possuem uma linguagem ubíqua consistente baseada nos princípios do DDD, criando um ambiente caótico para ferramentas determinísticas.

No ano passado, fiz uma entrevista e o líder técnico me perguntou: "Qual é a sua capacidade de trabalhar em um projeto muito complexo onde cada classe pode ter 6 mil ou até mais linhas de código?"

Na pergunta seguinte, ele queria estratégias para economizar tokens e disse que os agentes de IA eram uma porcaria, pois não funcionavam bem. E este é o problema: sem boas práticas, a IA (que é muito determinística) precisa de uma boa base de código para funcionar bem.

O cérebro humano tem trilhões de neurônios e evolui naturalmente, então ele consegue entender o errado como certo, mas uma ferramenta determinística não.

Se você for um "dinossauro", ainda se lembra do contexto do MS-DOS ou do ENIAC.

Mas um agente de IA perde o contexto a cada sessão.

Quando ele recebe uma nova tarefa, precisa escanear tudo novamente. Portanto, se a sua base de código for gigantesca porque não segue o Princípio da Responsabilidade Única, isso vai custar muitos tokens e você terá problemas.

O ser humano já carrega a consciência do sistema; é por isso que os fundadores dos projetos sempre sabem o que fazer.

Agora, se você criar bons prompts com o contexto adequado, incluindo arquivos .md, o agente saberá exatamente quais classes e métodos importam.

Torna-se como um tiro de sniper em um alvo estático.

É assim que, com inteligência, você realmente tem sucesso com a IA.

Como estou obtendo bons resultados com agentes de IA, mantendo meus valores e boas práticas.

Eu escrevo alguns arquivos .md, por exemplo:

• claude.md ou copilot.md - Define instruções gerais e quais arquivos MD devem ser lidos.
• Communication.md - Instruções para comunicação.
• Arquitecture.md - Define os detalhes da estrutura de alto nível, como estratégias de teste.
• SystemDesign.md - Define padrões de projeto e princípios como SRP, clean code, DRY.
• Limits.md - Define restrições, como deletar recursos na Azure ou dar push direto na master.
• Stories/FeatureX.md - Define cada funcionalidade em um arquivo onde posso especificar todo o contexto dos requisitos, evitando textos massivos nos prompts.

Então, com a ajuda do ChatGPT, escrevo um prompt com técnicas de engenharia de prompt, como o uso de Auto-Reflexão (Self-Reflection).

Uso o modo de planejamento (plan mode) para garantir que o código gerado por esse prompt siga minhas diretrizes e para evitar alucinações.

Faço tudo no ambiente local, em uma branch específica para essa funcionalidade ou alteração.

Depois de aceitar as alterações, executo os testes, testo manualmente, reviso e abro o pull request.

Dicas pessoais extras:

• Use o melhor modelo para a sua tarefa, por exemplo: Opus para tarefas complexas, Sonnet para tarefas mais simples.
• Conheça a fundo a ferramenta de sua escolha. A minha é o Claude, então uso comandos como /clear peer task, /compact para sessões longas e /plan para ativar discussões.
• Tenha uma ferramenta de backup; eu também utilizo o Copilot.
• Para planejamentos de alto nível, uso o OpenAI Pro, que é muito melhor para brainstorm de ideias.

Conclusão final

Concordo com o Fabio Akita: a IA vai amplificar nossos valores como desenvolvedor, ou como quer que você se chame.

As empresas que estão vencendo com a IA geralmente são as mesmas que já tinham maturidade: elas continuam aplicando boas práticas, processos de QA, investindo em aprendizado e na melhoria dos processos.

Palavras-chave de SEO

Agentes de codificação de IA, vibe coding, engenharia de software, arquitetura limpa, débito técnico, manutenibilidade de software, engenharia de prompt, desenvolvimento assistido por IA, TDD, Clean Code, escalabilidade de software, programação com IA, Codex, Claude AI, práticas de engenharia de software.