Poniższy artykuł stanowi zapis notatek z webinaru, w którym Teresa Torres dzieliła się swoimi doświadczeniami. Wszystkie opisane przemyślenia, obserwacje i wnioski pochodzą bezpośrednio od prelegentki.

TL;DR

Zacznij od prostych narzędzi, które znasz – Torres wykorzystała Airtable zamiast uczyć się skomplikowanych platform ewaluacyjnych
Wiedza domenowa przewyższa umiejętności techniczne – głębokie zrozumienie customer interviews pozwoliło stworzyć skuteczniejsze ewaluacje niż pure coding skills
Ucz się w praktyce, wspierając się AI – Torres opanowała Python i Jupyter notebooks, traktując ChatGPT jak osobistego mentora przy każdej linii kodu
Systematyczna ewaluacja ujawnia ukryte błędy – wizualizacja wyników pokazała problemy niewidoczne w subiektywnych ocenach „vibe checking”
Proste rozwiązania często przewyższają skomplikowane – detekcja przez słowa kluczowe okazała się skuteczniejsza niż LLM-based evaluation
Mierz przed każdą zmianą – Torres zredukowała błędy z 81% do 3% dzięki systematycznemu testowaniu każdej modyfikacji
Dobry system ewaluacji poprawia także ludzkie decyzje – pomaga doprecyzować kryteria i ujednolicić sposób oceny w zespole

Teresa Torres, autorka książki „Continuous Discovery Habits” i uznana ekspertka w dziedzinie product management, w swojej prezentacji opowiedziała historię transformacji z osoby nie znającej podstaw ewaluacji AI do twórczyni działającego produktu w środowisku produkcyjnym.

Problem: jak skutecznie uczyć customer interviews?

Torres prowadzi kursy dla product managerów, w tym program „continuous interviewing”, gdzie uczesznicy uczą się przeprowadzać wywiady z klientami. Jej specjalizacją są rozmowy oparte na konkretnych historiach z przeszłości – metodologia, która według Torres dostarcza bardziej wiarygodnych informacji niż standardowe pytania o preferencje.

W marcu, podczas rekonwalescencji po operacji kostki, Torres rozpoczęła rozważania nad fundamentalnym pytaniem: „Co generatywne AI czyni teraz możliwym?” W kontekście prowadzonych przez nią kursów największy potencjał dostrzegła w usprawnieniu procesu przekazywania informacji zwrotnej studentom.

Zidentyfikowany problem był jasny. Studenci w klasie przekazują sobie nawzajem informacje zwrotne na podstawie rubryk, jednak nie posiadają odpowiedniej ekspertyzy. Dlatego Torres podjęła decyzję o stworzeniu narzędzia, które pomoże im w lepszym, bardziej szczegółowym ocenianiu praktycznych wywiadów.

Interview coach: od pomysłu do pierwszej wersji

Rezultatem prac był interview coach – narzędzie analizujące transkrypty wywiadów i oceniające je w czterech wymiarach:

Story-based questions – czy zadano pytanie o konkretną historię
Setting the scene – czy pomożono uczestnikowi „ustawić scenę” dla lepszego przywoływania wspomnień (cognitive tip dla memory recall)
Building timeline – czy pomożono przejść krok po kroku przez historię, żeby dowiedzieć się, co faktycznie się stało
Redirecting generalizations – przykład Torres: jeśli zapytasz o ostatni raz oglądania Netflix, osoba zacznie generalizować o tym, co zwykle robi na Netflix. Zadanie interviewer’a to przekierowanie z powrotem na specifics tej konkretnej historii

Każdy wymiar otrzymuje ocenę (keep practicing, getting it, great) oraz konkretną informację zwrotną z cytatami z transkryptu plus praktyczne wskazówki. Torres podkreśliła, że prezentowana wersja stanowi jedynie fragmentaryczną odpowiedź – coach generuje znacznie więcej treści.

Pułapka „vibe checking”: Początkowo Torres sprawdzała intuicyjnie odpowiedzi – niektóre wyglądały dobrze, inne miały problemy. Jak zauważyła, to szybko prowadziło do frustrującej sytuacji: mała zmiana w prompcie mogła poprawić jeden fragment odpowiedzi, ale jednocześnie pogorszyć inny. Brakowało systematycznego sposobu mierzenia jakości oraz sprawdzania, czy zmiany rzeczywiście coś poprawiają.

