Słownik

Każdy termin, który pojawia się w programie, prostym językiem.

Pierwszy raz tutaj? Przeczytaj darmową pierwszą lekcję. Konto nie jest potrzebne.

Pojęcia AI

Agent: System AI, który samodzielnie wykonuje wiele kroków w stronę celu: sam wybiera toole i po drodze się dostosowuje.
Agent bez nadzoru: Agent, który wykonuje zadanie od początku do końca, a nikt go po drodze nie pilnuje ani nie odpowiada na jego pytania. Ludzie widzą tylko wynik, więc nadzór muszą przejąć sprawdzenia i środowisko.
AGI: Ogólna sztuczna inteligencja: hipotetyczna AI tak sprawna jak człowiek w większości zadań. Wiele się o niej mówi i wciąż jej nie ma.
Closed model: Model zastrzeżony, do którego dostaniesz się tylko przez API albo aplikację dostawcy.
Coding agent: Asystent AI, który ma ręce. Czyta pliki, edytuje je, uruchamia komendy i po drodze sprawdza wyniki.
Compaction: Streszczanie wcześniejszych części rozmowy, żeby zwolnić miejsce w context window.
Completion / response: To, co model odsyła po twoim prompcie.
Context: Wszystko, co model ma teraz przed sobą: twój prompt, przebieg rozmowy, załączniki i notatki dorzucone po drodze.
Context rot: Awaria pętli: historia rozmowy rośnie, aż sygnał w niej tonie. Ratunek to streszczanie starych tur i przypinanie celu.
Context window: Największa liczba tokenów, jaką model utrzyma naraz: twój prompt plus wszystko, co już przeczytał.
Embedding: Liczbowa reprezentacja tekstu, dzięki której system szuka po znaczeniu, a nie po dokładnych słowach.
Embedding models: Modele, które zamieniają tekst na liczby, żeby toole mogły szukać po znaczeniu. Pracują pod spodem asystentów podłączonych do twoich dokumentów.
Fine-tuning: Dodatkowy, wyspecjalizowany training na bazowym modelu, dopasowany do konkretnego zastosowania.
Frontier model: Największy, najnowszy i najsprawniejszy model, jaki ma w ofercie dany dostawca.
Generation: Ostatni krok w RAG: znalezione fragmenty trafiają do promptu, a model odpowiada na ich podstawie.
Gradient descent: Proces trainingu, w którym model po trochu poprawia miliardy wewnętrznych parametrów, aż dobrze przewiduje następne słowo.
Inference: Każde użycie modelu. Wysyłasz prompt, przechodzi on przez zamrożone parametry i powstaje wynik.
Korpus źródłowy: Miejsce, w którym w układzie RAG mieszka prawda: strony, dokumenty, umowy albo dawne zgłoszenia, z których wyszukujesz.
LLM: Duży model językowy, technologia stojąca za asystentami takimi jak ChatGPT, Gemini i Claude.
Long context: Ile asystent utrzyma w jednej rozmowie. Long context mieści naraz tyle, co niewielka biblioteka.
MCP (Model Context Protocol): Standardowy sposób podłączania aplikacji AI do zewnętrznych tooli, danych i usług. Coś jak USB dla AI.
Memory: Funkcja, która zapisuje wybrane fakty o tobie i wstawia je z powrotem do contextu na początku kolejnych rozmów.
Model decyzyjny: Model, który odpowiada na pytanie, wybierając jedną ze zdefiniowanych przez ciebie opcji, z prawdopodobieństwem dla każdej z nich, zamiast pisać tekst. Przykłady to Jev i Laya.
Modele graficzne: Modele, które tworzą obrazy z opisu tekstowego, jak DALL-E, Midjourney czy Stable Diffusion.
Modele mowy: Modele, które zamieniają mowę na tekst i odwrotnie, jak Whisper do transkrypcji czy ElevenLabs do syntezy głosu.
Multimodal: Zdolność modelu do pracy z czymś więcej niż tekst: z obrazem, a czasem z dźwiękiem i wideo.
Open weights: Model, którego parametry możesz pobrać i uruchomić u siebie.
Przewidywanie następnego słowa: Sedno działania LLM-a. Model wciąż od nowa przewiduje najbardziej prawdopodobne następne słowo i tak składa przydatną odpowiedź.
RAG (Retrieval-Augmented Generation): System najpierw szuka w twoich dokumentach albo w sieci, a potem model odpowiada na podstawie tego, co znalazł.
Rozszerzony LLM: Wywołanie modelu wzbogacone o retrieval, toole i memory. Anthropic traktuje je jako podstawowy element każdego wzorca przepływu pracy i każdego agenta.
Session: Jedna nieprzerwana rozmowa z asystentem, zwykle jedna karta czatu. Nowy czat startuje z pustym contextem.
Skalibrowane prawdopodobieństwo: Prawdopodobieństwo, które zgadza się z tym, jak często odpowiedzi okazują się trafne: spośród wszystkich odpowiedzi z wartością około 0,8 trafnych jest mniej więcej 80%. Opisuje grupy odpowiedzi, nigdy pojedynczą, a polegać na nim możesz dopiero wtedy, gdy sprawdzisz je na własnych oznaczonych przypadkach.
Subagent: Osobny agent z własnym context window, który bierze na siebie zadanie poboczne, na przykład wyszukiwanie albo przegląd, i oddaje tylko podsumowanie. Nie widzi głównej rozmowy, więc jego brief musi powtórzyć każdą regułę, która padła tylko w tamtej rozmowie.
System prompt: Instrukcje, które na starcie rozmowy ustawiają rolę i zasady dla AI.
Token: Małe kawałki tekstu, które asystent czyta i pisze, około 3/4 słowa. W tokenach liczy się długość i koszt.
Tool: Łącznik, dzięki któremu AI robi coś więcej niż pisanie tekstu: szuka, liczy albo sięga do innego systemu.
Training: Kosztowny, jednorazowy proces, w którym model uczy się wzorców z ogromnych ilości tekstu. Robią to dostawcy, nie ty.
Training cutoff: Data, po której model nie zna niczego z trainingu, więc późniejsze wydarzenia go omijają, o ile mu ich nie podasz.
Wyszukiwanie agentowe: Agent sam znajduje to, czego potrzebuje, w trakcie pracy, przez toole do wyszukiwania, ścieżki plików i linki, zamiast dostać fragmenty wczytane przed startem. To, co czyta, jest aktualne, ale działa to wolniej niż retrieval, a bez wskazówek agent może zbłądzić.

Promptowanie i techniki

