Я більше не пояснюю свою дидактику. Я один раз її записав.

Нещодавно я набрав речення, коротше за будь-який лист того вечора: "Перевір мені вправи в модулі з бухобліку."

Те, що повернулося, не було думкою. Це була таблиця. 26 вправ, кожна оцінена за п'ятьма критеріями, чотири найслабші вгорі, з обґрунтуванням, чому вони слабкі.

Суть не у швидкості. Суть у тому, що того вечора я жодним словом не пояснив, що робить вправу доброю. Ці п'ять критеріїв я записав місяцями раніше, рівно один раз. Відтоді вони просто там лежать, і ШІ сам їх дістає, щойно питання звучить відповідно.

Мене часто питають, що ж особливого в моїй системі. Очікувана відповідь — це кількість: 18 під'єднаних сервісів, десь сорок skills, сервер Moodle із понад дев'яноста інструментами. Але кількість — не відповідь. Відповідь — це зчеплення двох половин, яке легко проґавити, бо окремо кожна з них звучить непримітно.

Дві половини, що поодинці мало варті

Почнімо з понять, коротко й без передумов.

MCP означає Model Context Protocol. Це стандарт розеток. ШІ від початку вміє говорити й писати, але не може нічого торкнутися. MCP-сервер — це невелика програма, що стоїть перед справжньою системою, скажімо Moodle, і пропонує ШІ перелік дій: створити курс, перейменувати розділ, наповнити тест питаннями, зчитати оцінки. Щойно цей сервер під'єднано, ШІ може виконувати ці дії у вашій справжній системі, з вашими справжніми правами. MCP дає йому руки.

Skills — це інша половина. Технічно skill — це тека з текстовим файлом усередині. Угорі файлу два рядки: назва й опис того, коли цей skill доречний. Нижче звичайною мовою написано, як тут працюють. Які критерії діють. У якому порядку. Що відрізняє добрий результат від посереднього. Жодного коду, жодного програмування. ШІ читає цей файл лише тоді, коли опис пасує до поставленого завдання. Skill дає йому судження.

Різниця стає ясною з одного питання:

Я будував обидві половини одну за одною і пережив кожну окремо. Обидві розчарували.

Спершу половина MCP. Про неї я вже писав, у 12 серверів, один протокол. Відчуття, коли вперше набираєш "Створи тест на тему порушень договору купівлі-продажу" і за тридцять секунд бачиш готовий тест, було величезним. І його вистачило приблизно на три тижні. Тоді я помітив, що дуже швидко виробляю дуже багато посереднього. Питання були правильні й нудні. Курси були повні й неживі. Я дав ШІ руки і забув сказати йому, що вважаю доброю роботою.

Половина зі skills сама по собі так само невтішна, лише навпаки. ШІ, який знає вашу модель якості, але ні до чого не дотягується, видає вам чудово обґрунтовану рекомендацію. Яку потім відпрацьовуєте ви самі. У неділю ввечері. Вручну.

На другий раз це вже skill

Очевидне питання: звідки я знаю, коли щось має стати skill?

Мій поріг нижчий, ніж більшість припускає. Він на другому разі.

Коли я пояснюю ШІ те саме вдруге, це вже не випадковість, а закономірність. Я пояснюю двічі не тому, що модель забудькувата, а тому, що маю вимогу, настільки для мене самоочевидну, що я її ніколи не вимовляв. Саме такі вимоги — цінні. Вони і є різниця між моєю роботою і будь-якою роботою.

Першого разу пояснювати — нормально. Другого разу пояснювати — це недбалість, яка накопичує відсотки.

На практиці це означає: я більше не пишу пояснення в чат, а у файл. Другого разу це коштує хвилини чотири більше, ніж пояснити. Третього разу виходить у нуль. Від четвертого це вже прибуток, і назавжди, бо файл не втомлюється і не йде у відпустку.

А далі йде та частина, яку я спершу недооцінив: skill не має жодної користі, якщо його не знаходять. ШІ не читає сорок файлів, перш ніж відповісти. Він читає рядки опису й за ними вирішує, який файл узагалі буде відкрито.

Тобто: опис — це не обгортка. Це і є інструмент. Чудовий skill із розмитим описом — це книжка в бібліотеці без каталогу. Тому в моїх описах стоять слова, якими я справді користуюся, коли втомлений: "робочий аркуш", "гендаут", "створити курс", "кінець сесії", "ми закінчили". Не ті слова, що стояли б у документації.

