Punkt, od którego nie ma odwrotu: Claude Code zamiast gotowych narzędzi

O czym jest ten film

1. Autor twierdzi, że Claude Code osiągnął poziom, przy którym w jego firmie pytanie brzmi już nie „jakie narzędzie kupić”, lecz „czy kupić, czy zbudować dokładnie to, czego potrzebujemy”.
2. Główna pułapka: sama możliwość zbudowania czegoś nie jest powodem do budowania — jako przykład autor przywołuje próbę odtworzenia w Claude Code całego CRM-a (odpowiednika GoHighLevel).
3. Decyzję warto liczyć jak wymianę: miesięczny abonament za gotowe narzędzie kontra własny czas na budowę i — przede wszystkim — utrzymanie.
4. Budować samemu opłaca się tylko wtedy, gdy narzędzie jest rdzeniem wartości oddawanej klientowi albo gdy żadne gotowe rozwiązanie nie obsługuje konkretnego problemu.
5. Pierwszy przykład: studio treści — system generujący spójne wizualnie karuzele na social media, z szablonami stylu i edycją pojedynczych warstw grafiki.
6. Problem, który je zrodził: grafiki z AI bywają gotowe w 90 procentach, a jedna literówka zmusza do regeneracji całości — stąd pomysł plików warstwowych à la Canva.
7. Drugi przykład: system pamięci dla Claude Code, bo wbudowana pamięć zapomina decyzje i kontekst, co przy projektach rozciągniętych na miesiące jest nie do zaakceptowania.
8. Cztery wymagania wobec pamięci: cytowanie źródeł z datą, pamięć krótkoterminowa, wyszukiwanie po znaczeniu oraz dostęp filtrowany według tego, kto pyta.
9. W obu przypadkach użyto tego samego procesu: podział problemu na fazy i dobór najlepszego rozwiązania — własnego albo gotowego — dla każdej fazy osobno.
10. Materiał zawiera też wątek promocyjny społeczności (instalacje obu systemów wraz z kursami, rabat do końca czerwca) oraz zapowiedź następnego filmu z dokładnym planem budowy systemu pamięci.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Buduj sam tylko przy jednym z dwóch powodów

Na czym polega: Własne narzędzie ma sens wyłącznie wtedy, gdy jest rdzeniem twojego produktu i wartości dla klienta, albo gdy żadne gotowe rozwiązanie nie rozwiązuje twojego konkretnego problemu (w tym gdy ograniczenia obecnego narzędzia realnie blokują twój sposób pracy).

Jak stosować: Zanim zaczniesz cokolwiek budować, odpowiedz pisemnie na dwa pytania: „Czy to wprost wpływa na to, za co płaci mi klient?” i „Czy jakieś gotowe narzędzie realnie załatwia mój przypadek?”. Dwie odpowiedzi „nie” oznaczają: kupujesz i nie dotykasz kodu.

Na co uważać: Na racjonalizacje w stylu „fajnie będzie to zbudować” albo „przy okazji się nauczę” — to nie są kryteria biznesowe, tylko preteksty.

2.Wliczaj koszt utrzymania, nie tylko budowy

Na czym polega: Decyzja „buduj czy kup” to rachunek dwóch kosztów: stałego abonamentu za gotowe narzędzie albo twojego czasu — najpierw na zbudowanie, potem na niekończące się utrzymanie. Ta druga pozycja znikąd nie znika.

Jak stosować: Oszacuj godziny potrzebne na zbudowanie, dodaj przewidywany stały nakład na naprawy i aktualizacje (realnie kilka–kilkanaście godzin miesięcznie), przemnóż przez swoją stawkę i dopiero wtedy porównuj z ceną subskrypcji.

Na co uważać: Na złudzenie „skoro już zbudowane, koszt wynosi zero”. Autor mówi wprost z własnego doświadczenia: oszczędność 50–100 dolarów miesięcznie potrafi nigdy nie zwrócić czasu włożonego w samodzielny rozwój.

3.Nie odtwarzaj dojrzałych produktów od zera

