Paved Road: como a Barte reduz fricção e acelera quem constrói

Todo time de engenharia que cresce esbarra no mesmo problema: cada squad resolvendo deploy, infraestrutura e configuração do seu próprio jeito. O resultado é energia gasta em decisões repetidas (qual biblioteca usar, como subir o serviço, onde guardar o secret) em vez de investir no que de fato diferencia o produto.

A resposta que adotamos na Barte tem nome: paved road, ou caminho pavimentado. A ideia é simples: oferecer o caminho mais fácil, rápido e seguro para as tarefas do dia a dia, sem obrigar ninguém a segui-lo. Quem está na estrada pavimentada anda mais rápido; quem precisa sair, sai, abrindo mão de algumas facilidades.

E tem um motivo a mais para começar por aqui: o paved road é também a base do que estamos construindo com IA. Os mesmos padrões e guardrails que aceleram as pessoas são o que permite colocar agentes autônomos para trabalhar com segurança. Mas isso é assunto para o fim do post.

O que é Paved Road

O termo “paved road” (caminho pavimentado), também chamado de “golden path” (caminho dourado), vem da engenharia de plataforma e descreve o caminho recomendado e bem suportado para realizar as tarefas mais comuns do dia a dia de quem desenvolve.

Na prática, é a forma mais fácil, rápida e segura de fazer algo que se repete o tempo todo: criar um novo serviço, fazer deploy, configurar infraestrutura, instrumentar observabilidade. Em vez de cada pessoa pesquisar, decidir e montar tudo do zero, ela segue um caminho que já incorpora as melhores práticas da organização.

Três características definem o conceito:

É opinativo. O paved road embute as escolhas e os padrões que a empresa já validou. Ele não pergunta “qual banco você quer usar?”: já vem com a resposta recomendada, porque alguém já pagou o custo de decidir.

Reduz fricção. Ele remove decisões repetitivas e complexidade desnecessária. O tempo que iria para configuração e boilerplate volta para o que importa: resolver o problema do produto.

Não é obrigatório. Esse é o ponto que mais gera confusão. Paved road não é uma jaula. Se um time precisa sair do caminho por uma razão legítima, ele pode. Só abre mão de algumas facilidades (templates prontos, suporte, automações) e assume mais responsabilidade. A estrada pavimentada é a opção padrão, não a única permitida.

O conceito não é invenção nossa. A Netflix popularizou o termo “paved road”, e o Spotify descreveu seus “golden paths” como forma de combater a fragmentação no ecossistema de software. A Barte adaptou a ideia ao seu contexto, e é disso que tratam as próximas seções.

Por que isso importa

Quando um time de engenharia é pequeno, a falta de padrão não dói. São poucas pessoas, todo mundo conhece todo mundo, e dá pra alinhar qualquer coisa numa conversa rápida. O problema aparece quando o time cresce.

Sem um caminho pavimentado, cada novo serviço vira uma ilha. Um time escolhe uma stack, outro escolhe outra. Um configura deploy de um jeito, o vizinho de outro. Cada decisão dessas parece pequena isolada, mas o custo se acumula:

Onboarding lento. Quem entra precisa aprender não um jeito de fazer as coisas, mas vários, e descobrir na marra qual vale para qual serviço.

Risco de segurança e compliance. Quando cada serviço trata secrets, scanning e configuração à sua maneira, garantir um padrão mínimo de segurança vira um esforço manual. E o que é manual escala mal e falha.

Manutenção cara. Diversidade sem propósito significa mais coisas para manter, atualizar e corrigir. Cada padrão a mais é uma superfície a mais de problema.

Esse é exatamente o momento da Barte: um time de engenharia crescendo e entregando rápido. Nesse cenário, padronizar deixa de ser burocracia e vira alavanca: é o que permite continuar acelerando sem que cada novo serviço aumente o caos. O paved road é a nossa forma de pagar esse custo uma vez, de forma centralizada, para que cada time não precise pagá-lo de novo.

