Jak 5-osobowy zespół dowozi 10×: inżynieria AI-native w eSimphony

eSimphony buduje pięcioosobowy zespół inżynierski. Produkt obejmuje ponad 150 krajów, ma natywne aplikacje na iOS i Androida, działa na wieloregionowym stosie integracji operatorskich, obsługuje pięć języków od początku do końca i wypuszcza zmiany co tydzień. Nie jesteśmy tysiącosobowym telekomem. Jesteśmy małym zespołem, który świadomie gra dźwignią.

Ta dźwignia bierze się z konkretnego podejścia do inżynierii, które zinternalizowaliśmy przez ostatnie 18 miesięcy. Nazywamy je rozwojem AI-native. Tak to wygląda w praktyce.

Kształt zespołu

Pięcioro inżynierów. Jeden product designer. Jeden CEO, który wciąż sam pisze część specyfikacji produktowych. Żadnego formalnego product managera — specyfikacje powstają z połączenia CEO, szkicowania wspieranego przez Mozę i inżynierskiego osądu. Żadnego wydzielonego zespołu QA — testowanie jest częścią pętli budowania. Żadnego osobnego DevOps — infrastrukturą zarządza ten, kto dowozi daną funkcję.

To nie przechwałka. To ograniczenie. Przy takiej wielkości zespołu jedynym sposobem, żeby dowieźć produkt o zakresie eSimphony, jest zwielokrotnienie wyniku każdej osoby. AI to mnożnik, na który postawiliśmy.

Pięcioetapowy przepływ pracy

Każda zmiana w eSimphony — od poprawki w tekście po nową integrację operatorską — przechodzi przez te same pięć etapów. Każdy etap jest wspierany przez AI; na każdym etapie jest człowiek w pętli.

1. Rozpoznanie (bez barier technicznych)

Gdy pojawia się nowy wymóg („musimy zintegrować operatora X, żeby objąć Egipt”), pierwszym ruchem inżyniera nie jest zgadywanie tego, czego nie wie. Jest nim użycie AI do zbadania nieznanego terenu w 20 minut zamiast w 2 dni.

W praktyce: inżynier, który nigdy nie integrował egipskiego MVNO, może wrzucić asystentowi AI dokumentację API operatora, dostać uporządkowane podsumowanie powierzchni integracyjnej, dopytać o przypadki brzegowe („jak wygląda typowy przepływ eKYC na tym rynku?”) i przygotować jednostronicową ocenę nakładu, ryzyk i niewiadomych jeszcze przed obiadem.

Co się zmienia: wąskim gardłem nie jest już „czy mamy inżyniera, który zna tę dziedzinę?”. Jest nim „czy inżynier, którego mamy, wsparty przez AI, opanuje tę dziedzinę wystarczająco w kilka godzin?”. Prawie zawsze — tak.

2. Specyfikacja (godziny, nie tygodnie)

Większość specyfikacji produktowych w większości firm zajmuje 1–3 tygodnie: PM pisze szkic, interesariusze go przeglądają, dochodzą przypadki brzegowe, doprecyzowują się kryteria akceptacji, a potem inżynieria wycenia zakres od nowa. Zanim specyfikacja jest „gotowa”, pierwotna okazja zdążyła się przesunąć.

Nasze podejście: inżynier (albo CEO, zależnie od funkcji) rzuca jednolinijkowy pomysł produktowy. AI rozwija go w ustrukturyzowany PRD — przepływ użytkownika, przypadki brzegowe, metryki sukcesu, kryteria akceptacji, pytania otwarte. Zespół dopracowuje to na 45-minutowej sesji roboczej. Specyfikacja trafia do inżynierii tego samego dnia.

Kompromis: specyfikacje z tego procesu są nieco bardziej surowe niż klasyczne, dwutygodniowe dokumenty prowadzone przez PM-a. Godzimy się na to. Skrócenie czasu do pierwszej implementacji jest warte dodatkowej niejednoznaczności, która i tak rozstrzyga się w trakcie budowania, a nie przed nim.

3. Projekt (szybka pętla informacji zwrotnej)

Przy funkcjach z rozbudowanym interfejsem nasz projektant pracuje ramię w ramię z inżynierem w pętli „projekt–implementacja–feedback” mierzonej w minutach, nie w dniach. Makiety generowane przez AI (wtyczki do Figmy plus generatory obrazów) pozwalają szybko przejrzeć warianty. Inżynier dowozi prototyp w kilka godzin. Projektant ocenia go na prawdziwym sprzęcie. Iteracje mierzy się w cyklach jednodniowych.