Na czym polega: Przykład z filmu: ktoś próbował przebudować w Claude Code cały CRM, choć takie produkty istnieją, działają i oddają więcej wartości, niż kosztują. To setki godzin pracy włożone w coś, co już jest zrobione.

Jak stosować: Zanim cokolwiek zbudujesz, zrób krótki przegląd rynku. Jeśli istnieje dojrzałe narzędzie, które dobrze spełnia zadanie — bierz je, a własną energię kieruj tam, gdzie realnie różnicujesz się na rynku.

Na co uważać: Na pokusę „zbuduję lepiej pod siebie” przy produktach z setkami funkcji. Każdą dodatkową funkcję, którą kopiujesz, będziesz też musiał utrzymywać.

4.Znajdź prawdziwą przyczynę, zanim projektujesz narzędzie

Na czym polega: Autor lat obwiniał się za nieregularne publikowanie („brak dyscypliny”), podczas gdy prawdziwa przyczyna była inna: nie chciał zamieszczać treści poniżej swojego standardu. Dopiero diagnoza rzeczywistego problemu wskazała, jakie narzędzie zbudować.

Jak stosować: Przy każdym nawracającym problemie zadaj pytanie: „co naprawdę sprawia, że przestaję to robić?”. Rozwiązuj źródło (np. brak narzędzia do utrzymania jakości), a nie objaw (np. kolejny kalendarz publikacji).

Na co uważać: Diagnoza „brak dyscypliny” jest wygodna, bo zamyka dalsze szukanie — i przez to potrafi blokować właściwe rozwiązanie na lata.

5.Duży problem dziel na fazy

Na czym polega: Oba systemy z filmu powstały tak samo: problem rozłożono na etapy. Studio treści: szablony stylu → generowanie obrazów → warstwowa edycja → publikacja. Pamięć: przechowywanie → wstrzykiwanie kontekstu do sesji → przywoływanie.

Jak stosować: Opisz najpierw cały przepływ od początku do końca, potem potnij go na etapy o wyraźnych, sprawdzalnych efektach. Każdy etap buduj i testuj osobno, zanim przejdziesz dalej.

Na co uważać: Na pokusę „zrobię to jednym promptem”. Autor podkreśla, że oba systemy zajęły ponad tydzień — realne narzędzia to tygodnie iteracji, nie jednorazowe zadanie na popołudnie.

6.Na każdej fazie osobno decyduj: budować, kupić czy połączyć

Na czym polega: Nie ma reguły „albo wszystko sam, albo wszystko kupione”. Autorzy systemu pamięci przejrzeli najlepsze rozwiązania open source, wybrali z nich najlepsze elementy i złożyli je we własnym środowisku, dopisując tylko to, czego brakowało.

Jak stosować: Dla każdej fazy z osobna sprawdź najpierw gotowe komponenty i projekty open source. Łącz je z własnym kodem wyłącznie tam, gdzie nic istniejącego nie spełnia wymagań.

Na co uważać: Na dwie skrajności: ambitne budowanie wszystkiego od zera oraz sklejanie tak wielu zewnętrznych zależności, że ich utrzymanie staje się większym ciężarem niż własny kod.

7.Świadomie trzymaj mały zakres narzędzia

Na czym polega: Opisane systemy mają celowo wąski zakres — jeden konkretny przypadek użycia. To nie przypadłość, lecz decyzja: mniej funkcji oznacza mniej utrzymania w przyszłości.

Jak stosować: Buduj pod jeden dobrze opisany przypadek. Każdą funkcję spoza niego notuj na liście „kiedyś” i odrzucaj na etapie projektowania, nie implementacji.

Na co uważać: Na rozrost zakresu w trakcie pracy — każda „drobna” funkcja to przyszła naprawa, dokumentacja i koszt, który zje czas zaoszczędzony na subskrypcji.

8.Warstwy ratują generowanie grafik

Na czym polega: Generowanie obrazów przez AI ma typową pułapkę: efekt jest gotowy w 90 procentach, ale jedna literówka czy zły kolor wymuszają regenerację całości z nadzieją, że tym razem wyjdzie. Rozwiązanie: API zamieniające płaski obraz w plik warstwowy (à la Canva), w którym każdy element można poprawić osobno.