Os princípios

Nosso paved road se apoia em cinco princípios que funcionam como critério de decisão: quando vamos construir ou mudar algo no caminho, é a esses princípios que recorremos.

Autonomia. Cada time é dono do ciclo de vida completo do seu serviço, do código ao deploy à operação. Isso significa deploy independente, sem depender de um time central para subir uma mudança, e liberdade para tomar decisões técnicas dentro do escopo do serviço. O paved road não tira autonomia. Pelo contrário: dá um caminho confiável para exercê-la com segurança. Como exemplo podemos citar nosso monolito (que pode ser papo para outro post): praticamente todos os times acabam subindo alterações e fazendo deploy. Nenhum deploy precisa de envolvimento do time de infra ou de qualquer outro time. Quem está propondo a alteração tem autonomia para efetuar o deploy.

Padronização. Templates compartilhados, conventions over configuration e uma stack única e bem definida. A ideia é que o padrão certo seja também o caminho mais fácil: você não precisa lembrar de configurar a coisa certa, porque ela já vem configurada. Assim, a criatividade sobra para onde realmente importa, em vez de se gastar em tarefa repetitiva. O repositório de template já possui todas as configurações necessárias para subir uma nova aplicação do zero em minutos. Alguns recursos: migrations, testes (com TestContainers), coverage, Datadog (logs, traces, métricas etc.), infra com Terraform (ECS, Lambda, EC2 etc.) e fluxo de CI/CD, entre outros. Lembrando que nossa stack core é Kotlin + Spring Boot.

Simplicidade. A meta é zero-config para 80% dos casos. Menos camadas, mais pragmatismo. Temos até uma régua interna: “se precisa de diagrama pra explicar, está complexo demais”. Complexidade só se justifica quando paga por si mesma. O resto é fricção disfarçada.

Segurança by default. Segurança não pode ser um passo opcional no fim. No paved road ela vem embutida: secrets management obrigatório, security scanning automático e compliance built-in. Quem segue o caminho está seguro por padrão, sem precisar virar especialista em segurança para isso. Um exemplo real é o fluxo de code scan que roda automaticamente a cada novo PR aberto (utilizando o SonarCloud). Além disso, temos um fluxo de review automático com IA que já busca por possíveis brechas de segurança no código.

Developer Experience. Tudo isso existe para uma experiência fluida: Clone → Code → Push → Deploy. Ambiente local que funciona de verdade e documentação clara e acessível. Quando o caminho certo é também o mais agradável de percorrer, as pessoas o seguem por vontade própria. É aí que a padronização deixa de precisar ser imposta.

Como o Paved Road se materializa na Barte

Princípios só valem se viram ferramenta concreta. Na Barte, o paved road é um conjunto de peças que o time usa no dia a dia, cada uma cuidando de um pedaço do caminho. Aqui vai o mapa; cada peça vai virar um post próprio nesta série, com o detalhe de como construímos e por quê.

Application Template. O ponto de partida de qualquer serviço novo. Em vez de montar a estrutura do zero, você começa de um template que já vem com os padrões, configurações e integrações certas. Clone e comece a resolver o problema, não a configurar.

Terraform. Infraestrutura como código, versionada e padronizada. O provisionamento deixa de ser um passo manual e propenso a erro e passa a seguir o mesmo caminho previsível para todos os times.

Deploy. O processo de levar código à produção de forma independente e segura. É aqui que a autonomia dos times encontra a segurança by default.

Observabilidade. Instrumentação que já vem embutida, para que entender o que está acontecendo em produção não seja um esforço extra montado depois, e sim parte do caminho.

SonarCloud. Qualidade de código de forma automática e contínua, integrada ao fluxo de quem desenvolve. Em tempos de IA no desenvolvimento, o Sonar se tornou peça fundamental na análise estática de código, visando garantir uma maior qualidade do código gerado.

