Уявіть: молодий засновник з'являється в Twitter і каже — «побудував data room за вихідні за допомогою AI.» Аудиторія аплодує. Інвестори записують нотатки. Медіа пишуть про майбутнє без кодування. А потім хтось відкриває GitHub і запитує тихо, але чітко: «Зачекайте. Чому цей компонент один-в-один збігається з кодом, який ми писали два роки?»

Саме це нещодавно сталося між людиною на ім'я Nico і командою Papermark — open-source альтернативи DocSend для захищеного ділення документами та data rooms. Засновник Papermark публічно вказав: продукт, який Nico презентував як власну AI-розробку, мав підозріло знайому архітектуру. Не просто «схожу» — а структурно ідентичну чужому open-source коду. За даними оригінальної публікації, ситуацію помітила спільнота Hacker News, і дискусія набрала понад 100 upvotes — а це аудиторія CTO, engineering managers і VC, які приймають реальні рішення.

Vibe coding обіцяв демократизацію розробки: будь-хто з ідеєю може тепер будувати продукти, просто описуючи їх AI-асистенту. Cursor, Claude, Copilot — ці інструменти справді змінили швидкість прототипування. Але цей скандал розкриває тіньову сторону хайпу. У світі, де «AI зробив це» стало технічним поясненням, яке важко спростувати без аудиту коду, межа між AI-асистованою розробкою і банальним копіюванням стала небезпечно розмитою.

Для AI-білдерів, які щодня використовують ці інструменти для написання реального коду — це не абстрактна дискусія про етику. Це питання про те, що саме ви будуєте і чому репутація завжди цінніша за shortcuts.

Papermark і data room: що насправді стоїть на кону

Щоб зрозуміти масштаб ситуації, треба знати контекст. Papermark — це open-source проект, який команда будувала роками як альтернативу дорогим корпоративним data room-рішенням. Data rooms — спеціалізовані захищені середовища для ділення конфіденційними документами під час M&A, fundraising або due diligence — коштують бізнесу серйозні гроші: Intralinks, Merrill DataSite, Firmex стартують від $400 на місяць і легко доходять до $2000+ залежно від обсягу транзакцій.

Papermark зробив ставку на open-source як модель диференціації: прозорість коду — перевага перед закритими enterprise-рішеннями. Публічний GitHub-репозиторій — це і маркетинг, і спосіб залучення контриб'юторів, і сигнал довіри для потенційних клієнтів. Але публічний код — це також можливість для тих, хто хоче скористатися чужою роботою без attribution.

Data room як продукт має специфічні технічні виклики, які не виникають «самі по собі»: захищене ділення файлами з link expiration, granular контроль доступу, watermarking документів, детальна аналітика переглядів (хто дивився, скільки часу, які саме сторінки), NDA-гейтинг перед доступом до матеріалів. Це не той функціонал, який стандартний AI-промпт генерує з нуля за вихідні — якщо тільки у вас немає вже готової реалізації під рукою.

Саме тут і виникає ключове питання: де закінчується «AI допоміг мені побудувати» і де починається «AI допоміг мені переупакувати чуже»?

Як виявляють крадіжку коду в 2026 році

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

Структурна схожість понад статистичний поріг. Алгоритми виявлення плагіату коду — MOSS, JPlag, SourcererCC — аналізують не лише текстову подібність, але й AST (Abstract Syntax Tree), тобто дерево синтаксичних структур програми. Якщо два файли мають однакову структуру компонентів, схожі назви функцій, ідентичні коментарі або той самий порядок імпортів — це важко пояснити випадковістю, навіть якщо змінено назви змінних.

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

License fingerprinting. Open-source ліцензії типу MIT вимагають збереження copyright notice у кожному файлі. Видалення attribution — це не просто порушення etiquette, а пряме порушення ліцензійного договору з юридичними наслідками.

Git history як доказ. Якщо репозиторій містить один великий «initial commit» з тисячами рядків складного функціонального коду, але автор нібито «тільки починав» — це red flag. AI справді може генерувати великі блоки коду, але конкретні бізнес-логіки — NDA flow, watermarking pipeline, viewer analytics — мають характерні архітектурні рішення, які не виникають з порожнього місця.

Де legitimate vibe coding кінчається і де починається проблема

Важливо не допустити помилки і не демонізувати vibe coding як явище. За останній рік ми бачили справжні успіхи: продукти, побудовані некодерами за допомогою Cursor і Claude, які вирішували реальні проблеми і залучали реальних платних користувачів. Різниця — у тому, що саме генерує AI і що є вихідним матеріалом.

Legitimate vibe coding виглядає так: описуєш Cursor архітектуру data room з нуля. AI пропонує підходи, пише компоненти, допомагає з edge cases. Ти ітеруєш, правиш логіку, тестуєш flow. Результат — твій, хоч і з великою допомогою AI. Код може бути схожий на інші рішення (бо AI навчений на тих самих патернах), але він не є копією конкретного чужого репозиторію.

