Jak Boris Cherny zbudował Claude Code — lekcje z podcastu The Light Cone #EN379

Notatka wstępna: Ten artykuł powstał na podstawie rozmowy Borisa Chernego (twórcy Claude Code) w podcaście The Light Cone prowadzonym przez Y Combinator. Wszystkie przemyślenia, obserwacje i przykłady pochodzą bezpośrednio od uczestników rozmowy. Checklista, prompty i kluczowe wnioski to moja interpretacja oparta na informacjach z podcastu.

TL;DR

Boris Cherny stworzył Claude Code przypadkowo, rozpoczynając od prostej aplikacji terminalowej do nauki API Anthropic
Fundamentalna zasada: buduj dla modelu, który pojawi się za 6 miesięcy, nie dla obecnego
Całą bazę kodu Claude Code przepisuje się co kilka miesięcy — scaffolding stanowi wyłącznie dług techniczny
Najważniejsza zasada produktowa: latent demand — użytkownicy już robią coś naturalnie, wystarczy to ułatwić
Plan mode powstał w niedzielny wieczór w 30 minut, po zaobserwowaniu zachowań użytkowników
Produktywność inżynierów w Anthropic wzrosła o 150% po wdrożeniu Claude Code
Zawód „software engineer” prawdopodobnie zniknie, zastąpiony rolą bliższą „builderowi”

Początki: weekend, terminal i ciekawość API

We wrześniu 2024 roku Boris Cherny zasiadł w biurze Anthropic bez konkretnego zadania. Miał jedynie luźny cel: zbudować coś w obszarze kodowania, ponieważ model wydawał się gotowy. Nikt nie polecił mu tworzenia CLI. Nie istniał żaden szczegółowy plan.

Kontekst był jednak istotny. Boris dołączył do zespołu Anthropic Labs — grupy odpowiedzialnej za trzy produkty: Claude Code, MCP i aplikację desktopową. Jak podkreśla Cherny, to nie przypadek. Ta triada stanowi ścieżkę do bezpiecznego AGI: najpierw nauczyć model kodowania, następnie używania narzędzi, a na końcu obsługi komputerów. Sposób, w jaki te produkty się łączą, ilustruje tę strategię.

Cherny chciał po prostu zrozumieć działanie API Anthropic. Zbudował więc najprostszą możliwą rzecz — niewielki chat w terminalu. Nie dlatego, że terminal był optymalnym wyborem, ale dlatego, że nie wymagał budowania interfejsu użytkownika. Sam przyznaje: używa VS Code, nie Vim ani tmux — po prostu zwykłego VS Code, ponieważ jest prostszy.

Potem pojawiło się tool use. Boris zdecydował się je przetestować, choć nie do końca rozumiał zastosowanie. Przekazał modelowi narzędzie Bash — akurat było w przykładach dokumentacji. Pierwsza komenda: odczytaj plik. Model wykonał zadanie. Następnie Boris zapytał: co jeszcze potrafisz?

Poprosił model o informację, jakiej muzyki słucha. Claude napisał AppleScript łączący się z odtwarzaczem na Macu Borisa i zwrócił odpowiedź. To był jego pierwszy moment poczucia AGI. Model po prostu chciał używać narzędzi — nic więcej nie było potrzebne.

Dwa dni później Boris przekazał prototyp zespołowi do dogfoodingu. Następnego dnia zobaczył Roberta — inżyniera siedzącego naprzeciwko — jak używa Claude Code do kodowania. Cherny zapytał: „Co robisz? To jeszcze nie jest gotowe”. Ale już było. Robert po prostu wykorzystywał narzędzie w codziennej pracy.

Podczas launch review w listopadzie 2024 Dario (CEO Anthropic) spojrzał na wewnętrzny wykres UCS. Wykres był pionowy — wszyscy korzystali z narzędzia. Dario zapytał: „Czy zmuszasz inżynierów do używania tego?” Boris odpowiedział: „Nie, nie. Po prostu opublikowałem informację, a oni sami zaczęli o tym mówić”.

Zasada pierwsza: nie buduj dla modelu obecnego

To najważniejsza rada, którą Boris Cherny kieruje wprost do founderów budujących na LLM-ach.

W lutym 2025, gdy Claude Code był już publicznie dostępny, model pisał około 10% kodu Borisa. Resztę Cherny pisał ręcznie. Narzędzie nie było jeszcze sprawne w kodowaniu — jednak Boris już wiedział, że tak będzie.