Chain (prompt chaining): Ciąg promptów, w którym wynik jednego staje się wejściem następnego. Ty pilnujesz chaina, AI wykonuje kolejne etapy.
Chain of thought: Prośba, żeby model rozumował krok po kroku przed odpowiedzią. Podnosi trafność w zadaniach wieloetapowych.
Chunking: Cięcie korpusu na małe kawałki (256 do 512 tokenów, z nakładką 10 do 20%), żeby dały się wyszukiwać.
Determinizm a ocena: Determinizm znaczy, że krok daje ten sam wynik za każdym razem. Ocena znaczy, że wynik może się różnić i to jest w porządku. Oznacz każdy krok.
Dopracowywanie w rundach: Traktujesz AI jak rozmowę i poprawiasz wynik przez kilka rund, zamiast liczyć na doskonały pierwszy szkic.
Dziennik promptów: Zapisany zbiór promptów, które zadziałały, z czasem urastający do szablonów wielokrotnego użytku w twojej pracy.
Evaluator-optimizer: Wzorzec przepływu pracy, w którym jedno wywołanie modelu pisze, a drugie ocenia wynik według jasnych kryteriów i w pętli odsyła informację zwrotną, aż wynik przejdzie albo zostanie osiągnięty limit.
Few-shot: Dajesz modelowi kilka przykładów tego, jak wejście ma się zamieniać w wynik. Bardzo podnosi to powtarzalność.
Format wyniku: Wyniki pośrednie trzymaj w postaci czytelnej dla maszyn (tabele, JSON, stałe pola). Swobodna proza rozrywa chainy.
Krok AI: Krok procesu, który wymaga oceny zależnej od danych wejściowych. Właśnie tu wydawaj swój budżet na AI.
Krok deterministyczny: Krok procesu obsłużony sztywną logiką: formułą, właściwością w bazie albo skryptem.
Meta-prompting: Prosisz AI o krytykę i przepisanie twojego promptu, żeby dawał pewniejszy wynik.
Najpierw plan, potem wykonanie: Prosisz model, żeby najpierw zaplanował pracę i wskazał luki, a dopiero potem zrobił rzecz. Dzięki temu nie zalepia luk domysłami.
Nakładanie ról: Każesz AI przeanalizować sprawę kolejno z kilku eksperckich punktów widzenia, a potem zebrać to w jedną rekomendację.
Ograniczenia negatywne: Mówisz AI, czego nie robić. To odpycha od jej domyślnych zachowań i często jest łatwiejsze niż opisanie tego, czego chcesz.
Orchestrator-workers: Wzorzec przepływu pracy, w którym centralne wywołanie modelu w trakcie działania dzieli zadanie na podzadania, przekazuje je wywołaniom wykonawczym i łączy ich wyniki. Stosuj go, kiedy nie da się z góry wypisać podzadań.
Persona: Nadanie modelowi roli, żeby podniósł poprzeczkę jakości. Zmienia sposób odpowiedzi, ale nie to, czy odpowiedź jest trafna.
Persona prompts: Nadaj każdemu etapowi rolę (asystent prawny, specjalista od zgodności). Persona zmienia słownictwo, głębokość i ton.
Progressive disclosure: Zawsze wczytujesz niewiele, a resztę tylko wtedy, gdy jest potrzebna. Warstwa zawsze aktywna zostaje mała.
Projektowanie contextu: Dobieranie wszystkiego, co trafia do contextu modelu w trakcie pracy, nie tylko promptu: instrukcji, plików, opisów tooli, wyników tooli i historii. Celem jest najmniejszy zestaw użytecznych informacji, który prowadzi do właściwego działania.
Prompt: To, co wpisujesz asystentowi. Promptowanie to sztuka dobrego pytania.
Promptowanie wieloetapowe: Dziel pracę na etapy, zamiast pisać jeden wielki prompt. Każdy etap daje czysty, nazwany wynik, z którego korzysta następny.
Przekazanie (styk): Moment, w którym wynik jednego kroku staje się wejściem następnego. Tu pęka większość chainów, więc na styku stawiaj sprawdzenia.
Pułap instrukcji: Poziom szczegółowości, na jakim są napisane wytyczne. Za niski pułap to krucha lista reguł typu „jeśli…, to…”, za wysoki to mglista nadzieja. Właściwy pułap podaje cel, decyzje wymagające oceny i twarde ograniczenia, każde z powodem, który za nim stoi.
Retrieval: Dobranie właściwych fragmentów do zapytania. Retrieval hybrydowy (semantyczny plus po słowach kluczowych) z rerankerem to domyślne rozwiązanie na produkcji.
Routing: Wzorzec przepływu pracy, w którym jeden krok przypisuje dane wejściowe do kategorii i wysyła je do kroku zbudowanego dla tego rodzaju, na przykład e-maili o płatnościach, sprawach technicznych albo koncie.
Rozłożenie procesu na kroki: Dzielisz proces obejmujący wiele zespołów na kroki i decydujesz, które są dla AI, które deterministyczne, a które wymagają człowieka.
Schemat czterech elementów: Sprawdzona budowa promptu: Rola, Context, Zadanie, Format (znany też jako CRAFT albo RCTF).
Structured outputs: Prosisz o konkretny schemat, na przykład JSON albo tabelę, żeby wynik był jednoznaczny i łatwy do użycia w innych toolach.
Ustrukturyzowane notatki: Agent w trakcie pracy zapisuje notatki do pliku poza swoim context window, na przykład listę rzeczy do zrobienia albo plik z ustaleniami, i później czyta je z powrotem. Notatki przetrwają compaction, bo nigdy nie były w oknie.
Warstwa zawsze aktywna: Mały zestaw treści czytany w każdej turze: twarde ograniczenia, reguły firmowe i aktywne zadanie.
Wczytywanie na żądanie: Schematy danych, specyfikacje, procedury i dokumenty wczytujesz tylko wtedy, gdy zadanie ich potrzebuje, sięgając po nazwie.
Wstępne wypełnienie odpowiedzi: Zaczynasz odpowiedź modelu za niego. Format i ton są wtedy przypięte, a driftu jest mniej.
Zero-shot: Prosisz model o zadanie bez żadnych przykładów. W prostych, dobrze znanych zadaniach to wystarcza.
Zrównoleglanie: Wzorzec przepływu pracy, w którym wywołania modelu idą jednocześnie: niezależne części zadania obok siebie (podział na sekcje) albo to samo zadanie kilka razy, żeby porównać odpowiedzi (głosowanie).
Złota zasada: Zawsze dawaj AI tyle contextu, ile możesz. Lepsze wejście niezawodnie daje lepszy wynik.

Budowanie i wdrażanie

