Kaiyao Duan, a Chongqingban működő Force Academy G7–G12 diákjaival végzett munkájában rendszeresen alkalmaz egy egyszerű, de éles tesztet: kész projektet ad át egy másik diáknak, hogy az használja, ellenőrizze vagy módosítsa. A cél nem csupán a fájlok megléte; a kézbesítés próbája annak a kérdésnek, hogy a munka mennyire érthető annak, aki nem a készítője. A szerző pontosan tudja, mit jelentenek az egyes változók, miért hozott meg egy döntést, melyik eszközt használta, és mit lehet biztonsággal megváltoztatni. A második felhasználónak csak az a rendelkezésére áll, amit a projekt láthatóvá tesz.
A generatív mesterséges intelligencia különösen feltáróvá teszi ezt a kézfogást, mert lerövidíti és olcsóbbá teszi az első, meggyőző verzió létrehozását. A diákok ma sokkal gyorsabban tudnak kódot, elemzést, szöveget, vizualizációt és prototípust előállítani, mint néhány éve. Az iskolai környezetben azonban egy projekt csak addig hasznos, amíg megmutatja, hogy a tanuló mit ért és mit tud megvédeni: az AI által simára csiszolt, „polírozott” munka önmagában már nem bizonyítja a megértést.
Egy konkrét példa: egy diákcsoport tanulmánya, melynek címe Verification Responsibility in AI-Applicable Occupations, arra kérdezett rá, mi marad gazdaságilag fontos, ha az AI olcsóvá teszi a jelöltek által előállított kimeneteket, de mégis embernek kell ellenőriznie, dönteni a biztonságukról és vállalni a felelősséget. A vezető diák dolgozta ki a fogalmi modellt és a legtöbb analitikus munkafolyamatot. Egy második diák kapott egy szűkebb feladatot: függetlenül futtassa újra a fő elemzéseket, rögzítse a forrásadatok verzióit, dokumentálja, hogyan kötötték össze az egyik adatbázis foglalkozásait a másikéval, és hasonlítsa össze a közzétett táblázatokat és ábrákat az alapul szolgáló eredményekkel. Amit kezdetben procedurális ellenőrzésnek szántak, gyorsan lényegi felülvizsgálattá vált.
Az első probléma a reprodukálhatóság volt. Az elemzés lefutott az eredeti gépen, de a munkafolyamat túl sok döntésre támaszkodott, amelyek csak az egyetlen diák memóriájában éltek. A más gépen való reprodukáláshoz a csapatnak fel kellett írnia az adattranszformációkat, le kellett jegyezni a foglalkozáskapcsolási szabályokat, és meg kellett tartani a köztes eredményeket, hogy egy másik személy láthassa, hogyan készültek a végső számok, ahelyett hogy pusztán újrafuttatnák a scriptet és megbíznának a kimenetben.
A súlyosabb probléma a mérés tervezésében volt. A tanulmány egy korai verziójában ugyanazokból a autonómia és vezetés felmérési tételekből néhányat két külön mértékben is felhasználtak: a "verification responsibility" és az "adaptive capacity" mutatókban. A szoftver technikailag helyesen számolta ki a mutatók közötti kapcsolatot, de annak egy része mesterségesen keletkezhetett amiatt, hogy a két mutató részben ugyanazokra a bemenetekre épült. Másképp fogalmazva: a kód azt tette, amit kértek tőle, a kérdés az volt, hogy a viszonyításra használt nagyobb egységek elég tisztán voltak-e definiálva.
A csapat újraépítette a mutatókat úgy, hogy ne osszanak meg tételeket, eltávolították a kétértelmű tételeket, és átdolgozták a munkafolyamatot úgy, hogy a forrásverziók, a keresztadatbázis-illesztések, a kizárások, a köztes fájlok és a közzétett eredmények visszakövethetők legyenek. Későbbi verziók alternatív specifikációkat és robusztussági ellenőrzéseket is tartalmaztak. Ami egy „kérlek, futtasd újra” feladattal indult, végül a tanulmány újratervezéséhez vezetett.
A kézbesítés megváltoztatta azt is, ahogyan a szerző olvassa a diákmunkát. A második felhasználó nem csupán azt teszteli, hogy a fájlok rendezettek-e; olyan kényelmetlen kérdéseket tesz fel, amelyeket a készítő talán már nem vett észre: miért van egy adott változó a projektben? Melyik következtetés azon a feltevésen alapul, amelyet soha nem fogalmaztak meg? Ebben a projektben ezek a kérdések visszanyúltak magába a mérés tervezésébe.
A feladat pedagógiai értéke abból fakad, hogy az iskolai feladatok és a termelési szoftverek céljai különböznek. A szakmai fejlesztők sokat tanulnak a szoftver átadása után, mert azt el kell szállítaniuk, meg kell magyarázniuk, támogatniuk, karban kell tartaniuk és reagálniuk kell, ha valaki váratlanul használja. A diákprojektek általában eltűnnek a kurzus végén, és ez rendben is van; az alkotás önmagában nem célszerű végcél. Fontos azonban behozni néhány tanulságot az átadásból és a fenntartásból: döntések magyarázata, támogatás mások használata számára, és a munka módosítása, ha a privát kontextus már nem áll rendelkezésre.
A Force Academyben a pontos feladat a projekt jellegétől függ. Egy számításos modellnél a másik diák megváltoztathat egy paramétert vagy kicserélhet egy szabályt, majd megnézheti, mi marad stabil. Egy AI-támogatott munkafolyamatnál a feladat lehet az áthelyezés egy másik modellbe vagy környezetbe. Adat-elemzésnél a második diáknak meg kell próbálnia rekonstruálni egy eredményt a rögzített forrásfájlokból és transzformációkból. Ha a transzfer megbukik, azt szeretném, hogy az eredeti diák döntse el, mire volt valójában szüksége a másiknak, és mit kell változtatni a projekten, ahelyett hogy egyszerűen ott állna mellette és magyarázna.
Ezt a látható belépési pontok gyűjteményét "handles"-nek nevezem. Egy handle ad valami kézzelfoghatót, amit a másik személy megvizsgálhat vagy megváltoztathat anélkül, hogy előbb privát eligazítást kapna. Lehet ez egy jól elnevezett paraméter, egy explicit feltételezés, egy teszt, ami egy korábbi hibát rögzít, egy cserélhető komponens, megtartott köztes adatkészlet vagy egy prompt, amelynek fontos kontextusa le van írva a privát chat-előzmény helyett.
A handles-ek produktívabbá teszik a nézeteltéréseket is. Egy feltárt feltevés megkérdőjelezhető; egy világos határral rendelkező komponens módosítható vagy kicserélhető a teljes projekt újraépítése nélkül; és egy számérték, amely összekapcsolható a forrásadataival és transzformációival, ellenőrizhető, ahelyett hogy tekintélyalapból elfogadnánk.
Az iskolán kívül az AI-rendszerek ugyanazokat a gyengeségeket tárják fel. Egy prompt, munkafolyamat, skill vagy agent-konfiguráció hordozhatónak tűnhet, mert másolható, miközben a működés feltételei máshol maradnak: eszközhozzáférés, fájlszerkezet, modellviselkedés, privát memória, névkonvenciók vagy apró döntések, amelyeket a készítő soha nem dokumentált. Az artefaktum áthelyezése gyakran feltárja, hogy a működő rendszer mekkora része sosem volt valóban az artefaktumban.
Ezért az első sikeres lefuttatás gyenge bizonyíték. Azt mutatja, hogy egy bizonyos személy, modell, eszközök, adatok és kontextus kombinációja egyszer adott egy kimenetet. Erősebb próba, ha egy másik személy képes rekonstruálni, mi számít, megkülönböztetni a feltevéseket a megvalósítás részleteitől, és változtatni anélkül, hogy a munka logikáját tönkretenné.
Tim O’Reilly "architecture of participation" gondolata adja meg a tágabb keretet. Egy műszaki artefaktum hasznosabbá válik, ha mások beléphetnek hozzá anélkül, hogy a készítővel privát alkut kellene kötniük. A szoftvernél ez általában interfészeket, konvenciókat, dokumentációt, modularitást és cserélhető komponenseket jelent. Az adatelemzésben ugyanezt a elvet a rögzített forrásverziók, látható transzformációk, megtartott köztes eredmények, explicitté tett feltételezések és annyi analitikai logika testesíti meg, hogy valaki más újrafuttathassa vagy megkérdőjelezhesse a munkát.
Oktatási szempontból az a mérföldkő érdekel, hogy a tanuló eléggé érti-e a munkát ahhoz, hogy ennek egy részét hozzáférhetővé tegye mások számára. Ha egy második diák képes használni, megkérdőjelezni és kiterjeszteni a projektet, az erősebb bizonyíték számomra, mint egy polírozott első lefuttatás. Az AI megnöveli, mit képes egy ember felépíteni — még egy tizenéves is sokkal többet próbálhat meg csapat nélkül —, de a bővült lehetőség könnyen összekeverheti a sikeres generálást a valódi megértéssel. Amikor meg akarom tudni, mit ért egy diák, ma többet tanulok az első komoly átadásból, mint az első sikeres futtatásból.
