A eSimphony é construída por uma equipa de engenharia de cinco pessoas. O produto cobre mais de 150 países, tem apps nativas para iOS e Android, corre uma pilha de integrações com operadores em várias regiões, suporta cinco idiomas de ponta a ponta e lança alterações de produto todas as semanas. Não somos uma operadora com mil funcionários. Somos uma equipa pequena a operar com alavancagem deliberada.

Essa alavancagem vem de uma abordagem específica à engenharia que interiorizámos nos últimos 18 meses. Chamamos-lhe desenvolvimento AI-native. É isto que significa na prática.

O formato da equipa

Cinco engenheiros. Um designer de produto. Um CEO que ainda escreve algumas das especificações de produto. Sem gestor de produto formal — as especificações saem do CEO, com apoio da Moza na redação e com o critério da engenharia. Sem equipa de QA dedicada — testar faz parte do ciclo de construção. Sem DevOps à parte — a infraestrutura pertence a quem entrega a funcionalidade.

Isto não é uma bravata. É uma restrição. Com uma equipa deste tamanho, a única forma de entregar um produto com o âmbito da eSimphony é multiplicar a produção de cada engenheiro. A IA é o multiplicador em que apostámos.

O fluxo de trabalho em cinco etapas

Todas as alterações na eSimphony — de uma correção de texto a uma nova integração com um operador — passam pelas mesmas cinco etapas. Cada etapa é assistida por IA; cada etapa tem um humano no circuito.

1. Descobrir (sem barreiras técnicas)

Quando chega um requisito novo ("precisamos de integrar o operador X para cobrir o Egito"), o primeiro passo do engenheiro não é assumir aquilo que não sabe. É usar IA para explorar o território desconhecido em 20 minutos em vez de 2 dias.

Na prática: um engenheiro que nunca integrou um MVNO egípcio pode dar a documentação da API do operador a um assistente de IA, receber um resumo estruturado da superfície de integração, fazer perguntas de seguimento sobre casos-limite ("qual é o fluxo típico de eKYC neste mercado?") e produzir uma avaliação de uma página com esforço, riscos e incógnitas antes do almoço.

O que muda: o estrangulamento deixa de ser "temos algum engenheiro que domine este domínio?" e passa a ser "o engenheiro que temos, aumentado por IA, consegue ficar suficientemente competente neste domínio em poucas horas?". Quase sempre, sim.

2. Especificar (horas, não semanas)

A maioria das especificações de produto, na maioria das empresas, leva de 1 a 3 semanas: um PM escreve, os intervenientes revêem, acrescentam-se casos-limite, afinam-se critérios de aceitação e depois a engenharia volta a dimensionar o trabalho. Quando a especificação está "pronta", a oportunidade original já mudou.

A nossa abordagem: o engenheiro (ou o CEO, consoante a funcionalidade) escreve uma ideia de produto numa linha. A IA expande-a num PRD estruturado — fluxo do utilizador, casos-limite, métricas de sucesso, critérios de aceitação, questões em aberto. A equipa afina numa sessão de trabalho de 45 minutos. A especificação segue para a engenharia no mesmo dia.

O compromisso: as especificações que saem deste processo são um pouco mais toscas do que uma especificação tradicional de duas semanas liderada por um PM. Aceitamos isso. A compressão do tempo até à primeira implementação vale a ambiguidade adicional, que se resolve durante a construção e não antes dela.

3. Desenhar (ciclo rápido de feedback)

Nas funcionalidades com componente visual significativa, o nosso designer trabalha ao lado do engenheiro num ciclo de "desenhar-construir-avaliar" medido em minutos, não em dias. Os mockups gerados por IA (plugins do Figma mais geradores de imagem) exploram variantes depressa. O engenheiro entrega um protótipo em poucas horas. O designer avalia em hardware real. A iteração mede-se em ciclos do mesmo dia.

O resultado é que design e engenharia não são sequenciais — são simultâneos. Quando o desenho está "final", a implementação já está quase pronta para produção.