Jak stosować: Jeśli tworzysz karuzele lub infografiki: zbuduj (lub dobierz) pipeline, który generuje szablony stylu dla spójności między slajdami, a na końcu rozbija obraz na edytowalne warstwy. Literówkę poprawiasz wtedy jednym poleceniem (promptem) skierowanym do pojedynczej warstwy — za ułamek kosztu pełnej regeneracji.

Na co uważać: Warstwy redukują żmudną robotę, ale nie zastępują gustu — nadal trzeba iterować i ręcznie kontrolować jakość przed publikacją.

9.Pamięć agenta bez cytowań to zgadywanie

Na czym polega: Przy klientach i projektach rozciągniętych na miesiące odpowiedź typu „umówiliśmy się na X” nic nie znaczy bez źródła. System pamięci ma podawać, z której rozmowy pochodzi informacja, dokładnymi słowami i z datą — a gdy czegoś nie wie, ma to przyznać wprost.

Jak stosować: Przy budowie lub wyborze systemu pamięci wymagaj dwóch rzeczy: każda odpowiedź o ustaleniach z przeszłości wskazuje źródło i datę; brak danych kończy się komunikatem „nie wiem”, a nie domysłem. Odpowiedzi bez źródła traktuj jako niewiarygodne.

Na co uważać: Na złudne poczucie, że model „pamięta”. Bez mechanizmu cytowań odpowiedź o ustaleniach sprzed trzech miesięcy jest po prostu konfabulacją ubraną w pewny ton.

10.Wspólna pamięć zespołu wymaga uprawnień i wyszukiwania po znaczeniu

Na czym polega: Gdy z jednej bazy wiedzy korzysta cały zespół, każde wspomnienie musi być oznaczone właścicielem, a każde zapytanie filtrowane według tego, kto pyta (tzw. scoped access, czyli dostęp ograniczony zakresem uprawnień). Poza tym wyszukiwanie ma działać po znaczeniu: pytanie o obsługę płatności ma odnaleźć rozmowy o Stripe, nawet jeśli to słowo wtedy nie padło.

Jak stosować: Jeśli narzędzie ma obsługiwać więcej osób lub klientów, zaprojektuj tagi własnościowe i filtrowanie odpowiedzi od pierwszego dnia. Do historii wielomiesięcznej używaj wyszukiwania semantycznego zamiast dopasowywania słów.

Na co uważać: Jeden wspólny „mózg” dla wszystkich bez filtrów to prosta droga do wycieku informacji klientowych między projektami. Z kolei wyszukiwanie po samych słowach kluczowych pominie rozmowy opisane innym językiem niż Twoje pytanie.

Redakcyjne tłumaczenie

Pytanie zmieniło się z „co kupić” na „czy budować”

Wszyscy w kółko powtarzają, że zaraz zastąpimy wszystkie narzędzia SaaS Claude Code, a ja zawsze kiwałem na to głową z niedowierzaniem — brzmiało jak przesada. Tymczasem Claude Code (Informacja dodatkowa: terminalowe narzędzie firmy Anthropic, w którym agent AI samodzielnie pisze, uruchamia i poprawia kod) regularnie dowodzi, że się mylę. Co jakiś czas wpadam w irytujący problem w biznesie — taki, za który dawniej poszedłbym szukać gotowej aplikacji. Dziś zamiast tego poświęcam dzień, czasem tydzień pracy po godzinach i buduję ją sam. Potem siadam i myślę: chwila, czy my właśnie nie zastąpiliśmy całego produktu?

Claude Code po cichu wszedł na zupełnie nowy poziom, bo zmieniło się samo pytanie, jakie sobie zadajemy: czy to się opłaca kupić, czy lepiej zbudować i utrzymywać dokładnie to, czego potrzebujemy? W tym materiale pokażę dwa narzędzia, które zbudowaliśmy i właśnie uruchamiamy w naszej społeczności. Ważniejsze jest jednak to, co za nimi stoi: proces decyzyjny. Jak rozpoznajemy właściwe problemy, jak oceniamy, co w ogóle warto budować, i jak zamieniamy to w narzędzia, z których naprawdę korzystamy na co dzień. Bo najtrudniejsze nie jest już samo pisanie oprogramowania — najtrudniejsze jest rozpoznanie, które problemy warto rozwiązywać samemu.