Wraz z rozwojem narzędzia problem nasilał się. Torres wyjaśniła: „Jej narzędzie zaczęło się od prostego promptu, lecz z czasem rozwinęło się do złożonego procesu składającego się z 5–9 wywołań LLM.” Wraz ze wzrostem złożoności, systematyczna ewaluacja stała się koniecznością.

Odkrycie ewaluacji: od chaosu do nauki

Torres rozpoczęła poszukiwanie rozwiązań, jednak natrafiła na dokumentację OpenAI o ewaluacjach. Problem? Brzmiało to jak konieczność posiadania ogromnych zbiorów danych. Próby syntetycznego generowania transkryptów wywiadów okazały się, jak to ujęła, „do dupy”.

Przełom nastąpił po przeczytaniu artykułu Amon Khana w newsletterze Lenny’ego o różnych typach ewaluacji. To doprowadziło ją do klasy o automated evaluations, gdzie w pierwszej sesji „zapaliły się żarówki”.

Torres rozpoznała w modelu ewaluacji metodę naukową, którą sama nauczała. To był moment, gdy pomyślała: „jestem w grze”.

Ważny kontekst: Torres ma wykształcenie w symbolic systems na Stanfordzie – interdyscyplinarny program łączący informatykę, lingwistykę, filozofię analityczną oraz psychologię poznawczą. Wszystko skupione na tym, jak ludzie i maszyny przetwarzają informacje. To dało jej silne podstawy w krytycznym myśleniu oraz rozwiązywaniu problemów – umiejętności, które okazały się kluczowe w nauce automatycznych ewaluacji.

Pierwszy tydzień: od Airtable do działających ewaluacji

Zamiast od razu rzucać się na skomplikowane narzędzia, Torres zastosowała metodyczne podejście krok po kroku:

1. Start z prostymi narzędziami

Torres zaczęła od tego, co znała – Airtable. Zebrała około 35 wywiadów (15 własnych, 10 od instruktorów, 10 od absolwentów) oraz użyła interfejsu Airtable jako swojego pierwszego annotation tool. Dzięki temu mogła szybko zobaczyć, jakiego rodzaju problemy rzeczywiście występują i w jakiej skali.

2. Ręczna analiza błędów

Pierwszy szok przyszedł, gdy zobaczyła wszystkie failure modes: „Holy crap, mój coach ssie”. Torres przeprowadziła ręczną kategoryzację błędów, co pozwoliło jej zidentyfikować najczęstsze oraz najbardziej krytyczne problemy.

3. Nauka narzędzi „just-in-time”

Kluczowy moment nastąpił w niedzielny wieczór, gdy usiadła do zaprojektowania pierwszych ewaluacji. Mąż zasugerował Jupyter notebooks, o których Torres wcześniej nie słyszała. ChatGPT wyjaśnił, czym są notesy, więc Torres zaczęła eksperymentować.

Zabawny szczegół: Torres początkowo pisała pseudokod w Apple Notes, które automatycznie zamieniały cudzysłowy na „smart quotes” – przez co kod się nie kompilował. Frustrowała się, aż mąż zapytał: „dlaczego nie użyjesz Jupyter notebook?”

Dwie przełomowe ewaluacje

Torres stworzyła dwie pierwsze ewaluacje dla swoich największych obaw:

1. Leading questions eval (LLM-based) Jeśli coach sugerował pytanie prowadzące (sugerujące odpowiedź), test nie przechodził. Torres iterowała nad strategiami – czasem wysyłała wszystkie pytania naraz, czasem pojedynczo, testowała różne konteksty.

2. General questions eval (code-based) Znacznie prostsze rozwiązanie. Zamiast uczyć LLM, czym są general questions, Torres stworzyła listę słów kluczowych, które wskazują na problematyczne pytania. Ta „elementarna ewaluacja” ma wysoką zgodność z ludzkimi ocenami oraz prawie zero fałszywie pozytywnych wyników.

Torres podkreśla moment olśnienia: „kto ma to robić w prawdziwym życiu?” Zrozumiała, że domain expertise była kluczowa – tylko dzięki latom nauczania customer interviews mogła zidentyfikować ten wzorzec.

Ewolucja narzędzi i podejścia

Partnerowanie z AI w nauce