Agent loop: Cykl działania: przeczytaj context, zdecyduj, wywołaj tool, przeczytaj wynik, zdecyduj znowu, aż zadanie będzie zrobione.
Agentic loop: Zadanie przygotowane tak, żeby coding agent mógł dojść do celu metodą prób i błędów: jasny cel, sprawdzenie, które mówi „przeszło” albo „nie przeszło”, komendy do wypróbowywania zmian i bezpieczne miejsce do działania z wyłączonym zatwierdzaniem. Każdy agent działa w pętli; pętla agentowa to pętla, którą projektujesz.
Agentowe testowanie ręczne: Polecenie coding agentowi, żeby użył własnej zmiany tak, jak zrobiłby to człowiek: wywołał funkcję z wiersza poleceń, API przez curl albo stronę w prawdziwej przeglądarce, i zapisywał każdą komendę z jej wynikiem. Potrafi wykryć to, co przeoczą przechodzące testy.
AGENTS.md: Standardowy plik instrukcji, który rozumieją różne toole. Trzymaj tu swoje ustalenia jako jedno źródło prawdy.
Aktualizacja zależności: Zmiana, która podnosi jedną z zależności projektu do nowszej wersji. Aktualizacja, która zmienia tylko numer wersji, nadaje się dla zwykłego skryptu; ta ze zmianami łamiącymi zgodność wymaga też zmian w kodzie i sprawdzenia, czy projekt wciąż się buduje i przechodzi testy.
Anatomia briefu: Części, których potrzebuje dobry brief agenta: rola, trigger, wejścia, kroki, format wyniku i zabezpieczenia.
Backpressure: Automatyczne sprawdzenia, które odrzucają słaby wynik agenta, takie jak testy, type checkery i skanery bezpieczeństwa, więc agent musi poprawić swoją zmianę, zanim pójdzie dalej. Niech będą szybkie, bo agent na nie czeka.
Blokada zadania: Zajęcie elementu roboczego, na przykład mały plik, który agent commituje do wspólnego repo, zanim zacznie, żeby inni agenci wybrali coś innego. Blokady trzymane za długo albo nigdy niezwolnione spowalniają wszystkich.
Boilerplate: Kod, który trzeba napisać, ale który nie niesie żadnej nowej idei, na przykład konfiguracja, łączenie elementów albo kolejny test o tym samym kształcie. Łatwo go opisać i łatwo sprawdzić, dlatego dobrze nadaje się do przekazania coding agentowi.
Branch: Równoległy tor pracy w tym samym repo. Na branchu eksperymentujesz, nie ruszając głównej linii.
Breaking change: Zmiana w nowej wersji biblioteki albo usługi, przez którą kod napisany pod starą wersję przestaje działać albo działa inaczej. Część takich zmian psuje coś głośno, jak usunięta funkcja. Inne są ciche, jak zmieniona wartość domyślna, i wyłapują je tylko testy, które przypinają zachowanie.
Błąd projektowy: Awaria, której źródłem jest architektura przepływu pracy. Naprawa to przestawienie etapów albo przeprojektowanie całości.
Changelog: Krótka bieżąca notatka na końcu briefu, która zapisuje zmiany w każdej wersji, żeby inni widzieli, jak brief się zmieniał.
Checkout: Przełączenie folderu roboczego tak, żeby pokazywał wybrany branch albo commit. To samo repo, inny widok.
Ciągła integracja (CI): Automatyczny build i testy, które uruchamiają się przy każdej proponowanej zmianie, zanim zostanie scalona. W fabryce oprogramowania to pierwsze sprawdzenie, przez które musi przejść zmiana agenta, a zielony wynik jest wiarygodny tylko na tyle, na ile wiarygodne są stojące za nim testy.
CLAUDE.md: Plik instrukcji dla Claude Code, w katalogu głównym projektu albo w ~/.claude dla ustawień globalnych. Często wskazuje po prostu na AGENTS.md.
Code owners (CODEOWNERS): Plik, który wskazuje, kto jest właścicielem których ścieżek w repo. Gdy włączysz odpowiednią regułę, zmiana w pliku, który ma właściciela, nie zostanie scalona bez zatwierdzenia przez jednego z jego właścicieli.
Commit: Jedna zapisana zmiana z notatką, co się zmieniło i dlaczego. Historia repo to łańcuch commitów.
Compound engineering: Sposób pracy opisany przez firmę Every, w którym każda zmiana ma ułatwiać następną. Po planowaniu, pracy i przeglądzie przychodzi czwarty krok: zamień zdobytą wiedzę w dokumentację, przykład, test albo sprawdzenie i zapytaj, czy system wyłapałby teraz ten problem sam.
Context budget: Traktujesz context window jak budżet, który świadomie rozdzielasz, wydając najwięcej na to, co zmienia odpowiedź.
Czujnik (sprzężenie zwrotne): Mechanizm harnessu, który sprawdza pracę agenta, kiedy ten już zadziała, na przykład test, tool do sprawdzania linków albo model sprawdzający, żeby agent mógł sam się poprawić.
Deferred tools: Wypisujesz toole z nazwy, a model dociąga pełną definicję na żądanie. Context zostaje chudy.
Definicja gotowości: Uzgodniona w zespole lista tego, co musi zawierać element roboczy, zanim ktokolwiek zacznie nad nim pracę. W fabryce decyduje, które elementy mogą trafić do kolejki agenta; pozostałe wracają do autora z informacją, czego brakuje.
Definicja ukończenia: Krótka lista stwierdzeń o skończonej pracy, spisana, zanim praca się zacznie, którą każdy mógłby sprawdzić. Każdy punkt jest dla wyniku prawdziwy albo fałszywy, więc „gotowe” znaczy „sprawdzone”, a nie tylko „wygląda na gotowe”.
Diff: Lista zmian w twoich plikach, linijka po linijce: linie usunięte i linie dodane. Czytanie diffu po każdym kroku pozwala zobaczyć dokładnie, co zrobił agent.
Dokument decyzji architektonicznej (ADR): Krótki plik w repo, który zapisuje jedną istotną decyzję: jej kontekst, samą decyzję, jej status i konsekwencje. Mówi ludziom i coding agentom, dlaczego kod jest taki, jaki jest, żeby ani jedni, ani drudzy nie akceptowali go ani nie zmieniali na ślepo.
DORA metrics: Pięć miar tego, jak zespół wdraża oprogramowanie, z DORA, programu badawczego prowadzonego przez Google Cloud. Czas realizacji zmian, częstotliwość wdrożeń i czas przywracania po nieudanym wdrożeniu pokazują przepustowość; odsetek nieudanych zmian i odsetek wdrożeń naprawczych pokazują niestabilność.
Edge cases: Wejścia poprawne, ale nietypowe. Brief powinien mówić, co robić z brakującymi polami, sprzecznościami i danymi wrażliwymi.
Element roboczy: Jedna porcja pracy we wspólnej kolejce, na przykład zgłoszenie (issue) w systemie zgłoszeń. Kiedy bierze go agent, element jest całym jego briefem: oczekiwany efekt, sprawdzenia, które go potwierdzają, to, co jest poza zakresem, i kogo pytać.
Etap walidacji: Pierwszy etap chaina, który sprawdza, czy każde wymagane pole jest obecne i poprawne. Gdy sprawdzenie nie przechodzi, etap zatrzymuje pracę i woła człowieka.
Eval możliwości: Eval z zadań, z którymi agent wciąż sobie nie radzi. Startuje z niskim odsetkiem zaliczeń i pokazuje, czy zmiany w harnessie pomagają.
Eval regresyjny: Eval z zadań, z którymi agent już sobie radzi i które powinny przechodzić prawie za każdym razem. Spadek znaczy, że coś się zepsuło, często po zmianie modelu, instrukcji albo tooli.
Fabryka oprogramowania: System, w którym wielu agentów AI bierze elementy robocze z kolejki i zamienia je w sprawdzone zmiany, z ludźmi w wybranych przez ciebie punktach zatwierdzenia. Agent to jeden krok; to kolejka, odizolowane środowiska, sprawdzenia i zatwierdzenia sprawiają, że jego zmiany można bezpiecznie scalić.
Fan-out: Rozbicie jednej powtarzalnej zmiany na osobne uruchomienia agenta dla każdego elementu, na przykład pliku, startowane ze skryptu z tym samym promptem. Każde uruchomienie zaczyna ze świeżym contextem. Najpierw wypróbuj kilka elementów, popraw prompt, a potem uruchom resztę ze sprawdzeniem każdego z nich.
Forking: Kopiujesz udostępnionego agenta albo asystenta i dostosowujesz go do siebie, przejmując lekcje, które wyniósł jego autor.
Format drift: AI zwraca wynik w trochę innej postaci niż zamówiona, przez co pęka wszystko dalej, co liczyło na dokładny format.
Formularz zgłoszenia: Formularz albo szablon, który ludzie wypełniają, żeby zgłosić element roboczy, z jednym polem na każdy punkt definicji gotowości i z najważniejszymi polami oznaczonymi jako wymagane. Utrudnia pominięcie pól, ale tego nie uniemożliwia, więc triaż jeszcze raz sprawdza każdy element. Na GitHubie to formularz issue.
Frontmatter: Mały blok YAML na samym początku pliku, z faktami o samym pliku.
Git bisect: Komenda gita, która znajduje commit, w którym błąd pojawił się po raz pierwszy. Oznaczasz dobry commit i zły, dajesz jej test, a ona przeszukuje historię, za każdym razem dzieląc ją na pół. Coding agenci dobrze radzą sobie z uruchamianiem jej za ciebie.
Gotowe na produkcję: Przepływ pracy przetestowany na prawdziwych wejściach, z typowymi awariami i HITL gate'ami w briefie, opisany, mający właściciela i logowany na wypadek driftu.
Harness: Wszystko, co budujesz wokół modelu: context, który mu podajesz, toole, po które może sięgnąć, i pętla, w której działa.
Headless run: Uruchomienie coding agenta ze skryptu, bez nikogo przy klawiaturze, na przykład claude -p albo codex exec. Dozwolone toole, sandbox i limity tur i kosztów trzeba ustawić, zanim się zacznie.
Idempotency: Agent jest idempotentny, jeśli drugie uruchomienie na tym samym wejściu jest bezpieczne: daje ten sam wynik albo pomija pracę.
Infrastruktura (a tool): Rozwiązanie, od którego zależy wiele osób. W tej skali potrzebuje wskazanego właściciela, opisanego działania, HITL gate'ów i planu utrzymania.
Instrukcje dla konkretnych ścieżek: Pliki instrukcji, które działają tylko wtedy, gdy agent pracuje na pasujących plikach, na przykład plik .instructions.md w GitHub Copilot ze wzorcem applyTo albo reguła w Cursor z globami.
Inżynieria agentowa: Tworzenie oprogramowania z coding agentami, przy którym inżynier pozostaje odpowiedzialny za wynik: wyznacza cel, sprawdza kod i dowody i decyduje, co trafia na produkcję. Simon Willison używa tego określenia jako przeciwieństwa vibe codingu, w którym nikt nie patrzy na kod.
Jednorazowe środowisko: Przestrzeń robocza tworzona od nowa dla jednego zadania ze standardowej konfiguracji i potem wyrzucana, na przykład worktree, kontener albo sandbox w chmurze. Nic, czego potrzebujesz, nie istnieje tylko w niej, więc każde uruchomienie można zacząć od nowa.
Kaskada: Najpierw działa tani, szybki model, a do mocniejszego modelu albo do człowieka trafiają tylko przypadki, których nie był pewny. Oszczędza koszty, ale podnosi trafność tylko wtedy, gdy drugi etap popełnia inne błędy.
Konflikt scalania: To, co się dzieje, gdy dwie gałęzie zmieniają te same linie tego samego pliku. Git nie połączy ich sam, więc wybrać musi człowiek albo agent. Podział równoległej pracy według obszarów sprawia, że konflikty zdarzają się rzadko.
Koszt: Cena każdego tokenu: w pieniądzach, w czasie odpowiedzi i w rozproszonej uwadze modelu.
Koszt użytecznego wyniku: Całe wydatki podzielone przez wyniki, które nie wymagały poprawek. To ta miara kosztu, którą warto mieć w głowie.
Kryteria odbioru: Warunki, które praca musi spełnić, żeby uznać ją za skończoną, spisane przed rozpoczęciem pracy. Dla agenta każde z nich najlepiej działa jako sprawdzenie, które może uruchomić: test, komenda albo wynik, który każdy może zobaczyć, a przy sprawdzeniach nowego zachowania najpierw potwierdzasz, że nie przechodzą.
Limit budżetu: Warunek stopu, który stawia twardy sufit na liczbę tur, tokenów albo wywołań tooli.
Limit ponownych prób: Limit tego, ile razy agent może spróbować ponownie po niezaliczonym sprawdzeniu, na przykład dwie rundy CI. Gdy zostanie osiągnięty, uruchomienie się zatrzymuje, a gałąź trafia do człowieka razem z wynikiem nieudanego sprawdzenia.
Lockfile: Plik, który zapisuje dokładną wersję każdego pakietu instalowanego przez projekt, łącznie z pakietami, które wciągają jego zależności. Jego zmiany w diffie pokazują wszystko, co wnosi nowy pakiet.
Mapa styków: Mapa przekazań w procesie: kto przekazuje, kto odbiera, co się gubi, ile to kosztuje czasu i gdzie jest miejsce dla AI.
Mechanizm oparty na modelu: Przewodnik albo czujnik, który opiera się na ocenie modelu, na przykład pisemne instrukcje albo przegląd przez AI. Potrafi ocenić znaczenie, ale jest wolniejszy, kosztuje więcej i może dawać różne wyniki w kolejnych uruchomieniach.
Mechanizm programowy: Przewodnik albo czujnik obsługiwany przez zwykłe oprogramowanie, na przykład test, linter albo skrypt. Jest szybki i tani, a za każdym razem daje ten sam wynik.
Merge: Wciągnięcie zmian z brancha z powrotem do głównej linii, kiedy są gotowe.
Merge queue: Kolejka, która przed scaleniem testuje każdy pull request razem z najnowszą gałęzią main i pull requestami, które są przed nim, żeby zmiany przechodzące osobno nie mogły razem zepsuć gałęzi.
Miejsce wywołania: Miejsce w kodzie, w którym wywoływana jest dana funkcja. Przed aktualizacją albo zmianą nazwy lista wszystkich miejsc wywołania, łącznie z testami i skryptami, pokazuje, jak duża jest zmiana i co trzeba sprawdzić.
Oceniający: To, co rozstrzyga, czy próba przeszła: kod tam, gdzie da się coś sprawdzić dokładnie, model z kryteriami oceny tam, gdzie potrzebna jest ocena, albo człowiek. Zanim zaufasz modelowi w roli oceniającego, porównaj go z ludźmi.
Odłożony scenariusz: Historyjka użytkownika end-to-end, przechowywana poza bazą kodu, która sprawdza oprogramowanie po tym, co może zaobserwować użytkownik. Agenci nigdy jej nie widzą, więc nie mogą jej przepisać ani napisać kodu, który tylko ją zalicza.
Ograniczenie modelu: Awaria, w której model nie jest w danym zadaniu dość niezawodny. Naprawa to deterministyczne sprawdzenie albo ciaśniejszy HITL gate.
OpenTelemetry (OTel): Otwarty standard wysyłania metryk, logów i śladów z programu do wybranego przez ciebie kolektora. Toole do agentów korzystają z niego, żeby raportować tokeny, koszt i wywołania tooli każdego uruchomienia.
Optymistyczna współbieżność: Sposób, w jaki wielu agentów może współdzielić stan bez blokad: każdy może go odczytać, ale zapis się nie udaje, jeśli stan zmienił się od odczytu, a wtedy piszący odczytuje go jeszcze raz i ponawia próbę.
Output schema: Dokładna, zapisana definicja pól i typów wyniku, ustalona przed napisaniem promptu.
pass@k (co najmniej raz): Odsetek zadań, które agent zalicza co najmniej raz w k próbach. Pokazuje, czy agent potrafi wykonać zadanie, a nie czy robi to za każdym razem.
pass^k (za każdym razem): Odsetek zadań, które agent zalicza w każdej z k prób. Spada, gdy k rośnie, i liczy się najbardziej tam, gdzie ludzie za każdym razem oczekują tego samego wyniku.
Pielęgnacja dokumentacji: Cykliczne uruchomienie, często wykonywane przez agenta, które porównuje dokumentację w repo z kodem i otwiera pull request dla każdej strony, która przestała być aktualna. Dzięki temu dokumentacja, na której polegają agenci, pozostaje prawdziwa.
Plan utrzymania: Krótki dokument, który wskazuje właściciela, zastępcę, częstotliwość przeglądów, znane awarie i sposób testowania zmian.
Plik instrukcji: Plik ze stałymi zasadami, który agent czyta, zanim zabierze się do pracy. AGENTS.md to jego najczęstsza nazwa.
Plik postępu: Plik, który agent czyta na początku każdej rozmowy i aktualizuje na jej końcu: cel, reguły i zapis tego, co zrobiono i co dalej. Z listą pozycji obok nowa rozmowa może podjąć długą pracę, niczego nie powtarzając i niczego nie pomijając.
Pliki referencyjne: Stabilne dokumenty (przepisy, przewodniki stylu, glosariusze) dołączone do własnego asystenta, żeby rozumował z nimi spójnie.
Pokrycie: Jedna z sił w projektowaniu harnessu: dać modelowi dość, żeby zadziałał poprawnie. Gdy dostanie za mało, zgaduje albo wymyśla API.
Poziomy dojrzałości: Etykiety dla udostępnianych przepływów pracy: na własne ryzyko, wyróżnione (po przeglądzie) i oficjalne (utrzymywane, na poziomie produkcyjnym).
Próba: Jedno wykonanie jednego zadania w evalu. Agenci działają za każdym razem trochę inaczej, więc każde zadanie dostaje kilka prób, każdą od czystego startu.
Programowanie oparte na specyfikacji: Najpierw spisanie intencji w formie specyfikacji, a potem budowanie z niej przez coding agenta. Poziomy różnią się tym, co dzieje się ze specyfikacją później: służy jednej zmianie (spec-first), zostaje przy funkcji (spec-anchored) albo jest jedynym plikiem, który ludzie edytują (spec-as-source).
Projektowanie harnessu: Projektowanie i ulepszanie wszystkiego wokół modelu agenta: jego instrukcji, tooli, sprawdzeń i ograniczeń. W rozumieniu Mitchella Hashimoto to nawyk zmieniania harnessu za każdym razem, gdy agent popełni błąd, żeby nie popełnił go ponownie.
Przegląd ze świeżym contextem: Przegląd wykonany przez model, który dostaje gotową pracę, jej definicję ukończenia i źródła, ale nie rozmowę ani rozumowanie, z których powstała. Może otwierać pliki i uruchamiać sprawdzenia.
Przepływ pracy: System, w którym model i toole idą krokami ustalonymi z góry. Prostszy, tańszy i łatwiejszy do przetestowania niż agent, więc sięgaj po niego zawsze, gdy znasz kroki.
Przewaga kosztu wyniku: Tokeny wyniku kosztują zwykle 3 do 5 razy więcej niż tokeny wejściowe, więc gadatliwy domyślny styl szybko mnoży wydatki.
Przewodnik (sterowanie z wyprzedzeniem): Mechanizm harnessu, który kieruje agentem, zanim ten zacznie działać, na przykład instrukcje, przewodnik stylu albo szablon. Zwiększa szansę na dobrą pierwszą próbę.
Przycinanie harnessu: Wyjmowanie elementów harnessu po jednym i ponowne uruchamianie tych samych evali po każdej zmianie, żeby zostawić tylko to, co nadal poprawia wyniki. Każda reguła i każde sprawdzenie to założenie na temat modelu, a modele się zmieniają.
Pull request: Paczka commitów zgłoszona do przeglądu przed wciągnięciem do głównej linii.
Ralph loop: Sposób na uruchamianie jednego coding agenta bez nadzoru: skrypt w kółko wysyła mu ten sam prompt, plik planu i specyfikacje. Każdy obieg zaczyna się ze świeżym contextem, realizuje jeden element, uruchamia sprawdzenia i robi commit.
Rebase: Ponowne nałożenie commitów gałęzi na najnowszą gałąź main. Rebase tuż przed ostatnimi sprawdzeniami sprawia, że sprawdzenia testują kod, który naprawdę zostanie scalony.
Recall: Na ile niezawodnie model stosuje daną regułę. Reguły zakopane w środku long contextu przepadają.
Red/green TDD: Programowanie zaczynające się od testu: napisz test, uruchom go i zobacz, że nie przechodzi (czerwony), a potem zmieniaj kod, aż przejdzie (zielony). To, że najpierw widzisz porażkę, pokazuje, że test sprawdza zmianę, a nie coś, co już działało. W pracy z coding agentem zwykle wystarczy poprosić o red/green TDD.
Repository (repo): Folder projektu z pamięcią. Trzyma pliki, testy i zapis każdej zmiany, więc nic nigdy naprawdę nie ginie.
Satysfakcja (scenariusze): Miara StrongDM dla odłożonych scenariuszy: spośród wszystkich uruchomień wszystkich scenariuszy odsetek tych, które prawdopodobnie zadowoliłyby użytkownika. Zastępuje pojedynczy wynik „zaliczone” albo „niezaliczone”, gdy oprogramowanie z modelem w środku nie zachowuje się za każdym razem tak samo.
Scope judge: Model, który czyta tylko element roboczy i diff, który agent dla niego wytworzył, i wetuje zmiany wykraczające poza element. Działa po sprawdzeniach builda i testów. Śledź jego odsetek wet i ręcznie sprawdzaj próbkę jego werdyktów.
Shadow mode: Model decyzyjny pracuje na prawdziwych zadaniach, a decyzje nadal podejmuje obecny proces. Logujesz obie odpowiedzi i porównujesz je później. Żadna odpowiedź modelu nie uruchamia działania.
Shift left: Przesunięcie sprawdzenia tak wcześnie, jak tylko może się uruchomić, na przykład lint przy każdym pushu zamiast w CI albo w przeglądzie, żeby niepowodzenie wyszło tam, gdzie najtaniej je naprawić.
Skill: Paczka instrukcji i materiałów, która uczy asystenta dobrze wykonywać jedną robotę, do użycia w każdej kolejnej rozmowie.
SKILL.md: Jedyny wymagany plik skilla: na górze frontmatter YAML (nazwa i opis), a niżej w treści procedura.
Ślad: Zapis jednego uruchomienia jako drzewa kroków z pomiarem czasu, zwanych spanami: uruchomienie w korzeniu, a pod nim każde wywołanie modelu i każde wywołanie toola. Pokazuje, na co poszły czas i tokeny, co się nie udało i dlaczego uruchomienie się zatrzymało.
Sprawdzenie po cofnięciu poprawki: Wyjęcie poprawki, uruchomienie jej nowego testu, żeby zobaczyć, że znowu nie przechodzi z tego samego powodu co przed poprawką, a potem przywrócenie poprawki. Test, który przechodzi także bez poprawki, nie sprawdza jej i nie wyłapie błędu, jeśli ten wróci.
Środowisko w chmurze: Przygotowana konfiguracja, od której startują uruchomienia agenta w chmurze: pobrany kod, zainstalowane zależności, reguły sieci i sekrety. Każde uruchomienie pracuje na własnej kopii, więc każde zaczyna tak samo.
Stop hook: Hook, który uruchamia się za każdym razem, gdy agent skończy odpowiadać, i może odesłać go z powrotem do pracy, na przykład dopóki test nie przechodzi. Potrzebuje bezpiecznika, żeby sprawdzenie, które nigdy nie przejdzie, kończyło uruchomienie, zamiast kręcić się w kółko.
Stos pull requestów: Seria małych pull requestów, w której każdy opiera się na poprzednim, dzięki czemu dużą pracę przegląda się po jednej samodzielnej zmianie naraz. Każdy z nich po zmergowaniu musi zostawiać działający system.
Strefy progowe: Dwa progi, które dzielą odpowiedzi modelu decyzyjnego na trzy ścieżki: model działa sam, odpowiedź potwierdza człowiek albo sprawa trafia do człowieka (eskalacja). Wyznaczasz je na podstawie własnych oznaczonych przypadków i tego, ile kosztuje każdy błąd.
Styk: Punkt, w którym informacja przechodzi między osobami, zespołami albo systemami. Na stykach gubi się czas i jakość.
Symlink: Plik-skrót, który wskazuje na inny plik, żeby jedna prawdziwa kopia mogła pojawiać się w wielu miejscach.
Szablony ze zmiennymi: Briefy produkcyjne to szablony z nazwanymi zmiennymi. Dzięki temu da się je przejrzeć, wersjonować i forkować.
Tabela kalibracji: Tabela, która grupuje odpowiedzi modelu według prawdopodobieństwa i pokazuje, jak często każda grupa była trafna. Mówi ci, czy 0,8 naprawdę znaczy na twoich danych około 80%.
Terminal (shell): Okno tekstowe, w którym wpisujesz komendy, zamiast klikać przyciski. Tu mieszkają coding agenci.
Test celu: Warunek stopu, który agent uruchamia, zamiast go ogłaszać: build przechodzi albo endpoint zwraca 200.
Test odtwarzający błąd: Test napisany tak, żeby nie przechodził z powodu zgłoszonego błędu, zanim ktokolwiek ten błąd naprawi. Musi nie przechodzić z tego samego powodu, z którego błąd widzą użytkownicy, a nie przez literówkę czy brakującą konfigurację, żeby to, że później przejdzie, pokazało, że poprawka działa.
Test suite: Samosprawdzenia projektu, uruchamiane jedną komendą, która melduje: przeszło albo nie przeszło.
Triggers: Sposoby, w jakie agent się uruchamia: według harmonogramu, na żądanie albo na zdarzenie, na przykład nowy wiersz w bazie.
Tripwire: W SDK do agentów sygnał wysyłany przez zabezpieczenie, gdy jego sprawdzenie nie przechodzi. Uruchomienie się zatrzymuje, a twój kod decyduje, co dalej, na przykład mówi użytkownikowi, że prośby nie da się obsłużyć.
Ukryty kontekst: System prompty, pliki referencyjne, historia rozmowy i dociągnięte fragmenty. Wszystko to wydaje tokeny przy każdym uruchomieniu.
Użyteczny a poprawny: Użyteczny znaczy, że kolejne etapy potrafią odczytać wynik. Poprawny znaczy, że treść się zgadza. Liczy się jedno i drugie.
Verifier: Sprawdzenie, które agent może uruchomić, ale którego nie kontroluje, na przykład build albo przebieg testów, i które odpowiada w kilku linijkach. W fabryce verifiery działają, zanim otworzy się pull request, a niezaliczony verifier nie pozwala go otworzyć.
Vibe coding: Budujesz coś, opisując zwykłymi słowami, czego chcesz, a kod pisze AI. Ty sterujesz na wyczucie.
Worktree: Druga kopia robocza tego samego repo, we własnym folderze i na własnym branchu, żeby dwie prace nigdy sobie nie wchodziły w drogę.
Wymagane sprawdzenie statusu: Sprawdzenie, na przykład test suite, które musi przejść, zanim pull request będzie mógł zostać scalony z chronioną gałęzią. Dzięki niemu testy przestają być radą i stają się warunkiem.
YAML: Ustawienia zapisane jako opisane linie, na przykład name: pdf-export. Czytaj to jak formularz, a nie jak kod.
Zasada 50 wejść: Przetestuj agenta na 50 różnych prawdziwych wejściach, zanim zaufasz mu bez nadzoru. Każdy błąd przypisz do kategorii.
Zasada budowania: Kiedy łapiesz się na tej samej pracy po raz drugi, zbuduj z niej agenta, żeby za trzecim razem zrobiła się sama.
Zaufane dane wejściowe: Dane zwalidowane już wcześniej, jak wiersz w bazie z wymuszonym schematem. Na nich możesz działać.
Zbiór ewaluacyjny: Zestaw zadań, które możesz uruchomić ponownie, każde z warunkiem zaliczenia, żeby ocenić agenta i jego harness przed zmianą i po niej. Rozbudowuj go na podstawie prawdziwych błędów i dodaj przypadki, w których coś nie powinno się stać.
Zbiór powtórek: Stała lista dawnych elementów roboczych, każdy z commitem, od którego startuje, i wynikiem, który liczy się jako zaliczenie. Zanim wdrożysz zmianę, puszczasz na nim obecny i zmieniony system i porównujesz element po elemencie.
Zbiór referencyjny: Prawdziwe przypadki z twojej pracy, każdy oznaczony właściwą odpowiedzią przez osoby, które znają tę pracę. Na nim oceniasz model decyzyjny, zanim mu zaufasz.
Zestaw reguł: Nazwany zestaw reguł dla gałęzi repo, na przykład wymóg pull requesta, zaliczonych sprawdzeń i zatwierdzenia, zanim cokolwiek zostanie scalone. Zmiany od agentów podlegają mu tak samo jak zmiany wszystkich innych.
Zmiana w całej flocie: Ten sam rodzaj zmiany wprowadzany w wielu repo, na przykład aktualizacja zależności albo konfiguracji, zwykle jako jeden mały pull request na repo. O tym, czy zmiana zostanie scalona, nadal decydują sprawdzenia i właściciele każdego repo.
Źródło prawdy: Jedno miejsce, w którym fakt jest oficjalnie zapisany i na które wskazuje każda inna wzmianka. W bazie kodu wersjonowana dokumentacja w repo może być źródłem prawdy dla architektury, decyzji i reguł biznesowych.
Zweryfikowany wynik: Zmiana, która została zmergowana, wdrożona i nie wymagała wycofania, hotfixa ani późniejszej poprawki. Liczenie takich zmian zamiast otwartych pull requestów albo wygenerowanych linii pokazuje, co praca z coding agentami naprawdę dała.
Złota reguła: Stanowcza, mechaniczna reguła tego, jak kod ma zawsze wyglądać, zapisana w repo, żeby agent uruchamiany według harmonogramu mógł znajdować odstępstwa i otwierać małe pull requesty, które je poprawiają.

