AWS Leva o Superblocks para Nuvens Privadas, Redefinindo a Corrida de IA entre Amazon e Google

A AWS deu um passo incomum na disputa de nuvem entre Amazon e Google ao ajudar o Superblocks a operar inteiramente nos ambientes privados da AWS de seus clientes. O acordo aproxima uma plataforma terceirizada de vibe coding dos dados empresariais, controles de segurança e sistemas de compras. Também desafia a suposição de que um aplicativo de IA precisa permanecer vinculado à empresa de modelos que ajudou a criá-lo.

O Superblocks anunciou a parceria com a AWS junto com o Superblocks 3.0 em 3 de agosto de 2026. Sua plataforma permite que funcionários criem aplicativos empresariais por meio de instruções em linguagem natural, uma prática comumente chamada de vibe coding. A mudança importante está em onde esses aplicativos, prompts, modelos e recursos de suporte podem operar.

No novo modelo de implantação, o Superblocks afirma que sua plataforma opera dentro da conta AWS do cliente e usa o Amazon Bedrock para inferência de IA. A AWS fornece o perímetro de infraestrutura e o gateway de modelos, enquanto o Superblocks oferece as camadas de criação de aplicativos e governança.

Essa estrutura exerce pressão além do concorrido mercado de ferramentas de programação com IA. Ela dá à AWS uma forma de capturar aplicativos criados com produtos da OpenAI, Anthropic, Replit, Lovable e outros. O Google Cloud enfrenta a mesma questão estratégica por meio do Vertex AI: a nuvem que hospeda o aplicativo pode importar mais do que o modelo que o gerou?

A resposta depende de as empresas aceitarem o Superblocks como um caminho controlado do protótipo à produção. Também depende de suas alegações de implantação privada se sustentarem em avaliações reais de segurança, operação e conformidade.

O Superblocks 3.0 Leva o Vibe Coding para Dentro do Perímetro da AWS

A mudança central não é mais um assistente de programação. É uma rota gerenciada para levar aplicativos gerados por IA à infraestrutura controlada pela TI empresarial.

O Superblocks descreve sua arquitetura Cloud-Prem como uma implantação dedicada, de locatário único, dentro da conta AWS do cliente. Uma implantação de locatário único oferece a um cliente uma instância isolada, em vez de compartilhar um ambiente de aplicativos com outras organizações.

A empresa afirma que a implantação inclui seu plano de controle, plano de dados e a inferência de IA Clark. O plano de controle gerencia aplicativos e políticas, enquanto o plano de dados executa código e se conecta a sistemas empresariais privados.

As solicitações de IA passam pelo Amazon Bedrock usando modelos e regiões aprovados pelo cliente. Os aplicativos se conectam a um plano de dados do Superblocks localizado próximo aos dados privados do cliente. A empresa afirma que isso reduz a movimentação de dados, mantendo o isolamento regional.

A arquitetura Cloud-Prem também usa os controles existentes da AWS para identidade, rede, criptografia e auditoria. Os funcionários se autenticam por meio do provedor de identidade da organização, e os administradores aplicam as políticas de acesso existentes.

Isso difere de simplesmente conectar um criador de aplicativos hospedado a um banco de dados empresarial. Segundo o Superblocks, todo o ambiente de criação de aplicativos fica dentro do perímetro de nuvem do cliente.

Quando um funcionário solicita que um aplicativo armazene dados, o Superblocks afirma que a plataforma pode provisionar recursos do Amazon Aurora ou Amazon S3 dentro desse perímetro. Ela também pode executar migrações de banco de dados quando um aplicativo passa do desenvolvimento para a produção.

Essas operações são importantes porque o código gerado é apenas um componente de um aplicativo empresarial funcional. O software de produção também precisa de bancos de dados, identidades, permissões, caminhos de rede, estágios de implantação, logs e um responsável.

O Superblocks tenta reunir esses componentes em um caminho que funcionários de negócios possam usar sem receber acesso irrestrito à nuvem. As equipes de segurança e plataforma mantêm a supervisão por meio do Superblocks e do console da AWS.

O anúncio de agosto também descreveu uma função de importação para protótipos criados com ChatGPT, Claude, Replit, Lovable e código puro. Os aplicativos importados entram no ambiente do Superblocks, onde as equipes podem conectá-los a dados aprovados e processos de implantação.