Torres nigdy wcześniej nie widziała Pythona, jednak ChatGPT stał się jej przewodnikiem. Kluczowa zasada: „nie uruchomię kodu, którego nie rozumiem”.

Jej proces uczenia się z AI obejmował:

Analizowanie każdej linii kodu przed skopiowaniem
Pytanie o znaczenie niezrozumiałych fragmentów
Brak wstydu przy zadawaniu „głupich pytań” – LLM nie ocenia
Iterowanie w trybie konwersacyjnym zamiast single-shot prompting
Kopiowanie i wklejanie fragmentów z pytaniem „co to znaczy?”

To stanowiło przeciwieństwo frustracji z czasów studiów, gdy bała się zadawać „głupie pytania” asystentom czy kolegom. LLM nie ocenia – można zadać dowolne pytanie bez wstydu.

Notebooks jako game-changer

W jednym notesie Torres mogła brainstormować różne implementacje w markdown, testować trzy różne podejścia w osobnych cell blocks, porównywać wyniki oraz iterować bez tracenia poprzednich wersji.

Helper functions okazały się kluczowe. Torres wyodrębniła przetwarzanie transkryptów do osobnych funkcji, co zmniejszyło koszty LLM calls, przyspieszyło ewaluacje oraz umożliwiło eksperymentowanie z różnymi strategiami kontekstowymi.

To podejście nazywa „context engineering” – ograniczenie kontekstu do minimum potrzebnego dla danej ewaluacji, co poprawia zarówno wydajność jak i efektywność kosztową.

Pierwsze rezultaty i niespodzianki

Pierwszy przebieg ujawnił fascynujące rzeczy. Leading questions pojawiały się w 20-25% przypadków. Jedna ewaluacja przechodziła konsekwentnie negatywnie, ale po głębszej analizie okazało się, że problem był w ludzkich labelach, nie w kodzie – ewaluacja była lepsza niż human judgment.

Bug w helper function został wykryty dzięki systematycznej analizie danych. Torres była zaskoczona, jak daleko zaszła w cztery dni, biorąc udział w klasie.

Dzisiejsza infrastruktura: od notebook do production

VS Code i Claude Code

Torres przeszła na VS Code głównie ze względu na integrację z Claude Code. Ważne rozróżnienie: nie robi „vibe coding” z Claude Code. Nadal pair-programuje, rozumiejąc każdą linię kodu.

„Jestem dobra w opisywaniu, czego chcę”, mówi Torres. Claude Code może napisać większość kodu, ale Torres musi wszystko zrozumieć oraz zaakceptować. Jej zasada: „optimalizuję pod 4-line diffs, nie 1000-line diffs” – małe, zrozumiałe zmiany zamiast massive code dumps.

Kluczowe rozróżnienie: Torres pracuje w „planning mode” oddzielonym od implementation. Najpierw dyskutuje z Claude różne podejścia, analizuje pros & cons, wybiera strategię – bez dotykania kodu. Dopiero potem przechodzi do step-by-step implementation.

Enterprise-level narzędzia

Torres rozbudowała infrastrukturę do poziomu enterprise:

Infrastruktura ewaluacji:

Cały katalog ewaluacji w projekcie (nie w notebooks)
AB test runner napisany przez Claude Code
Guardrails running na percentage of traces w production

Development & analysis:

Custom annotation tools z keyboard shortcuts i progress bars
Około pół tuzina różnych annotation tools – czasem dla whole trace, czasem dla pojedynczych pytań
Widgets w notebooks do diagnostyki individual traces
Caching system dla expensive helper functions
Production eval code separated od data analysis notebooks

Kreatywne podejście do annotacji: Torres eksperymentowała z Claude jako annotation interface. Dała Claude listę pytań i powiedziała: „pokazuj mi jedno na raz, powiem ci failure mode.” Przeannotowała 100 rekordów w mniej niż 10 minut.

Production success story

Największy sukces: przejście od notebook prototype do SOC 2 compliant production feature w Vistaly – platformie do product discovery.

Nieoczekiwany problem: Torres planowała narzędzie dla practice interviews w kursach, ale studenci zaczęli wysyłać prawdziwe customer interviews z wrażliwymi danymi. „To było scary – po prostu wrzucałam to do Airtable, nie byłam SOC 2 compliant.” Musiała przestać przyjmować takie dane.

Rozwiązanie? Partnerstwo z Vistaly, gdzie product teams już przechowują customer interviews w sposób zgodny z wszystkimi przepisami data management.