4. Construir (a IA escreve o código; os humanos revêem todos os diffs)

Esta é a parte AI-native mais visível. O processo de engenharia na eSimphony, hoje:

A IA gera cerca de 90% do código novo (Cursor, Claude, GitHub Copilot, muitas vezes em combinação)
Os engenheiros escrevem as decisões de arquitetura, as fronteiras de integração e a lógica de negócio complicada, que exige conhecimento profundo do sistema
100% do código é revisto por humanos antes do merge. Todos os diffs. Todos os PR. Sem exceções.

Este último ponto é crítico e muitas vezes mal compreendido. "A IA escreve o código" não quer dizer "nenhum humano olha para o código". Quer dizer que o papel do engenheiro passa de escrever implementação a rever implementação. O trabalho cognitivo — isto corresponde à especificação, cobre os casos-limite, encaixa na arquitetura, escala? — continua a ser do engenheiro. O trabalho mecânico — traduzir intenção em código sintaticamente correto e idiomático — é delegado.

Um PR típico na eSimphony tem:

200 a 800 linhas de código alteradas (contra as habituais 100 a 200 nas equipas de 2024)
1 engenheiro a rever em detalhe
Muitas vezes testes unitários gerados por IA, com mais de 80% de cobertura no código novo
Comentários do revisor focados na arquitetura, não na sintaxe

5. Entregar (adaptar em minutos)

A entrega é gradual: feature flags para alterações arriscadas, deployments canário para os serviços de backend e telemetria monitorizada por IA que faz emergir anomalias poucos minutos depois do rollout. Quando uma entrega parte alguma coisa, o rollback mede-se em minutos, não em horas.

A parte da "telemetria monitorizada por IA" merece uma frase: depois do deploy, um agente de IA vigia anomalias em taxas de erro, latência, problemas reportados por utilizadores e conversão. Quando as anomalias passam um limiar, o engenheiro de prevenção é chamado com um resumo das causas prováveis. Isto comprime o tempo de deteção de "um utilizador reporta um erro às 9h" para "o alerta dispara às 09:03".

Os números

Métricas aproximadas dos últimos 12 meses:

Ciclo de sprint: 1 semana. As funcionalidades novas saem semanalmente; as correções pequenas saem diariamente.
5 engenheiros a tempo inteiro no produto. Mais um engenheiro em regime parcial.
Mais de 90% do código novo é gerado por IA (sobretudo Cursor e Claude).
100% do código integrado foi revisto por humanos.
Tempo mediano da especificação à produção: 5 a 10 dias.
Incidentes em produção por trimestre: 1 a 2. Abaixo da média da indústria para o nosso âmbito.
Pedidos de apoio escalados para a engenharia: cerca de 5 por semana. A maioria resolve-se no próprio dia.

Estes números não são teóricos. São o ritmo real de funcionamento da nossa equipa.

O que isto não é

Vale a pena ser explícito sobre o que o desenvolvimento AI-native na eSimphony não significa.

Não é "vibe coding". O código é revisto linha a linha. As decisões de arquitetura são tomadas por humanos. A IA acelera a escrita, não o pensamento.

Não é "sem testes". Os testes gerados por IA têm fraquezas específicas (tendem a testar melhor os caminhos felizes do que os casos-limite), por isso os engenheiros acrescentam testes escritos à mão para as extremidades. A cobertura de testes anda consistentemente acima dos 80% no código novo.

Não é "não são precisos engenheiros seniores". Pelo contrário. A IA aumenta drasticamente o valor do critério sénior, porque um engenheiro sénior consegue rever e afinar o resultado da IA 5 a 10× mais depressa do que o escreveria de raiz. Os engenheiros juniores que usam IA sem revisão sénior tendem a produzir código que compila mas é estruturalmente frágil.

Não é "sem pensamento de design ou de produto". A IA é inútil sem especificações claras e fluxos de utilizador bem pensados. O trabalho cognitivo de "o que devemos construir, porquê e para quem" continua a ser humano.