Isso torna o produto menos dependente de ser o lugar onde uma ideia começa. Em vez disso, o Superblocks pode se tornar o destino controlado onde um aplicativo experimental se torna operacional.

O anúncio do Superblocks 3.0 da empresa apresenta isso como um caminho intermediário para diretores de informação e segurança. Eles não precisam proibir aplicativos criados por funcionários nem deixá-los fora da governança normal.

Esse enquadramento vem do Superblocks, não de uma avaliação independente de segurança. Ainda assim, o problema subjacente é reconhecível. Ferramentas de programação generativa permitem que funcionários criem software mais rapidamente do que muitas empresas conseguem inventariar, revisar ou dar suporte.

A implantação na AWS oferece a essas empresas outra opção. Elas podem tentar absorver a experimentação dos funcionários no mesmo perímetro técnico que já governa cargas de trabalho consolidadas.

Por Que a Disputa entre Amazon e Google Está Subindo Acima da Camada de Modelos

Amazon e Google competem cada vez mais para se tornar a camada operacional duradoura sob os aplicativos, mesmo quando outra empresa fornece o modelo de IA preferido.

A competição inicial em IA generativa se concentrou na qualidade dos modelos. As empresas comparavam benchmarks, limites de contexto, desempenho em programação e velocidade de resposta. Essas métricas continuam importantes, mas mudam com frequência.

Um aplicativo empresarial costuma durar mais do que a vantagem inicial de seu modelo. Suas conexões de dados, fluxos de aprovação, regras de identidade e histórico operacional se tornam mais difíceis de substituir do que o endpoint do modelo.

A AWS se beneficia quando os clientes tratam o Bedrock como o gateway estável sob esses aplicativos. O Bedrock oferece modelos da Amazon e de fornecedores externos por meio de interfaces gerenciadas e controles de governança da AWS.

A AWS afirma que suas ferramentas de escolha de modelos permitem que os clientes avaliem e substituam modelos sem reescrever aplicativos inteiros. Essa promessa não elimina todos os problemas de migração. Os modelos ainda diferem em prompts, uso de ferramentas, formatos de saída, comportamento e disponibilidade regional.

No entanto, a direção é clara. A AWS quer que a seleção de modelos se torne uma decisão de infraestrutura gerenciada dentro da AWS, e não uma relação permanente entre cada aplicativo e um fornecedor de modelos.

O Google adotou uma posição semelhante. O Vertex AI Model Garden reúne modelos do Google, modelos abertos e ofertas selecionadas de terceiros em uma única plataforma.

O Google afirma que o Model Garden oferece padrões comuns para descobrir, testar, personalizar e implantar modelos. O Vertex AI também conecta o acesso a modelos com avaliação, disponibilização e políticas organizacionais.

Portanto, a competição entre Amazon e Google vai além de Nova versus Gemini. Ambas as nuvens querem que os clientes construam sistemas de aplicativos capazes de consumir vários modelos, mantendo uma única nuvem como ponto de controle.

O Superblocks dá à AWS uma rota de distribuição nessa disputa. A startup oferece uma camada de aplicativos que os funcionários podem compreender, enquanto a AWS fornece uma infraestrutura familiar às equipes empresariais de tecnologia.

Essa divisão de trabalho pode ajudar ambas as empresas. O Superblocks ganha acesso a clientes que já confiam à AWS cargas de trabalho sensíveis. A AWS ganha aplicativos que consomem armazenamento, bancos de dados, logs, redes, serviços de segurança e inferência de modelos.

O fornecedor do modelo não necessariamente desaparece. Um aplicativo operando na AWS ainda pode usar um modelo de terceiros disponível por meio do Bedrock. O centro comercial e operacional simplesmente se desloca para a nuvem de hospedagem.

O Google pode apresentar o mesmo argumento com o Vertex AI e suas próprias opções de implantação privada. Seu desafio não é apenas convencer as empresas de que o Gemini tem bom desempenho. Ele também precisa tornar o Google Cloud o local preferido para aplicativos gerados em qualquer lugar.

A Microsoft enfrenta uma tarefa equivalente por meio do Azure, GitHub e seu catálogo de modelos. No entanto, a rivalidade entre Amazon e Google expõe com mais clareza o padrão estratégico mais amplo, porque ambas as empresas operam grandes portfólios de nuvem e IA.

