# Dev x Arquiteto de Software: as diferenças

> Published 2026-10-11T02:08:03.078Z on https://www.crazystack.com.br/pt/p/dev-x-arquiteto-de-software-as-diferencas/
> Source video: https://www.youtube.com/watch?v=Mkifn-_dD_8

Dev x arquiteto de software se resolvem em três palavras: system design, tradeoffs e impacto. O arquiteto entende escalabilidade, mensageria e o teorema de CAP, e usa esse repertório para tomar decisões que o dev que só executa não enxerga.

## O que separa um dev de um arquiteto de software

Três pontos separam um dev de um arquiteto de software: domínio de system design, compreensão de tradeoffs e visão de impacto no negócio. O arquiteto não escreve mais código que o dev; ele decide como o sistema deve funcionar antes que qualquer linha seja escrita.

Essa distinção vem de Felipe Rocha, do canal Full Stack Club, em vídeo publicado em outubro de 2026. O argumento central é direto: com a inteligência artificial escrevendo código cada vez melhor, a execução pura perde valor de mercado, enquanto a decisão arquitetural continua sendo humana.

A comparação fica mais clara lado a lado:

## Dev ou arquiteto: comparativo rápido

| Dimensão | Dev | Arquiteto de software |
| --- | --- | --- |
| Foco diário | Implementar tarefas e features | Projetar o sistema como um todo |
| System design | Conhecimento pontual | Escalabilidade, mensageria, teorema de CAP |
| Tradeoffs | Enxerga a solução, não o preço dela | Pesa leitura x escrita, consistência x disponibilidade |
| Decisão | Executa o que foi pedido | Questiona e orienta stakeholders antes de codar |
| Exposição à IA | Código gerado por IA substitui execução simples | IA não arquiteta; decisão continua humana |

As próximas seções destrincham cada um desses pontos com os conceitos que o vídeo recomenda estudar.

## System design: o repertório que define o arquiteto

System design é o primeiro divisor de águas. O arquiteto entende escalabilidade horizontal e vertical, sabe o que faz um load balancer, conhece os tipos de índices de banco de dados e decide quando usar um banco relacional ou não relacional.

Ele também sabe quando plugar mensageria, e principalmente quando não plugar. Toda fila introduz problemas novos, como o dual write, em que você grava no banco e na fila e os dois lados podem dessincronizar. Saber lidar com esse cenário faz parte do repertório.

Outro pilar citado é o [teorema de CAP](https://en.wikipedia.org/wiki/CAP_theorem), que afirma que um sistema distribuído não consegue garantir consistência, disponibilidade e tolerância a partição ao mesmo tempo. Priorizar consistência custa disponibilidade, e o contrário também vale. O arquiteto escolhe conscientemente qual sacrifício o negócio pode pagar.

Se você não domina esses conceitos, o caminho indicado é leitura lenta e anotada, sem pressa de terminar.

## Tradeoffs: toda solução tem um preço

Tradeoff é o preço que você paga por uma solução. Na engenharia de software, tudo que você ganha em um ponto você paga em outro, e o arquiteto enxerga esse preço antes de decidir.

O exemplo clássico é o índice no banco de dados. Ele acelera consultas porque cria uma estrutura adicional, mas toda escrita precisa atualizar essa estrutura. Quanto mais índices, mais lenta tende a ser a escrita. Mesma lógica vale para disponibilidade contra consistência no teorema de CAP.

O que impede um dev de enxergar tradeoffs é falta de repertório. Quem não entende a fundo como um índice funciona não consegue pesar o custo dele. O resultado é uma pilha de ferramentas caras, lentas e que às vezes nem resolvem o problema.

A citação original atribuída a Francis Bacon resume bem: conhecimento é poder, e aqui ele é poder de decisão.

## Impacto no negócio: código é meio, não fim

O terceiro divisor é pensar em impacto, e não só em código. Todo dev passa pela fase de receber a tarefa e resolvê-la sem questionar, e isso é esperado no início da carreira.

O arquiteto faz diferente. Se o time de produto propõe uma feature de engajamento que vai deixar o sistema mais lento, ele sinaliza: o aumento do tempo médio de resposta pode derrubar a retenção e produzir o efeito contrário. Ele leva esse risco aos stakeholders antes de implementar.

A tese do vídeo é provocativa: empresas não pagam você para escrever código, pagam para resolver problemas. O código, inclusive o gerado por IA, é apenas o meio. Quem entende isso deixa de ser executor e passa a influenciar o produto.

## Como estudar: os livros recomendados

O caminho de estudo passa por dois livros. O primeiro é [Designing Data-Intensive Applications](https://dataintensive.net/), de Martin Kleppmann, publicado em 2017. É denso e recomendado como primeira leitura de arquitetura: leia com papel e caneta, durante meses, e mantenha por perto para consultar sempre.

O segundo é a série System Design Interview, de Alex Xu, reunida no site [ByteByteGo](https://bytebytego.com/). O autor arquiteta junto com o leitor projetos que caem muito em entrevistas de system design, comuns em processos para vagas sênior e tech lead.

O ideal é combinar leitura com prática: pegue um sistema que você conhece, identifique os tradeoffs dele e pergunte o que faria diferente.

## Perguntas frequentes

- **Dev ganha mais ou arquiteto de software?** Arquitetos de software tendem a ganhar mais, como aponta o vídeo de forma direta. O motivo é o tipo de decisão envolvida: quem define arquitetura assume responsabilidade sobre escalabilidade, custo e resultado do produto, não só sobre a entrega de uma tarefa.

- **A inteligência artificial vai substituir o desenvolvedor?** A tese do vídeo é que a IA substitui a execução pura de código, não a decisão arquitetural. Quem entende tradeoffs, system design e impacto no negócio usa a IA como ferramenta e continua relevante.

- **Por onde começar a estudar arquitetura de software?** Comece por Designing Data-Intensive Applications, lendo sem pressa e anotando. Depois parta para a série System Design Interview, que simula problemas reais de entrevistas. Conceitos como teorema de CAP e índices de banco devem ficar sólidos no caminho.

- **O que é um tradeoff em engenharia de software?** É o preço que você paga por uma solução. Mais disponibilidade pode custar consistência; um índice compra leitura rápida e paga com escrita mais lenta. Toda escolha técnica sacrifica algo, e o arquiteto é quem enxerga esse sacrifício antes de decidir.

- **Preciso deixar de programar para virar arquiteto?** Não. O arquiteto arquiteta aplicações, mas continua próximo do código. A mudança é de postura: antes de escrever, você passa a questionar requisitos, antecipar gargalos e conversar com o time de produto sobre consequências técnicas.

## Transforme seus vídeos em artigos com Skala Blog

A ideia central deste artigo é que o valor está em transformar conhecimento falado em repertório estruturado. Se você tem explicações, opiniões ou aulas gravadas em vídeos no YouTube, esse conteúdo pode virar um artigo de verdade, com estrutura, títulos e respostas diretas.

O fluxo é simples: você cola a URL do vídeo no [Skala Blog](https://skalablog.com), a ferramenta transcreve o vídeo e gera um artigo pronto para revisar e publicar. Seu conhecimento deixa de viver só em vídeo e passa a alcançar quem busca respostas escritas.

[Source video](https://www.youtube.com/watch?v=Mkifn-_dD_8)