O gargalo no desenvolvimento de software não é mais escrever código: é decidir o que construir, como conectar e como manter o sistema à medida que ele muda. Por duas décadas, a escassez era de capacidade de produção; hoje, a produção de código é abundante e barata, e a escassez se deslocou completamente para as decisões de design que nenhuma ferramenta de geração de código pode tomar por você.
Isso tem uma consequência comercial concreta para qualquer empresa que compre serviços de desenvolvimento em 2026: o valor por hora para escrever código está caindo e o custo de uma decisão arquitetônica ruim está aumentando. Comprar como se ainda estivéssemos em 2019 — comparando fornecedores por preço e velocidade — é otimizar a variável errada.
A intuição sugere que, se a produção de código for mais rápida, os projetos deverão terminar mais cedo. Os dados contam uma história diferente.
O relatório DORA de 2024, compilado pelo Google Cloud com base em aproximadamente 39.000 profissionais do setor, constatou que um aumento de 25% na adoção de IA correlacionou-se com uma diminuição de 1,5% na taxa de entrega e uma redução de 7,2% na estabilidade. Isso não ocorreu porque o código gerado fosse inerentemente ruim, mas sim porque o tamanho dos lotes de alterações estava aumentando: mais código estava sendo implantado de uma só vez, as revisões eram menos rigorosas e mais código apresentava falhas. No mesmo estudo, 39,2% dos desenvolvedores relataram pouca ou nenhuma confiança no código gerado por IA.
A GitClear, ao analisar 211 milhões de linhas de código entre 2020 e 2024, documentou o outro lado do mesmo fenômeno: o código refatorado ou "movido" caiu de aproximadamente 251 TP3T em 2021 para menos de 101 TP3T em 2024, enquanto a prática de copiar e colar aumentou de 8,31 TP3T para 12,31 TP3T e os blocos duplicados aumentaram oito vezes.
Escreve-se mais, reorganiza-se menos. Acumula-se.
O estudo da METR de julho de 2025 adicionou uma nuance que precisa ser abordada honestamente. Em um teste controlado com 16 desenvolvedores experientes de código aberto e 246 tarefas do mundo real, os participantes levaram 19% a mais usando IA, embora esperassem ser 24% mais rápidos e, após o teste, ainda acreditassem ter sido 20% mais rápidos. A própria METR revisou esse projeto em fevereiro de 2026 em busca de um possível viés de seleção, e uma coorte maior mostrou uma diferença muito menor. O resultado exato está aberto a debate. O que não está aberto a debate é a descoberta secundária: a velocidade percebida e a velocidade real se dissociam.
Quando a percepção de velocidade se dissocia da realidade, a disciplina que corrige o rumo não é a execução, mas sim o planejamento.
Nem todas as decisões técnicas têm o mesmo peso. A distinção prática reside entre o que pode ser mudado em uma semana e o que moldará os próximos cinco anos.
Tipo de decisão | Exemplo | Custo da alteração posterior |
Ferramenta | Framework de front-end, biblioteca gráfica | Baixa: semanas |
Fornecedor de modelos | Mudança de um LLM para outro | Sob a qual existe uma camada de abstração |
Modelo de dados | Como representar um cliente ou um pedido | Alto: afeta tudo o que for construído acima dele. |
Fronteiras entre sistemas | Qual módulo detém qual informação? | Muito alto: reescrita parcial |
Modelo de autorização | Quem pode ver e fazer o quê, e com que rastreabilidade? | Muito alto: implica segurança e conformidade. |
As duas primeiras linhas são as que geram mais ruído em reuniões técnicas. As três últimas são as que determinam se, daqui a três anos, a empresa conseguirá evoluir seu sistema ou se terá que reescrevê-lo.
Um exemplo concreto que se repete em logística, seguros e saúde é a decisão sobre se um "registro de paciente" é uma entidade independente com seu próprio ciclo de vida ou simplesmente uma visualização construída sobre outras tabelas. Essa decisão é tomada na segunda semana do projeto, quase sempre sem discussão, e determina por anos se as alterações podem ser auditadas, se a retenção de dados pode ser imposta e se o registro pode ser exposto a terceiros por meio de uma API. Nenhum gerador de código tomará essa decisão porque não é uma questão de programação: é uma questão de negócios.
Este é o trabalho que fazemos em desenvolvimento de software personalizado [link interno] Antes de escrever a primeira linha: defina o que existe, o que pertence a quê e qual o contrato de cada módulo com os outros.
A arquitetura de um sistema empresarial é definida por quatro limites. Quando todos os quatro estão bem definidos, o sistema evolui. Quando qualquer um deles se torna impreciso, o sistema se degrada, mesmo que o código seja impecável.
A fronteira dos dados. Cada dado deve ter um único proprietário: um sistema que o comanda e outros que o consultam. A alternativa — três sistemas registrando a mesma informação — gera contradições que nenhuma camada superior consegue resolver, e é a causa principal da maioria dos projetos de inteligência de negócios que terminam em discussões sobre qual número está correto.
A fronteira dos contratos. Os módulos comunicam-se através de interfaces explícitas, versionadas e documentadas. Um contrato é uma promessa: "isto é o que entrego, isto é o que garanto, isto é o que altero mediante aviso prévio". Sem contratos, cada integração é um novo acoplamento e cada alteração é uma negociação.
A fronteira das autorizações. Quem pode ver o quê e quem pode fazer o quê deve ser uma camada do sistema, não uma condição repetida em quarenta lugares. Essa fronteira tornou-se crítica com a chegada de agentes de IA que executam ações: se o modelo de permissões era frágil com usuários humanos, ele se desfaz com identidades não humanas.
O limite da observabilidade. Um sistema onde é impossível saber o que aconteceu, quando e porquê, não é nem sustentável nem auditável. E, desde que componentes probabilísticos foram introduzidos na cadeia, a rastreabilidade deixou de ser uma boa prática operacional e tornou-se um requisito de governança.
Essas quatro fronteiras são o que estruturam uma arquitetura composável, uma abordagem que desenvolvemos em detalhes em nossa análise sobre arquitetura composta, APIs e inteligência artificial
Uma auditoria formal não é necessária para detectar os sintomas iniciais. Estes são os indicadores que aparecem primeiro:
Quando três ou mais desses sintomas aparecem, aumentar a capacidade de desenvolvimento não acelera nada. Apenas aumenta o número de pessoas esperando que uma decisão de projeto seja tomada.
O argumento a favor da arquitetura é frequentemente apresentado em termos de engenharia, razão pela qual perde força em comitês de gestão. Traduzindo para a linguagem empresarial, uma boa arquitetura realiza quatro funções mensuráveis:
Reduza o custo de mudar de ideia. Uma empresa que consegue modificar sua oferta, seu processo de faturamento ou seu modelo de preços em semanas compete de forma diferente de uma que precisa de seis meses.
Transforme a tecnologia em um ativo, não em uma despesa recorrente. Um sistema com propriedade de código clara, documentação e contratos explícitos é valioso em processos de due diligence. Um sistema que depende de um único fornecedor, não.
Permite a substituição de peças sem a necessidade de reconstruir a montagem. Isso é especialmente relevante no caso de modelos de IA, cujos preços, capacidades e políticas de utilização mudam várias vezes ao ano.
Isso torna as decisões auditáveis. Com o quadro regulamentar europeu cada vez mais rigoroso, é importante poder demonstrar o que o sistema fez e com que dados passou de desejável a obrigatório.
Na The Cloud Group, isso é formalizado no TCG-SAF™, nossa estrutura de arquitetura de sistemas: cinco etapas — Visão, Domínios, Módulos, Engenharia e Execução — e um único documento de arquitetura que rege toda a construção. Isso não é uma questão de preferência estética. É o motivo pelo qual podemos fornecer garantias de prazo por escrito: uma data só pode ser confirmada quando o escopo é estruturado antes do início do projeto.
Durante o auge da euforia, presumia-se que, se todos tivessem acesso aos mesmos modelos, as capacidades seriam igualadas. O oposto ocorreu. Duas empresas com acesso idêntico às mesmas ferramentas obtêm resultados radicalmente diferentes, e a diferença reside em seus dados proprietários, seu conhecimento do domínio e a qualidade da integração entre seus sistemas.
Os modelos se tornam commodities. As ferramentas de geração de código se tornam commodities. O que não se torna commodity é a capacidade de transformar funcionalidades genéricas em um sistema específico, confiável e proprietário.
Essa habilidade tem um nome antigo e pouco glamoroso: engenharia.
A arquitetura de software é o conjunto de decisões sobre quais componentes existem, que informações cada um contém e como eles se comunicam entre si. Ela é mais importante que o código, pois o código pode ser reescrito em semanas, enquanto a alteração do modelo de dados ou dos limites entre os sistemas pode exigir uma reescrita parcial do produto.
Os sintomas típicos incluem: pequenas alterações demoram tanto quanto as grandes, as estimativas são pouco confiáveis, cada nova integração custa o mesmo que a primeira, existem áreas do sistema que a equipe evita mexer e o conhecimento do fluxo de informações depende de uma única pessoa.
Não: na verdade, aumenta. Quando gerar código é barato, a escassez passa a ser a decisão sobre o que construir e como conectar os elementos. O relatório DORA de 2024 constatou que o aumento na adoção de IA estava correlacionado com menor estabilidade nas entregas, justamente porque o volume de mudanças cresce sem um aumento correspondente na disciplina de design.
Os três aspectos mais dispendiosos para reverter são o modelo de dados (como as entidades de negócio são representadas), os limites de propriedade entre sistemas (qual módulo controla qual informação) e o modelo de permissões e rastreabilidade. Alterar frameworks ou fornecedores de modelos é comparativamente mais barato.
Depende do grau de acoplamento, mas o padrão típico é que o custo cresce de forma não linear ao longo do tempo: cada mês de desenvolvimento em um limite mal definido adiciona código que dependerá dessa decisão. É por isso que uma auditoria técnica inicial geralmente custa uma fração do que custaria a reescrita que ela evita.
Sim. A abordagem usual é isolar o sistema existente por meio de contratos explícitos e substituir os domínios um a um, em vez de reescrever tudo de uma vez. Isso requer uma avaliação preliminar que priorize qual domínio modernizar primeiro, com base no risco e no valor para o negócio.
Você suspeita que sua arquitetura seja o obstáculo? Nossa auditoria técnica de software fornece um diagnóstico por escrito da arquitetura, código, dívida técnica e segurança em até 10 dias úteis, por um preço fixo. Sem proposta comercial inclusa: primeiro o diagnóstico, depois a decisão. Solicitar auditoria → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