Code Review AI. Uso de IA para apoiar e acelerar o code review, mantendo o padrão sem virar gargalo humano.

DORA Metrics. As métricas que nos dizem se tudo isso está realmente funcionando: frequência de deploy, lead time, taxa de falha e tempo de recuperação. É como medimos se o caminho está, de fato, pavimentado.

Cada uma dessas peças tem uma história própria de decisão e trade-off, e é isso que vamos abrir nos próximos posts.

O que muda na prática

O resultado de um paved road bem feito não aparece num lugar só. Aparece na velocidade e na tranquilidade do time como um todo.

Um serviço novo sai do zero ao ar em uma fração do tempo, porque o template, a infra e o deploy já vêm resolvidos. Quem entra na empresa fica produtivo mais rápido, já que existe um caminho claro a seguir em vez de uma coleção de exceções para decorar. E segurança, observabilidade e qualidade deixam de depender da memória de cada pessoa: vêm de fábrica.

O ganho mais importante, porém, está em onde a energia do time passa a ser gasta: menos em encanamento, mais no que diferencia o produto. É esse o objetivo do caminho pavimentado: deixar o trabalho repetitivo no automático para sobrar tempo no que importa.

Quem mantém o Paved Road

Aqui vale uma confissão que talvez surpreenda: não temos um time de plataforma dedicado. Não há um squad cujo trabalho seja cuidar do paved road em tempo integral.

O caminho foi criado e vem sendo mantido pelos engenheiros mais seniores do time, no meio do trabalho de produto. E isso é uma escolha, não uma limitação que estamos esperando resolver. Acreditamos em times de engenharia enxutos e em fazer o paved road crescer como uma comunidade interna: quem usa o caminho também ajuda a pavimentá-lo. Quando alguém resolve um problema que vale para todos, esse aprendizado volta para o template, para a documentação, para o padrão.

Isso tem um efeito interessante. Como ninguém é “dono exclusivo” do caminho, ninguém o trata como caixa-preta de outro time. O paved road é de todos, e a régua da simplicidade ajuda a mantê-lo sustentável mesmo sem uma equipe full-time por trás. Um caminho que poucos conseguem manter é, por definição, complexo demais.

Não é o modelo certo para toda empresa, e pode mudar conforme crescermos. Mas, no nosso momento, é o que mantém o equilíbrio entre padronização e um time leve.

O Paved Road como fundação para IA

Há um motivo a mais, e talvez o mais estratégico, para investir tanto nesse caminho: o paved road é a fundação do que estamos construindo com IA.

Agentes autônomos só são seguros dentro de limites claros. Eles precisam de guardrails: padrões previsíveis, ambientes consistentes, validações automáticas, segurança embutida. É exatamente o que um paved road bem feito já oferece. Quando o caminho é padronizado, um agente que cria um serviço, abre um PR ou ajusta uma configuração opera dentro de trilhos conhecidos, com as mesmas verificações de qualidade e segurança que aplicamos a um humano.

Ou seja: o mesmo esforço que pavimenta o caminho para as pessoas é o que o torna seguro para as máquinas. Sem essa base, “IA autônoma na engenharia” seria uma aposta arriscada. Com ela, vira extensão natural do que já fazemos.

Como isso funciona na prática, e o que já estamos construindo com agentes, é papo para um próximo post da série.

Conclusão

Paved road, para a Barte, é tanto cultura quanto tecnologia: a aposta de que padronizar bem é o que dá liberdade para ir rápido. É assim que vivemos o Tech Driven na prática, e é a base sobre a qual construímos desde um novo serviço até nossos primeiros agentes de IA.

Nos próximos posts desta série vamos abrir cada peça desse caminho por dentro: Application Template, Terraform, Deploy, observabilidade, métricas e mais.

E se construir esse tipo de coisa te anima, vale conhecer a Barte: estamos crescendo o time. Confira as vagas: vagas.barte.io