Чому тримає лише добуток обох

Справу можна уявити як чотири поля, і всі чотири трапляються в повсякденні.

Ані те, ані інше. Ви описуєте ШІ свою проблему, він розумно відповідає, а потім ви все робите самі. Це нормальний випадок для більшості людей, і це немало. Але це порада, а не робота.

Лише руки. ШІ дістається всюди і не знає, що добре. Тоді він дуже швидко виробляє дуже багато матеріалу, який проходить і нікого не досягає. Це найнебезпечніший кут, бо він відчувається як продуктивність. Ви бачите обсяг і не помічаєте, що якість із ним не зросла.

Лише судження. ШІ знає ваш критерій і не може застосувати його ніде. Результат — добрий план. Виконувати його вам.

Обидва. І тут стається щось, що не відчувається як додавання. Оскільки судження закладене назавжди, змінюється сам характер моїх вказівок. Я більше не кажу, що треба зробити. Я кажу, чого хочу досягти. З "Створи тест на вісім питань про порушення договору купівлі-продажу, з них два з вибором відповіді, формулюй діяльнісно, жодних питань на голе знання" стає "Побудуй мені вступ до модуля 3."

Речення стало коротшим. Але не стало неточнішим, бо точність переїхала. Тепер вона живе у файлах, а не в моїй короткочасній пам'яті.

Це і є справжній зиск, і це не економія часу. Це зміщення: від наказування до вирішування.

Чотири риси моєї системи

Я не описую тут своїх skills. Вони мало вам дадуть, бо містять мої предмети, мою школу і мій корпоративний стиль. Я описую чотири ідеї, що стоять за ними, бо саме вони переносяться.

Skill несе модель, а не послідовність кроків

Skill, який того вечора оцінив 26 вправ, не містить жодної інструкції. Він містить модель із п'ятьма критеріями: чи є сюжетний якір, на якому тримається вправа? Чи є що побачити? Наскільки глибоким є мислення, якого вимагають? Що учениця насправді робить, окрім читання? І: що стається у разі помилки, помилку карають чи пояснюють?

П'ять питань. Жодного порядку дій, жодної послідовності, жодної технічної вказівки.

Різниця більша, ніж здається. Послідовність кроків старіє разом з інструментом, для якого її писали. Модель переживає зміну інструмента, бо описує, за чим упізнають добру роботу, а не яку кнопку натиснути. Мій аналіз курсів працює за моделлю чотирьох компетентностей, моя перевірка вправ — за тими п'ятьма критеріями, мої шкільні документи — за корпоративним стилем школи. У всіх трьох випадках я записав фахове переконання, а не інструкцію користувача.

І саме тут учительство має фору, про яку не здогадується. Ці моделі вже в їхніх головах. Просто ніколи не було формату, у якому їх можна було б передати.

Вимірювання і покращення — це два окремі інструменти

У мене все парами. Один skill аналізує розділи курсу, другий їх оптимізує. Один оцінює вправи, другий їх переробляє. Завжди два, ніколи один.

Це навмисно, і мені коштувало дійти до цього. Інструмент, який одночасно вимірює й лагодить, вимірює себе прикрашено. Він зацікавлений у результаті. Він знаходить ті проблеми, які вміє розв'язати, і надійно оминає ті, для яких не має рішення. Врешті ви отримуєте звіт, у якому все виглядає добре, бо все погане дорогою тихо виправили і вже ніхто не знає, наскільки погано було раніше.

Окремі інструменти змушують до проміжної зупинки: я бачу вимір до того, як щось змінять. Я можу заперечити. Іноді найслабша вправа — це саме та, що найкраще працює на уроці, бо має історію, якої не охоплює жоден критерій. Це рішення належить мені, і воно належить мені лише тоді, коли я бачу цифри до втручання.

Skill диригує, а не хапається сам

Мій найбільший skill будує цілі навчальні ситуації. Він шукає джерела, планує дидактику, створює матеріал, перевіряє його якість і врешті публікує на кількох платформах. Що він робить сам: нічого з переліченого.

Він описує порядок і передає кожен крок тим рукам, які це вміють. Пошук — шляху пошуку, матеріал — генерації медіа, публікацію — під'єднанню до Moodle і порталу навчальних модулів. Skill — диригент, а не музикант.