Ryzyko i bezpieczeństwo

Adversarial testing: Celowe podawanie agentowi wejść trudnych, sprzecznych, niepełnych albo złośliwych, żeby jeszcze w testach znaleźć miejsca, w których pęka.
Adversarial verification: Rozdzielasz tworzenie i ocenianie. Jedno przejście tworzy, drugie atakuje z zadaniem podważenia, a wdrażasz tylko to, co przetrwa.
AI slop: Byle jaki, masowo produkowany tekst albo obraz z AI. Dokładnie to, czego unika dobre promptowanie.
Audit logs: Zapis każdego wywołania toola MCP: znacznik czasu, kto wywołał, z jakim scope'em i z jakim wynikiem. Tu sprawdzasz, co się właściwie stało.
Automatyczna pauza: Bezpiecznik, który zatrzymuje agenta, gdy trafność w próbkach spada poniżej ustalonego progu, i trzyma go wstrzymanego, dopóki człowiek nie włączy go z powrotem.
Blast radius: Zasięg systemów, na które agent wpłynie, jeśli coś pójdzie źle. Agent podłączony do wielu z nich potrzebuje ciaśniejszych HITL gate'ów.
Brak postępu: Awaria pętli: agent w kółko powtarza tę samą nieudaną akcję. Notuj, co już zostało wypróbowane, i ogranicz liczbę powtórzeń.
Błąd automatyzacji: Skłonność do polegania, albo nadmiernego polegania, na wyniku systemu zautomatyzowanego. Unijny AI Act nazywa ją wprost, a odsetek korekt bliski zera to jeden z sygnałów ostrzegawczych.
Confidence calibration: Każesz AI ocenić własną pewność (wysoka, średnia, niska) i podać powód, żeby było jasne, które wyniki wymagają przeglądu.
Deny rule: Reguła uprawnień, która blokuje tool, komendę albo ścieżkę niezależnie od tego, co zdecyduje model, na przykład Read(./.env) w Claude Code. Reguły deny są sprawdzane najpierw, więc reguła allow nie może zrobić od nich wyjątku.
Drift: Wyniki modelu z czasem się psują, bo zmienił się wzorzec wejść. Dzieje się cicho i widać to tylko na wielu wynikach naraz.
Drift (loop): Awaria pętli: agent zapomina cel i optymalizuje zadanie poboczne. Powtórz cel blisko końca contextu.
Działania zawsze z człowiekiem: Rzeczy, które zawsze wymagają zgody człowieka: pieniądze, zdrowie, bezpieczeństwo, umowy, warunki prawne, pisma do urzędów, status prawny.
Eksfiltracja: Wysyłanie danych na zewnątrz komuś, kto nie powinien ich mieć. W przypadku agenta może je wynieść każda droga komunikacji ze światem zewnętrznym: e-mail, wiadomość, żądanie do sieci, a nawet link albo adres obrazka.
Faworyzowanie własnej pracy: Skłonność agenta do zbyt łagodnego oceniania własnej pracy, kiedy ma ją sprawdzić albo ocenić. Przeciwdziała temu model sprawdzający, który tej pracy nie wykonywał.
Guardrails: Zabezpieczenia. Zasady i sprawdzenia, które nie pozwalają AI zrobić czegoś ryzykownego.
Hallucination: Asystent podaje nieprawdę z pełnym przekonaniem. Zawsze warto to szybko sprawdzić.
Hallucination pakietów: Pakiet oprogramowania, który podsuwa model, a który nie istnieje. Każdy może zarejestrować wymyśloną nazwę i wypełnić ją szkodliwym kodem, więc sprawdzaj każdy nowy pakiet, zanim go zostawisz.
Higiena danych: Nawyki pracy z prywatnymi informacjami przy AI. Dane wrażliwe trzymaj tam, gdzie już są, zamiast wklejać je do toola, nad którym nie masz kontroli.
HITL gate: Punkt, w którym człowiek przegląda wynik, zanim agent zadziała. Wymagany przy działaniach nieodwracalnych i przy niskiej pewności.
Human-in-the-loop (HITL): Człowiek przegląda albo zatwierdza wynik AI przed jakimkolwiek działaniem, zwłaszcza na krokach regulowanych, nieodwracalnych albo o dużych skutkach.
Indirect prompt injection: Odmiana prompt injection, w której obce instrukcje przychodzą w treści czytanej przez agenta, na przykład na stronie internetowej, w e-mailu, w udostępnionym pliku albo w wyniku toola, a nie w tym, co wpisuje użytkownik.
Izolacja: Ograniczenie tego, do czego agent może sięgnąć, niezależnie od tego, co zdecyduje: sandbox, dostęp do sieci wyłączony albo ograniczony do listy i dane uwierzytelniające trzymane poza jego zasięgiem. Działa także wtedy, kiedy nikt nie patrzy, a zatwierdzenia tego nie potrafią.
Jailbreak: Prompt skrojony tak, żeby obejść zabezpieczenia AI. Nie próbuj: te zabezpieczenia chronią ciebie i innych.
Lenistwo agenta: Agent przerywa w połowie długie zadanie z wieloma częściami i zgłasza całą pracę jako gotową. Przeciwdziała temu sprawdzenie, które agent musi uruchomić, zanim się zatrzyma.
Lethal trifecta: Określenie Simona Willisona na agenta, który ma dostęp do prywatnych danych, widzi niezaufane treści i może wysyłać dane na zewnątrz. Kiedy agent ma wszystkie trzy, atakujący może podstępem doprowadzić do wycieku danych. Usuń co najmniej jedną z tych trzech nóg.
Lista dozwolonych hostów: Lista hostów, do których może sięgnąć uruchomienie agenta, na przykład twój rejestr pakietów. Wszystko inne jest zablokowane, co ogranicza to, dokąd zdezorientowany albo zmanipulowany agent może wysłać dane.
Mechanizm wymuszany przez tool: Ograniczenie stosowane przez tool niezależnie od tego, co zdecyduje model, na przykład reguła uprawnień, hook, sandbox albo aplikacja, której nie podłączono. W przeciwieństwie do instrukcji model nie może go pominąć.
Model szwajcarskiego sera: Obraz z inżynierii bezpieczeństwa: każda warstwa sprawdzeń ma dziury, ale warstwy z dziurami w różnych miejscach przepuszczają niewiele błędów. Żadne pojedyncze sprawdzenie nie wyłapie wszystkiego, więc układaj kilka warstwami.
Nadgorliwość: Agent robi krok, który wygląda na pomocny, ale wykracza poza to, o co prosisz, i poza to, na co się zgadzasz, na przykład używa znalezionych danych uwierzytelniających. Ogranicz to mechanizmami wymuszanymi przez tool.
Nadzór: Pilnowanie bezpieczeństwa agenta przez człowieka, który zatwierdza każde działanie, zanim zostanie wykonane. Działa tylko, dopóki ta osoba uważa i rozumie, co zatwierdza, więc praca, która toczy się, kiedy nikt nie patrzy, wymaga izolacji.
Najmniejsze uprawnienia: Dawanie agentowi, człowiekowi albo programowi tylko takiego dostępu, jakiego wymaga jego zadanie, i niczego, co przetrwa to zadanie. Dla agenta bez nadzoru oznacza to jedno repo, mały zestaw tooli i dane uwierzytelniające, które wygasają razem z uruchomieniem.
Pewny siebie błąd: Odpowiedź, która brzmi autorytatywnie, a jest subtelnie błędna, w dokładnie tym samym tonie co odpowiedzi trafne.
Poziom ryzyka działania: Niski, średni albo wysoki poziom ryzyka nadany jednemu działaniu, które agent może wykonać, na podstawie czterech pytań: czy coś zapisuje, czy da się je cofnąć, czyjego dostępu używa i czy w grę wchodzą pieniądze. Każdemu poziomowi odpowiada allow, ask albo deny.
Próg pewności: Poziom, poniżej którego agent zatrzymuje się i eskaluje sprawę, zamiast działać.
Prompt injection: Złośliwe instrukcje ukryte w treści, którą AI czyta, próbujące przejąć kontrolę nad tym, co robi.
Proxy danych uwierzytelniających: Usługa poza sandboxem agenta, która przechowuje prawdziwy klucz i dodaje go do wychodzących żądań do dozwolonych domen. Kod wewnątrz sandboxa widzi tylko wartość zastępczą, więc przejęte uruchomienie nie ma klucza, który mogłoby ukraść.
Push protection: Sprawdzenie w GitHubie, które blokuje push zawierający hasło, klucz albo token, zanim trafi do repo, zamiast ostrzegać cię po fakcie.
Red-teaming: Adversarial testing z celem atakującego: celowo atakujesz własną, prawdziwą konfigurację, na przykład próbując doprowadzić do wycieku danych, żeby zobaczyć, które mechanizmy obrony wytrzymają. W przypadku agenta często oznacza to podrzucenie nieszkodliwej instrukcji do czegoś, co agent czyta.
Revocation: Zdejmowanie scope'ów z połączenia MCP, kiedy przepływ pracy przechodzi na emeryturę, żeby nie zbierały się uśpione połączenia.
Reward hacking: Zaliczenie sprawdzenia bez zrobienia tego, czego sprawdzenie miało dowieść, na przykład usunięcie nieprzechodzącego testu albo napisanie kodu, który działa tylko dla danych wejściowych testu. Chroń sprawdzenia przed edycją, a część z nich trzymaj tam, gdzie agent ich nie widzi.
Ścieżka eskalacji: Ustalona droga dla oznaczonej sprawy: kto dostaje powiadomienie, jak i z jakim contextem. Każdy HITL gate potrzebuje takiej drogi.
Scopes: Uprawnienia do poszczególnych akcji, które wystawia serwer MCP, na przykład read_employees osobno od update_employee. Nadawaj tylko minimum.
Slopsquatting: Rejestrowanie nazwy pakietu, którą modele AI mają skłonność wymyślać, żeby kod idący za podpowiedzią modelu zainstalował pakiet atakującego. Nazwa pochodzi od typosquattingu, w którym atakujący rejestrują nazwy pakietów z literówkami.
Test podmiany: Zmieniasz jeden szczegół, który nie powinien mieć znaczenia, na przykład imię albo miejsce, i uruchamiasz przypadek jeszcze raz. Jeśli odpowiedź przesuwa się bardziej niż zwykły szum, decyzja korzysta z tego szczegółu.
Ukryte znaki Unicode: Znaki, które nie zajmują widocznego miejsca, na przykład łączniki o zerowej szerokości i znaczniki kierunku tekstu. Mogą ukryć w pliku instrukcję, której człowiek czytający plik nie zobaczy, a model ją przeczyta.
Workspace trust: Sprawdzenie, które coding agent robi, zanim użyje własnych ustawień folderu, na przykład hooków zapisanych w repo: pyta, czy ufasz temu folderowi. Uruchomienia ze skryptu mogą pominąć to pytanie i traktować folder jako zaufany.
Wyrywkowe sprawdzanie: Bierzesz część wyników przepływu pracy (powiedzmy 10%) i przeglądasz je samodzielnie.
Zasada dwóch dla agentów: Reguła projektowa firmy Meta dotycząca prompt injection: w ramach jednej sesji agent powinien mieć najwyżej dwie z trzech właściwości: niezaufane dane wejściowe, dostęp do wrażliwych systemów albo prywatnych danych i możliwość zmieniania stanu albo komunikowania się na zewnątrz. Mając wszystkie trzy, potrzebuje człowieka albo innego niezawodnego sprawdzenia.
Żelazna zasada: Nigdy nie wklejaj do ogólnego toola AI danych bankowych, haseł, dokumentów tożsamości ani niczego prywatnego, co nie należy do ciebie.
Zmęczenie zatwierdzaniem: Co się dzieje, kiedy ludzie widzą tyle próśb o zgodę, że przestają je czytać. Zatwierdzenia wciąż padają, ale przestają być sprawdzeniem. Pytaj rzadziej, pokazuj dokładnie, co się stanie, i izoluj rutynową pracę.
Zły moment zatrzymania: Awaria pętli: agent kończy za wcześnie albo nie kończy nigdy. Ratunek to jawny test zakończenia.

