Quanto mais código produzimos, mais importante se torna organizá-lo

O papel dos componentes na sustentabilidade de sistemas modernos

Se já era difícil organizar software antes, o que muda agora que a IA gera código em segundos?

Como bons sistemas se transformam em uma grande bola de lama

O desafio não é produzir mais código, mas manter sistemas compreensíveis e evolutivos.

Fazendo uma ponte com o que conversamos por aqui em outro post sobre decisões arquiteturais, critérios de sucesso, arquitetura evolutiva e o papel da arquitetura em um cenário onde a IA vem acelerando a criação de software.

Talvez a conclusão natural fosse imaginar que, com ferramentas cada vez mais inteligentes, o desenvolvimento tende a ficar mais organizado.

Na prática, nem sempre acontece assim. Na verdade, existe um risco curioso.

Se produzir código está ficando mais rápido, também pode ficar mais rápido produzir complexidade.

E, quase sempre, ela não chega de uma vez.

Ela se instala aos poucos.

O caos raramente começa com uma grande decisão

Poucos sistemas nascem ruins. Normalmente eles começam pequenos.

As responsabilidades fazem sentido e os componentes são relativamente claros.

As dependências ainda são compreensíveis.

Então chega a primeira urgência.

Depois uma exceção.

Uma integração inesperada.

Uma feature importante para ontem. (de vez em sempre… 😅)

Mais um hotfix.

Mais um comportamento especial. (aquele puxadinho maroto que parece inofensivo)

Cada decisão, isoladamente, parece razoável.

O problema é que arquitetura não é consequência de uma única decisão.

Ela é consequência da soma delas. É o resultado acumulado de todas as pequenas escolhas e trade-offs do dia a dia.

E, quando ninguém percebe, aquela arquitetura que parecia simples acumula acoplamento sutil, deixa escapar detalhes de implementação e começa a ficar cada vez mais difícil de entender, modificar e evoluir.

A grande bola de lama

Existe um nome bastante conhecido para esse fenômeno :

Big Ball of Mud.

Talvez você nunca tenha ouvido esse termo, normalmente usado na literatura de engenharia e arquitetura de software, mas provavelmente já abriu um projeto e pensou algo como:

“Quem foi que fez isso?” ou “Como chegou neste ponto?” 😅

É exatamente desse tipo de sistema que estamos falando. (E não vá culpar um único dev por isso… 😄…normalmente é um problema mais coletivo e estrutural)

Pense em um sistema onde:

• tudo depende de tudo (acoplamento ao extremo);
• responsabilidades se misturam;
• mudanças simples exigem alterações em vários lugares;
• alterar uma funcionalidade quebra outras três que aparentemente não tinham relação (o clássico efeito colateral imprevisível);
• ninguém consegue explicar claramente onde determinada regra de negócio deveria estar.

Curiosamente, esses sistemas quase nunca foram planejados dessa forma.

Eles apenas cresceram. E cresceram sem limites claros. Sem componentes bem definidos.

A verdade é que toda grande bola de lama começou com uma decisão que parecia pequena demais para merecer uma conversa sobre arquitetura.

Produzir mais código não significa produzir melhor arquitetura

Vivemos um momento curioso.

Cada vez mais ferramentas baseadas em IA conseguem escrever código, sugerir implementações, criar testes, gerar documentação e até desenvolver aplicações inteiras a partir de especificações relativamente simples.

Abordagens como Spec-Driven Development (SDD), agentes especializados e fluxos de desenvolvimento assistidos por IA (ou SDLC agêntico) estão tornando o desenvolvimento cada vez mais produtivo.

Contudo, produzir mais não significa estruturar melhor.

Existe uma diferença importante.

Essas ferramentas aceleram a produção de código.

Elas não garantem, por si só, uma boa arquitetura.

Se a especificação estiver confusa, os limites do sistema forem mal definidos ou as responsabilidades estiverem espalhadas, a IA provavelmente fará exatamente o que foi pedido.

Só que… muito mais rápido. :/

A velocidade aumenta tanto a capacidade de construir quanto a capacidade de criar dívida técnica e arquitetural.

Não por acaso, um relatório da PwC sobre o SDLC Agêntico mostra bem esse cenário ao definir a IA como um verdadeiro “amplificador organizacional“:

A IA potencializa os resultados de equipes com processos e arquitetura maduros, mas amplifica na mesma proporção as disfunções de organizações que tentam acelerar sem uma estrutura preparada

Se a resposta envolver algo como: 5 componentes diferentes, 3 serviços, 2APIs e uma boa dose de esperança…

É um forte indício de que o acoplamento venceu e existe um problema claro de modularidade.

Modularidade não é burocracia

Durante muito tempo, modularidade foi tratada como um luxo ou capricho de desing.

Algo que deixava o projeto “bonito” no diagrama.

Hoje, parece cada vez mais claro que ela é um mecanismo de sobrevivência.

Sistemas modulares costumam facilitar:

• evolução contínua;
• manutenção e isolamento de falhas;
• testabilidade (testar componentes isolados com mais facilidade);
• onboarding de novos desenvolvedores;
• trabalho paralelo entre equipes com menos conflitos de integração;
• adoção de novas tecnologias quando necessário.

Não porque módulos sejam elegantes.

Mas porque reduzem drasticamente o custo cognitivo de entender, manter e evoluir o sistema.

…

Componentes também ajudam a IA

Existe outro efeito interessante.

Quanto melhores forem os limites entre componentes, mais contexto conseguimos fornecer para ferramentas baseadas em IA.

Isso melhora:

• geração de código;
• refatorações;
• criação de testes;
• compreensão do domínio;
• recuperação de contexto em agentes e soluções baseadas em RAG.

Em outras palavras:

Arquitetura bem definida também melhora a qualidade da colaboração entre humanos e IA.

Talvez esse seja um dos argumentos menos discutidos atualmente.

Arquitetura evolui… ou se degrada

Em um artigo anterior que postei por aqui, conversamos sobre arquitetura evolutiva.

Mas existe um detalhe importante.

Nem toda evolução acontece na direção certa.

Arquiteturas também evoluem para pior.

A diferença é que essa degradação costuma ser silenciosa.

Ela acontece uma pequena decisão de cada vez.

Por isso, modularidade não é apenas uma preocupação de arquitetura.

É um mecanismo para preservar a capacidade de evolução do software.

Na era do código abundante, talvez a pergunta deixe de ser:

A pergunta que fica

“Estamos produzindo software mais rápido?”

E passe a ser (ou deveria ser):

“Estamos organizando esse software de forma que ele continue compreensível daqui a dois anos?”

Porque toda grande bola de lama começou exatamente assim:

Como um sistema aparentemente organizado.

---

Seguimos juntos pelo código e além (com IA ou sem)! ☕🚀