Jak podkreśla Cherny, w Anthropic myślenie zawsze jest zorientowane na przyszłość. Nie budujesz dla modelu obecnego — budujesz dla modelu, który pojawi się za sześć miesięcy. Ryzyko odwrotnego podejścia jest konkretne: inwestujesz czas w budowanie pod obecne możliwości, znajdujesz product-market fit, a następnie ktoś inny — kto budował dla następnego modelu — po prostu cię wyprzedza.

The Bitter Lesson i dług techniczny scaffoldingu

Przy biurku Borisa w Anthropic wisi oprawiony wydruk „The Bitter Lesson” Richa Suttona. Ten krótki post sprowadza się do jednej myśli: bardziej ogólny model zawsze pokona bardziej wyspecjalizowany.

Dla twórców produktów AI ma to konkretne przełożenie. Można dodać scaffolding — kod wokół modelu poprawiający jego wydajność w danym obszarze. Może to dać 10-20% lepsze wyniki, jednak przy kolejnym modelu ten zysk zostaje wymazany. Model po prostu robi to lepiej samodzielnie.

Liczby z Claude Code to potwierdzają: żadna część kodu nie istnieje w tej samej formie od sześciu miesięcy, narzędzia są dodawane i usuwane co kilka tygodni, a całą bazę kodu ciągle przepisuje się od podstaw. To nie wyjątek — to zasada. Scaffolding zawsze należy traktować jako dług techniczny, nigdy jako docelową architekturę.

Zasada druga: latent demand — obserwuj, co użytkownicy już robią

Drugi filar filozofii produktowej Borisa Chernego to latent demand. Sam przyznaje, że to dla niego najważniejsza idea w produkcie — i dodaje, że przez pierwsze kilka startupów jej nie rozumiał. Idea jest prosta: nie możesz sprawić, żeby ludzie robili coś nowego. Możesz tylko ułatwić im robienie tego, co już robią.

Plan mode stanowi idealny przykład. Cherny nie wymyślił go przy białej tablicy. Zauważył, że użytkownicy piszą do Claude rzeczy w stylu: „zaplanuj to, ale jeszcze nie koduj”. Różne wersje, różne sformułowania — jednak wspólny mianownik: zrób coś bez pisania kodu. W niedzielny wieczór około 22:00 Boris przeglądał issues na GitHubie i kanał feedbackowy na Slacku. Napisał plan mode w 30 minut. We wtorek rano funkcja była na produkcji.

Podobnie powstało Claude.md. Inżynierowie sami zaczęli tworzyć pliki Markdown z instrukcjami i przekazywali je modelowi. Boris tylko to zauważył i sformalizował.

Jeszcze lepszy przykład to verbose mode. Boris ukrył szczegóły odczytów plików — zamiast pokazywać „read foo.md” system wyświetlał „read 1 file, searched 1 pattern”. Dogfoodowali to przez miesiąc w Anthropic. Wydawało się w porządku. Wypuścili na zewnątrz. Użytkownicy na GitHubie zbuntowali się — chcieli widzieć szczegóły. Boris dodał verbose mode w konfiguracji. Ludzie dalej byli niezadowoleni. Więcej iteracji. To właśnie oznacza słuchanie użytkowników w praktyce.

Metoda zbierania feedbacku Chernego jest bardzo dosłowna: chodzi po biurze, zagląda przez ramię kolegom i obserwuje, jak naprawdę używają narzędzia.

Codzienny workflow Borisa z Claude Code

Cherny opisuje swój sposób pracy w kilku miejscach rozmowy. Złożone w całość, pokazuje coś znacznie bardziej radykalnego niż większość obecnych praktyk.

Około 80% sesji rozpoczyna od plan mode. Boris otwiera terminal, zleca planowanie zadania, przechodzi do kolejnej zakładki i robi to samo tam. Następnie kolejna zakładka, potem aplikacja desktopowa. Kilka równoległych planów jednocześnie. Kiedy plan jest dobry — a czasem wymaga krótkiej wymiany z modelem — Boris po prostu każe Claude wykonać. Od Opus 4.5 model niemal zawsze pozostaje na właściwym torze bez nadzorowania.

