Demitido pela Atlassian depois de 8 anos: a infraestrutura real por trás do Jira e o aviso sobre vibe coding

Um engenheiro foi demitido pela Atlassian depois de 8 anos. Em vez de desaparecer, ele gravou 40 minutos documentando cada sistema que construiu — e no final do vídeo, quase de passagem, soltou o aviso mais honesto sobre vibe coding que apareceu esse ano.

Se você está construindo coisas com IA hoje — agentes, automações, apps, sistemas internos — o que ele disse é diretamente para você.

"Vai ser interessante com todas essas apps codadas com vibe e apps assistidas à IA para ver como lidamos quando temos pessoas que não são realmente familiares com o que criaram e os problemas de manutenção aparecem. Eles não aparecem no começo." — Vasilios Syrakis, ex-engenheiro Atlassian

Por que esse relato importa (e não é sobre demissão)

Vasilios Syrakis trabalhou 8 anos na Atlassian como engenheiro de infraestrutura de plataforma. O layoff recente da empresa o afetou diretamente. O vídeo que ele gravou não é sobre o mercado de trabalho — é uma retrospectiva técnica honesta do que ele construiu: um sistema de edge centralizado que levou Jira, Confluence, Bitbucket e Status Page para trás de uma infraestrutura de proxies gerenciada pelo time de plataforma, com mais de 2.000 instâncias em 13 regiões da AWS.

Por que isso interessa para quem está construindo com IA? Porque o problema central que ele resolveu — e o aviso que ele deixou — é exatamente o problema que está sendo criado agora em escala, em milhares de empresas que estão usando IA para gerar código que ninguém entende completamente.

O problema que ele resolveu (e a lógica por trás)

Em 2016, a Atlassian tinha mais de mil times de desenvolvimento. Cada um precisava de autenticação, proteção contra DDoS, rate limiting e logs de acesso nos seus serviços. A pergunta era simples: isso deveria ser responsabilidade de cada time individualmente?

A resposta deles foi não — e o argumento não era técnico. Era organizacional:

• 1.000 times implementando autenticação individualmente = 1.000 implementações diferentes, com 1.000 padrões de erro diferentes
• Cada novo requisito de segurança precisaria ser propagado para 1.000 serviços
• O custo não aparece no código — aparece na velocidade de entrega e no custo de manutenção

A solução foi centralizar na plataforma: um único ponto de gestão de edge, onde autenticação, roteamento, proteção e logs acontecem antes de o request chegar em qualquer serviço de backend. O time de produto declara a intenção ("quero que meu serviço seja acessível publicamente, com autenticação por JWT"). A plataforma resolve o como.

Isso é o que método significa na prática: não a ferramenta que você escolheu, mas a lógica que centraliza decisões repetidas para que não precisem ser tomadas de novo.

O que foi construído em 4 anos (simplificado)

Para quem quer entender a estrutura sem precisar saber configurar o Envoy Proxy:

1. Broker de provisionamento: o desenvolvedor envia um pedido ("quero load balancing"). O sistema enfileira, executa em background (cria registros DNS, configurações de CDN, chamadas AWS) e confirma quando está pronto. Ninguém precisa abrir ticket para a equipe de plataforma.
2. Plano de controle: um servidor que combina contexto dinâmico (estado atual dos serviços) com templates de configuração para gerar automaticamente as regras de roteamento e proxy. Quando o estado muda, a configuração muda. Sem redeploy, sem downtime.
3. Infraestrutura imutável: as proxies nascem com tudo pré-instalado — segurança, logs, tracing, configuração de rede. No runtime, só recebem segredos e chaves. Instâncias que se configuram no momento de subir são imprevisíveis. Instâncias que nascem prontas são auditáveis.
4. Funcionalidades como módulos independentes: autenticação, autorização e rate limiting são containers separados, mantidos por times diferentes, que se plugam na proxy. Cada um tem seu ciclo de vida próprio, sem acoplar ao sistema central.

O resultado: 2.000+ proxies em 13 regiões, carregando todo o tráfego de Jira, Confluence e Bitbucket — com uma equipe pequena de plataforma.

O aviso sobre vibe coding que ninguém está dando

O trecho mais importante do vídeo acontece nos últimos 10 minutos, quando Vasilios fala sobre manutenção de longo prazo. E não é sobre código — é sobre pessoas.

Nos 8 anos que ele trabalhou lá, viu um padrão se repetir:

• Sistema é construído por um time com contexto completo
• Parte do time sai, o contexto tácito vai junto
• Novos membros chegam, olham para o código existente e querem mudar coisas sem entender o porquê das decisões originais
• Áreas específicas acumulam mudanças repetidas — o que ele chama de "áreas churrascadas": a concentração de complexidade que cresce até se tornar um problema estrutural

