Princípios de engenharia na Barte: menos controle, mais direção

Todo time de engenharia que cresce passa pelo mesmo momento: as discussões começam a se repetir. Qual stack usar no serviço novo? Pode resolver esse fluxo numa ferramenta no-code? De quem é esse domínio? Preciso do outro time, mas ele não vai priorizar — e agora? Cada uma dessas conversas parece razoável isolada. O problema é quando elas voltam toda semana, em squads diferentes, com desfechos diferentes.

Existem duas respostas clássicas de gestão para isso. A primeira é centralizar o controle: comitês de arquitetura, aprovações em cadeia, alguém que precisa dar o “ok” antes de qualquer decisão. Funciona até certo ponto, mas cria gargalo e ensina o time a esperar em vez de decidir. A segunda é não responder nada e deixar cada time resolver do seu jeito. Também funciona até certo ponto — até o dia em que você percebe que tem cinco stacks, três ferramentas de deploy e lógica de negócio espalhada em lugares que ninguém audita.

Na Barte escolhemos um terceiro caminho: tornar os trade-offs explícitos. Em vez de aprovar decisões uma a uma, decidimos uma vez, por escrito, e deixamos o time decidir o resto sozinho.

O que é um princípio para nós

Princípio, no nosso vocabulário, não é frase de parede. É um trade-off que o time já discutiu, já decidiu e documentou — para que ninguém precise revisitar a mesma discussão em loop.

Dois detalhes fazem diferença na forma como escrevemos os nossos:

Princípio descreve o caminho, não a foto de hoje. Nossos documentos deixam isso explícito: o que está ali não necessariamente reflete a realidade atual, mas o rumo que vamos seguir a partir de agora. Isso tira o peso de “mas o sistema X ainda não é assim” e transforma o princípio em direção, não em auditoria.

Princípio existe para multiplicar decisões, não para restringi-las. Um time de engenharia toma milhares de microdecisões por dia. Nenhuma estrutura de gestão consegue (nem deveria) participar de todas. O que a gestão pode fazer é dar critério: se a direção está clara e os trade-offs estão explícitos, cada pessoa decide com autonomia — e as decisões saem consistentes sem ninguém precisar conferir uma a uma.

A metáfora que usamos internamente é a da mochila leve: cada tecnologia extra, cada ferramenta fora do padrão, cada dependência entre times é peso na mochila da organização. Dá para carregar, mas custa velocidade. Os princípios são a nossa forma de decidir, de caso pensado, o que entra na mochila.

Os três princípios que escolhemos

1. Stack unificada

Temos uma stack padrão, e ela é a escolha default para qualquer serviço, aplicação ou componente novo: Kotlin com Spring Boot no backend; Next.js com TypeScript e nosso design system no frontend; AWS como cloud; Terraform para infraestrutura; GitHub Actions para CI/CD; Datadog para observabilidade.

Sair da stack não é proibido — é exceção. Exige justificativa técnica clara, registrada via RFC, e vem com uma regra que muda o jogo: quem escolhe sair assume o custo. O time que adota algo fora do padrão fica responsável por operar, manter e dar suporte àquilo. Não introduzimos linguagem, framework ou banco novo por preferência pessoal.

O racional é organizacional, não tecnológico. Stack unificada reduz carga cognitiva, simplifica contratação e onboarding, baixa o custo de segurança e operação — e, como veremos adiante, é o que torna viável tanto a colaboração entre times quanto o uso de IA em escala. Tecnologia é meio, não fim.

2. Sem no-code/low-code no core

Não usamos ferramentas de no-code/low-code para domínio e funcionalidades core: transações, saldo, repasse, estorno, operações bancárias. Nem como MVP.

A régua para decidir é uma pergunta só: “se isso quebrar ou vazar, o cliente ou a Barte são afetados diretamente?” Se a resposta for sim, vai para a stack de tech. No-code continua tendo lugar — sites institucionais, comunicações não-críticas, automações internas de apoio — mas nunca no caminho do dinheiro ou dos dados de cliente.

O racional: lógica core espalhada em ferramentas externas é difícil de versionar, testar, monitorar, auditar e operar em produção. E MVP não é desculpa — um MVP em no-code que toca domínio core vira dívida e ponto cego de segurança no minuto em que vai pra produção. Preferimos prototipar e iterar dentro da nossa stack.

3. Inner source: comunidade interna ativa

Qualquer time pode enviar PRs para repositórios de outros times. O time dono continua 100% responsável pela direção, pelos padrões e pela operação — e é quem aceita ou rejeita contribuições. Quando você precisa de algo no domínio de outro time e ele não consegue priorizar, o caminho não é esperar na fila: é contribuir.

