…czyli kilka słów o tym, czego nikt Ci nie powie o budowie startupu z AI (cz.I)
W każdym poważnym projekcie przychodzi moment poważnej decyzji, której pierwszy efekt wygląda jak cofnięcie się w pracach. Czasem jednak taki ruch jest konieczny by móc spojrzeć w przyszłość. Decyzja i ostatnie dwa tygodnie w Bizpull.ai to jest właśnie taki moment.
To o czym piszę dziś, to nie spektakularna awaria, nie kryzys, o którym można by się rozpisywać. To coś subtelniejszego i bardziej niebezpiecznego: drobne, powtarzalne odchylenia w zachowaniu dotychczasowego systemu. Mówię o przypadkach, w których mechanizm działał, ale nie działał przewidywalnie – dane pojawiały się, ale w nieoczekiwanych prze ze mnie momentach, sekwencje procesów czasem wykonywały się w złej kolejności. System a raczej jego podstawowa część tzw. Enrichment Engine był funkcjonalny (to znaczy funkcjonował 🙂 , ale niestety okazał się być zawodny.
Zrozumiałem, że nie możemy budować kolejnych warstw na niestabilnym fundamencie.
Sygnały
Kiedy pracujesz z AI jako współtwórcami produktu — Claude jako CTO, ChatGPT jako COO, Lovable jako development platform — pojawia się pokusa traktowania systemu jak czarnej skrzynki. Działa? Świetnie, budujmy dalej.
Ale właśnie w tym tkwi pułapka.
AI nie zwalnia z myślenia. Wymaga większej dyscypliny, bo kiedy automatyzujesz procesy, każda niespójność w logice mnoży się setki razy dziennie. Każdy edge case, który przejdzie niezauważony w testach, staje się realnym problemem w produkcji i może realnie nie dawać rady przy dużej ilości użytkowników i tak właśnie się stało.
Zauważyłem trzy rzeczy:
Pierwsza: system generował dane, ale nie zawsze w oczekiwanym formacie. Czasem pojawiało się pole A, czasem pole B. Niegroźne w testach na 10 rekordach. Katastrofalne przy 10 000.
Druga: sekwencje działań — enrichment, scoring, follow-up generation — czasem wykonywały się w niewłaściwej kolejności. 90% przypadków działało perfekcyjnie, ale te 10% to były -prosto ujmując – przyszłe brakujące dane, niepoprawne dopasowania, zmarnowane leady.
Trzecia: im więcej dodawaliśmy funkcji, tym bardziej system stawał się nieprzewidywalny. Klasyczny symptom architektury budowanej na szybko, bez czasu na konsolidację.
I wtedy podjąłem najtrudniejszą decyzję ostatnich miesięcy: cofamy sprint. Wracamy do fundamentu. Miałem juz taką jedną decyzje za sobą, ale ona była dużo wcześniej, nie była na tym etapie prac.
Cofnięcie, które paradoksalnie jest przygotowaniem do skoku
Ktoś kto budował kiedykolwiek startup wie, ze naturalny instynkt foundera to „więcej, szybciej, dalej”. Dodawać funkcje. Pokazywać progres. Imponować inwestorom. Więc tak, to była dla mnie bardzo silna pokusa by budować dalej na istniejącym i sprawnym małym Agent AI Engine odpinając na boczny tor wadliwy duży dający skalowalność silnik Enrichment Engine (oczyszczalnię i fabrykę danych) tylko po to, by pokazać swoim szacownym, (uzbrojonym w cierpliwość) beta testerom i potencjalnym przyszłym inwestorom jak to pięknie działa.
Oczywiście, można byłoby juz zrobić wizualne elementy UI (Interfejs użytkownika) i się pokazać publicznie, ale prawda jest inna moi drodzy: ignorowanie sygnałów kończy się znacznie gorzej niż kilkoma dniami (lub najczęściej tygodniami) odbudowywania jakiegoś elementu.
Jak już wspomniałem, to nie pierwszy raz, gdy Bizpull przechodził przez taki etap. Poprzednie rebuildy trwały 200, 250, nawet 300 godzin ciągłej pracy (pracy po pracy). Dzień po dniu: testy, analiza zachowań, korekty logiki, retesty. Setki rozmów z Claude, ChatGPT i Lovable. Debugowanie każdego edge case’a, aż system zacznie zachowywać się dokładnie tak, jak powinien.
To są momenty, kiedy wchodzisz w ciemny tunel i nie wiesz kiedy i czy wogóle z niego wyjdziesz samodzielnie. To są te momenty o których nikt głośno nie mówi, ale które decydują o jakości produktu … no i testują twój charakter i nerwy do granic wytrzymałości.
Tym razem proces debugowania wygląda tak:
Zacząłem od kompletnego audytu wszystkich procesów. Chodzi o to by nie łatać, tylko zrozumieć gdzie dokładnie pojawiają się niespójności? Które moduły komunikują się niepoprawnie? Gdzie brakuje walidacji?… trzeba było stworzyć jeszcze raz dokumentację
Potem rozmowy z AI — ale nie w trybie „napraw to”, tylko „pomóż mi zrozumieć dlaczego”. Claude analizował flow danych krok po kroku. ChatGPT pomagał w strategicznej decyzji, co przebudować teraz, a co odłożyć na później, jak ma wygladać ścieżka. Lovable pokazywał, gdzie architektura no-code osiągnęła swoje limity i wymaga niestandardowych rozwiązań.
I wtedy przyszło najważniejsze odkrycie: problem nie jest w kodzie. Problem w pewnym sensie był w całej perspektywie wizji developerskiej a raczej był wynikiem braków mojej wiedzy i umiejętności…. Bum! …zawsze to wiedziałem ale teraz publicznie się do tego przyznaję.
System był budowany iteracyjnie – co oczywiście jest dobre – ale bez wystarczającej refleksji nad tym, jak te iteracje mają się składać w spójną całość. Każdy moduł działał. Ale razem? Tworzyły mozaikę, a nie mechanizm zegarowy.
To nie jest naprawa kodu – To jest oczyszczenie placu budowy.
—
Jeśli chcesz śledzić ten proces od środka — bez marketingowej otoczki — możesz dołączyć do wczesnych testerów:
Jeśli chcesz być jedną z pierwszych firm, które skorzystają z tego podejścia:
Dołącz do wczesnych testerów Bizpull.ai
https://beta.bizpull.aiBo w 2026 roku przewagę będą miały te firmy, które zaczną rozmowy i sprzedaż szybciej i trafniej a przede wszystkim wcześniej niż konkurencja.