Pułapka: to, że potrafisz coś zbudować, nie znaczy, że powinieneś

Widuję ludzi, którzy budują albo przebudowują od zera całe platformy. Niedawno ktoś usiłował odtworzyć w Claude Code kompletny CRM — odpowiednik GoHighLevel (Informacja dodatkowa: GoHighLevel to popularna platforma SaaS dla agencji marketingowych, łącząca CRM, automatyzacje i lejki sprzedażowe). Serio? Wpychać setki godzin w odtwarzanie czegoś, co już istnieje, działa bardzo dobrze i przynosi więcej wartości, niż wynosi rachunek miesięczny?

Prawdziwa umiejętność nie polega więc na budowaniu, tylko na wyborze: co zrobić samemu, a co wziąć gotowe. Najlepiej myśleć o tym jak o wymianie barterowej: z jednej strony stały koszt abonamentu, z drugiej twój czas — na zbudowanie i utrzymanie. I proszę, nie zapominaj o utrzymaniu. Ono nigdzie nie znika.

Kiedy budować samemu

Schemat jest prosty. Budujesz we własnym zakresie, gdy prawdziwe jest jedno z dwóch twierdzeń:

1. Narzędzie stanowi rdzeń twojego produktu i wartości, którą oddajesz klientowi. Wszystko inne, co da się zlecić na zewnątrz, powinno być zlecone na zewnątrz.
2. Żadne gotowe rozwiązanie nie rozwiązuje twojego konkretnego problemu — w tym sytuacja, gdy ograniczenia narzędzia, z którego korzystasz na co dzień, realnie blokują twój sposób pracy.

Jeśli nie spełnia się żadne z powyższych — kup gotową aplikację. Mówię z własnego doświadczenia: czas pochłonięty ręcznym utrzymaniem samodzielnie zbudowanego systemu sprawi, że będziesz żałować decyzji podjętej dla oszczędności rzędu 50–100 dolarów miesięcznie. Ale gdy którykolwiek warunek jest spełniony, budowanie opłaca się podwójnie. Zaraz pokażę dwa przykłady, w których tak właśnie było — oba rozwiązywały problemy, które naprawdę mieliśmy.

Przykład pierwszy: studio treści

Naszym problemem była regularność w social mediach. Przez długi czas obwiniałem siebie: za mało publikuję, brak dyscypliny. Ale to nie była prawdziwa przyczyna ourych zatorów. Prawdziwa była taka, że nie chciałem wystawiać na swoich osiach treści poniżej pewnego poziomu. Zależy mi, żeby wszystko, co publikuję, wyglądało jak moje i było dopracowane — to z pewnością rys perfekcjonisty, ale taka już jest moja natura. Nie zamierzałem wrzucać karuzeli czy infografiki, które wyglądałyby na niedokończone albo „wygenerowane przez AI”.

Problem opierał się rozwiązaniu, bo zaprojektowanie karuzeli to praca stricte wizualna, a nie jestem grafikiem. I tu dochodzimy do rzeczy, którą znamy chyba wszyscy: generowanie obrazów przez AI bywa znakomite, ale nigdy idealne — zwłaszcza gdy tworzysz coś wielowarstwowego, jak karuzela. Scenariusz wygląda tak: generujesz, po kilku iteracjach masz efekt gotowy w dziewięćdziesiąt procent i… utknąłeś. Jedno słowo jest przekręcone, jeden kolor nie ten, jeden element leży w złym miejscu — i nie ma sposobu, żeby to naprawić. Pozostaje generować całość od nowa i trzymać kciuki, że tym razem wyjdzie.