Toole i asystenci

Agent w chmurze: Coding agent, który działa na maszynach dostawcy zamiast na twoich. Dajesz mu zadanie, on pracuje we własnym przygotowanym środowisku i oddaje gałąź albo pull request, który przejrzy człowiek.
Agent wbudowany w systemy firmowe: Agent, który mieszka w toolu takim jak Notion i czyta oraz zapisuje jego strony i bazy.
AI agent: Zapisany brief, który sam wykonuje powtarzalne zadanie: według harmonogramu, na żądanie albo na zdarzenie.
Approval policy: W Codex ustawienie, które decyduje, kiedy agent zatrzymuje się i pyta, zanim wyjdzie poza swój sandbox, na przykład on-request albo never. Tryb sandboxa ustala, co komendy mogą technicznie zrobić.
Artifacts: Funkcja Claude, która tworzy kod, dokumenty, slajdy i interaktywne wyniki w edytowalnym panelu z boku.
Asystent AI: Twój samodzielny tool do czatu (ChatGPT, Gemini, Claude albo Grok). Działa reaktywnie: ty pytasz, on odpowiada.
Asystent wbudowany w aplikację: AI wbudowana w aplikację, której już używasz, jak Gmail, Notion czy Word. Działa na otwartej stronie.
ChatGPT: Asystent OpenAI, bezpłatnie na chatgpt.com. Solidny wszechstronniak z największą społecznością użytkowników.
Checkpoint (migawka plików): Migawka twoich plików, którą tool do programowania robi, zanim agent je edytuje, żeby dało się cofnąć jego ostatnie kroki. Służy do szybkiego odzyskiwania w obrębie jednej rozmowy; niektóre toole nie widzą zmian zrobionych komendami shella, więc commituj też do gita.
Claude: Asystent Anthropic, bezpłatnie na claude.ai. Mocny w długich tekstach, ciężkiej analizie dokumentów i trudnym rozumowaniu.
Claude Projects: Trwałe przestrzenie pracy w Claude, w których trzymasz dokumenty referencyjne. Claude ma je pod ręką w każdej rozmowie.
Co-pilot: AI, która pracuje obok ciebie w toolu i podpowiada na bieżąco, a stery zostają u ciebie.
Connectors: Połączenia, dzięki którym Claude sięga za twoją zgodą do tooli takich jak Drive, Gmail, Slack, GitHub i Linear.
Custom GPTs: Zapisani asystenci ChatGPT wielokrotnego użytku: ustawiasz raz, korzystasz zawsze.
Deep Research: Tryb, który prowadzi rozbudowane śledztwo po wielu źródłach i wraca z gotowym raportem z przypisami.
Gemini: Asystent Google, bezpłatnie na gemini.google.com. Najmocniejszy, gdy wejście jest duże, mieszane albo wizualne, i działa w Google Workspace.
Gems: Zapisani własni asystenci Gemini wielokrotnego użytku: ustawiasz raz, korzystasz zawsze.
Grok: Asystent xAI, bezpłatnie na grok.com. Wpięty w X i w żywą sieć, najmocniejszy w bieżących wydarzeniach.
Instrukcje projektu: Stałe instrukcje, które ustawiasz raz w projekcie w ChatGPT albo Claude. Dostaje je każdy czat w projekcie razem z plikami projektu, ale to wciąż prośby, które model może pominąć.
Permission mode: Ustawienie coding agenta, które decyduje, jakie działania agent wykonuje, nie pytając cię wcześniej, od samego czytania po wszystko. Reguły uprawnień nakładają się na to ustawienie, a reguła deny i tak blokuje w każdym trybie.
Plan mode: Tryb coding agenta, w którym agent czyta kod i proponuje plan, ale niczego nie zmienia, dopóki go nie zatwierdzisz. Oddziela ustalanie, co zrobić, od samego robienia.
Platforma automatyzacji: Tool no-code (Zapier, Make), który według harmonogramu przenosi dane między aplikacjami.
Plugin: Paczka, która instaluje naraz kilka części konfiguracji agenta, na przykład skille, hooki i połączenia z serwerami. Plugin może uruchamiać kod z twoimi uprawnieniami, więc przed instalacją przeczytaj, co zawiera.
Przegląd kodu przez AI: Przegląd pull requesta albo diffu wykonany przez model AI. Jego uwagi to tropy do sprawdzenia w kodzie, a nie zatwierdzenia, i nie zastępuje on testów ani przeglądu przez człowieka.
Zapisany asystent wielokrotnego użytku: Własny asystent, którego ustawiasz raz i używasz wielokrotnie, na przykład Custom GPT, Gem albo Claude Project.