Do trudnych bugów wykorzystuje sub-agentów. W zespole nazywają głównego Claude „Mama Claude” — to ona promptuje wszystkie sub-agenty. Jak zauważa Boris, dziś większość agentów jest prawdopodobnie promptowana przez Claude, nie przez ludzi. Dla trudniejszych zadań badawczych Boris kalibruje liczbę sub-agentów do trudności problemu: 3, 5, nawet 10 pracujących równolegle.

Przykład najlepiej to ilustrujący: memory leak w Claude Code. Zamiast ręcznie analizować heap dump w devtools, inny inżynier z zespołu po prostu zapytał Claude. Model napisał dla siebie narzędzie do analizy heap dumpa i znalazł leak szybciej niż Boris robiący to manualnie.

A co z Claude.md? Cherny przed wywiadem sprawdził swój plik. Ma dokładnie dwie linie:

Włącz auto-merge na każdym PR
Opublikuj PR w kanale zespołu dla szybkich review

Cała reszta instrukcji znajduje się w Claude.md zaczekowanym do repozytorium — do którego cały zespół współtworzy wiele razy w tygodniu. Boris często taguje Claude bezpośrednio na PR-ach: „dodaj to do Claude.md”. Radzi: jeśli Twój Claude.md jest za długi, po prostu usuń go i zacznij od zera. Dodawaj z powrotem tylko to, co naprawdę potrzebne.

Checklista: workflow z Claude Code według Borisa Chernego

Rozpocznij sesję od plan mode — nie od kodowania
Otwórz kilka równoległych zakładek z różnymi planami jednocześnie
Gdy plan jest dobry, każ Claude wykonać — nie nadzoruj ciągle
Do trudnych bugów wykorzystaj sub-agentów (np. jeden analizuje logi, drugi ścieżkę kodu)
Kalibruj liczbę agentów do trudności zadania (łatwe = 1, trudne = 3-10)
Rzeczy powtarzające się często — wrzuć do Claude.md; resztę po prostu przepromptuj
Gdy Claude.md staje się zbyt długi — usuń i zacznij od zera, dodając tylko niezbędne elementy

Produktywność: +150% w Anthropic i 1000x vs Google

Boris Cherny przytacza konkretne liczby. Zespół Anthropic podwoił się w ciągu roku, lecz produktywność na inżyniera mierzona pull requestami wzrosła o 150%.

Żeby zrozumieć wagę tej liczby, Cherny daje kontekst z poprzedniej roli. Gdy odpowiadał za jakość kodu w Meta — przy wszystkich produktach, Facebooku, Instagramie, WhatsAppie — zespół pracował nad poprawą produktywności. Wzrost rzędu 2% był wynikiem roku pracy setek ludzi. 150% to nie drobna poprawa, ale zmiana jakościowa.

Liczby spoza Anthropic są jeszcze bardziej spektakularne:

1000x produktywność inżyniera Anthropic vs inżyniera Google w szczytowej formie (według posta Steve’a Yegge’a)
70% startupów wybiera Claude jako główny model (dane Mercury)
4% wszystkich publicznych commitów na świecie tworzy Claude Code
NASA użyła Claude Code do plotowania kursu dla rovera Perseverance na Marsie (Boris wydrukował postery — jak mówi, to była najfajniejsza rzecz dla zespołu)

Od Opus 4.5 Boris nie edytuje ręcznie ani jednej linii kodu. Odinstalował IDE. Ląduje 20 pull requestów dziennie.

Terminal dla przeciętnego inżyniera, nie dla Vim ninja

Jedna rzecz może być zaskakująca: Boris używa VS Code. Nie Vim, nie Emacs, nie tmux. Zwykłego VS Code. Sam przyznaje: uważa się za przeciętnego inżyniera, nie wykorzystuje zaawansowanych narzędzi.

To istotne, ponieważ łatwo założyć, że twórca narzędzia terminalowego to zagorzały zwolennik command-line. Jednak Boris budował Claude Code dla ludzi takich jak on — nie dla specjalistów. Nie musisz rozumieć Vim, tmux, SSH czy innych zaawansowanych narzędzi. Po prostu otwierasz terminal i zaczynasz.

W zespole są ludzie jak Adam Wolf, którzy mówią: „nigdy nie zabierzecie mi Vima”. To w porządku, lecz Claude Code nie wymaga tego poziomu zaawansowania.