Wtedy pomyślałem: a gdyby istniało jedno miejsce do poprawiania efektów? Edytujesz szablon, żeby po regeneracji wszystko trzymało spójny styl. Zmieniasz pojedyncze warstwy. Naprawiasz jeden zepsuty element na stronie. Szczerze mówiąc, gdy zacząłem rozpatrywać to jako pełnoprawny problem, uznałem, że zbudowanie czegoś takiego jest nierealne. A potem sprawdziłem nasze dwa kryteria — i okazało się, że projekt spełnia oba. Po pierwsze: leży w samym środku wartości mojej marki, bo publikowanie w social mediach to dla mnie główne źródło pozyskiwania uczestników społeczności, a przy tym chcę być dumny z jakości tego, co wychodzi. Po drugie: nawet gotowe produkty, takie jak Higgsfield (Informacja dodatkowa: platforma do generowania obrazów i wideo z AI), nie rozwiązują mojego konkretnego problemu — nie potrafią zrobić rezultatów wystarczająco spójnych z marką, żeby zdjąć ze mnie większość ręcznej roboty. Czyli drugie kryterium również się potwierdza: żadne gotowe narzędzie nie jest wystarczająco dobre dla mojego sposobu pracy.

Rozbiliśmy więc problem na fazy. Najpierw system tworzy szablony stylu wizualnego na podstawie postów-inspiracji. Szablony te zasilają etap generowania obrazów, dzięki czemu wszystkie slajdy karuzeli utrzymują firmowy wygląd i klimat. A trzecia część — i to był właściwy powód, dla którego w ogóle budowaliśmy — to coś, czego nie dostaliśmy nigdzie indziej: znaleźliśmy usługi API, które zamieniają płaskie obrazy w pełnowartościowe pliki warstwowe, w duchu funkcji Magic Layers w Canvie, gdzie każdy element staje się osobno edytowalnym obrazem. Wystarczy więc jedno dodatkowe polecenie skierowane wyłącznie do danej warstwy — za ułamek kosztu pełnej regeneracji. Poprawki wprowadzamy bezpośrednio w tym miejscu, a gotowa karuzela publikuje się sama przez API Zeno. W ten sposób zniknęło ręczne zarządzanie, którym wcześniej obejmowaliśmy projektowanie i wrzucanie karuzel do social mediów.

Bądźmy realistami: nie powstało to jednym promptem. Zajęło nam dobrze ponad tydzień. Ale skoro to rdzeń naszego sposobu pracy, czas ten był dobrze wydany — a teraz możemy udostępnić rozwiązanie także członkom społeczności. Korzyść po obu stronach: dla nas i dla naszej wartości głównej. Mamy więc problem rozbity na fazy i dobrane narzędzie dla każdej z nich.

Zauważcie przy tym, jak wąski zakres ma zbudowany produkt. To celowe — nie chcemy, żeby w przyszłości generował koszty utrzymania. Nie budowalibyśmy na tym miejscu pełnego CRM-a z dwudziestoma funkcjami, bo każdą z nich trzeba potem utrzymywać. To prosty przepływ pod jeden konkretny przypadek użycia.

Przy okazji: ten system, podobnie jak następny, jest dostępny w naszej społeczności jako instalacja online wraz z kompletnymi kursami, pozwalającymi zbudować własne wersje od zera. Do końca czerwca pierwszy miesiąc w mocno obniżonej cenie — zainteresowanych odsyłam na school.com/scrapes.

Przykład drugi: system pamięci

Drugie narzędzie narodziło się wprost z ograniczenia Claude Code w wersji domyślnej — ale jednocześnie stanowi rdzeń naszej oferty dla członków społeczności. Chodzi o pamięć, bo ta wbudowana jest, delikatnie mówiąc, bardzo słaba. Zapomina decyzje, które już zapadły, kontekst, który już wyjaśniłeś, pracę, którą już odwalono. Po jakimś czasie każda sesja zaczyna przez to kosztować dodatkowy czas: w kółko tłumaczysz te same rzeczy. Dla osób prowadzących własny biznes robi się z tego prawdziwy bloker — nie da się prowadzić realnych klientów i projektów przez wiele miesięcy na wbudowanej infrastrukturze. Na pytanie „na co się umówiliśmy z tym klientem trzy miesiące temu?” potrzebna jest wiarygodna odpowiedź poparta źródłem i cytatem, a domyślna wersja najczęściej nie jest w stanie odpowiedzieć nawet w ogóle. Skoro więc system nie przechowuje twojego kontekstu i nie pozwala go przywołać — to po co go używać?