Um provedor de nuvem não precisa ter todos os modelos vencedores para controlar a carga de trabalho ao redor deles. Ele precisa do banco de dados, sistema de identidade, políticas de rede, logs, runtime de aplicativos e relação de compras.

É por isso que a parceria com o Superblocks traz implicações que vão além de uma startup. Ela torna o ambiente de aplicativos mais portátil entre fornecedores de modelos, ao mesmo tempo que torna mais valiosa a relação com a nuvem subjacente.

A AWS Está Transformando a Flexibilidade de Modelos em Gravidade de Aplicativos

Desacoplar aplicativos de modelos individuais pode reduzir uma forma de dependência, ao mesmo tempo que aumenta a dependência da nuvem que coordena todo o restante.

O Superblocks chama seu agente de IA de Clark. Na implantação da AWS, Clark pode enviar solicitações de inferência pelo Bedrock usando modelos selecionados pelos administradores da organização.

A empresa também descreve um Smart Router que separa uma solicitação complexa de aplicativo em tarefas menores. Ele pode direcionar o trabalho de planejamento difícil para um modelo e o trabalho rotineiro de programação para outro.

O Superblocks afirma que esse roteamento pode reduzir os custos de inferência em até 30 por cento sem reduzir a qualidade final do aplicativo. Esse número é uma estimativa da empresa e não foi validado de forma independente em diversas cargas de trabalho empresariais.

A ideia mais significativa é o roteamento de modelos no nível das tarefas. Um criador de aplicativos não precisa mais de um único modelo para lidar com todas as etapas de planejamento, geração de código, testes e revisão.

Essa abordagem trata os modelos como recursos computacionais substituíveis. A camada de aplicativos decide qual recurso se encaixa em cada tarefa, enquanto a nuvem gerencia acesso, identidade, capacidade e faturamento.

No entanto, os modelos não são realmente intercambiáveis. Um pode seguir esquemas de ferramentas com confiabilidade, enquanto outro produz melhor código de interface. Um terceiro pode lidar bem com documentos longos, mas ter dificuldades com saídas estruturadas precisas.

Os sistemas de roteamento precisam avaliar essas diferenças continuamente. Eles também precisam de regras de contingência quando um modelo fica indisponível, muda de comportamento ou não tem suporte em uma região AWS exigida.

O Superblocks se posicionou como a camada que absorve essa complexidade. O cliente interage com um sistema de criação de aplicativos, em vez de selecionar um modelo para cada prompt.

A AWS se beneficia porque cada solicitação roteada pode permanecer dentro do Bedrock. Mesmo quando o modelo selecionado vem de um desenvolvedor externo, a AWS continua envolvida no controle de acesso, entrega de inferência e monitoramento operacional.

Isso cria gravidade de aplicativos. Quando uma organização conecta o Superblocks a identidades da AWS, bancos de dados privados, registros de pacotes, logs e processos de implantação, torna-se difícil mover o sistema completo.

O modelo pode mudar mais facilmente do que os controles ao redor. Esse é o desacoplamento no centro deste acordo.

Não é o fim da dependência de fornecedores. É uma mudança de onde essa dependência se acumula.

Uma empresa pode evitar depender inteiramente da Anthropic, OpenAI ou de outro desenvolvedor de modelos. Ainda assim, pode se tornar profundamente dependente das APIs do Bedrock, da infraestrutura da AWS e das definições de aplicativos do Superblocks.

O Superblocks afirma que sua abordagem elimina a dependência de fornecedores, mas essa alegação merece tratamento cuidadoso. Manter os dados em uma conta AWS pertencente ao cliente melhora o controle, mas a portabilidade operacional exige mais do que a propriedade dos dados.

As equipes precisariam recriar regras de identidade, definições de infraestrutura, lógica de aplicação, pipelines de implantação, histórico de auditoria e comportamento de roteamento de modelos em outro lugar. A dificuldade desse trabalho determina o nível real de portabilidade.

O Google está construindo sua própria versão de gravidade de aplicações. Vertex AI conecta o Model Garden às redes do Google Cloud, serviços de dados, ferramentas de avaliação e controles de políticas.

A batalha entre Amazon e Google está, portanto, se tornando uma disputa pela melhor abstração. Cada provedor quer que os clientes vejam os modelos como substituíveis, ao mesmo tempo em que consideram seu plano de controle em nuvem essencial.

