Developer Tools

Poproś model o odpowiedź w JSON i w większości przypadków json.loads() działa bez problemu. Problemy zaczynają się tam, gdzie kosztują cię sesję debugowania: jednoliniowy komentarz w środku obiektu, markdown code fence owijający całość, klucz zapisany jako userEmail, gdy kod oczekuje user_email. Bardziej rygorystyczny prompt (“odpowiedz WYŁĄCZNIE obiektem JSON, bez żadnego innego tekstu”) sprawia, że takie przypadki są rzadsze. Nie eliminuje ich całkowicie, bo model nadal może zignorować prośbę. Ustrukturyzowane wyjście usuwa prośbę z równania: przekazujesz API JSON Schema, który ogranicza samplowanie tokenów samego modelu tak, że odpowiedź musi do niego pasować. ...

Zapisujesz plik, Prettier go formatuje, a ESLint natychmiast zgłasza błąd w linii, którą Prettier właśnie dotknął. Oba narzędzia są skonfigurowane, oba działają — i zamiast pomagać, walczą ze sobą. Te dwa narzędzia robią różne rzeczy. Problem w tym, że oba mają zdanie na temat jednej sprawy: jak kod ma wyglądać na ekranie. Co ESLint faktycznie sprawdza ESLint rozkłada kod na abstrakcyjne drzewo składniowe i uruchamia reguły na jego strukturze. Największa wartość pochodzi z reguł, które wyłapują realne bugi: zmienną, która nigdy nie została zdefiniowana, nieosiągalny return po innym return, nieużywany import, który został po refaktoryzacji, zduplikowany klucz w obiekcie, który bez ostrzeżenia nadpisuje pierwszy. To kontrole semantyczne — ESLint czyta, co kod robi. ...

Czemu “wygląda dobrze” nie jest testem dla prompta Dopracowujesz treść prompta, który klasyfikuje zgłoszenia, sprawdzasz go na trzech przykładach otwartych w notatniku i wdrażasz. Tydzień później reklamacje dotyczące rozliczeń, które wcześniej trafiały do właściwej kolejki, zaczynają trafiać do “pytania”. Nie te trzy przypadki, które sprawdziłeś, ale te pozostałe czterysta, których nie sprawdziłeś. Nic się nie wywala. Nie ma żadnego stack trace’u. Prompt przeczytany na głos wciąż brzmi dobrze. Code review i kilka ręcznych sprawdzeń tego nie wychwytuje, bo ten sam prompt na tym samym wejściu nie zwraca dwa razy tego samego tekstu. Nie możesz porównać dwóch przebiegów bit po bicie i nazwać różnicę bugiem, tak jak przy czystej funkcji. Co możesz sprawdzić, to czy każda odpowiedź ma właściwości, na których ci zależy: właściwą kategorię, podsumowanie poniżej limitu długości, żadnego pola, którego źródło nigdy nie wspominało. Eval uruchamia te sprawdzenia na zbiorze prawdziwych danych wejściowych przy każdej zmianie prompta albo modelu, więc regresja wychodzi na jaw w twoim terminalu, a nie w zgłoszeniu klienta. ...

Co function calling naprawdę robi w LLM Zapytaj model “jaka jest teraz pogoda w Austin” bez żadnego połączenia ze światem zewnętrznym, a masz dwie opcje: powie, że nie wie, albo coś zmyśli. Function calling daje mu trzecią opcję. Model opisuje, czego potrzebuje, przekazuje ten opis twojemu kodowi i czeka na prawdziwą odpowiedź, zanim sam odpowie. Nazwa jest trochę myląca. Model niczego nie wywołuje. Zwraca blok ustrukturyzowanych danych mówiący, jaki tool chce użyć i z jakimi argumentami, a twoja aplikacja decyduje, czy go uruchomić i co zrobić z wynikiem. “Tool use” to dokładniejszy termin, ten używany w dokumentacji Anthropic; OpenAI i Google zwykle mówią function calling. Mechanizm jest ten sam pod obiema nazwami. Model tworzy tylko żądanie, nigdy sam efekt. ...