Os problemas de manutenção não aparecem no lançamento. Aparecem 2 ou 3 anos depois, quando quem construiu já saiu e o conhecimento que não foi documentado evaporou.

Agora multiplique isso por apps geradas por IA. Código que ninguém escreveu linha por linha. Sistemas que funcionam mas cuja lógica interna o autor não consegue explicar completamente. O ciclo de tentar, desistir e voltar para o Excel que já existe hoje vai ganhar uma nova camada: tentar, gerar com IA, colocar em produção, e não saber o que fazer quando quebrar 18 meses depois.

Método vs. ferramenta — o que isso muda para você

A infraestrutura que Vasilios construiu não é replicável pela maioria das pessoas lendo este texto. Não é esse o ponto.

O ponto é a lógica de decisão que estava por trás das escolhas:

• O que não precisa ser repetido, não deve ser. Toda vez que você resolve o mesmo problema duas vezes em contextos diferentes, você criou uma dívida que vai cobrar mais tarde. Centralizar não é sobre arquitetura — é sobre não multiplicar pontos de falha.
• Configuração como dado, não como código. O sistema dele funciona porque a lógica está nos templates, não hardcoded. Mudar comportamento = mudar dados, não redeploy. Quanto do que você está construindo hoje depende de redeploy para qualquer ajuste?
• Documentar o porquê, não o o quê. O código diz o que faz. O que desaparece quando as pessoas saem é o porquê — as decisões de design, as limitações conhecidas, os casos esperados de falha. Vasilios diz explicitamente que o maior aprendizado de manutenção foi entender que runbooks precisam existir antes de a pessoa que sabe sair.

Com IA gerando código cada vez mais rápido, a velocidade de criação aumentou. A capacidade de manutenção não acompanhou. Esse gap vai aparecer — e vai aparecer exatamente onde os agentes proativos de IA mais prometem simplificar: sistemas autônomos que ninguém entende completamente por dentro.

O que fazer com isso agora

Não é sobre parar de usar IA para gerar código. É sobre adicionar o que a maioria está pulando:

1. Documente a decisão, não o código. Para cada componente que você gerar com IA, escreva um parágrafo: "Escolhemos isso porque X. Sabemos que tem limitação Y. Se quebrar, verificar Z." Isso não precisa ser formal — precisa existir.
2. Teste o que você não escreveu. Código gerado por IA passa no teste que você escreveu para ele. Mas testa o comportamento de borda que você não pensou em testar? Manutenção começa nos casos que não foram previstos.
3. Identifique as "áreas churrascadas" antes de elas aparecerem. Qualquer parte do sistema que muda com frequência é candidata a acumular complexidade. Não espere o problema — sinalize a área e documente as invariantes que precisam ser preservadas.

A falta de método não é sobre usar ou não usar IA. É sobre o que você faz com o que foi gerado — e se alguém que não estava na sala quando foi criado consegue manter isso daqui a dois anos.

O que é Envoy Proxy e por que a Atlassian usou?

Envoy é um proxy open source criado pelo Lyft, hoje mantido pela CNCF (Cloud Native Computing Foundation). Funciona como um intermediário entre clientes e servidores backend, com suporte a configuração dinâmica via API — ou seja, você pode mudar as regras de roteamento, autenticação e rate limiting sem reiniciar o serviço. A Atlassian o escolheu para substituir load balancers enterprise com custo de licença e tornar a infraestrutura de edge autogerenciada pelos times de produto.

O que é platform engineering?

Platform engineering é a disciplina de construir ferramentas e infraestrutura interna para que times de produto consigam se autoatender — sem depender da equipe de plataforma para cada operação. O objetivo não é tecnologia bonita: é eliminar trabalho repetido em escala. Na prática, significa que um time de produto declara o que quer ("preciso de autenticação JWT no meu serviço") e a plataforma entrega o resultado sem que o time precise entender a implementação.

Por que os problemas de manutenção aparecem depois, e não no lançamento?

Porque no lançamento o sistema está com as pessoas que o construíram, que conhecem os casos de borda, as decisões de design e os pontos frágeis. Os problemas de manutenção aparecem quando esse conhecimento tácito sai — por rotatividade de equipe, crescimento do sistema além do escopo original, ou mudanças de requisito que ninguém documentou. Com código gerado por IA, esse gap é maior: o autor pode não ter entendido completamente o que foi gerado, então o conhecimento tácito nunca existiu de verdade.

Vibe coding é necessariamente ruim?

Não. O problema não é a velocidade de geração — é a ausência de método depois da geração. Código gerado rápido com IA pode ser excelente se vier acompanhado de documentação de decisões, testes de comportamento de borda e clareza sobre os invariantes do sistema. O aviso de Vasilios não é "não use IA para gerar código" — é "os problemas de manutenção não aparecem no começo, e você precisa estar preparado para eles".