Проблемне використання виглядає інакше: відкриваєш публічний GitHub, клонуєш репозиторій, робиш поверхневі зміни — ребрендинг, зміна кольорів, нова назва — і потім кажеш «я vibe coded це за вихідні». AI тут виступає в ролі постфактум-виправдання, а не реального інструменту розробки.

На ринку є чіткі приклади того, як будувати легітимно на чужій основі. Cal.com — публічний форк концепції Calendly з повним disclosure і доданою цінністю. Resend будується на поштових бібліотеках, але з оригінальним DX шаром. Trigger.dev використовує Bull під капотом, але це задокументовано. Різниця між цими проектами і описаним скандалом — не в технологіях, а в чесності щодо того, звідки прийшла основа.

Практичні уроки: три сценарії для AI-білдерів

Цей скандал — не просто Twitter-drama. Це навчальний кейс з практичними висновками для кожного, хто будує продукти з AI.

Сценарій перший: форк і модифікація — це окей, якщо чесно. MIT ліцензія дозволяє використовувати код Papermark у комерційних продуктах. Але умови чіткі: збережіть copyright notice, додайте attribution у README, і не стверджуйте, що побудували це з нуля. Форк з доданою цінністю — це legitimate підхід, яким користуються десятки успішних SaaS-компаній. Проблема виникає тоді, коли походження коду приховується.

Сценарій другий: UI-компоненти і шаблони. Shadcn/UI, Radix, Tailwind UI — весь екосистем компонентів існує для того, щоб будувати швидше. Це не крадіжка, а правильне використання інструментів. Проблема виникає тоді, коли ви використовуєте цілий готовий продукт, а не окремі компоненти для його будівництва.

Сценарій третій: «inspiration» через AI vs copy-paste через AI. Claude або GPT можуть генерувати схожі рішення для схожих проблем — це нормально, бо вони навчені на тих самих патернах і best practices. Якщо AI незалежно генерує схожий код — це збіг, а не плагіат. Але якщо ти завантажуєш чужий репозиторій у context window і просиш «зробити те саме, але з іншою назвою» — ти використовуєш AI як інструмент для обходу attribution, а не як інструмент розробки.

Ризики, які вибухнуть пізніше

Для тих, хто думає «може, пронесе» — ось реальна картина наслідків, яка не є гіпотетичною.

Юридичні наслідки

MIT ліцензія не така безнешкідна, як здається. Порушення вимоги про збереження copyright notice — це реальна правова претензія. У B2B SaaS-контексті, де потенційні клієнти й інвестори роблять due diligence, перевірка IP ownership є стандартною практикою. Виявлення «borrowed» коду на пізньому етапі fundraising або M&A — це гарантований провал угоди.

Репутаційні наслідки

Twitter і Hacker News мають довгу пам'ять та ефективну пошукову видачу. Публічне викриття з 100+ upvotes на HN — це постійний SEO-слід, який буде з'являтися при пошуку вашого імені. Аудиторія HN — ті самі люди, які приймають рішення про hiring, партнерства та інвестиції в технологічному секторі.

Технічний борг і security

Скопійований код приходить разом з усіма помилками і вразливостями оригіналу. Якщо в базовому продукті є security issue — ваш продукт теж вразливий. Але на відміну від оригінальної команди, у вас немає контексту, щоб швидко це виправити. Клієнти, які довіряють вам конфіденційні M&A документи або fundraising матеріали, платять за вашу безпеку — а ви запозичили і чужі вразливості.

Висновок AiiN: vibe coding потребує vibe ethics

Скандал із Nico і Papermark — це не ізольований інцидент. Це симптом системної проблеми, яка буде загострюватися в міру того, як AI-інструменти стають доступнішими і потужнішими.

Нова реальність така: Cursor і Claude настільки прискорюють розробку, що дозволяють недобросовісним акторам клонувати складні продукти з мінімальними зусиллями. Це створює реальну загрозу incentive structure open-source розробки. Якщо будь-хто може безкоштовно взяти роки чужої роботи і продавати під виглядом «vibe coded за вихідні» — навіщо взагалі публікувати код відкрито?

Наш прогноз на наступні 6–12 місяців: по-перше, відповіддю open-source спільноти стане автоматизований plagiarism detection як частина стандартного CI/CD pipeline. Інструменти structural similarity analysis вже існують — питання лише в інтеграції та стандартизації. По-друге, подібні публічні викриття стануть нормою, і інвестори почнуть включати «покажіть повний git history від першого коміту» в стандартний технічний due diligence. По-третє, культура «build in public» з регулярними публічними оновленнями і відкритою історією розробки стане репутаційним страхуванням — саме так будують найуспішніші indie hacker проекти сьогодні.

Для AI-білдерів практичний takeaway простий: vibe coding — це реальний і потужний інструмент. Але він не скасовує фундаментальних правил. Код має автора. Ліцензії мають юридичну силу. Репутація — ваш найцінніший актив у світі, де перевірити походження коду можна за п'ять хвилин. Використовуйте AI для прискорення розробки — а не для камуфлювання shortcuts, які в підсумку коштуватимуть більше, ніж зекономлений час.