Odpal npm install w projekcie, a potem pnpm install na tym samym package.json – dostajesz dwa różne drzewa node_modules i dwa różne lockfile’y. Dodaj kolegę, który sięga po Yarn, i w historii repozytorium lądują trzy lockfile’y, każdy opisujący nieco inne drzewo zależności. Wszystkie trzy czytają ten sam package.json i pobierają z tego samego rejestru npm. Nie zgadzają się co do tego, co zapisać na dysku. Jak npm, Yarn i pnpm układają node_modules Struktura npm jest płaska. Każdy pakiet, którego potrzebują twoje zależności, niezależnie od tego, jak głęboko w drzewie, trafia do głównego node_modules, jeśli nie ma konfliktu wersji. To domyślne zachowanie od npm 3. Efekt uboczny: twój kod może zrobić require() albo import pakietu, którego nigdy nie wpisałeś do package.json, o ile cokolwiek innego w drzewie od niego zależy. Działa to, dopóki ten inny pakiet nie usunie tej zależności w minor release – wtedy twój build się psuje, mimo że w twoim kodzie nic się nie zmieniło. To jest phantom dependency, a struktura npm nic z tym nie robi. ...

Co dekorator naprawdę robi z twoją funkcją Chcesz zmierzyć czas każdej funkcji, która wywołuje wolne zewnętrzne API. Możesz wkleić wywołania time.perf_counter() do każdej z nich albo napisać pomiar raz i stosować go wszędzie. Dekorator to druga opcja: to funkcja, która bierze inną funkcję, owija ją dodatkowym zachowaniem i zwraca owiniętą wersję pod oryginalną nazwą. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 import time def timed(func): def wrapper(*args, **kwargs): start = time.perf_counter() result = func(*args, **kwargs) elapsed = time.perf_counter() - start print(f"{func.__name__} took {elapsed:.3f}s") return result return wrapper @timed def fetch_price(ticker): time.sleep(0.2) # zastępuje wywołanie sieciowe return 142.50 fetch_price("AAPL") # fetch_price took 0.201s @timed nad def fetch_price to skrót od fetch_price = timed(fetch_price). Python wywołuje timed raz, zaraz po zdefiniowaniu fetch_price, i przypisuje nazwę fetch_price do tego, co zwraca timed. To jest cała robota, jaką wykonuje @. ...

Zainstaluj na jednym komputerze dwa projekty w Pythonie i drugi może zepsuć pierwszy. Jeden potrzebuje requests==2.28, drugi requests==2.32, a pip ma dokładnie jeden systemowy katalog site-packages, do którego zapisuje. Wygrywa ostatnia instalacja, po cichu. Zauważasz to, gdy drugi projekt zaczyna zgłaszać błędy, które nie mają nic wspólnego z kodem, który właśnie zmieniłeś. Wirtualne środowisko daje każdemu projektowi własny site-packages. Nic globalnego się nie zmienia, a dwa projekty mogą zależeć od niekompatybilnych wersji tej samej biblioteki, bez wzajemnej kolizji. ...

Poproś agenta CLI do kodowania o naprawienie failującego testu, a nie odpowie ci sugestią. Odczyta wynik testu, otworzy plik, zmieni linijkę, uruchomi test ponownie i zgłosi się z powrotem, dopiero gdy przejdzie. Ta pętla jest produktem, nie okno czatu. Model wewnątrz pętli przyciąga najwięcej uwagi i to też ta część, która zmienia się najszybciej: dostawcy podmieniają go co kilka miesięcy, a wielu agentów pozwala go samemu wybrać. To, co zostaje na miejscu, to harness owinięty wokół modelu — do jakich narzędzi ma dostęp, jak zarządza kontekstem, co może uruchomić bez pytania i gdzie te komendy się wykonują. Dwaj agenci na tym samym modelu mogą zachowywać się zupełnie inaczej właśnie przez to. Harness to jest to, co naprawdę wybierasz. ...