Звучить як дрібниця, але саме тому ця штука працює вже місяцями. Якщо змінюється одне під'єднання, змінюється одне під'єднання. Порядок лишається чинним. Якби я вписав виконання в сам skill, мені довелося б чіпати його щоразу, коли змінюється будь-яка задіяна система.

Та сама досяжність, різні особи

Це та частина моєї системи, яку я пояснюю найрідше і вважаю найважливішою.

Мої під'єднання йдуть не прямо до серверів, а крізь тонкий проміжний шар. Він робить одну-єдину річ: вирішує, яким ключем працювати, залежно від того, у якому контексті я зараз сиджу. Школа — один контекст. Блог — інший. Адміністрування серверів — третій. Товариство, у якому я волонтерю, — четвертий, і воно суворо відокремлене від школи.

Ефект подвійний. По-перше, я бачу потім у журналі, що відбулося в якому контексті. По-друге, і це справжній виграш, сесія, задумана для блогу, не може випадково дістатися до даних учнів. Не тому, що я дисциплінований, а тому, що ключа для цього в тій сесії просто не існує.

Та сама логіка діє й для найнебезпечнішої плутанини взагалі. У мене дві інсталяції Moodle: локальний майданчик і справжня, зі справжніми курсами і справжніми учнями. Вони названі по-різному навмисно, і правило записане: якщо неоднозначно, яка мається на увазі, — питають, а не вгадують.

Спосіб роботи навколо цього

Досі йшлося про інструменти. Але найбільше в мене змінили не інструменти, а три звички навколо них. Вони нічого не коштують і працюють без жодного сервера.

Перша: кожен проєкт отримує теку, у якій написано, що тут робили і чому. У мене це датовані документи задуму, плани впровадження і звіти про те, що вийшло насправді. У проєкті інфраструктури таких задумів уже шістнадцять.

Причина — не любов до порядку. Причина в тому, що вікно чату вмирає.

Сесія ШІ має пам'ять, яка закінчується разом із нею. Усе, що ви разом напрацювали за три години, кожен глухий кут, кожне зважування, кожна причина, чому ви врешті обрали другий за якістю шлях, — після цього зникає. Якщо ви повернетеся через шість тижнів, перед вами сидітиме хтось, хто бачить ваш проєкт уперше. Та й ви самі вже не пам'ятаєте причини, а лише рішення.

Тека проєкту — це відповідь на це, і вона має адресата, про якого не думають одразу: наступного агента. Я пишу ці документи не для себе. Я пишу їх, щоб наступна сесія їх прочитала і за п'ять хвилин мала той стан, на який минулого разу пішло три години. Це саме та точка, у якій з окремих добрих вечорів постає щось накопичувальне. Моя робота росте не тому, що я швидше друкую, а тому, що кожна сесія спирається на те, що лишила попередня.

Друга звичка: усе лежить під контролем версій. У мене це Git, віддзеркалений на GitHub, і це стосується як коду, так і навчальних матеріалів, skills і документації.

Це зазвичай продають як тему порядку, і тому майже ніхто не слухає. Але це не тема порядку. Це передумова для того, щоб узагалі мати змогу працювати сміливо.

Послідовність така: спершу безпека, потім свобода. Я дозволяю ШІ без нагляду працювати одразу в сорока файлах лише тому, що одна команда повертає стан, який був хвилину тому. Кожна зміна — це пропозиція, а не втручання. Без цього зворотного квитка я став би обережним, а обережність — саме те, що руйнує цей спосіб роботи. Тоді пробуєш лише те, на що й так наважувався, а це і є той бар'єр, про який я писав у Три бар'єри, яких більше не існує.

І ще одне, що стає важливим лише згодом: контроль версій робить роботу успадковуваною. У Я це відтворив я описав, чому відомства сахаються саморобних рішень, і це заперечення слушне. Репозиторій, який хтось може склонувати й дати прочитати ШІ, — це половина відповіді на нього. Тека на вашому столі — не відповідь узагалі.

Третя звичка найменш популярна: я занотовую, що я виміряв, із датою, і занотовую також те, що виявилося хибним.