Jak zauważa Cherny, terminal został terminalem przez przypadek — rok temu myślał, że ma 3-miesięczny lifespan. Dziś Claude Code działa w terminalu, web (claude.ai/code), aplikacji desktopowej, iOS, Android, Slack, GitHub, rozszerzeniach VS Code i JetBrains. Terminal jednak pozostał. Boris wielokrotnie mylił się co do tego, co zadziała.

Claude Code buduje Claude Code (i wszystko inne)

Jedną z najbardziej meta rzeczy w tym wywiadzie jest moment, gdy Boris wspomina o funkcji Plugins. Została zbudowana w weekend, całkowicie przez swarm agentów. Bez interwencji człowieka. Inżynier przekazał Claude specyfikację i polecił użycie tablicy Asana. Claude stworzył tickety, uruchomił wiele agentów, które zaczęły podejmować zadania. Główny Claude — „Mama Claude” — dawał instrukcje. Agenty się porozumiały. Plugins wyszedł w formie, w jakiej powstał, i trafił na produkcję.

To nie jedyny przykład. Zespół wykorzystuje Claude Agent SDK do automatyzacji praktycznie każdej części developmentu: code review, security review, labelowanie issues, przenoszenie rzeczy na produkcję. Większość procesów jest zautomatyzowana przez agenty.

Cowork — narzędzie non-technical do Claude Code? Zbudowane w 10 dni, w 100% przez Claude Code. Felix z zespołu (wczesny współtwórca Electron) hakował różne pomysły i po prostu wypuścił to, co działało.

Skąd wiedzieli, że Cowork ma sens?

Latent demand. Ponownie. Boris i zespół obserwowali, jak ludzie już wykorzystują Claude Code do rzeczy niezwiązanych z kodowaniem:

Ktoś monitorował pomidory w ogródku
Ktoś odzyskiwał zdjęcia ślubne z uszkodzonego dysku
Ludzie używali tego do finansów
Cały zespół designerski w Anthropic korzystał
Cały zespół finansowy korzystał
Dział sprzedaży korzystał

Ludzie przeskakiwali przez przeszkody, żeby zainstalować narzędzie terminalowe — do celów poza kodowaniem. To był sygnał. Dlatego Felix i zespół zbudowali wrapper z GUI w aplikacji desktopowej z zabezpieczeniami dla użytkowników nietechnicznych (virtual machine, permission prompting, guardrails przy usuwaniu). 10 dni pracy Claude. Gotowe.

Jakich ludzi szukać i jak ich rozpoznać

Cherny zmienia też sposób myślenia o rekrutacji. Stare podejście — szukaj ekspertów z silnymi opiniami i dużym doświadczeniem — przestało działać tak samo. Seniorzy są nagradzani za silne opinie, jednak wiele z nich po prostu przestało być aktualnych. Model się zmienił, intuicje sprzed sześciu miesięcy też.

Najlepsi inżynierowie w zespole to według niego dwa typy: hiper-specjaliści, którzy rozumieją jeden obszar lepiej niż ktokolwiek inny (przykład: Jared i JavaScript runtimes), oraz hiper-generaliści, którzy spinają produkt z infrastrukturą, designem, researchem i biznesem jednocześnie.

Pytanie rekrutacyjne Chernego: „Kiedy ostatnio się myliłeś?” Chce zobaczyć, czy ktoś potrafi przyznać się do błędu, wyciągnąć wniosek i zmienić sposób myślenia.

Najbardziej konkretny przykład typu myślenia, którego szuka: Daisy, inżynierka która przeniosła się do zespołu Claude Code z innego zespołu. Kilka tygodni po dołączeniu postawiła PR dodający nową funkcję. Zamiast jednak po prostu ją zaimplementować, najpierw dała Claude narzędzie do testowania dowolnego narzędzia. Dopiero potem kazała Claude napisać feature zamiast robić to sama. To dokładnie ten rodzaj nieszablonowego myślenia, którego Boris szuka.

Cherny i jego zespół eksperymentują też z oceną kandydatów przez analizę transkryptów ich sesji z Claude Code.

Checklista: jak ocenić kandydata przez transkrypt sesji z Claude Code

