Function calling, agenci i MCP wszystkie opierają się na tym samym: narzędziach, które LLM może wywołać. Ale narzędzie zbudowane dla niedeterministycznego, omylnego wołającego potrzebuje innego projektu niż zbudowane dla kodu. Deep-dive o tym, co czyni narzędzie niezawodnym dla LLM — nazewnictwo, zakres, walidacja, komunikaty błędów, z których może się odzyskać, i bezpieczeństwo, które nie może żyć w modelu.
Poskładaj to razem — Solid Stack bez Redisa, Kamal, pgvector i wypracowane w praktyce zasady budowania z LLM — a wyłania się spójny obraz: Rails to znakomite środowisko dla aplikacji AI-native, właśnie dlatego, że pozwala małemu zespołowi budować i uruchamiać zarówno aplikację, jak i jej funkcje AI. Synteza tego, w którym miejscu ten stos się dziś znajduje.
Evale przed startem mówią ci, że agent działa na twoim zbiorze testowym. Produkcja mówi ci, czy działa na rzeczywistości — a tylko ciągłe monitorowanie zamyka tę lukę. Deep-dive o obserwowaniu agentów na wolności: co logować, co mierzyć, jak łapać cichą degradację i jak awarie produkcyjne wracają do twoich evali.
Gdy pojedyncze agenty działają, kusi, by spiąć kilka razem — badacza, pisarza, krytyka — i pozwolić im współpracować. Czasem to potężne; często to złożoność, której nie potrzebowałeś. Deep-dive o wzorcach orkiestracji dla systemów wieloagentowych, kiedy zarabiają na swoje utrzymanie i o trybach awarii, które mnożą się, gdy agenty się mnożą.
Gdy agent AI robi implementację, specyfikacja staje się artefaktem o najwyższej dźwigni w projekcie — jasna specyfikacja produkuje dobry kod, mglista produkuje pewny siebie bałagan. Deep-dive o tym, dlaczego rozwój sterowany specyfikacją odżył w erze agentów, jak wygląda dobra specyfikacja dla agenta i jak faktycznie zmienia się przepływ pracy.
Najbardziej niezawodne systemy AI działające produkcyjnie nie są w pełni autonomiczne — utrzymują człowieka przy decyzjach, które mają znaczenie. Ale „człowieka w pętli” łatwo zaprojektować źle: bezmyślne zatwierdzenia, zmęczenie alertami, obwinianie ludzi za błędy modelu. Dogłębna analiza tego, jak podzielić pracę między człowieka a AI, żeby każde robiło to, w czym jest naprawdę dobre.
Małe modele stały się dość dobre, a urządzenia dość potężne, że uruchamianie AI na własnym sprzęcie użytkownika — telefonie, laptopie, przeglądarce — jest teraz realną opcją. Wpis trendowy o tym, co kupuje AI local-first, co kosztuje i o hybrydowej rzeczywistości, gdzie uczciwą odpowiedzią jest „trochę obu”.
Postawienie agenta na produkcji jest trudniejsze niż pojedyncze wywołanie LLM, bo agent to pętla z pomnożoną powierzchnią awarii — i musisz zarazem ograniczyć go w czasie wykonania i mierzyć go w czasie. Deep-dive o dwóch dyscyplinach, które czynią agentów produkcyjnych godnymi zaufania: barierach ograniczających, co agent może zrobić, i evalach testujących całą trajektorię, nie pojedyncze wyjście.
Są trzy sposoby, by skłonić LLM, by robił to, czego twoja aplikacja potrzebuje — prompting, pobieranie i fine-tuning — a zespoły rutynowo sięgają po niewłaściwy. Rozwiązują różne problemy, a koszty różnią się ogromnie. Wpis trendowy o tym, do czego każdy faktycznie służy, i kolejność decyzji, która ratuje cię przed przeinżynierowaniem.
Związanie aplikacji z pojedynczym dostawcą LLM to ryzyko: zmiana ceny, awaria albo lepszy model gdzie indziej zostawia cię utkniętym. Traktowanie dostawców jako wymiennych za warstwą routingu kupuje odporność i elastyczność — ale ma realne koszty. Deep-dive o routingu wielodostawcowym, gdzie się opłaca i gdzie jest przedwczesny.
Wywołania LLM są opomiarowane per token, więc w aplikacji intensywnie używającej LLM koszt to wymiar inżynierski, który projektujesz — nie rachunek, który odkrywasz. Deep-dive o wzorcach, które trzymają go pod kontrolą: warstwowanie modeli, cache, dyscyplina tokenów, budżety i pomiar, który musi przyjść przed którymkolwiek z nich.
Prototyp był magią. Potem wysłaliśmy go do prawdziwych użytkowników i wszystko, co demo ukryło, stało się wymagalne naraz — koszt, opóźnienie, nadużycie, padające API i unikalny problem wspierania funkcji, której wyjścia nie możesz w pełni przewidzieć. Opowieść z frontu o przepaści między demem LLM a produktem LLM.
Rok temu AI w edytorze oznaczało głównie autouzupełnianie. Teraz mamy narzędzia, które edytują przez wiele plików, uruchamiają komendy i przepracowują zadanie, gdy patrzysz. Po roku używania ich w prawdziwej pracy oto uczciwy przegląd: w czym są naprawdę dobre, gdzie zawodzą i jak zmieniają zawód.
Modele o otwartych wagach, takie jak Llama 2 i Mistral, sprawiają, że sprawnego LLM można dziś uruchomić na własnej infrastrukturze zamiast korzystać z czyjegoś API. Spojrzenie na to, po co w ogóle to robić — prywatność, koszt, kontrola — jaki jest realny koszt operacyjny i uczciwe pytanie, czy w ogóle warto.
Function calling pozwala LLM-owi poprosić twój kod o uruchomienie funkcji i skorzystanie z wyniku — model, który umiał tylko mówić, zaczyna wyszukiwać dane i działać. Szczegółowo o tym, jak to naprawdę działa, dlaczego to po prostu ustrukturyzowany output z pętlą dookoła i dlaczego to ty w pełni kontrolujesz, co się faktycznie uruchamia.
Nie możesz asertować dokładnej równości na wyjściu, które za każdym razem jest inne — więc jak w ogóle testować funkcję LLM? Deep-dive o evalach: budowaniu reprezentatywnego zbioru testowego, ocenianiu właściwości zamiast łańcuchów, łapaniu regresji i traktowaniu ewaluacji jako siatki bezpieczeństwa, która pozwala zmieniać prompty z pewnością.
Wywołanie LLM trwa sekundy, a użytkownik gapiący się na spinner czuje każdą z nich. Strumieniowanie tokenów w miarę ich generowania zamienia martwe oczekiwanie w żywy tekst — a Turbo Streams to dokładnie ten prymityw Railsów, który wypycha ten tekst na stronę. Deep-dive o podłączeniu wolnego wyjścia modelu do responsywnego UI.
Wyszukiwanie słów kluczowych dopasowuje słowa; wyszukiwanie semantyczne dopasowuje znaczenie. Deep-dive o embeddingach i podobieństwie wektorowym oraz o tym, jak pgvector pozwala robić wyszukiwanie semantyczne w Postgresie, który już uruchamiasz — bez osobnej bazy wektorowej.