Чому рабер-дак — це AI-практика, якій я довіряю найбільше
Інструмент, який приносить мені найбільше користі, не пише за мене код і не готує документи. Це рабер-дак (rubber duck, метод «гумової качечки» з програмування) — агент, якому я поставив завдання ставити запитання, а не відповідати на них. Він допитує все, що я йому приношу, поки в моїх міркуваннях не проявляться прогалини, і майже щотижня це виявляється ціннішим за будь-яку готову відповідь.
Майже кожен спрямовує AI на результат: написати функцію, підсумувати переписку, скласти повідомлення. Це раціональний варіант за замовчуванням. Хорошу відповідь легко виміряти, вона реально економить години, і більшість роботи перед вами просто цього потребує. А практика, якій я довіряю найбільше, спрямовує AI у зворотний бік, на мої власні міркування. Машина для відповідей дає те, що ви просили. Хороший рабер-дак показує запитання, яке ви не додумались поставити.
Як рабер-дак розкрив мене напередодні зустрічі в Мілані
Наскільки гострим це буває, я відчув перед поїздкою до Мілана. У мене була бізнес-ідея та запланована зустріч із двома потенційними співзасновниками. За кілька днів до неї я відкрив рабер-дак, щоб підготуватися. Хотів переконатися, що проведу цю зустріч правильно.
Усе почалося із запитання, яке я сам пропустив: із чим я хочу вийти з цієї зустрічі? Потім він перейшов до того, як я реагуватиму: що скажу, якщо вони засумніваються в ідеї, як поверну розмову, якщо вона піде не туди. Після третього чи четвертого запитання в мене не було відповіді.
Вердикт рабер-дак уже виніс. Я знав, чого хочу від ідеї, але не зробив тієї розумової роботи, якої вимагала б ділова розмова. Зустріч пройшла приблизно так, як і мала за таких обставин: ми ні до чого не дійшли, і ідея померла просто в тій кімнаті. Жоден інструмент не врятує вас від непідготовленості. Але цей зробив дещо краще: сказав мені правду до того, як я сів у літак, а не за столом навпроти людей, яких я хотів переконати.
Ця практика старша за AI
Метод рабер-дак з'явився задовго до мовних моделей. Енді Гант і Дейв Томас описали й назвали його в книзі The Pragmatic Programmer 1999 року. Поясніть свій код гумовій качечці на столі, рядок за рядком, і баг, як правило, видає себе ще до того, як ви закінчите. Качечка нічого не додає від себе. Всю роботу виконуєте ви, а промовляння думки вголос — це те, що й вибиває помилку назовні.
Якийсь варіант цього я практикую все своє кар'єрне життя. Поки я ще не довіряв власній логіці, то спершу писав коментар до кожного рядка, описуючи, що він має робити, і лише потім заповнював код під ним. Часто логіка розвалювалася вже на етапі коментарів. Саме заради цього вони й писалися. Помилку дешевше зловити словами, ніж кодом.
Що якраз правильно робить качечка CS50 з Гарварду: стриманість
Коли я створював власну AI-версію, базову ідею я взяв у Гарварда. У їхньому вступному курсі CS50 працює AI-качечка під назвою CS50 Duck, до якої студенти можуть звертатися з питаннями цілодобово. Ключове рішення в її дизайні — стриманість: команда наклала на неї обмеження, щоб вона підштовхувала студента до розв'язку, але зупинялася перед тим, як просто його видати. У своєму описі вони формулюють мету як індивідуального репетитора, що веде до відповіді, а не «зливає» її наперед.
Ця стриманість і є весь продукт. За замовчуванням модель прагне бути корисною, а корисність вона розуміє як відповідь. Щоб отримати справжню качечку, їй потрібно чітко й регулярно наказувати робити складніше: ставити наступне запитання і потім чекати.
Де це найбільше окупається: репетиція змін
Перш ніж зробити щось, що потім важко відкотити назад, наприклад новий процес чи реорганізацію, я прокручую його впровадження через рабер-дак ще до того, як про нього дізнається хоч одна людина. Качечка грає роль скептика: за що зачепляться старші інженери, яка фраза прозвучить як загроза там, де я мав на увазі план. Вона знаходить непорозуміння, яке я сам, не помічаючи, заклав у формулювання, поки виправити слова ще нічого не коштує. До того моменту, коли зміна доходить до людей, я вже встиг один раз програти цю суперечку наодинці й переписати все простішими словами.
Той самий прийом працює й перед великою зміною в коді. Перед рефакторингом чи міграцією я проговорюю план і даю качечці розхитати його. Вона питає, що зламається, якщо моє головне припущення хибне, і що я лишаю тому, що воно правильне, а що — просто тому, що звичне. Качечка бере будь-яке рішення, яке я збираюся ухвалити, і змушує мене відстояти його ще до того, як написано хоч рядок коду.
Коли рабер-дак — не той інструмент?
Усе це не безкоштовне і не завжди доречне. Рабер-дак спеціально повільний за задумом, тож коли мені потрібна лише відповідь, наприклад деталь синтаксису чи шаблонний код, я просто прошу відповідь і йду далі.
Крім того, якість цього методу залежить від того, наскільки я сам чесний із ним. Я можу підкинути йому висновок, який хочу почути, і отримати заспокійливий кивок. Він перевіряє мою логіку, але мотиви приймає на віру.
Про мою ситуацію він знає лише те, що я йому розповів, і те, на чому його навчили. Ця сама сліпа зона дозволяє йому переписувати код, якого він не бачить. Це дзеркало, що вміє ставити хороші запитання, але не має власного судження.
Тож я тримаю у роботі два типи AI. Один відповідає, тобто це те, що більшість людей мають на увазі під цим словом, і він справді економить мій час. Другий лише запитує, нічого не відповідаючи, і саме тому для мене він цінніший. Він частіше робить мене правим або принаймні вчасно зупиняє мене ще до того, як шанс це зробити отримають люди по той бік столу.