Superblocks fortalece a AWS nessa disputa porque leva funcionários menos técnicos para o pipeline de aplicações. Mais criadores podem desenvolver mais aplicações, e cada aplicação pode consumir serviços adicionais da AWS.

Essa expansão só tem valor quando as empresas conseguem governá-la. Caso contrário, uma criação mais rápida simplesmente produz uma coleção maior de software interno sem suporte.

A Governança É o Produto, mas Ainda Precisa de Provas

Superblocks está vendendo acesso controlado à produção, não geração irrestrita de código, e essa promessa exige um nível muito maior de evidências.

A empresa afirma que toda alteração de código passa por agentes de segurança especializados e scanners determinísticos antes de chegar à produção. Scanners determinísticos aplicam regras fixas para encontrar fraquezas conhecidas, como credenciais codificadas diretamente ou fluxos de dados inseguros.

Segundo relatos, os agentes de segurança examinam um contexto mais amplo da aplicação, incluindo autenticação, autorização, APIs e lógica de negócios. Os administradores também podem definir agentes de políticas para requisitos específicos da organização.

A Superblocks afirma que seus controles de produção incluem registros privados de pacotes e listas de materiais de software. Uma lista de materiais de software registra os componentes e dependências incluídos em uma aplicação.

Segundo a empresa, a plataforma continua examinando dependências implantadas em busca de vulnerabilidades recém-divulgadas. Ela pode alertar os responsáveis pela aplicação quando surge uma vulnerabilidade relevante.

São controles úteis, mas sua presença não comprova sua eficácia. Agentes de segurança podem não identificar problemas sutis de autorização, aprovar lógica gerada insegura ou produzir alertas falsos em volume suficiente para que os administradores os ignorem.

Aplicações geradas também levantam questões de responsabilidade. Alguém precisa decidir quem mantém uma aplicação quando seu funcionário original muda de função, uma API muda ou um fluxo de trabalho gerado por modelo produz uma decisão de negócios incorreta.

O isolamento na nuvem não pode responder a essas perguntas. Manter código e prompts dentro de uma conta AWS reduz determinados caminhos de exposição, mas não torna a lógica gerada correta.

As políticas de IAM existentes também podem conter permissões excessivas. Uma aplicação que opera inteiramente dentro de uma nuvem privada ainda pode expor dados sensíveis ao funcionário errado ou alterar um registro crítico.

A mesma cautela se aplica à afirmação da Superblocks de que prompts e dados permanecem dentro do ambiente AWS seguro do cliente. Os compradores precisam verificar quais metadados, diagnósticos, registros de suporte e eventos administrativos saem desse ambiente.

A arquitetura da empresa afirma que a comunicação dos planos de dados regionais pode ser somente de saída. As organizações ainda precisam inspecionar esses caminhos de saída, mecanismos de suporte, acordos de criptografia e os privilégios administrativos da Superblocks.

Cloud-Prem também é um serviço gerenciado. A Superblocks cuida de atualizações, correções de segurança, confiabilidade e suporte, enquanto o cliente controla políticas no nível da nuvem e limites de implantação.

Essa divisão pode reduzir o trabalho operacional, mas cria responsabilidade compartilhada. Os compradores precisam de uma descrição precisa de qual parte pode acessar cada componente e do que acontece durante um incidente.

Uma implantação privada também pode complicar as atualizações. A Superblocks precisa oferecer suporte a muitos ambientes de clientes com diferentes restrições de rede, requisitos regionais e processos de aprovação.

A empresa afirma que planeja e executa atualizações. Clientes empresariais ainda devem testar se as mudanças preservam o comportamento das aplicações, o roteamento de modelos, as políticas e as integrações.

Outra incerteza é a adoção. Usuários de negócios podem preferir a liberdade imediata de ferramentas de programação para consumidores a uma plataforma aprovada com revisões e etapas de promoção.

A Superblocks tenta lidar com esse problema importando protótipos existentes. Isso permite que os funcionários comecem em ferramentas familiares e entrem no ambiente governado quando uma aplicação precisa de dados de produção.

Essa ponte faz sentido estratégico, mas tem limites. O código importado pode trazer pacotes sem suporte, licenças pouco claras, premissas frágeis e estruturas que não se mapeiam perfeitamente para a Superblocks.

