Compositor: ШІ здешевлює clean-room розробку

Compositor — не Photoshop, але сигнал уже серйозний

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

Найсильніша кількісна опора для цієї тези походить не від Compositor, а з публікації MirrorCode. Там frontier-модель заново реалізувала інструментарій Go обсягом приблизно 16 000 рядків за 14 годин і $251; Epoch AI оцінила аналогічну людську роботу у два—17 тижнів. Цифри вражають, але обмежений інструментарій і зрілий графічний пакет — це різні вагові категорії.

Система рівня Photoshop потребує відтворення не лише функцій. Потрібно заново вибудувати архітектуру, поведінку інтерфейсу, роботу з ресурсами, продуктивність і безліч недокументованих крайніх випадків. Саме тому ProjDevBench і Vibe Code Bench оцінюють доставку цілих проєктів, а не тільки виправлення окремих завдань. Проте навіть вони не доводять, що автономна система здатна зібрати повноцінну заміну зрілому продукту.

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

Цінність переходить від написання коду до знання продукту

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

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

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

Останні оновлення Obsidian показують, як розширюване програмне забезпечення може швидко отримувати просунуті можливості через CLI, плагіни та локальні робочі процеси. Та сама динаміка пояснює, чому open-source проєкти дедалі частіше кидають виклик усталеним творчим інструментам.