Efekt jest taki, że projektowanie i inżynieria nie są sekwencyjne — biegną równolegle. Gdy projekt jest „finalny”, implementacja jest już w większości gotowa do produkcji.

4. Budowa (kod pisze AI; ludzie przeglądają każdy diff)

To najbardziej widoczna część podejścia AI-native. Tak dziś wygląda proces inżynierski w eSimphony:

• AI generuje około 90% nowego kodu (Cursor, Claude, GitHub Copilot, często w połączeniu)
• Inżynierowie odpowiadają za decyzje architektoniczne, granice integracji i tę trudną logikę biznesową, która wymaga głębokiej znajomości systemu
• 100% kodu przechodzi ludzkie review przed scaleniem. Każdy diff. Każdy PR. Bez wyjątków.

Ten ostatni punkt jest kluczowy i często źle rozumiany. „AI pisze kod” nie znaczy „nikt nie patrzy na kod”. Znaczy, że rola inżyniera przesuwa się z pisania implementacji na jej przeglądanie. Praca poznawcza — czy to zgadza się ze specyfikacją, czy obsługuje przypadki brzegowe, czy pasuje do architektury, czy się wyskaluje — wciąż należy do inżyniera. Praca mechaniczna, czyli przełożenie intencji na poprawny składniowo, idiomatyczny kod, zostaje oddelegowana.

Typowy PR w eSimphony ma:

• 200–800 zmienionych linii kodu (wobec klasycznych 100–200 w zespołach z 2024 roku)
• 1 inżyniera przeglądającego go w szczegółach
• Często testy jednostkowe wygenerowane przez AI, z pokryciem powyżej 80% nowego kodu
• Komentarze recenzenta skupione na architekturze, nie na składni

5. Wdrożenie (adaptacja w minutach)

Wdrażamy stopniowo: feature flagi na ryzykowne zmiany, wdrożenia kanarkowe dla usług backendowych, telemetria pilnowana przez AI, która wyłapuje anomalie w ciągu kilku minut od wypuszczenia. Gdy wdrożenie coś psuje, wycofanie mierzy się w minutach, nie w godzinach.

Fragment o „telemetrii pilnowanej przez AI” wart jest jednego zdania: po wdrożeniu agent AI obserwuje anomalie we wskaźnikach błędów, opóźnieniach, zgłoszeniach użytkowników i konwersji. Gdy anomalia przekroczy próg, dyżurny inżynier dostaje powiadomienie razem z podsumowaniem prawdopodobnych przyczyn. To skraca czas wykrycia z „użytkownik zgłasza błąd o 9:00” do „alert odpala o 9:03”.

Liczby

Przybliżone metryki z ostatnich 12 miesięcy:

• Cykl sprintu: 1 tydzień. Nowe funkcje co tydzień; drobne poprawki codziennie.
• 5 inżynierów pracujących nad produktem na pełen etat. Jeden dodatkowy inżynier współpracuje na część etatu.
• Ponad 90% nowego kodu generuje AI (głównie Cursor i Claude).
• 100% scalonego kodu przeszło ludzkie review.
• Mediana czasu od specyfikacji do produkcji: 5–10 dni.
• Incydenty produkcyjne na kwartał: 1–2. Poniżej średniej branżowej dla naszego zakresu.
• Zgłoszenia z supportu eskalowane do inżynierii: około 5 tygodniowo. Większość rozwiązujemy tego samego dnia.

Te liczby nie są teoretyczne. To realne tempo pracy naszego zespołu.

Czym to nie jest

Warto powiedzieć wprost, czego rozwój AI-native w eSimphony nie oznacza.

To nie jest „vibe coding”. Kod jest przeglądany linia po linii. Decyzje architektoniczne podejmują ludzie. AI przyspiesza pisanie, nie myślenie.

To nie jest „bez testów”. Testy generowane przez AI mają swoje słabości (dokładniej sprawdzają ścieżki szczęśliwe niż przypadki brzegowe), więc inżynierowie dopisują własne testy na brzegi. Pokrycie testami nowego kodu stale przekracza 80%.

To nie jest „senior nie jest już potrzebny”. Wręcz przeciwnie. AI drastycznie podnosi wartość doświadczonego osądu, bo senior potrafi przejrzeć i dopracować wynik AI 5–10× szybciej, niż napisałby go od zera. Juniorzy korzystający z AI bez przeglądu seniora zwykle produkują kod, który się kompiluje, ale strukturalnie jest kruchy.

To nie jest „bez myślenia projektowego i produktowego”. AI jest bezużyteczne bez jasnych specyfikacji i przemyślanych przepływów użytkownika. Praca poznawcza — „co powinniśmy zbudować, po co i dla kogo” — pozostaje ludzka.