As equipes de segurança também precisam de evidências de que os inventários de aplicações permanecem completos. Uma plataforma governada não pode controlar protótipos que os funcionários nunca importam ou divulgam.

A versão mais forte do argumento da Superblocks, portanto, exige mudança comportamental, não apenas implantação técnica. Os funcionários precisam aceitar o caminho aprovado, e a TI precisa tornar esse caminho mais rápido que as alternativas informais.

A Pressão Recai sobre as Plataformas de Programação e a TI Empresarial

Os perdedores imediatos são as plataformas que não conseguem cruzar a fronteira entre protótipo rápido e produção governada sem reconstruir a aplicação em outro lugar.

As ferramentas de programação voltadas ao consumidor reduziram o esforço necessário para produzir protótipos funcionais. Elas costumam otimizar para um criador individual que deseja feedback visual rápido e implantação simples.

A produção empresarial introduz requisitos diferentes. As aplicações precisam de acesso controlado a registros de clientes, sistemas financeiros, APIs internas e dados regulamentados.

Também precisam de registros de auditoria, separação de ambientes, procedimentos de incidentes e responsabilidade clara. Um protótipo visualmente convincente não satisfaz automaticamente essas condições.

A Superblocks está mirando a lacuna entre essas etapas. Ela não precisa impedir que funcionários usem ChatGPT, Claude, Replit ou Lovable durante a ideação. Precisa dominar a transição para a produção.

Essa posição pressiona outras plataformas de vibe coding a adicionar opções comparáveis de governança e implantação privada. Caso não façam isso, correm o risco de se tornar fornecedoras de plataformas que lidam com a etapa operacional final.

A pressão também alcança fornecedores estabelecidos de ferramentas internas. Seus produtos já tratam de permissões, conexões de dados e implantação, mas a geração por IA muda quem pode criar e a velocidade com que as aplicações se multiplicam.

Esses fornecedores precisam apoiar criadores não tradicionais sem enfraquecer os controles que atraíram as empresas em primeiro lugar. Também precisam de flexibilidade de modelos confiável, à medida que os clientes evitam a dependência de um único fornecedor de IA.

Os provedores de nuvem enfrentam outra decisão. Eles podem construir seus próprios ambientes de geração de aplicações ou distribuir produtos independentes por meio de marketplaces e canais de vendas.

A AWS está adotando a rota de parceria com a Superblocks enquanto continua expandindo o Bedrock e seus serviços para desenvolvedores. Essa abordagem permite que a AWS ofereça uma experiência especializada de aplicações sem possuir todas as interfaces.

O Google pode responder por meio do Vertex AI, de seus produtos de desenvolvimento de aplicações e de parceiros externos. A Microsoft pode combinar serviços de IA do Azure com GitHub e sua presença em softwares empresariais.

A pressão mais profunda recai sobre a TI empresarial. Os funcionários já têm acesso a agentes de programação e criadores de aplicações baseados em navegador, independentemente de essas ferramentas aparecerem ou não em catálogos aprovados.

Bloquear todas as ferramentas pode empurrar o desenvolvimento ainda mais para fora da supervisão oficial. Aprovar todos os experimentos cria uma carga de revisão que as equipes de segurança e plataforma não conseguem sustentar.

A Superblocks propõe a aplicação automatizada de políticas como resposta. Se seus agentes de segurança e controles de implantação funcionarem como descrito, a TI poderá revisar regras e exceções em vez de inspecionar manualmente cada linha gerada.

Essa proposta precisa de evidências operacionais reais. As equipes devem medir quantas aplicações chegam à produção, com que frequência as políticas bloqueiam mudanças inseguras e quanto tempo as exceções levam para ser resolvidas.

Elas também devem acompanhar aplicações abandonadas. Uma criação mais rápida pode produzir acúmulo de software, incluindo fluxos de trabalho duplicados e ferramentas sem um responsável definido pela manutenção.

Uma base de conhecimento de engenharia pesquisável pode ajudar as equipes a preservar decisões de design, runbooks e o contexto das aplicações. Ela não substitui controles técnicos, mas pode reduzir a perda de conhecimento em torno de software criado por funcionários.

A métrica mais importante não é o número de aplicações geradas. É o número que permanece seguro, útil, mantido e menos caro do que os processos que substituiu.

