Umiejętności jako program nauczania: kiedy Antigravity, kiedy Apps Script, a kiedy Workspace Studio?

Jest taki moment, który zna każdy szkolny technolog: właśnie zbudowałeś coś, co naprawdę działa — realny system, z realną logiką, realnymi przypadkami brzegowymi i realnymi użytkownikami, którzy na nim polegają — i wtedy pojawia się nowe narzędzie, które obiecuje zrobić „to wszystko” jednym promptem.

Google Antigravity wjechało w listopadzie 2025 roku dokładnie z taką energią.

Napędzane przez Gemini 3 Pro, jest to środowisko IDE zaprojektowane wokół agentów, w którym nie piszesz kodu linijka po linijce — opisujesz oczekiwany rezultat i pozwalasz autonomicznym agentom zaplanować, wykonać i zweryfikować pracę. Robi to naprawdę duże wrażenie. I stawia całkiem zasadne pytanie przed każdym, kto spędził miesiące na budowaniu szkolnej automatyzacji w Apps Script: co dokładnie to zastępuje, a czego nie zastępuje ani trochę?

Odpowiedź kryje się w zrozumieniu trzech różnych pojęć, które łatwo ze sobą pomylić: eksploracji agentowej, automatyzacji procesów oraz logiki produkcyjnej. Każde z nich odpowiada innemu narzędziu. Pomyłka na tym poziomie oznacza albo przeinżynierowanie prostego zadania, albo — co znacznie groźniejsze — niedoinżynierowanie zadania złożonego.

Problem systemu rekrutacyjnego

W PSP Leonarda Piwoni w Szczecinie prowadzimy środowisko Google Workspace dla mniej więcej 750 uczniów w czterech szkołach. W zeszłym semestrze zbudowałem w Apps Script kompletny system zarządzania rekrutacją: generowanie kart ucznia, panel WebApp obsługujący ścieżki akceptacji przez sekretariat, jednorazowe zbieranie danych wrażliwych oparte na tokenach, generowanie umów w formacie PDF oraz funkcję przenoszenia uczniów między szkołami.

Ten system istnieje, ponieważ problem, który rozwiązuje, jest strukturalnie złożony. Nie technicznie złożony w sensie wymagania rzadkiej wiedzy — ale złożony w tym sensie, że koduje realną logikę instytucjonalną: kto co zatwierdza, w jakiej kolejności, na podstawie jakich danych, przy jakich ograniczeniach prawnych (RODO, polskie prawo oświatowe) i z jaką ścieżką awaryjną, gdy coś pójdzie nie tak.

Czy mógłbym zbudować go w Antigravity?

Spróbujmy być precyzyjni, a nie lekceważący: Antigravity mogłoby przyspieszyć fazę eksploracji — wczesne prototypowanie, na etapie którego dopiero zastanawiasz się, czy maszyna stanów oparta na Sheets to w ogóle właściwa architektura. Agent, który potrafi w kilka minut postawić działający prototyp w Next.js, jest naprawdę użyteczny, dopóki wciąż pytasz „co ja właściwie buduję?”.

Ale system produkcyjny? Nie. I nie dlatego, że Antigravity nie potrafi — chodzi o to, że wiedza, dzięki której system w ogóle działa, nie mieści się w żadnym prompcie. Ona żyje w kontekście instytucjonalnym: w konkretnej ścieżce, jakiej używa sekretariat, w przypadku brzegowym, gdy uczeń przenosi się w połowie roku, w wymogu prawnym, że pewnych dokumentów nie wolno wysyłać mailem. Ta wiedza musi być zakodowana gdzieś w sposób świadomy i możliwy do utrzymania. W naszym przypadku jest to Apps Script z jawną kontrolą wersji i udokumentowaną logiką biznesową.

To rozróżnienie — między eksploracją a produkcją — jest pierwszą osią każdego uczciwego frameworka.

Czym naprawdę jest Skill

