Artykuły
Sufitem AI jest twoja ambicja: cztery wymiary – szybkość, wysokość, głębia i zasięg
Felix Rieseberg, inżynierski lider w Anthropic, rozkłada „większą ambicję wobec AI" na cztery wymiary: szybkość, wysokość, głębię i zasięg. Ten tekst zbiera jego metody i przykłady oraz moje własne notatki z praktyki: celowe polecenia nastawione na cel i zespół ekspertów złożony z Multi-AI Agents, który robi wielostronne recenzje krzyżowe i podnosi jakość zadań.
· 5 min czytania
Felix Rieseberg, inżynierski lider w Anthropic, pisze w tekście „How to be more ambitious: A tutorial for humans with models", że gdy widzi, jak ktoś osiąga imponujące rezultaty z pomocą AI, on i ludzie wokół niego reagują zwykle tak samo: „Nie jesteśmy wystarczająco ambitni."
Moja interpretacja: granicą tego, jak daleko człowiek zajdzie z AI, jest zwykle jego własna ambicja i wyobraźnia, a nie model.
Rozkłada „ambicję" na cztery wymiary:
- Szybkość (Speed): ta sama praca wykonana w krótszym czasie.
- Wysokość (Altitude): podniesienie poziomu abstrakcji, patrzenie na końcowy rezultat, a nie na pojedyncze zadanie.
- Głębia (Depth): praca według standardów, narzędzi i metod czołowych ekspertów w danej dziedzinie.
- Zasięg (Range): wyjście poza jedną dziedzinę i szukanie rozwiązań na styku dziedzin.
Wniosek na początek: precyzyjnie formułuj polecenia nastawione na cel i kieruj zespołem ekspertów złożonym z Multi-AI Agents, który współpracuje z wielu perspektyw i robi recenzje krzyżowe – dopiero wtedy jakość zadań rośnie w całości.
1. Szybkość: najbardziej podstawowa i najrzadziej blokująca#
Ta sama praca wykonana w krótszym czasie. Felix uważa, że wszyscy dobrze to już znają, więc w artykule pomija ten wymiar.
Moje zdanie: szybkość to najbardziej oczywista wartość AI, ale jeśli liczy się tylko ona, sposób współpracy niewiele się zmieni. Prawdziwą różnicę robią pozostałe trzy wymiary.
2. Wysokość: pytaj o „cel stojący za celem"#
Podstawowe pytanie: jaki jest naprawdę oczekiwany rezultat następnego kroku? Jaki jest cel stojący za celem?
Przykłady Felixa:
- Od naprawienia jednego crasha do aplikacji, która przestaje się crashować. Najpierw poprosił Claude'a o naprawę jednego crasha, potem zmienił wymaganie na zero crashy w aplikacji. Żeby to mogło działać automatycznie i ciągle, musiał najpierw zmienić własny proces: ułatwić dostęp do raportów o crashach, powiązać wersje aplikacji z commitami w Gicie i pozwolić Claude'owi używać maszyn z Windows, macOS i Linuksem do odtwarzania i weryfikowania poprawek.
- Trzy stopnie eskalacji kwartalnego przeglądu biznesowego (QBR):
- Użyć jak najbardziej surowych danych i wyjaśnić, co zmieniło się w tym kwartale, dlaczego i co robić dalej.
- Wskazać 3 najpilniejsze decyzje i dla każdej napisać argumenty za i przeciw.
- Zaprojektować mechanizm zastępczy, który wykrywa problemy wcześniej niż kwartalna prezentacja, przetestować go na danych historycznych i przez jeden kwartał prowadzić równolegle z obecnym procesem.
Zaznacza też granicę: w 2026 roku niejasne cele w rodzaju „Claude, zarób dla mnie pieniądze" jeszcze nie działają, ale spodziewa się, że poziom abstrakcji, z którym radzą sobie modele, będzie stale rósł.
3. Głębia: wymagania na miarę czołowych ekspertów#
Metody Felixa:
- Używaj narzędzi, z których naprawdę korzysta dana branża. Modele często zmieniają tylko słownictwo, a nie metodę, i na odczepnego dają tabelę w Markdownie. Trzeba nalegać na prawdziwe narzędzia analityczne, takie jak bazy danych i modele statystyczne.
- Stawiaj cele, które wydają się nierozsądne, i mów modelowi, że da się je osiągnąć. Jego przykład: po skróceniu ładowania strony z 10 do 5 sekund zażądał 200 milisekund. Gdy model się wycofuje, upieraj się, że cel jest osiągalny.
- Podważaj założenia, w które sam wierzysz. Daj modelowi surowe dane i sprawdzaj je w sposób adwersarialny. Na przykład: „Uważamy, że odpływ użytkowników wynika z onboardingu; spróbuj odtworzyć ten wniosek na podstawie surowych danych."
- Wytwarzaj nową wiedzę. Zbuduj symulację na podstawie logów, znajdź najwcześniejszy sygnał odejścia, którego jeszcze nie znasz, i zweryfikuj go na danych, których model wcześniej nie widział.
- Znajdź zewnętrznego sędziego (Outside Judge). Nie pozwalaj modelowi oceniać samego siebie. Najlepiej podłączyć narzędzie, które model może uruchomić bezpośrednio i od razu dostać informację zwrotną.
Jego zasada pisania promptów: chcesz „głębszej wersji", a nie „większej wersji". Poproś model, by powiedział, co dodatkowo zrobiłby czołowy profesjonalista, gdzie leżą najbardziej surowe dane, jakich metod i narzędzi użyć oraz co poza modelem i twoją oceną może dowieść, że wynik jest poprawny.
4. Zasięg: czasowniki zamiast rzeczowników i zespół ekspertów#
- Czasowniki zamiast rzeczowników. Tę ideę Felix czerpie z książki „The Art of Innovation". QBR to nie tyle „prezentacja", ile „sposób, by w 30 minut zajęty człowiek zrozumiał związki przyczynowo-skutkowe i podjął decyzję w niepewności". Gdy cel zdefiniujesz czasownikiem, widać, jakich kompetencji z jakich dziedzin potrzeba.
- Zbuduj zespół. Do dobrej prezentacji potrzebujesz analityka, dziennikarza i redaktora; do wystąpienia na scenie dochodzi projektant animacji i dźwięku. Do audytu adwersarialnego szukaj analityka z funduszu grającego na spadki i biegłego księgowego.
- Nie rób bezsensownego odgrywania ról. Nie każ modelowi „pisać tonem funduszu grającego na spadki", tylko naprawdę wykonać metodę, którą taki fundusz stosuje przy badaniu jednego fragmentu. Sama zmiana tonu nie poprawia wyniku.
Warunek: model musi mieć komputer z możliwością instalowania oprogramowania i dostęp do potrzebnych danych, na przykład przez konektory MCP.
5. Moje notatki z praktyki: od „przekazywania danych" do „realizacji intencji"#
Poniżej moje rozszerzenie, oparte na architekturze oprogramowania i praktyce inżynierskiej. To nie jest treść oryginału.
1. Jobs to be Done i podejście oparte na intencji (Intent-Based)#
- Nie pytaj „co zrobić", pytaj „co osiągnąć". Projekt nie powinien zatrzymywać się na biernym potoku przekazywania danych w rodzaju
generate_deck_pdf(), tylko wznieść się do intencji będącej przejściem stanu, jak resolve_leadership_uncertainty_and_commit_budget().
- Zdefiniuj prawdziwą funkcję straty. Jeśli wymagasz tylko artefaktu, model wyprodukuje pozornie doskonałe puste frazesy; jeśli wymagasz rozwiązania niepewności decyzyjnej, model i Sub-agenty same uzupełnią luki w logice i granice ryzyka.
2. Dywergencja przy eksploracji, konwergencja przy odbiorze#
- Przy eksploracji najpierw rozbiegaj się w poszukiwaniu możliwości, potem zbieżaj.
- Przy odbiorze już się nie rozbiegaj. Unikaj pytań bez granic, w rodzaju „jak jeszcze można to zrobić?" – dają tylko ogólniki.
- Wprost zapisz zakres celu, ograniczenia i obiektywne narzędzia weryfikacji (konkretne skrypty testowe, progi wskaźników biznesowych), aby zespół Multi-Agent przeprowadzał testy obciążeniowe w skupionych ramach i dostarczał wynik wysokiej jakości.
Podsumowanie#
- Nastawienie na cel: czasowniki zamiast rzeczowników. Dostarczaj rezultat, który rozwiązuje problem, a nie artefakt wytworzony tylko po to, by odfajkować zadanie.
- Eksploracja i konwergencja: przy eksploracji rozbiegaj się w poszukiwaniu możliwości, przy odbiorze ściśle zbieżaj i weryfikuj granice.
- Skupienie abstrakcji: wychodź od podstawowego pytania i przebuduj cały proces zadania.
- Głębia eksperta: nie naśladuj tylko tonu eksperta, lecz zmuszaj model, by rozwiązywał problem narzędziami i metodami czołowych ekspertów.
Oryginał: How to be more ambitious: A tutorial for humans with models (Felix Rieseberg, 2026-10-13)