Se a Superblocks conseguir demonstrar esse resultado, a AWS ganhará uma rota repetível para expandir o consumo de nuvem por meio do desenvolvimento liderado pelos negócios. Se não conseguir, a parceria continuará sendo uma história atraente de implantação sem um modelo operacional comprovado.

O Que Vem a Seguir na Disputa de Nuvem entre Amazon e Google

Três sinais mostrarão se essa parceria transforma o desenvolvimento de aplicações empresariais ou se torna mais uma opção limitada de nuvem privada.

O primeiro sinal é a adoção em produção. AWS e Superblocks precisam de clientes executando aplicações relevantes por meio da arquitetura Cloud-Prem, e não apenas avaliando demonstrações ou pilotos isolados.

Evidências úteis incluiriam contagens de aplicações, criadores ativos, uso em produção, taxas de incidentes e o tempo necessário para colocar um protótipo em operação. Estudos de caso de clientes devem distinguir resultados medidos de estimativas fornecidas pela Superblocks.

A adoção em setores regulamentados reforçaria a tese central. Essas organizações têm os motivos mais claros para exigir residência de dados, auditabilidade e controle sobre o acesso a modelos.

Implantações lentas a enfraqueceriam. Elas sugeririam que a instalação em nuvem privada e a governança criam atrito demais para os funcionários que a Superblocks quer atender.

O segundo sinal é uma resposta competitiva direta. Google, Microsoft, fornecedores estabelecidos de ferramentas internas e outras plataformas de vibe coding agora têm motivos para reforçar seus próprios caminhos de protótipo à produção.

Uma resposta relevante combinaria escolha de modelos, infraestrutura controlada pelo cliente, aplicação de políticas e gestão do ciclo de vida das aplicações. Adicionar outro gerador de código não resolveria o mesmo problema.

O Google é especialmente importante porque já oferece um amplo catálogo de modelos e recursos de implantação privada. A disputa entre Amazon e Google se intensificará se o Google conectar esses ativos a uma camada de aplicações empresariais igualmente acessível.

Tal movimento reforçaria a ideia de que os modelos estão se tornando componentes dentro de sistemas de aplicações controlados pela nuvem. Uma resposta discreta sugeriria que os rivais veem a Superblocks como um produto mais restrito de ferramentas internas.

O terceiro sinal é a evidência de troca bem-sucedida de modelos. Superblocks e AWS argumentam que as organizações podem rotear tarefas entre modelos aprovados sem vincular aplicações a um único provedor.

Os clientes devem testar essa proposta durante atualizações e substituições reais de modelos. Eles precisam medir a qualidade da saída, falhas das aplicações, latência, comportamento das políticas e o trabalho de engenharia necessário para cada mudança.

Uma troca fácil fortaleceria a posição da AWS. Isso mostraria que Bedrock e Superblocks podem separar aplicações de longa duração de ciclos mais curtos de modelos.

Falhas frequentes ou reescritas extensas de prompts enfraqueceriam o argumento de desacoplamento. Elas revelariam que o comportamento específico de cada modelo continua incorporado à lógica das aplicações, mesmo por trás de uma interface comum de nuvem.

Os compradores também devem examinar o mapa de dependências resultante. Substituir um modelo pode se tornar mais fácil, enquanto substituir AWS ou Superblocks pode se tornar mais difícil.

Essa troca não é automaticamente desfavorável. As empresas frequentemente aceitam a dependência de infraestrutura em troca de segurança, suporte e processos de aquisição consistentes.

No entanto, a decisão deve ser explícita. Uma implantação em nuvem privada oferece controle sobre localização e acesso, mas não garante portabilidade entre plataformas.

A parceria da AWS com a Superblocks é relevante porque coloca o valor duradouro do software de IA acima do próprio modelo. A aplicação, suas conexões de dados e sua governança podem sobreviver a qualquer modelo que tenha gerado o código inicialmente.

É para lá que a disputa entre Amazon e Google está caminhando. Os provedores de nuvem querem controlar o ambiente em que os modelos se transformam em sistemas empresariais responsáveis.

Para desenvolvedores e compradores corporativos, o próximo passo é prático: testar uma aplicação importada com políticas reais de segurança e, em seguida, substituir seu modelo. Os resultados revelarão se essa arquitetura realmente cria flexibilidade ou apenas transfere a dependência para outra camada.