W ciągu ostatnich dwóch tygodni Torres musiała nauczyć się być „prawdziwym software engineerem” z dev/prod environments oraz professional error handling. Dwa tygodnie temu nigdy nie pracowała w IDE i nie miała środowisk dev/prod.

Kluczowe lekcje dla product managerów

Domain expertise > umiejętności techniczne

Torres podkreśla, że jej sukces wynikał z lat doświadczenia w uczeniu customer interviews. Engineer bez tej wiedzy prawdopodobnie nie zidentyfikowałby kluczowych wzorców.

Kluczowe pytanie: „kto ma to robić w prawdziwym życiu?” Torres rozumie, że nie każdy PM będzie kodować jak ona, ale domain expertise musi być zaangażowana w design ewaluacji. Jej refleksja jest jednoznaczna: „gdyby to zadanie przypadło wyłącznie inżynierom, wiele skutecznych rozwiązań — takich jak proste reguły w kodzie — nigdy by nie powstało.”

Jako discovery coach ucząca cross-functional collaboration, Torres widzi potrzebę bardzo bliskiej współpracy, ponieważ nie każdy product manager będzie pisać kod, ale musi być zaangażowany w projektowanie swoich ewaluacji.

Mierz przed optymalizacją

Torres stosuje systematyczne podejście do każdej zmiany:

Standard workflow:

Baseline measurement na zbiorze testowym
Implementacja pojedynczej zmiany (prompt/temperatura/workflow)
Uruchomienie ewaluacji na tym samym zbiorze testowym
Analiza trade-offs – które ewaluacje się poprawiły, które pogorszyły
Świadoma decyzja o release vs rollback

„Nigdy nie jest całkowicie lepiej lub gorzej – niektóre ewaluacje się poprawiają, inne pogarszają.”

Przykład sukcesu: problem z duplicate excerpts:

Baseline: 81% transcripts affected
Solution: send previous excerpts to subsequent LLM calls
Result: 3% transcripts affected
Time: 3 dni od detection do fix

Incremental learning approach

Kluczowa strategia: ograniczaj ile musisz nauczyć się w każdym kroku. Torres zaczęła od Airtable, ponieważ znała narzędzie. Dodawała complexity stopniowo.

Jej pattern: zidentyfikuj najmniejszy element do nauczenia → wykorzystaj LLM do jego zrozumienia → iteruj → repeat.

Przyszłość: otwarte pytania o collaboration

Torres nadal zastanawia się nad rolami w zespołach. Niektóre pomysły to PM jako engineer z instructor jako data analyst, notebooks jako sposób na obfuscation kodu przy zachowaniu możliwości wykonania, czy nowe skills w „pair programmingu” z LLM.

Planuje podcast o cross-functional teams building AI products – nie o tym, jak ludzie używają AI w codziennej pracy, ale o konkretnych historiach produktów AI oraz współpracy zespołów.

Obsesja i pasja

Torres przyznaje, że ma więcej funu niż kiedykolwiek w karierze i jest obsessed. Koduje cały dzień, a mąż żartuje, że „zerwała z nim dla Claude’a.” Musi ustawiać timer na zegarku, żeby przypominał jej o robieniu przerw.

„To feels like lata 90te, początek internetu – wszyscy się nakręcają i uczą, dzielą się ze sobą.”

Plany na przyszłość: Torres planuje rozwijać Interview Coacha w stronę inteligentnego agenta, który dostosowuje feedback do indywidualnej ścieżki nauki studenta. Jak podkreśla, „chciałabym, żeby coach analizował historię nauki studenta i dostosowywał feedback na podstawie tego, gdzie student jest w swojej edukacyjnej podróży.” To dopiero początek tej drogi – vision obejmuje przejście do pełnego agent model.

Praktyczny sukces: od 81% do 3% błędów

Jeden z najlepszych przykładów skuteczności metodyki Torres: problem z powtarzającymi się excerptami między wymiarami. Początkowo próbowała stworzyć question classifier – skomplikowane oraz nieefektywne.

Rozwiązanie? Wysyłaj kolejnym LLM calls listę już użytych excerptów z instrukcją, żeby ich nie używać. Proste, ale skuteczne – od 81% transcripts affected do 3% w trzy dni.

Prawdziwe wyzwania production: step functions error handling