Aqui tem uma nuance importante: inner source é o plano B. O plano A é eliminar dependências entre times — via arquitetura, transferência de domínio ou reorganização. O inner source entra quando essa eliminação não é possível, e funciona porque a stack é unificada: contribuir no repositório de outro time é fácil quando a stack é a mesma que a sua.

Princípios não vivem sozinhos

Um erro comum é tratar princípios como um documento isolado. Os nossos só funcionam porque se apoiam num ecossistema que os torna práticos — e é aqui que as peças se conectam.

O paved road é o princípio virando ferramenta. De nada adianta declarar “stack unificada” se seguir o padrão der mais trabalho que sair dele. Nosso paved road inverte essa conta: template de aplicação que sobe serviço novo em minutos, Terraform pronto, deploy independente, observabilidade e segurança embutidas. O padrão certo é também o caminho mais fácil — e aí ninguém precisa ser convencido a segui-lo.

A suíte de testes é o que torna a autonomia segura. Deploy independente e decisão descentralizada só funcionam se existir uma rede de proteção automática. Já escrevemos sobre isso: a IA tornou o código barato, mas a confiança continua cara — e a suíte de testes é o que sustenta essa confiança, para humanos e para agentes.

Observabilidade e gestão de incidentes fecham o ciclo. Autonomia sem visibilidade é abandono. Todo serviço no paved road já nasce instrumentado (OpenTelemetry + Datadog, logs correlacionados com traces), e a resposta a incidentes segue um processo único, com papéis claros e postmortem blameless. A mensagem para o time é coerente: você tem autonomia para decidir e fazer deploy — e tem as ferramentas e o processo para operar o que decidiu.

E a IA é o multiplicador de tudo isso. Essa talvez seja a consequência mais estratégica dos princípios. Agentes de código funcionam melhor dentro de limites claros: uma stack previsível, padrões consistentes, validações automáticas, testes confiáveis. Um agente que abre PR num repositório da Barte encontra a mesma estrutura em qualquer time — mesma stack, mesmo CI, mesma régua de qualidade. Princípios explícitos são, na prática, o contexto que damos para as máquinas. Um time com cinco stacks e lógica espalhada em ferramentas no-code não consegue colocar agentes para trabalhar com segurança; um time com mochila leve, consegue.

O que isso muda na gestão

Princípios explícitos mudam o trabalho de gestão de lugar. Em vez de aprovar decisões, a gestão passa a manter o critério das decisões — escrever, revisar e evoluir os princípios conforme o contexto muda. O gestor deixa de ser gargalo de aprovação e vira editor de contexto.

Isso aparece em coisas concretas. O onboarding encurta: quem chega lê os princípios na primeira semana e entende não só o que usamos, mas por que — em vez de descobrir as regras na marra, PR rejeitado a PR rejeitado. As discussões técnicas sobem de nível: ninguém gasta reunião debatendo qual framework usar; o debate acontece uma vez, vira RFC e vira princípio. E as exceções ficam visíveis: como sair do padrão exige registro, a organização sabe exatamente onde e por que está carregando peso extra na mochila.

E tem um efeito que só aparece com o tempo: princípios são a forma como planejamos o futuro. A visão de produto diz para onde a Barte vai — novos domínios, novos volumes, novos mercados. Os princípios traduzem essa visão em direção de engenharia: se sabemos o que vem, escrevemos hoje os critérios que vão decidir bem amanhã. Foi assim com IA — stack unificada e paved road existiam antes de agentes de código serem realidade, e quando eles chegaram, a casa já estava pronta. Planejar o futuro da engenharia, para nós, é menos prever tecnologia e mais garantir que as mil decisões de amanhã já tenham critério.

Nada disso é estático. Princípio que não pode ser revisado vira dogma, e dogma é só controle centralizado com outro nome. A regra do jogo é: seguir o princípio é grátis, questioná-lo é bem-vindo, ignorá-lo silenciosamente é que não dá.

Conclusão

A pergunta que os princípios respondem não é “como controlamos o que o time faz?”, e sim “como garantimos que mil decisões por dia, tomadas por pessoas diferentes, apontem para o mesmo lugar?”. Nossa resposta: decidir os trade-offs grandes uma vez, por escrito, e construir o ecossistema — paved road, testes, observabilidade, IA — que torna o caminho decidido também o caminho mais fácil.

Menos controle, mais direção. É assim que tentamos escalar engenharia sem escalar burocracia.

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