Czy przegląda logi i je analizuje?
Czy potrafi zatrzymać agenta, gdy schodzi z kursu?
Czy stosuje plan mode przed kodowaniem?
Czy weryfikuje obecność testów?
Czy myśli o systemach — nie tylko o konkretnym zadaniu?
Czy rozumie, kiedy plan jest przeładowany (overengineered)?
Czy potrafi poprawić agenta zamiast poddać się i zrobić ręcznie?

Co czeka software development

Boris Cherny nie unika mocnych stwierdzeń. Jego prognoza: kodowanie zostanie „rozwiązane” dla wszystkich. Dziś jest praktycznie rozwiązane dla niego — wkrótce będzie dla każdego, niezależnie od domeny. Tytuł „software engineer” prawdopodobnie zniknie. Zastąpi go coś bliższego „builderowi” lub product managerowi — albo pozostanie jako forma szczątkowa, lecz praca będzie wyglądać zupełnie inaczej. Inżynierowie będą pisać specyfikacje, rozmawiać z użytkownikami, myśleć o systemach.

W Anthropic ten świat już istnieje: PM-owie kodują, designerzy kodują, dział finansowy koduje, dział sprzedaży koduje. Role stały się płynne. Każda funkcja w zespole Borisa koduje.

Górna granica prognoz Chernego jest bardziej niepokojąca. Mówi wprost o ASL4 — poziomie bezpieczeństwa, przy którym model byłby zdolny do rekurencyjnego samodoskonalenia. Oraz o ryzyku katastroficznego nadużycia: projektowaniu bioweaponów, exploitów zero-day. To nie science fiction dla Borisa — to powód, dla którego wybrał Anthropic zamiast innego miejsca pracy. W przerwie lunchowej w Anthropic ludzie rozmawiają o AI safety — nie jako corporate talk, lecz jako rzeczywistą troskę.

Biblioteka promptów z Claude Code — co działa w praktyce

Boris Cherny i jego zespół nie stosują skomplikowanych promptów. Większość to krótkie, konkretne instrukcje — zapisane w Claude.md lub podawane ad hoc w zależności od sytuacji.

Prompty podstawowe

Plan mode (zamiast wbudowanego trybu):

Please don't code yet

Kiedy używać: Gdy chcesz, żeby Claude przemyślał rozwiązanie przed implementacją. To dosłownie cały kod plan mode — jedna linijka w prompcie.

Pierwsze odkrycie możliwości (eksploracja):

What music am I listening to?

Kiedy używać: Nie dosłownie to pytanie, lecz ten typ promptu — pytanie wymagające od modelu połączenia kilku kroków i użycia dostępnych narzędzi. Boris użył tego, żeby sprawdzić, czy model potrafi samodzielnie napisać AppleScript. To był jego „moment AGI”.

Prompty do Claude.md (osobisty)

Auto-merge PR (Claude.md Borisa):

Whenever you put up a PR, enable auto-merge

Kiedy używać: Jeśli pracujesz sam lub w małym zespole i chcesz minimalizować friction. PR merguje się automatycznie po zatwierdzeniu.

Notyfikacja zespołu o PR:

Whenever I put up a PR, post it in our internal team stamps channel

Kiedy używać: Gdy potrzebujesz szybkich review. Automatyczna notyfikacja oznacza szybszą pętlę sprzężenia zwrotnego.

Prompty do Claude.md (zespołowe, na poziomie repozytorium)

Ocena architektury (ulubiony prompt Borisa):

For every plan, decide whether it's overengineered, underengineered, or perfectly engineered. And why.

Kiedy używać: W Claude.md na poziomie repozytorium. Zmusza model do myślenia o kompromisach między prostotą a złożonością przy każdym planie. Boris szczególnie to podkreśla jako wartościowe.

Dodawanie do Claude.md przez PR comment:

@claude add this to Claude.md

Kiedy używać: Gdy widzisz błąd w PR, któremu można było zapobiec instrukcją. Boris robi to wiele razy w tygodniu — taguje Claude na PR, Claude dodaje regułę do Claude.md na poziomie repozytorium.

Prompty do sub-agentów

Kalibracja liczby agentów do trudności:

Use [3/5/10] subagents to research this in parallel

Kiedy używać:

Proste zadanie = nie wspominaj, użyje 1
Średnio trudne = 3 agenty
Trudne = 5 agentów
Bardzo trudne research = 10 agentów równolegle

Boris dostosowuje to do złożoności problemu. Im więcej niepewności, tym więcej równoległych perspektyw.

Debug z sub-agentami:

