Як DeepSeek Harness сам створив плагін «Зошит помилок»

Нетехнічний користувач може отримати працюючий інструмент, не написавши жодного рядка коду. У DeepSeek Harness є режим «Створення»: ви описуєте потребу звичайною мовою, а агент сам пише код і вбудовує готовий плагін у ліву панель програми. Один автор пройшов цей шлях до кінця і зібрав собі «Зошит помилок» для шкільних завдань.

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

Режим «Створення» перетворює опис потреби звичайною мовою на плагін, який вбудовується в саму програму, а не лишається окремим проєктом у вашій теці. Автор кейсу замовив «Зошит помилок»: батько фотографує сторінку з помилками, інструмент сам розрізає її на завдання, розкладає за темами, пояснює причину помилки й генерує схожі приклади для тренування. Документ вимог, прототип, тисячі рядків коду і десятки перевірок написав агент, людина формулювала потребу й відповідала на уточнення. Шлях від ідеї до робочого плагіна зайняв один вечір, причому з одним відкритим збоєм, який інструмент знайшов і виправив сам. Межа такого підходу проходить по рішеннях: що саме робити і де межа даних, за вас не вирішить ніхто.

Короткий словник

• Плагін — окремий модуль, який додає програмі новий розділ або нову можливість.
• Vibe coding — спосіб отримати програму, описуючи потрібний результат словами, без написання коду.
• Субагент — помічник, якому головний агент передає окрему частину роботи.
• Контракт інтерфейсу — домовленість про те, якими даними обмінюються дві частини програми.
• Логи — технічний журнал, у який програма записує свої дії та збої.

Що сталося: плагін, який виріс просто в програмі

Звична картина роботи з ШІ над кодом виглядає так: ви відкриваєте свій проєкт, помічник пише в нього код, проєкт залишається вашим. Режим «Створення» працює інакше. Те, що ви замовили, виростає всередині самої програми: новий розділ з'являється в лівій боковій панелі поряд зі штатними, і далі ви користуєтеся ним як частиною інтерфейсу.

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

Готовий плагін закриває весь шлях від фотографії до тренування.

Чому Harness влаштований інакше: принцип «все є плагіном»

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

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

Динамічний чи запакований: коли плагін зникає після перезапуску

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

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

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

Три промпти: чому автор викинув половину першого

Увесь процес склався з трьох кроків, по одному опису потреби на кожен: зібрати вимоги, намалювати прототип, написати плагін. Між цими трьома репліками людина в роботу не влазила.

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

Що лишити в описі потреби, а що інструмент вгадає сам

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

Ще одна фраза в тому описі виявилася найцінніша: «якщо є невизначені місця, спочатку запитай мене». Саме вона змусила агента зупинитися й поставити шість запитань, замість того щоб вигадати відповіді за замовника.

Крок перший: протиріччя у вимогах, якого не побачив замовник

Агент не кинувся писати документ. Спершу він вивчив, що здатна дати плагінна система програми, а потім показав шість запитань.

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

Межа даних: що насправді означає «тільки локально»

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

Рішення зрозуміле. Цінність зошита помилок тримається на якості розпізнавання: дитячий почерк, знята під кутом сторінка, червоні позначки вчителя. Невелика модель на домашньому комп'ютері з таким не справляється.

Таке запитання корисно ставити собі до будь-якого ШІ-інструмента, який працює з вашими документами. Формулювання «дані нікуди не йдуть» часто означає «дані не зберігаються», а не «дані не передаються». Різниця з'ясовується на етапі вимог, якщо її хтось назве вголос.

Приватність дитини: чому на обробку має їхати лише завдання

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

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

Другий, несхожий приклад — прийом, який робить структуру гнучкою

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

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

Крок другий: прототип за двадцять хвилин і рішення поза документом

Другий опис потреби був коротким: зроби з документа вимог клікабельний прототип, покрий усі сторінки, зв'яжи їх переходами, візьми правдоподібні приклади даних і тримайся стилю програми.

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

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

Строки етапів у тому прогоні виглядали так.

Етап	Приблизний час
Уточнюючі запитання і рішення людини	кілька хвилин розмови
Документ вимог, перша версія	трохи більше за чверть години
Правки до документа	кілька хвилин
Клікабельний прототип усіх сторінок	близько двадцяти хвилин
Розробка плагіна з перевірками	основна частина вечора
Пошук причини збою і виправлення	менше за десять хвилин

Один сеанс тут означає вечір з кількома колами уточнень.

Крок третій: як інструмент організував собі команду

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

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

Заморожений контракт інтерфейсу — місце, де зриваються справжні команди

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

Агент дійшов до такого порядку з однієї загальної фрази. Про те, як рівні контролю роблять ШІ-агентів надійними, ми розбирали окремо в матеріалі про три рівні контролю для надійних AI-агентів.

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

Що пішло не так: червоний рядок замість плагіна

Перша установка завершилася провалом. Розділ у боковій панелі з'явився, автор відкрив його і побачив червоний рядок: запит до сервісу не вдався. Половина роботи зійшлася, половина ні.

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

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

Як працює готовий «Зошит помилок» на реальному фото

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

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

Пояснення причини помилки і генерація схожих завдань

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

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

Перевірку виконаного завдання можна доручити моделі або поставити оцінку самому. Після двох правильних спроб підряд завдання автоматично отримує статус «засвоєно». Власної моделі плагін не підключав: розпізнавання, пояснення й генерацію завдань він брав у програми-хоста.

Хто що робив: розподіл ролей між людиною і ШІ

Якщо скласти весь вечір в одну картину, видно чіткий поділ.

Етап	Людина	Інструмент
Постановка задачі	Назвав суть, користувача, сценарій і заборони	Поставив уточнюючі запитання й знайшов протиріччя
Межі даних	Обрав компроміс із завантаженням	Показав, що дві вимоги не сходяться
Документ вимог	Прочитав і вказав три хиби	Написав документ і вніс правки
Прототип	Погодив вигляд	Намалював усі сторінки з переходами
Розробка	Участі не брав	Розподілив роботу, зафіксував контракт, написав код і перевірки
Збій	Переслав текст помилки	Знайшов причину в логах і виправив
Приймання	Пройшов сценарій на своїх фотографіях	Віддав звіт про виконане і відомі проблеми

Людина входила в процес кілька разів, і щоразу приносила рішення: межу даних і оцінку результату.

Де проходить межа vibe coding і що з цього взяти підприємцю

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

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

Підходить такий підхід не кожній задачі.

Обмеження кейсу: прев'ю-версія, чужа модель і межі даних

Три речі в цьому кейсі легко не помітити, а вони вирішують, чи повторите ви результат.

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

Друге: модель. Плагін користується тією моделлю, яку налаштували в програмі, а автор кейсу підключив сторонню, до якої мав доступ окремо. З налаштуваннями за замовчуванням якість розпізнавання рукописного тексту й пояснень може відрізнятися.

Третє: дані. Межа «завантажувати лише в момент обробки» усе одно означає, що зображення покидає ваш комп'ютер. Для дитячих робіт автор додав вимогу надсилати лише завдання. Для робочих документів таке рішення ухвалюють до першої фотографії.

Як нетехнічному користувачу перевірити, що інструмент справді працює

Код ви читати не будете, тому приймання робиться проходженням сценарію на справжніх даних.

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