O que isto exige

Três coisas, por ordem de importância.

1. Revisão humana a sério

Cada linha de código gerado por IA passa pela revisão de um engenheiro sénior antes do merge. A tentação de saltar a revisão em pequenas alterações "obviamente corretas" é real e perigosa. Temos mantido a linha nos 100% de revisão.

2. Guarda-corpos de arquitetura apertados

Quando a IA gera código, segue as convenções locais. Convenções fortes = resultados fortes da IA. Investimos muito em fronteiras de módulo claras, nomenclatura consistente, interfaces bem tipadas e documentação explícita do "como se fazem as coisas aqui", para que a IA consiga reconhecer padrões com clareza.

3. Aceitação cultural da IA como opção por omissão

A equipa acordou, de forma explícita, que a assistência de IA é a norma em todos os fluxos de trabalho. Os engenheiros novos entram já com essa norma. As objeções ("mas eu prefiro escrever eu") são ouvidas e discutidas, mas a norma da equipa é que a IA trata do trabalho mecânico, a não ser que haja uma razão específica para não tratar.

Aquilo para que não usamos IA

Rever código gerado por IA (queremos olhos humanos frescos)
Decidir o que construir (a estratégia de produto é humana)
Escalamentos diretos de apoio ao cliente (os casos difíceis são para humanos)
Avaliações de desempenho e feedback à equipa (só humanos)
Decisões de contratação (só humanas, com IA a apoiar na pesquisa e na triagem)

O padrão: a IA aumenta a execução; os humanos são donos das decisões.

Porque é que isto importa para o produto

O resultado deste fluxo de trabalho vê-se no produto. Já entregámos:

A arquitetura do eSIM vitalício (um projeto de vários trimestres na maioria das empresas)
A Moza, a companheira de viagem com IA, em cinco idiomas
Os Planos Dinâmicos com IA em três regiões
O diagnóstico com IA com autorreparação
Apps nativas para iOS e Android com lançamentos semanais
Backend multirregião com mais de 99,9% de disponibilidade
Localização em 5 idiomas em toda a superfície do produto

Esta lista exige normalmente 30 a 50 engenheiros e mais de 3 anos. Nós entregámo-la com 5 engenheiros em 18 meses.

Uma nota sobre recrutamento

Estamos a fazer crescer a equipa com cuidado. Os engenheiros que se dão bem aqui partilham três traços:

Critério acima de volume. A IA trata da escrita; queremos engenheiros que sejam excelentes a rever, a decidir e a dar forma.
À vontade com a IA como colega. Engenheiros que tratam a IA como um par (delegam nela, revêem-na, contestam-na) em vez de a verem como oráculo mágico ou como ameaça à sua identidade.
Preocupação com o utilizador. Os fluxos AI-native são rápidos o suficiente para produzir muito código que compila mas não interessa. Os engenheiros que conseguem ancorar cada PR em "isto ajuda o utilizador?" fazem o melhor trabalho.

Se é o seu caso, estamos a contratar. Fale connosco pela página de carreiras ou escreva diretamente ao Trung.

O que vem a seguir

O mesmo fluxo de trabalho que construiu o produto atual está a entregar o roteiro:

Gestão de vários eSIM (maio de 2026)
Planos de família (junho de 2026)
Fidelização e recompensas (agosto de 2026)
Cobertura direta com operadores em todo o mundo (2027)

Cada uma destas coisas é um projeto de vários meses numa operadora tradicional. As nossas estimativas internas apontam para que as quatro saiam a horas, com a mesma equipa de cinco pessoas.

É essa a alavancagem. É essa a aposta. É assim que uma equipa pequena entrega contra a inércia de uma indústria inteira.

Veja a eSimphony em ação, leia sobre o nosso posicionamento ou consulte a nossa apresentação do MVNO Nation Americas.

Como uma equipa de 5 pessoas entrega a 10×: engenharia AI-native