I think there's a memory leak. Can you run this?

Kiedy używać: Przykład od Chrisa z zespołu — nie mówisz Claude JAK debugować, tylko przedstawiasz problem. Claude samodzielnie wziął heap dump, napisał narzędzie do analizy, znalazł leak. Lepsze niż manualne devtools.

Prompty które użytkownicy pisali PRZED plan mode

Boris zauważył te wzorce i dlatego stworzył plan mode:

Come up with an idea and plan this out, but don't write any code yet

Think through this approach but don't implement anything

Give me a spec for this feature without coding it

Kiedy używać: Jeśli nie masz dostępu do plan mode lub chcesz więcej kontroli nad tym, jak dokładnie Claude ma pomyśleć. Teraz to jest wbudowane, jednak warto znać wzorzec.

Prompty do automatyzacji workflow (z transkryptu — przykład Plugins)

Tworzenie zadań przez Claude:

[Inżynier przekazał Claude specyfikację i polecił użycie tablicy Asana]

Claude samodzielnie:

Stworzył tickety w Asanie
Uruchomił sub-agenty
Sub-agenty brały zadania
„Mama Claude” koordynowała

Kiedy używać: Duże projekty, które można podzielić na niezależne części. Claude może pełnić rolę product managera rozdającego zadania innym instancjom Claude.

Anti-pattern: Za długi Claude.md

Czego NIE robić: Nie pakuj wszystkiego do Claude.md. Boris radzi: jak jest za długi — usuń cały plik i zacznij od zera. Dodawaj tylko rzeczy, które naprawdę się powtarzają i które model robi źle.

Każdy nowy model potrzebuje MNIEJ instrukcji niż poprzedni. Twój Claude.md sprzed 6 miesięcy jest prawdopodobnie przestarzały.

Kluczowa obserwacja o promptach

Boris wspomina, że większość instrukcji w Claude.md zespołu znajduje się na poziomie repozytorium, nie osobistym. Jego osobisty Claude.md to 2 linie. Cała reszta to wspólne best practices, które cały zespół buduje razem.

To pokazuje, że dobre prompty nie stanowią sekretnej wiedzy jednej osoby — to shared knowledge base rozwijająca się z doświadczeniem zespołu.

Książki i źródła wspomniane w rozmowie

The Bitter Lesson — Rich Sutton (post blogowy, obowiązkowa lektura dla każdego budującego na AI)
Twórczość sci-fi (Boris nie podaje tytułów, jednak zaznacza, że jego półka jest pełna — literatura science fiction kształtuje jego rozumienie ryzyk AI)

Kluczowy insight

Długi lifespan kodu = sygnał opóźnienia

Standardowe myślenie: Dobry kod to kod łatwy w utrzymaniu — SOLID, DRY, clean architecture. Przepisywanie kodu oznacza marnotrawstwo. Legacy code to dług techniczny wymagający zarządzania. Jeśli ciągle przepisujesz, coś robisz źle.

Praktyczna rzeczywistość: W erze AI jest dokładnie odwrotnie. Boris mówi wprost: żadna część Claude Code nie istnieje w formie sprzed sześciu miesięcy. Dodaje również: produktywność w Anthropic wzrosła o 150% od wdrożenia Claude Code. Nie pomimo ciągłego przepisywania — dzięki ciągłemu przepisywaniu.

Dlaczego to istotne: Model zmienia się co miesiąc. Kod napisany dla modelu sprzed 6 miesięcy jest zoptymalizowany pod możliwości, które model już dawno przekroczył. Scaffolding dodany w marcu staje się niepotrzebny we wrześniu — model już to potrafi samodzielnie. Im dłużej trzymasz stary kod, tym bardziej tracisz na produktywności, którą mógłbyś osiągnąć z nowym modelem.

Test na jutro: Otwórz swój główny projekt. Uruchom git log --all --format="%ai %H" | sort i sprawdź, ile plików nie było modyfikowanych przez ponad 6 miesięcy. Jeśli to ponad 30% bazy kodu — prawdopodobnie masz dług w formie scaffoldingu dla starego modelu. Następnym razem, gdy model się zaktualizuje, zamiast dodawać więcej kodu wokół niego, zastanów się, co możesz USUNĄĆ — ponieważ nowy model już to potrafi.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: The Light Cone (YC) — „Boris Cherny: How We Built Claude Code„