Torres opowiada o kryzysie tuż przed release do Vistaly. Jej integration test wykrył uncaught error w step functions, którego wcześniej nie zauważyła. Okazało się, że JSON path errors w step functions nie są catchable ani retryable – po prostu powodują niepowodzenie całej funkcji.

Problem był poważny: wszystkie jej error handling między step function calls były źle zaimplementowane. Zamiast wyrzucać exceptions, zwracała errors w payload, co się nie łapało.

Rozwiązanie w trybie emergency (środa-piątek):

Przedyskutowała z Opus i O3 różne error handling patterns
Przeanalizowała pros & cons każdego podejścia
Stworzyła detailed project plan w „planning mode” (bez dotykania kodu)
Step by step przeprowadziła re-architekturę całego error handling
Release w poniedziałek rano

Walidacja: ChatGPT-5 przeanalizowało finalny kod oraz stwierdziło: „masz naprawdę solidny error handling.” Torres była zachwycona tym feedbackiem.

Tylko dwa sposoby na wypróbowanie: continuous interviewing course Torres lub Vistaly. Torres rozważa stworzenie light version publicznie dostępnej – przynajmniej feedback na leading/general questions.

Forward-looking: customer feedback loops

Torres myśli o przyszłości produktu w kontekście customer feedback loops – swojej specjalizacji. Prawie każdy AI product ma thumbs up/thumbs down, ale to nie daje granular insights.

Eksperymentuje z UX patterns, które mogłyby umożliwić bardziej szczegółowy feedback: nie tylko „helpful/not helpful” dla całej odpowiedzi, ale feedback na level individual excerpts czy tips. Jak zbliżyć customer do problemu oraz uzyskać actionable feedback na product improvement?

Checklista: jak zacząć z automatycznymi ewaluacjami (metoda Torres)

Przygotowanie (tydzień 0)

Zdefiniuj konkretny problem do rozwiązania (nie „chcę robić ewaluacje”)
Zbierz 20-50 przykładów rzeczywistych danych (nie synthetic)
Zidentyfikuj top 2-3 failure modes przez manual review
Wybierz znane narzędzie do zaczynania (Airtable/Excel/Sheets)

Pierwsze ewaluacje (tydzień 1)

Stwórz annotation tool w znanym narzędziu
Napisz 1-2 proste ewaluacje dla najważniejszych error cases
Przetestuj code-based approach przed LLM-based (często skuteczniejszy)
Zmierz baseline performance na swoich danych
Dokumentuj wszystko w notebook/spreadsheet

Rozwój (tygodnie 2-4)

Iteruj na alignment z human judgment
Wyodrębnij helper functions do preprocessing
Stwórz visualization wyników ewaluacji
Zbuduj feedback loop dla każdej zmiany w systemie
Rozdziel kod ewaluacji od data analysis

Red flags – kiedy zatrzymać się i przemyśleć

⚠️ Piszesz kod, którego nie rozumiesz – zawsze analizuj każdą linię
⚠️ Złożoność ewaluacji rośnie szybciej niż value – może potrzebujesz prostszego podejścia
⚠️ Spędzasz więcej czasu na infrastrukturze niż na domain problemie – wróć do podstaw
⚠️ Human agreement z ewaluacjami spada – problem może być w rubrycznie, nie w kodzie
⚠️ Nie mierzysz przed każdą zmianą – ślepe iterowanie to strata czasu

Biblioteca promptów Torres: sprawdzone formułki

Na podstawie transkryptu, oto konkretne prompty oraz strategie, które Torres używała w swojej drodze od zera do production. Wszystkie sprawdzone w praktyce:

Learning & getting started

„Jestem totalnym początkującym. Czym jest jupyter notebook?” Kiedy: Gdy natrafiasz na nowy tool/concept i potrzebujesz basic explanation. Torres podkreśla – nie wstydź się „głupich pytań.”

„Oto co próbuję zrobić. Czy możesz pomóc mi dowiedzieć się, jak to zrobić?” Kiedy: Masz jasny cel, ale nie wiesz jak go osiągnąć. Torres używała tego pattern przez całą naukę.

Code understanding & debugging

„Co masz na myśli przez to?” [kopiuje konkretną linię kodu] Kiedy: Nie rozumiesz fragmentu kodu. Torres nigdy nie kopiowała kodu, którego nie rozumiała – zawsze pytała o każdą linię.

