Codex відтворив механічний екран із відео за 15 хвилин

Як перетворити відео на робоче пояснення

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

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

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

Ще дві робочі ситуації

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

Третій сценарій — робота з комп’ютером уночі через Computer Use. Система може користуватися комп’ютером і продовжувати розв’язання задачі без постійної присутності автора. Це інший режим, ніж швидка збірка демо: завдання триває довше, а перевірка переноситься на момент, коли людина повертається до результату.

Окремий приклад — застарілий монорепозиторій. За спостереженням автора, система здатна розібратися в legacy-монорепо без додаткової специфікації. Тут цінність не в генерації нового проєкту з нуля, а в роботі з уже наявною кодовою базою.

Де закінчується цей прийом

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

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

Ще одна межа стосується бізнесового результату. Швидке створення софту саме по собі не відповідає на два питання, які автор вважає головними: за що користувач заплатить і де він побачить рекламу продукту. Готова демоверсія підтверджує можливість зібрати механізм, але не підтверджує попит чи наявність каналу залучення.

Що перевірити перед використанням результату

• Чи правильно Whisper розпізнав нідерландський текст і чи не змінив зміст матеріалу.
• Чи вебмеханізм відтворює принцип роботи екрана з відео.
• Чи інтерактивність справді пояснює будову, а не лише повторює зовнішній вигляд.
• Чи виконано поставлену задачу повністю, особливо якщо система працювала самостійно вночі.
• Чи перевірені результати тренування моделей або роботи з legacy-кодом до подальшого використання.
• Чи є відповідь на питання, за що платить користувач і через який канал він дізнається про продукт.

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