Praca z AI

AI-pilled: Ktoś, kogo AI przekonała. Raz zadziała w jednym zadaniu i już sięgasz po nią wszędzie. Zwykle mówi się to z przymrużeniem oka.
Biegłość w AI: Umiejętność pracy z AI, budowania na niej i myślenia razem z nią. Najbardziej opłacalna umiejętność tej dekady.
Ciemna fabryka: Najwyższy z pięciu poziomów autonomii Dana Shapiro: specyfikacje wchodzą, oprogramowanie wychodzi, a kodu nie pisze ani nie przegląda żaden człowiek. Nazwa pochodzi od fabryk prowadzonych w całości przez roboty, w których nie pracują ludzie.
Czytelność dla agenta: Czy wiedza, której agent potrzebuje, leży w miejscu, które może otworzyć w trakcie działania. Decyzja, która istnieje tylko na spotkaniu, w wątku na czacie albo w czyjejś głowie, jest nieczytelna: dla agenta nie istnieje.
Domyślnie najpierw AI: Przy każdym nowym zadaniu poświęcasz 30 sekund na pomyślenie, jak mogłaby pomóc AI, zanim zrobisz je ręcznie.
Dług zrozumienia: Rosnąca różnica między tym, ile kodu zespół wdrożył, a tym, ile z niego ktokolwiek w zespole rozumie. Narasta po cichu, kiedy testy są zielone, i wychodzi na jaw, gdy coś się psuje. Nazywa się go też długiem poznawczym.
Limit pracy w toku: Górna granica liczby zadań rozpoczętych i jeszcze niezmergowanych. Przy równoległych coding agentach ustal ją według tego, ile zmian zdołasz przejrzeć i zmergować, a nie według tego, ilu agentów możesz uruchomić, i przejrzyj to, co czeka, zanim uruchomisz kolejnych.
Myślenie w skali 100x: Nowe tempo: miesiące zmieniają się w dni, dni w godziny. Kiedy koszt spada sto razy, możliwe stają się rzeczy dotąd nierealne.
Naucz się uczyć od nowa: Metaumiejętność dalszej nauki, kiedy dawna wiedza ekspercka trafia pod automatyzację. Nowa przewaga.
Notatka przekazania: Krótka notatka, dzięki której nowa rozmowa może przejąć zadanie: cel w oryginalnym brzmieniu, reguły, które muszą obowiązywać, co zrobiono i jak to sprawdzono, co dalej i co nie zadziałało.
Paradoks nadzoru: Problem polegający na tym, że nadzorowanie agenta AI wymaga dokładnie tych umiejętności, które poleganie na nim może osłabiać. Badanie Anthropic na własnych inżynierach używa tego określenia w odniesieniu do programowania: sprawdzanie kodu agenta wymaga umiejętności programowania, które ćwiczysz rzadziej, kiedy kod pisze agent.
Pięć poziomów autonomii: Model Dana Shapiro opisujący, jaką część programowania zespół przekazuje AI, od Poziomu 0, na którym człowiek pisze każdą linijkę, po Poziom 5, czyli ciemną fabrykę. To model jednej osoby, przydatny jako wspólne słownictwo, a jeden zespół może być naraz na kilku poziomach.
Praca ma znikać: Podejście, w którym AI wymazuje całe kategorie pracy, usuwając zadania z listy na dobre.
Prawo Goodharta: Obserwacja, że liczba przestaje być dobrą miarą, kiedy ludzie są za nią nagradzani. Ustal liczbę otwartych pull requestów jako cel, a dostaniesz więcej pull requestów, niezależnie od tego, czy są coś warte.
Przykład referencyjny: Jeden fragment istniejącego kodu, który wskazujesz jako wzór dla danego schematu, na przykład nowego endpointu albo testu. Coding agenci kopiują to, co znajdą, więc wskazanie najlepszego przykładu kieruje tym, co skopiują.
Sprawdzanie krzyżowe: To samo ważne pytanie przepuść przez dwa toole i porównaj wyniki. Zgodność podnosi pewność, rozbieżność wskazuje coś do sprawdzenia.
Teraz każdy jest twórcą: Kto zbuduje przepływ pracy z AI, jest twórcą, niezależnie od tego, co ma w nazwie stanowiska.
Triaż: Sortowanie przychodzącej pracy tak, żeby każdy element trafił we właściwe miejsce. W fabryce każdy element trafia do agenta, do człowieka albo z powrotem do autora, a przy każdej decyzji zapisuje się uzasadnienie i poziom pewności.
Zanik umiejętności: Utrata umiejętności, której już nie ćwiczysz, bo pracę wykonuje tool. Przy coding agentach główną obawą jest debugowanie: w jednym badaniu właśnie tu różnica była największa, a to ta umiejętność jest potrzebna, żeby sprawdzić, co oddaje agent.
Zasada 80%: Do wszystkiego zaczynaj od swojego asystenta AI. Tool w aplikacji to wygodny skrót, który możesz pominąć.