„Wygląda na to, że moje ewaluacje dały to, a ja dałam to. Czy możesz stworzyć cell block, gdzie mogę porównać mój human label z eval label?” Kiedy: Potrzebujesz custom analysis tool. Torres iterowała z ChatGPT, żeby notebook stał się jej data analysis environment.

Planning & architecture

„Oto mój testing pattern. Jakie są istniejące wzorce? Jakie są najlepsze praktyki? Jak to naprawić?” Kiedy: Natrafiasz na complex technical problem. Torres używała tego dla error handling w step functions.

„Opowiedz mi o zaletach i wadach każdego [podejścia]” Kiedy: Masz kilka options i potrzebujesz help z decision making. Torres przeanalizowała tak 3-4 error handling patterns.

„Spójrz na moją bazę kodu i ile zmian musimy wprowadzić oraz jak stworzyć plan projektu?” Kiedy: Wiesz co chcesz zmienić, ale potrzebujesz structured approach. Torres używała tego w „planning mode” przed implementation.

Quality assurance & validation

„Przetestuj mój error handling” Kiedy: Chcesz stress-test swojej work. Torres użyła tego z ChatGPT-5 przed production release.

„Czego się nauczyłeś z tej rozmowy? Udokumentujmy to.” Kiedy: Po skomplikowanej sesji potrzebujesz summary dla przyszłego siebie. Torres robiła to regularnie z Claude Code.

Creative annotation solutions

„Pokaż mi jedno [pytanie] na raz, a ja po prostu powiem ci failure mode” Kiedy: Potrzebujesz fast annotation interface. Torres przeannotowała tak 100 rekordów w 10 minut.

Iterative improvement requests

„Podoba mi się interfejs z tego annotation tool, ale teraz mam nowy input lub nowy output format. Po prostu stwórz kolejne narzędzie” Kiedy: Masz working solution, ale potrzebujesz variation. Torres tworzyła tak pół tuzina annotation tools.

„Widzę ten błąd w tym trace, ale nie podałeś mi numeru trace. Jak mam to zbadać?” Kiedy: Tool działa, ale brakuje convenience features. Torres „wymagała rzeczy od Claude Code” w ten sposób.

Meta-strategy

Torres principle: „Optymalizowałam pod 4-line diffs, nie tysiąc line diffs” – zawsze proś o małe, zrozumiałe zmiany zamiast massive code dumps.

Key insight: Torres używała planning mode oddzielony od implementation – najpierw dyskutowała strategię bez dotykania kodu, dopiero potem step-by-step implementation.

Kluczowy insight

Paradoks prostego ewaluatora

Standardowo myślimy: Aby ocenić złożone odpowiedzi AI, trzeba użyć równie zaawansowanych metod – jeśli ewaluacja się nie zgadza z human judgment, to ewaluacja jest zła oraz trzeba ją poprawić żeby się dopasowała.

W praktyce okazuje się, że: Głęboka wiedza domenowa pozwala uprościć problem i rozwiązać go prostą regułą w kodzie. Torres odkryła, że jedna z jej ewaluacji była lepsza od jej własnej human judgment, ponieważ „żeby napisać specific eval dla tego error mode, musiałam być znacznie konkretniejsza co do tego, co oceniam. Skodyfikowałam to w kodzie, ale nie skodyfikowałam tego w mojej human label rubric.”

Dlaczego to jest istotne: Takie podejście jest znacznie tańsze, szybsze oraz bardziej niezawodne niż budowa kolejnych złożonych systemów. Założenie, że human always knows best, może hamować development dobrych ewaluacji.

Test na jutro: Zanim w zespole zapadnie decyzja „zbudujmy LLM-sędziego do oceny X”, najpierw zapytaj: czy błąd można uchwycić prostą logiką „tak/nie” albo zestawem słów kluczowych? Następnym razem gdy ewaluacja się nie zgadza z Twoim human judgment, przeanalizuj czy ewaluacja nie wymusza bardziej precyzyjnego myślenia o kryteriach.

Ten wpis stanowi część kolekcji notatek z ciekawych podcastów, webinarów oraz innych treści wartościowych do ponownego przeglądania. Oryginalne źródło: From Noob to Automated Evals In A Week (as a PM) w/Teresa Torres

Tag: Notebook Development

Od zera do automatycznych ewaluacji w tydzień – praktyczne lekcje Teresy Torres #EN253