Zamiast wymyślać wszystko od zera, sięgnęliśmy po najlepsze elementy najlepszych otwartych systemów pamięci. Zebraliśmy mnóstwo opinii z komentarzy pod filmami i od ludzi w społeczności, przeprowadziliśmy własny przegląd dostępnych rozwiązań, a potem przebudowaliśmy wybrane pomysły wewnątrz naszego agentowego systemu operacyjnego — tak, żeby pasowały do potrzeb właścicieli firm, czyli do nas i do naszej publiczności. I, podobnie jak przy studiu treści, rozbiliśmy zadanie na fazy oraz konkretne wymagania:

1. Cytowanie źródeł. Gdy system coś podaje, mówi też, skąd to wie: z której rozmowy, jakimi dokładnie słowami się umówiliśmy i kiedy. A jeśli czegoś nie potrafi przywołać — mówi to wprost. Dzięki temu można ufać odpowiedzi.
2. Krótkotrwała pamięć. Bieżący kontekst i najważniejsze informacje — na przykład aktywni klienci — mają być dostępne natychmiast, w zasięgu historii sesji.
3. Długoterminowe wyszukiwanie po znaczeniu. Pytam o obsługę płatności, a system sam rozumie, że ma przejrzeć rozmowy o procesorach płatności typu Stripe — bez wymagania, żebym pamiętał dokładne słowa użyte trzy–cztery miesiące temu.
4. Dostęp ograniczony zakresem uprawnień — w zespole i wobec klientów. Wszyscy przywykliśmy do pracy w Claude Code w pojedynkę, w odizolowanym środowisku. Ale jak przenieść to na firmę, na zespół ludzi, którzy mają jeden wspólny „mózg”? U nas każde wspomnienie jest oznaczone właścicielem, a każde zapytanie kierowane do bazy pamięci jest filtrowane według tego, kto pyta. Efekt: ludzie czytają to, co powinni czytać, i nie dostają rzeczy, których nie mogą lub nie wolno im zobaczyć.

Głębiej samą budowę opisałem w osobnym materiale, który podlinkuję. Zwróćcie uwagę, że proces był identyczny jak przy systemie treści: pamięć rozbiliśmy na trzy pytania — jak przechowuje wspomnienia, co wstrzykuje do pamięci krótkoterminowej sesji i jak je przywołuje — a następnie dla każdego wybraliśmy najlepsze rozwiązanie i złożyliśmy całość w Claude Code.

Dwa różne problemy, jeden proces

Zestawmy teraz oba przykłady. Jeden był w całości problemem wizualnym: tworzenie ładnych treści. Drugi — problemem infrastruktury: sprawienie, żeby Claude pamiętał dokładnie to, co powiedzieliśmy, i żeby pamięć była dostępna całemu zespołowi. A sposób działania użyty w obu przypadkach był dokładnie ten sam.

Rama decyzyjna w pigułce

Na koniec zostawiam kilka rad dotyczących wyboru tego, co budować:

1. Zanim zaczniesz budować, sprawdź kryteria. Czy to rdzeń twojej oferty? Czy gotowe narzędzia naprawdę tego nie robią?
2. Zejdź do pierwotnej przyczyny problemów, których doświadczasz.
3. Rozbij ją na pojedyncze fazy.
4. Przy każdej fazie podejmij decyzję „buduj czy kup” — albo dobierz gotowe elementy do połączenia z twoimi. Staraj się nie przebudowywać wszystkiego od zera.

To cała metoda. Tak, zabiera czas — nie będę udawał, że inaczej. Takie systemy potrafią zająć tygodnie, ale są w pełni wykonalne. A gdy raz zaczniesz tak myśleć, jesteś w stanie zbudować niemal wszystko, czego potrzebujesz. Buduj tylko wtedy, gdy naprawdę musisz.

Oba narzędzia — studio treści i system pamięci — właśnie startują w naszej społeczności. A jeśli chcecie poznać dokładny plan budowy systemu pamięci, żeby złożyć go u siebie samodzielnie, zajrzyjcie do następnego filmu.