Czego to wymaga

Trzech rzeczy, w kolejności ważności.

1. Twardego ludzkiego review

Każda linia kodu wygenerowanego przez AI przechodzi przed scaleniem przez review doświadczonego inżyniera. Pokusa, żeby pominąć przegląd przy „oczywiście poprawnych” drobiazgach, jest realna i groźna. Trzymamy linię 100% review.

2. Ciasnych barierek architektonicznych

Generując kod, AI podąża za lokalnymi konwencjami. Mocne konwencje = mocny wynik AI. Mocno zainwestowaliśmy w wyraźne granice modułów, spójne nazewnictwo, dobrze otypowane interfejsy i jawną dokumentację tego, „jak się u nas robi rzeczy”, żeby AI mogło czysto dopasować wzorce.

3. Kulturowej zgody na AI jako domyślne narzędzie

Zespół uzgodnił wprost, że wsparcie AI jest domyślne w każdym przepływie pracy. Nowi inżynierowie wchodzą w tę domyślność od pierwszego dnia. Sprzeciw („wolę napisać to sam”) wysłuchujemy i omawiamy, ale normą zespołu jest, że pracę mechaniczną wykonuje AI, chyba że jest konkretny powód, by było inaczej.

Do czego AI nie używamy

• Do przeglądania kodu wygenerowanego przez AI (chcemy świeżego ludzkiego oka)
• Do decydowania, co budować (strategia produktu jest ludzka)
• Do bezpośrednich eskalacji z obsługi klienta (trudne przypadki biorą ludzie)
• Do ocen okresowych i informacji zwrotnej w zespole (wyłącznie ludzie)
• Do decyzji rekrutacyjnych (wyłącznie ludzie, wspierani przez AI przy pozyskiwaniu i wstępnej selekcji)

Wzorzec jest taki: AI wzmacnia wykonanie, ludzie odpowiadają za decyzje.

Dlaczego to ma znaczenie dla produktu

Efekt tego przepływu widać w produkcie. Dowieźliśmy:

• Architekturę dożywotniego eSIM (w większości firm projekt na kilka kwartałów)
• Mozę, towarzyszkę podróży opartą na AI, w pięciu językach
• Dynamiczne plany AI w trzech regionach
• Diagnostykę AI z automatyczną naprawą
• Natywne aplikacje na iOS i Androida z cotygodniowymi wydaniami
• Wieloregionowy backend z dostępnością powyżej 99,9%
• Lokalizację na 5 języków na całej powierzchni produktu

Taka lista wymaga zwykle 30–50 inżynierów i ponad 3 lat. My dowieźliśmy ją w 5 osób w 18 miesięcy.

Słowo o rekrutacji

Powiększamy zespół ostrożnie. Inżynierowie, którym dobrze się u nas pracuje, mają trzy wspólne cechy:

1. Wysoki osąd ponad wysoką produkcję. Pisanie bierze na siebie AI; my szukamy ludzi, którzy są świetni w przeglądaniu, decydowaniu i nadawaniu kształtu.
2. Swoboda w traktowaniu AI jak współpracownika. Inżynierów, którzy traktują AI jak kolegę z zespołu (delegują, sprawdzają, spierają się), a nie jak magiczną wyrocznię ani zagrożenie dla własnej tożsamości.
3. Troska o użytkownika. Przepływy AI-native są na tyle szybkie, że łatwo wyprodukować mnóstwo kodu, który się kompiluje, ale nic nie wnosi. Najlepszą pracę wykonują inżynierowie, którzy każdy PR potrafią osadzić w pytaniu „czy to pomaga użytkownikowi”.

Jeśli to o Tobie — rekrutujemy. Napisz przez stronę kariery albo odezwij się bezpośrednio do Trunga.

Co dowozimy dalej

Ten sam przepływ, który zbudował obecny produkt, realizuje mapę drogową:

• Zarządzanie wieloma eSIM (maj 2026)
• Plany rodzinne (czerwiec 2026)
• Program lojalnościowy i nagrody (sierpień 2026)
• Globalne pokrycie w bezpośrednich umowach z operatorami (2027)

Każde z tych zadań to w klasycznym telekomie projekt na wiele miesięcy. Nasze wewnętrzne szacunki mówią, że wszystkie cztery wejdą zgodnie z planem, w tym samym pięcioosobowym zespole.

Na tym polega dźwignia. Na tym polega zakład. Tak mały zespół gra przeciwko bezwładności całej branży.

Zobacz eSimphony w akcji, przeczytaj o naszym pozycjonowaniu albo zajrzyj do naszej prezentacji z MVNO Nation Americas.