Antigravity wprowadza pojęcie Skill: katalogowy pakiet wiedzy, który leży uśpiony, dopóki zadanie agenta nie dopasuje się do jego opisu. Skille można definiować globalnie (dla wszystkich twoich projektów) albo na poziomie workspace’u (dla jednego konkretnego projektu).

Oficjalna narracja jest skrojona pod programistów: Skille pomagają zakodować konwencje zespołu, wytyczne do code review, procedury wdrożeniowe. Ale wystarczy odczytać to inaczej, by wyłoniło się coś ciekawszego.

Skill to skodyfikowana wiedza ekspercka na żądanie. Nie piszesz promptu — piszesz specyfikację tego, co wiedziałby ekspert dziedzinowy, zapakowaną tak, by agent mógł ją przywołać dokładnie wtedy, gdy jest potrzebna, zamiast ładować ją do każdej interakcji.

Dla nauczycieli takie ujęcie zmienia całe pytanie. Skill to nie „niech AI wykona moją pracę”. To raczej: co zapisałbym, gdybym szkolił zdolnego asystenta, który nigdy wcześniej nie pracował w szkole?

Skill o nazwie physics-worksheet-generator mógłby kodować: podstawę programową dla klasy 8 w Polsce, konwencje formatowania, do których przywykli twoi uczniowie, typowe błędne przekonania, które chcesz zaadresować w konstrukcji zadań, oraz format wyjściowy, który najlepiej sprawdza się przy druku na wysłużonej szkolnej drukarce laserowej. Nic z tego nie jest ogólną wiedzą AI. Wszystko to jest twoją ekspertyzą, uczynioną wielokrotnie użyteczną.

Dlatego ujęcie „Umiejętności jako program nauczania” to nie tylko chwytliwy tytuł. Struktura Skilla jest mechanizmem wymuszającym uczynienie milczącej wiedzy nauczyciela jawną — co ma wartość edukacyjną niezależnie od tego, czy agent kiedykolwiek ją uruchomi.

Trzy osie, jedna decyzja

Po pracy z wszystkimi trzema narzędziami — i po obserwowaniu, jak koledzy raz za razem sięgają po niewłaściwe — doszedłem do wniosku, że trzy osie z niezłą trafnością przewidują właściwy wybór.

Oś 1: Złożoność logiki. Ile rozgałęzień warunkowych, zarządzania stanem i kodowania reguł specyficznych dla dziedziny wymaga rozwiązanie? Proste „wyślij mail z potwierdzeniem po przesłaniu formularza” to niska złożoność. „Zwaliduj dane rekrutacyjne względem istniejących rekordów, wygeneruj dokument prawny, skieruj do akceptacji, obsłuż odrzucenie z możliwością ponownego złożenia, zarchiwizuj zakończone sprawy” to wysoka złożoność.

Oś 2: Zasięg odbiorców. Kto wchodzi w interakcję z rezultatem — i jakie są jego kompetencje techniczne oraz poziom zaufania? Narzędzie, którego używam sam, może mieć chropowate krawędzie. Narzędzie, z którym stykają się rodzice, już nie. Narzędzie, którego uczniowie używają do nauki, ma inne wymagania niż narzędzie, którego sekretariat używa do spełniania wymogów formalnych.

Oś 3: Trwałość rozwiązania. Czy to tygodniowy eksperyment, czy system, który musi niezawodnie działać przez trzy lata, przetrwać rotację kadr i dawać się debugować komuś, kogo nie było w pokoju, gdy go budowano?

Nanieś swój problem na te trzy osie, a wybór narzędzia przestaje być tak niejednoznaczny:

Niska złożoność + krótki cykl życia + odbiorcy z grona nauczycieli/pracowników → Antigravity Skills. Eksploruj szybko, przegrywaj tanio, poznaj prawdziwe wymagania, zanim zdecydujesz się na budowę produkcyjną.
Wysoka złożoność + długi cykl życia + dowolni odbiorcy → Apps Script. Pełna kontrola nad logiką, integracja z API Workspace, jawne wersjonowanie, możliwość debugowania, zgodność z RODO przy starannej budowie.
Niska-do-średniej złożoność + krótki-do-średniego cykl życia + pracownicy lub uczniowie, którzy chcą widzieć automatyzację bez kodu → Workspace Studio. Właściwe narzędzie, by pokazać nietechnicznym kolegom, jak działa automatyzacja, zanim zdecydujecie, czy warto inwestować w porządną budowę.