У моїй проєктній документації є речення на кшталт: "Виміряно 16.08. на справжній системі, попередній запис про це не відтворювався." Це схоже на бюрократію. Але саме це найнадійніше рятує мене від подвійної роботи. Спростоване припущення, яке ніде не записане, повертається. Воно гарантовано повернеться через чотири місяці, коли вже ніхто не пам'ятатиме, що це вже перевіряли, і тоді це перевірять ще раз.

Для сесій ШІ це справджується подвійно, бо ШІ охоче з вами погоджується. Він перейме ваше старе хибне припущення і побудує на ньому далі, якщо воно стоїть у ваших нотатках саме і поруч немає нічого іншого.

Чому в школах це працює краще, ніж деінде

Тепер та частина, заради якої мені все це.

Мені часто кажуть, що моя система — виняток, бо я адміністратор і тримаю сервери. Для кількості це слушно. Для суті — ні, і то з причини, яка в дискусії про ШІ в школі майже не з'являється.

Учительство вже володіє складнішою половиною. Не приблизно, а повністю і на такій глибині, яку деінде дорого купують. Колега, що п'ятнадцять років викладає українську, має цілісну внутрішню модель того, що відрізняє добре сформульоване завдання від поганого, де клас у цьому місці зазвичай звертає не туди, які помилки продуктивні, а які лише розчаровують, як подати те саме на трьох різних рівнях. Він ніколи цього не записував, бо ніколи не було адресата. Це можна розповісти стажистові, і на цьому все.

Тепер адресат є. І робота з перекладу полягає не в програмуванні, а в одному реченні: запишіть звичайною мовою те, що пояснили б стажистові.

Друга половина, досяжність, у школах теж уже є, лише непомітно. Є навчальна платформа, поштова система, списки класів, офісний пакет, система зберігання файлів. Це саме ті системи, до яких можна прибудувати руки. Зусилля справжні, але одноразові й подільні. І вони не мусять стояти на початку.

Сюди належить чесне доповнення: найменша осмислена система складається з нуля серверів. Один-єдиний skill, текстовий файл із вашим критерієм якості, без жодного під'єднання, уже дає вам ефект із першого розділу. Ваші вказівки коротшають, результати стають послідовнішими. Руки можна прибудувати через роки або ніколи.

Чесна ціна

Є три речі, які не працюють, і в таких текстах про них охоче мовчать.

Skills гниють. Skill, що вказує на інтерфейс, який змінився, гірший за відсутність skill, бо породжує хибну впевненість. Кілька моїх описів уже старші за системи, які вони мають на увазі. Це регулярно коштує часу на прибирання, і в цьому я не сильний.

Забагато skills гасять одне одного. При сорока з гаком уже тільки рядок опису вирішує, що буде знайдено. Два skills зі схожими описами гірші за один, бо тоді витягнеться той, що випадково звучить краще. Колекція потребує догляду, інакше вона заростає.

Темп не приносить якості із собою. Це урок, який коштував мені найбільше. Мені довелося будувати перевірку якості окремо, як власний інструмент, бо швидкість сама по собі породжує лише більше матеріалу. Хто вірить, що добрі результати з'являться, щойно зникне тертя, вироблятиме тиху посередність у великих обсягах.

І четверте, що не є ціною, а межею: усе це й далі тримається на одній людині. У мене є інструменти, а не інституція. Те, що я будую, переживає мене лише тому, що воно під версіями й задокументоване. Це краще за ніщо і менше за план наступності.

Перший крок коштує двадцять хвилин

Якщо це вас зачепило і ви не знаєте, з чого почати: не з сервера. Не з під'єднання. Не зі списку інструментів.

Почніть із файлу.

Візьміть ту єдину річ, яку цього тижня пояснювали вдруге. Запишіть звичайною мовою, за чим ви впізнаєте, що її зроблено добре. Не як її роблять, а за чим упізнають вдале. Напишіть один рядок про те, коли це має діяти, тими словами, якими ви користуєтеся, коли втомлені. Покладіть файл у теку, яку читає ваш ШІ.

Оце й усе. Двадцять хвилин, без сервера, без бюджету, без погодження.

І коли через раз ви помітите, що це пояснення більше не треба набирати, ви збудуєте ту половину, яку здобути важче. Руки — це техніка. Судження — це були ви.

Дірк Шуленбург, Гамбург. Записує речі, щоб не казати їх двічі.

Про цей текст: структура, чорновий варіант і приклади з моєї власної системи постали в розмові з Claude. Теза, добір десяти практик і остаточна редакція — мої.