Уілл ЛаФорест сьогодні працює Field CTO в Confluent — компанії, що розвиває платформи потокової обробки даних. Значну частину його роботи займають розмови з клієнтами, пояснення можливостей технологій на кшталт Apache Kafka та сучасних систем даних мовою бізнесу, а також повернення цього зворотного зв’язку в продуктові команди. Звучить як класична роль «перекладача» між світом інженерів і світом керівників. Але фундамент цього вміння заклався не в корпоративних переговорах, а в доволі болючому епізоді зі шкільного наукового ярмарку, коли перспективний проєкт зі штучного інтелекту буквально зник напередодні захисту.
Ця історія — не про ностальгію за 486‑ми і тридюймовими дискетами. Вона про те, як одна невдала спроба пояснити складну систему нефахівцям перетворилася на життєвий урок: технічна досконалість нічого не варта, якщо люди не розуміють, що перед ними і навіщо це їм потрібно.
Коли код зникає за ніч: провал, що виявився поворотним
На початку 1990‑х, ще в старшій школі, ЛаФорест захоплювався тим, що тоді вже називали штучним інтелектом. Один із його ранніх успішних проєктів — «AI‑пітчер» у бейсболі: програма на 486‑му під DOS, яка моделювала подачі, використовуючи однорівневу нейромережу та профілі відбивачів. Для свого часу це було сміливе й доволі передове завдання, особливо для школяра, який діставав знання не з інтернету, а з випадково знайденої книжки в університетській крамниці.
Успіх надихнув. Наступного року він із другом вирішив «підняти ставки» й замахнутися на загальнішу задачу: система, яка працює з «знаннями» і відповідає на запитання. Ідея була амбітною навіть за сучасними мірками, не кажучи вже про епоху модемів на 300 бод: замість нейромереж — евристичний підхід до обробки природної мови та власноруч зібраний граф знань.
Реальність виявилася жорсткою. Нейромережі для цієї задачі виявилися «занадто важкими», тож команда перейшла до примітивних евристик: система розуміла лише дуже вузький, граматично «правильний» діапазон фраз, а будь‑яке відхилення ламало всю логіку. На додачу до цього, напередодні самого ярмарку сталася катастрофа: код зник.
Усе, що було створено за майже рік роботи, зберігалося на кількох тридюймових дискетах. Десь там точно лежала робоча версія, але знайти її не вдалося. Відновити систему за ніч було нереально. Для шкільного проєкту це могло б означати просту відмову від участі, але був один фактор, який не дозволив просто здатися: тітка ЛаФореста власноруч зробила для нього розкішний стенд — з розписом, оформленням, усім тим, що мало створити «вау‑ефект» на ярмарку. Відмовитися означало б знецінити її працю.
Тож рішення було одне: виходити до суддів без демо.
Саме в цей момент технічна проблема — втрата коду — перетворилася на людську: як пояснити складну, невидиму систему людям, які не мають ані інструментів, ані контексту, щоб її оцінити?
Коли складність не працює: провалена спроба пояснити ШІ нефахівцям
Попередній проєкт із «AI‑пітчером» був зрозумілим для журі: можна було показати, як система «вчиться», як змінюються результати проти різних відбивачів, продемонструвати процес і ефект. Навіть якщо судді не були програмістами, вони бачили гру, бачили зміну поведінки, могли інтуїтивно відчути, що відбувається.
З новою системою все було інакше. По‑перше, не працював сам код, тож не було жодної живої демонстрації. По‑друге, судді були «звичайними» науковими експертами, а не спеціалістами з інформатики. Для них не існувало готових ментальних моделей, щоб одразу зрозуміти, що таке граф знань, евристичний аналіз тексту чи обмеження примітивної обробки мови.
ЛаФорест із другом намагалися пояснити, що вони будували: систему, яка ставить запитання, накопичує факти, а потім дозволяє ставити нові запитання на основі вже зібраної інформації. Вони намагалися описати логіку, структуру, загальну ідею. Але без живого прикладу, без можливості показати «ось як це працює» пояснення зависало в повітрі.
Це був не просто технічний провал. Це був провал комунікації. Виявилося, що:
по‑перше, сам факт наявності складної архітектури не переконує нікого поза колом розробників;
по‑друге, абстрактні описи алгоритмів не викликають довіри, якщо людина не може побачити, як це впливає на щось знайоме й зрозуміле;
по‑третє, без адаптації мови й прикладів до рівня та досвіду слухача навіть найцікавіша ідея виглядає як набір незрозумілих термінів.
ЛаФорест пізніше назве цю спробу пояснити свій другий проєкт суддям одним із найформативніших досвідів у житті. Саме тоді стало очевидно: між створенням технічно складної системи й умінням зробити так, щоб інші побачили в ній цінність, лежить прірва. І подолати її — не менш складне завдання, ніж написати сам код.
Від шкільного стенду до переговорної кімнати: як формується «людська» сторона технічної ролі
Сьогодні, працюючи Field CTO в Confluent, ЛаФорест описує свою роль як поєднання двох осей компетенцій. З одного боку, потрібне глибоке технічне розуміння: без нього немає довіри, особливо коли в кімнаті присутні інженери замовника, здатні швидко виявити поверхневі знання. З іншого боку, необхідно вміти «говорити людською мовою» — пояснювати, що робить технологія, не занурюючи всіх у деталі реалізації.
Саме тут досвід проваленого шкільного проєкту виявився не просто спогадом, а практичним уроком. Тоді, на ярмарку, він намагався донести ідею через технічні описи: структури даних, евристики, обмеження граматики. Сьогодні він робить навпаки: починає з того, що має значення для співрозмовника.
Коли мова заходить про потокову обробку даних, Kafka чи інші компоненти екосистеми Confluent, для багатьох керівників це просто набір незнайомих слів. Їх не цікавить, як саме реалізовано розподілені журнали чи механізми реплікації. Їх цікавить, як це вплине на час обробки транзакцій, на здатність виявляти шахрайство в реальному часі, на ефективність ланцюга постачання чи на досвід клієнта в мобільному застосунку.
Тому замість того, щоб «захищати» технологію як науковий проєкт, ЛаФорест будує розмову навколо домену клієнта. Якщо це банк, мова йде про платежі, ризики, регуляторні вимоги. Якщо це ритейл — про запаси, персоналізовані пропозиції, логістику. Технологія стає не об’єктом демонстрації, а інструментом у знайомому для співрозмовника контексті.
Це прямо протилежний підхід до того, що сталося на шкільному ярмарку. Там він намагався переконати суддів у цінності системи, виходячи з її внутрішньої складності. Тепер він виходить із зовнішньої цінності: що зміниться в бізнесі, якщо ця система запрацює.
Як перетворити абстрактний ШІ та стрімінг даних на зрозумілі історії
Ключовий висновок, який ЛаФорест виніс зі свого шкільного провалу, полягає в тому, що провалюються не стільки технології, скільки комунікації навколо них. Система може бути недосконалою, сирою, обмеженою — але якщо люди розуміють, що вона робить і чому це важливо, у неї є шанс на розвиток. І навпаки: навіть технічно блискучий продукт може залишитися непоміченим, якщо його не вдається «перекласти» на мову користувача.
Сьогодні це особливо помітно в розмовах про штучний інтелект і потокову обробку даних. Обидві теми насичені термінами, які легко перетворюються на «шум» для нефахівців. ЛаФорест будує свої демонстрації та дискусії так, щоб уникати цієї пастки.
По‑перше, він прив’язує абстрактні поняття до конкретних сценаріїв. Замість того, щоб говорити «ми можемо застосувати ШІ до ваших потоків даних», він показує, як це виглядає в конкретному бізнес‑процесі: наприклад, як система в реальному часі реагує на поведінку користувача в застосунку, змінює пропозицію, блокує підозрілу транзакцію чи оптимізує маршрут доставки. Це не просто «демо функцій», а історія, в якій технологія є логічним елементом сюжету.
По‑друге, він уникає «демо заради демо». На шкільному ярмарку план полягав у тому, щоб провести суддів по «щасливому шляху» взаємодії з системою: правильно поставлені запитання, коректні відповіді, демонстрація того, як граф знань дозволяє робити нові висновки. Втрата коду зруйнувала цей сценарій, і виявилося, що без нього пояснення не тримається. Сьогодні ЛаФорест проєктує демонстрації так, щоб навіть без ідеального «щасливого шляху» було зрозуміло, що відбувається і чому це важливо. Якщо щось іде не так, історія все одно залишається зрозумілою.
По‑третє, він свідомо адаптує наратив до домену. Це не просто «локалізація» прикладів, а глибше занурення: розуміння того, які метрики важливі для конкретної галузі, які ризики турбують керівників, які обмеження накладає регуляторика. Технологія подається не як універсальний «двигун прогресу», а як конкретний інструмент у конкретній ситуації.
Цей підхід — прямий наслідок того самого уроку зі шкільного ярмарку: якщо аудиторія не може співвіднести почуте з власним досвідом і завданнями, вона не побачить цінності, якою б вражаючою не була внутрішня складність системи.
Чому провалений шкільний проєкт виявився важливішим за успішні
Цікаво, що перший шкільний проєкт ЛаФореста — «AI‑пітчер» — був успішним і технічно, і з точки зору сприйняття. Він працював, його можна було показати, він викликав інтерес. Але саме другий, провалений проєкт із графом знань став тим, що сформував його підхід до комунікації.
Причина в тому, що успіх рідко змушує аналізувати, чому саме щось спрацювало. Коли демонстрація проходить гладко, легко приписати результат виключно технічній якості рішення. Натомість провал оголює слабкі місця — і часто це не код, а спосіб, у який він подається.
У випадку зі шкільним ярмарком ЛаФорест побачив одразу кілька речей.
По‑перше, він зрозумів, що не можна покладатися лише на «ефект демо». Якщо вся цінність проєкту тримається на можливості показати, як він працює, без глибшого розуміння контексту й цілей, будь‑який збій (на кшталт втрати коду) робить його невидимим.
По‑друге, він відчув на собі, як виглядає ситуація, коли аудиторія не має жодних «гачків», щоб зачепитися за ідею. Судді не були «комп’ютерними людьми», як він сам це формулює. Вони не могли оцінити ні складність реалізації, ні новизну підходу. Для них це була абстракція без опори в знайомій реальності.
По‑третє, він побачив, що емоційний контекст теж має значення. Відчуття провини перед тіткою, яка зробила стенд, бажання не підвести тих, хто вкладався в нього, змусили шукати спосіб донести ідею попри технічний крах. Це був перший досвід, коли «людський фактор» виявився сильнішим за «інженерний перфекціонізм».
Згодом ці інсайти трансформувалися в переконання, що найскладніші проблеми в кар’єрі — не технічні, а людські й комунікаційні. І що саме вони часто визначають, чи буде проєкт визнаний успішним, незалежно від того, наскільки елегантним є його внутрішній код.
Висновок: технічна глибина + людська мова як умова успіху
Історія про втрачений код шкільного проєкту з ШІ легко могла б залишитися просто анекдотом із минулого. Але для Уілла ЛаФореста вона стала точкою, де зійшлися дві лінії: пристрасть до складних систем і усвідомлення, що без уміння говорити про них «по‑людськи» ця складність нічого не варта.
Сьогодні, працюючи Field CTO в Confluent, він формулює вимоги до своєї ролі як до поєднання глибокої технічної компетенції та здатності комунікувати з людьми «вище по харчовому ланцюгу» — керівниками, які не зобов’язані знати, що таке Kafka, але мають розуміти, як технологія змінить їхній бізнес. Його підхід до розмов із клієнтами — це пряме продовження уроків шкільного ярмарку: адаптувати наратив до домену, прив’язувати абстрактні поняття до конкретних сценаріїв, проєктувати демонстрації так, щоб навіть нефахівці могли побачити вплив системи на реальний світ.
У добу, коли штучний інтелект і потокова обробка даних стають дедалі складнішими, а кількість «чорних скриньок» у технологічних стекх зростає, цей урок звучить особливо актуально. Проєкти падають не лише через баги чи неправильну архітектуру. Вони падають, коли люди, від яких залежить їхня доля, не розуміють, що перед ними і навіщо це їм потрібно. Іноді, щоб це усвідомити, достатньо одного зірваного шкільного проєкту.
Джерело
Tech vs. People: The Hardest Problem with Will LaForest | Ep. 26 | Confluent Developer Podcast