Interaktywne narzędzie pod adresem workspace.edu.pl/tools/edu-tool-selector pozwala przełożyć twoją konkretną sytuację na rekomendację wraz z przykładowymi fragmentami kodu dla każdego przypadku — wypróbuj je, zanim zaczniesz czytać dalej.

To, co Antigravity zmienia, a co nie dotyczy kodu

Dzieje się cichsza zmiana, którą narracja o „agentowym IDE” przysłania.

Kiedy nauczyciel buduje w Antigravity Skill do generowania zróżnicowanych prac domowych, robi coś, co wcześniej wymagało albo wiedzy programistycznej, albo długiego, kruchego promptu, nad którym i tak straciłby panowanie. Architektura Skilla daje temu nauczycielowi trwały artefakt — coś, co przetrwa, co można z czasem doszlifować i czym można się podzielić z kolegami.

Ma to znaczenie akurat dla szkół, bo ekspertyza nauczyciela jest notorycznie nieprzenaszalna. Kiedy odchodzi świetny nauczyciel, wiedza instytucjonalna, którą nosił — o tym, jak wprowadzić dane pojęcie krok po kroku, które przykłady rezonują z którymi profilami uczniów, jakie pytania obnażają błędne przekonania — w dużej mierze odchodzi razem z nim. Skille nie rozwiązują tego w pełni, ale tworzą nową kategorię artefaktu, w którym ta wiedza może zamieszkać.

Głębsze pytanie technologii edukacyjnej nie brzmi „które narzędzie jest najpotężniejsze?”. Brzmi ono: „które narzędzie najlepiej pomaga uczynić najważniejszą wiedzę jawną, przenaszalną i podatną na doskonalenie w czasie?”.

Wedle tej miary Antigravity Skills i Apps Script nie są konkurentami. Działają na różnych warstwach tego samego problemu. A zrozumienie tego rozróżnienia jest — jak twierdzę — najbardziej praktycznie użyteczną rzeczą, jaką szkolny technolog może wynieść z nadejścia agentowych platform deweloperskich.

Uwaga o tym, czym to nie jest

Ten framework jest z założenia praktyczny, a nie wyczerpujący. Nie obejmuje każdego scenariusza — w szczególności wyłaniającej się przestrzeni procesów wieloagentowych, w których Agent Manager z Antigravity koordynuje równoległe zadania w obrębie projektu. To naprawdę odmienna zdolność, która zasługuje na własną analizę.

Nie rozstrzyga też pytania, czy agentowe IDE w ogóle mają miejsce w rękach uczniów — co jest bardziej złożonym pytaniem pedagogicznym i etycznym, niż podejmuje ten artykuł. (W skrócie: dla informatyki w klasach 7–8 sądzę, że odpowiedź brzmi „tak, ostrożnie, z wyraźną rozmową o tym, co agent robi, a czego nie robi”. Ale to temat na osobny tekst.)

To, co ten framework rzeczywiście daje, to heurystyka decyzyjna, która broni się w realnych warunkach szkolnych: dopasuj narzędzie do warstwy złożoności, do wymogu trwałości i do odbiorców, dla których budujesz.

System rekrutacyjny zostaje w Apps Script. Generator kart pracy staje się Skillem. Szybkie demo na zebranie z rodzicami korzysta z Workspace Studio.

I żadne z nich nie jest złą odpowiedzią — o ile najpierw zadajesz właściwe pytanie.

Igor Wypijewski jest Dyrektorem ds. Innowacji i Technologii Edukacyjnych w Prywatnych Szkołach Leonarda Piwoni w Szczecinie, będących Google for Education Reference School. Pisze o praktycznym wdrażaniu AI, automatyzacji Google Workspace oraz o przepaści między obietnicą EdTech a realiami klasy szkolnej na workspace.edu.pl.