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

Звідси виникає важливий наслідок для IT: картина — це не просто зображення предметів, а стиснута модель світу, пропущена через темперамент автора. Ван Гог сам писав, що ми бачимо природу не буквально, а через власний темперамент; його численні “начерки” в листах слугували способом передати Тео не лише вигляд майбутньої картини, а й структуру задуму, майже як візуальне технічне завдання до появи Figma, Jira та інших цивілізаційних покарань. У розробці вебзастосунків ми робимо те саме: беремо реальний процес — виробництво деталі, обробку заявки, запис клієнта, роботу складу, рух грошей — і створюємо його формалізовану картину. База даних, інтерфейс, ролі, статуси, сценарії та обмеження стають мазками, з яких збирається модель реального світу. “Метод Ван Гога” у цьому сенсі — це спроба не безкінечно обговорювати реальність, а швидко зафіксувати авторське бачення процесу в завершеному цифровому артефакті: не ідеальному й не вічному, але достатньо цілісному, щоб його можна було показати, використовувати, продати або замінити наступною, точнішою картиною. Це прямо продовжує вихідну думку діалогу про програмний продукт як незмінний артефакт-модель бізнес-процесу.

Метод Ван Гога у створенні вебзастосунків: швидкий синтез завершених програмних артефактів за допомогою AI-агентів

Анотація

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

На відміну від класичного MVP, який створюється як засіб перевірки гіпотези й майже неминуче передбачає ітерації, “ван-гогівський” артефакт прагне бути самостійним завершеним об'єктом: його або продають, використовують і масштабують як окрему версію, або залишають як частину портфеля експериментів. Це не скасовує супровід повністю, тому що вебзастосунки живуть у змінному середовищі, а люди, як з'ясувалося, змінюють вимоги швидше, ніж сервери встигають перезавантажитися. Але метод обмежує нескінченне доопрацювання: функціональні зміни оформлюються як нова “картина”, а не як вічне копирсання в старій.

Історична метафора Ван Гога тут важлива не як романтизація страждання, а як модель продуктивності й відбору. Ван Гог за приблизно десятирічну кар'єру створив майже 900 картин і понад 1100 робіт на папері; його цінність виникла не з одного ідеального “першого мазка”, а зі щільності практики, виразного стилю, послідовності та подальшого культурного відбору. Міф про те, що він продав лише одну картину за життя, також спрощений: Van Gogh Museum вказує, що точна кількість невідома, але це було більше ніж пара, включно з комісією на 19 міських видів Гааги та продажем “The Red Vineyard”. (The Metropolitan Museum of Art)

1. Центральна теза

Метод Ван Гога для вебзастосунків — це не “вайб-кодинг”, не хаотична генерація коду і не чергова героїчна фантазія про програміста, який за ніч написав CRM, ERP, бухгалтерію і сенс життя. Це дисциплінований спосіб швидко створювати вузькі вебпродукти, використовуючи AI-агентів як виконавчу силу, а людину — як джерело наміру, доменної оцінки й фінального відбору.

Формула методу:

Стиснути домен → сформувати агресивно-точну специфікацію → згенерувати застосунок → перевірити мінімальними об'єктивними тестами → випустити як завершений артефакт → не перетворювати його на нескінченний ремонт, а створювати наступну версію або наступний продукт.

У вихідному діалозі ця ідея виникає з протиставлення двох режимів: звичайного перфекціоністського прототипування, де продукт може не з'явитися взагалі, і радикального режиму “одним довгим мазком”, де за обмежений час створюється відчутний продуктовий результат. Там само з'являється важлива думка: 10 хвилин можуть бути не часом повної розробки, а часом людської участі — 5 хвилин на первинне розуміння ніші й 5 хвилин на формування потужного промпта, після чого агентська система виконує основну роботу.

2. Чому це не просто MVP

Класичний MVP у Lean Startup — це мінімальний продукт, який дозволяє якомога швидше почати цикл “build-measure-learn”: побудувати, виміряти, навчитися і за потреби змінити напрям. Lean Startup прямо описує MVP як початковий інструмент навчання й перевірки гіпотези, а не як завершений художній об'єкт. (theleanstartup.com)

Метод Ван Гога близький до MVP за швидкістю, але відрізняється за філософією:

Тобто MVP каже: “випусти мінімум, щоб дізнатися”. Метод Ван Гога каже: “створи малий, але завершений об'єкт, щоб він міг бути куплений, використаний або відкинутий”. Різниця тонка, але важлива. MVP живе в логіці ітерації. Метод Ван Гога живе в логіці серії.

3. Теоретична база: чому вебзастосунок не може бути “вічним” буквально

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

Тут корисні закони еволюції програмного забезпечення Лемана. Він описував E-type systems як системи, що розв'язують задачі або реалізують застосунки в реальному світі. Для таких систем діє закон безперервної зміни: використовувана E-type програма має постійно адаптуватися, інакше з часом стає менш задовільною. (gwern.net)

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

Фред Брукс у “No Silver Bullet” розділяв складність програмування на випадкову й сутнісну. Інструменти можуть знижувати випадкову складність: синтаксис, шаблонний код, збірку, інфраструктуру. Але сутнісна складність залишається в самій предметній області: що саме має робити застосунок, які правила бізнесу він відображає, які винятки є в процесу.

Саме тому метод Ван Гога має бути не “ШІ напиши мені SaaS”, а методом стиснення сутнісної складності до форми, яку агент може реалізувати без нескінченного уточнення.

4. Чому зараз це стало практично можливим

AI-інструменти вже змінили розробку, але не так примітивно, як “нейромережа замінить усіх, крім людини, яка робить вигляд, що зрозуміла промпт”. Дані суперечливі, і це якраз важливо.

У контрольованому експерименті GitHub Copilot розробники з доступом до AI-помічника завершили задачу реалізації HTTP-сервера на JavaScript на 55,8% швидше за контрольну групу. Це добре підтримує ідею, що AI особливо сильний в обмежених, формалізовуваних, greenfield-задачах. (arXiv)

Але дослідження METR 2025 року щодо досвідчених open-source розробників показало протилежну картину: 16 розробників виконували 246 задач у зрілих проєктах, де вони мали в середньому 5 років досвіду; при дозволеному використанні AI вони очікували прискорення, але фактично витрачали на 19% більше часу. (arXiv)

Висновок для методу Ван Гога: AI краще використовувати не як “магічний прискорювач усього”, а як фабрику greenfield-артефактів на стандартизованій платформі. Агент ефективніший, коли задача схожа на створення нового обмеженого застосунку, а не на акуратне втручання в зрілу кодову базу з історією, контекстом і технічними шрамами.

Індустрія вже рухається туди. Stack Overflow Developer Survey 2025 показує, що 84% респондентів використовують або планують використовувати AI-інструменти в розробці, а 51% професійних розробників використовують їх щодня. При цьому довіра залишається низькою: більше розробників активно не довіряють точності AI-висновків, ніж довіряють, а головна фрустрація — рішення, які “майже правильні, але не зовсім”. (Stack Overflow Insights)

Великі компанії також впроваджують AI у розробку. Google у Q3 2024 повідомив, що понад чверть нового коду всередині компанії генерується AI, після чого перевіряється й приймається інженерами. (blog.google) Anthropic в аналізі 500 000 coding-related взаємодій виявив, що Claude Code частіше використовується для автоматизації, ніж для доповнення людини: 79% розмов були класифіковані як automation; також там зазначено, що JavaScript і HTML були найчастішими мовами в наборі даних, а UI/UX задачі — серед провідних сценаріїв. (Anthropic)

Це прямо підтримує обрану область: вебзастосунки, інтерфейси, мікропродукти, стартапні прототипи й малі бізнес-системи.

5. Визначення методу

Метод Ван Гога — це процес створення серії завершених вебзастосунків, де кожен застосунок:

1. моделює один обмежений бізнес-процес або одну предметну нішу;
2. створюється в жорстко обмеженому циклі людської участі;
3. реалізується AI-агентами на базі заздалегідь підготовлених архітектурних примітивів;
4. проходить мінімальний набір об'єктивних перевірок;
5. публікується як самостійний продуктовий артефакт;
6. оцінюється ринком, використанням або продажем;
7. не перетворюється на нескінченний backlog, а за потреби замінюється новою версією.

Ключовий зсув: ми не намагаємося створити ідеальну програму на віки. Ми створюємо “картину”: завершену модель фрагмента реального світу. Якщо модель застаріває, з'являється нова картина. Не реставрація до нескінченності, не нескінченні “а давайте додамо ще ось це”, не корпоративна некромантія над формою, яку ніхто не просив.

6. Градієнт “вічності” вебзастосунків

Не всі вебзастосунки однаково підходять для методу. Потрібен критерій відбору.

З цього випливає практичне правило:

Метод Ван Гога працює тим краще, чим стабільніший домен, менше зовнішніх інтеграцій, нижчий юридичний ризик і вужчий бізнес-процес.

7. Архітектурна модель

Щоб метод не перетворився на “згенерував сміття, задеплоїв, молись”, потрібна платформа. У діалозі згадується “Фрактал” як можливий продукт-каркас. У формалізованому вигляді це можна описати як генеративну платформу для збирання нішевих вебзастосунків.

Її шари:

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

8. Цикл “5 + 5 + агент”

У діалозі з'являється важлива операційна ідея: людина не зобов'язана писати код. Вона може за 10 хвилин підготувати агенту настільки щільне завдання, що той далі виконає проєкт. Формалізуємо це.

Фаза 1. Доменна розвідка, 5 хвилин

Мета — не “вивчити галузь”, тому що за 5 хвилин можна вивчити хіба що ступінь своєї самовпевненості. Мета — швидко отримати робочу карту предметної області.

AI має видати:

• хто користувачі;
• який біль у бізнесу;
• які сутності є в системі;
• які процеси найчастіше автоматизуються;
• які помилки й edge cases типові;
• який мінімальний продукт можна продати;
• які функції не можна включати в перший мазок.

Фаза 2. Агресивна специфікація, 5 хвилин

На основі розвідки людина формує “нахабний промпт”: не прохання “зроби сайт”, а директиву, де зазначені:

• ніша;
• цільовий користувач;
• продуктовий результат;
• стек;
• структура екранів;
• ролі користувачів;
• моделі даних;
• бізнес-правила;
• тести;
• обмеження;
• критерії готовності;
• формат результату.

Фаза 3. Агентська реалізація

Далі кодинг-агент:

• створює проєкт;
• пише моделі й міграції;
• збирає інтерфейс;
• додає авторизацію й ролі;
• пише тести;
• проганяє перевірки;
• виправляє помилки;
• готує деплой;
• створює README і комерційний опис.

Фаза 4. Людський відбір

Людина не зобов'язана вичитувати кожен рядок, але зобов'язана прийняти рішення:

• продається;
• відправляється в портфель;
• переробляється як нова версія;
• знищується, тому що деякі картини краще не показувати навіть родичам.

9. “Не правити більше ніколи”: реалістична версія

Абсолютна незмінність вебпродукту небезпечна. AI-generated код може містити вразливості: емпіричне дослідження Copilot-generated snippets виявило security weaknesses у 27,3% із 733 сніпетів, включно з 29,5% Python і 24,2% JavaScript сніпетів. (arXiv) CSET також виділяє ризики AI-generated code: небезпечний код, вразливість самих моделей до атак і downstream-ризики для supply chain; у їхній оцінці майже половина сніпетів від п'яти LLM містила баги, здатні призвести до експлуатації. (cset.georgetown.edu)

Тому правильніше розділити незмінність на два режими:

Так метод зберігає головну ідею: не перетворювати кожен маленький продукт на вічну яму супроводу, де “ще одна правочка” стає способом життя.

10. Метрики методу

Щоб метод був не красивою фантазією, а досліджуваною практикою, потрібні метрики.

Виробничі метрики

Якісні метрики

Ринкові метрики

Інженерні метрики

DORA пропонує вимірювати throughput та instability через change lead time, deployment frequency, failed deployment recovery time, change fail rate і deployment rework rate. Ці метрики корисні й для методу Ван Гога, але застосовувати їх потрібно на рівні конкретного застосунку, а не змішувати різні продукти в одну кашу, як люблять робити звіти заради відчуття контролю над хаосом. (Dora)

DORA 2024 також показує важливий нюанс: AI підвищує індивідуальну продуктивність, flow і задоволеність, але може негативно впливати на стабільність доставки та throughput, тому маленькі партії змін і сильне тестування залишаються критичними. (Dora)

11. Які вебзастосунки варто “ван-гожити”

Найкращі кандидати:

1. Нішеві CRM Наприклад: CRM для студії манікюру, клінінгу, ремонту техніки, оренди обладнання, локальної доставки.

2. Калькулятори та конфігуратори Розрахунок вартості послуги, підбір пакета, генерація КП, попередній кошторис.

3. Заявочні системи Форма → статус → менеджер → сповіщення → звіт.

4. Мінікабінети клієнтів Клієнт бачить заявки, документи, рахунки, статуси.

5. Операційні панелі Прості адмінки для малого бізнесу: замовлення, виконавці, календар, статуси, фінанси.

6. Генератори документів Шаблони договорів, актів, інструкцій, чек-листів, комерційних пропозицій.

7. Навчальні мікропродукти Бази знань, внутрішні інструкції, інтерактивні тренажери.

Погані кандидати:

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

12. Економічна логіка

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

Це ближче до портфельного підходу:

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

У діалозі важлива думка: цінність продукту вимірюється не тим, наскільки розробник пишається архітектурою, а тим, чи купують його. Це грубо, зате чесно. Ринок не зобов’язаний поважати ваш DDD, особливо якщо користувач хотів просто “щоб заявки не губилися”.

Метод особливо підходить для:

• стартаперів, яким потрібно швидко перевіряти ніші;
• малого та середнього бізнесу, якому не потрібна важка корпоративна система;
• агентств автоматизації;
• AI-first студій;
• компаній, які хочуть замінити ручні процеси мікросистемами;
• продуктових команд, яким потрібен швидкий market scan.

13. Наукові гіпотези для перевірки

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

H1. Для greenfield вебзастосунків з обмеженою предметною областю метод Ван Гога знижує human time до першого deploy порівняно з традиційною розробкою.

H2. Якість результату залежить не від довжини промпта, а від повноти доменної структури: актори, сутності, сценарії, обмеження, acceptance criteria.

H3. AI-агенти дають максимальний виграш у задачах генерації нових застосунків і мінімальний або негативний виграш у задачах зміни зрілих кодових баз. Це узгоджується з контрастом між експериментом GitHub Copilot і дослідженням METR. (arXiv)

H4. Що нижча волатильність домену та кількість зовнішніх залежностей, то довший строк життя “замороженого” артефакта.

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

H6. За наявності готової платформи примітивів якість AI-generated застосунків зростає швидше, ніж під час генерації “з нуля” для кожної ніші.

14. Практичний шаблон “нахабного промпта”

Ты выступаешь как продуктово-технический агент, архитектор, full-stack разработчик и QA-инженер.

Цель: создать законченное веб-приложение для ниши: [НИША].

Целевая аудитория:
[Кто покупает продукт]
[Кто ежедневно пользуется продуктом]

Главная боль:
[Какая проблема должна быть решена]

Формат результата:
Создать production-ready MVP, который можно показать клиенту, продать как SaaS/white-label или использовать как демо.

Стек:
[Backend]
[Frontend]
[DB]
[Auth]
[Deploy target]

Ограничения:
- Не добавлять лишнюю функциональность.
- Не использовать внешние API без необходимости.
- Все бизнес-правила держать явно.
- Все формы валидировать.
- Все роли и права доступа описать.
- Не оставлять секреты в коде.
- Подготовить seed data.
- Подготовить README.
- Подготовить демо-сценарий.

Нужно реализовать:

1. Краткое доменное описание:
   - акторы;
   - сущности;
   - ключевые процессы;
   - edge cases.

2. Модели данных:
   - таблицы;
   - поля;
   - связи;
   - ограничения.

3. Роли:
   - owner/admin;
   - manager;
   - user/client;
   - при необходимости staff/operator.

4. Экраны:
   - dashboard;
   - список сущностей;
   - создание/редактирование;
   - карточка объекта;
   - отчёты;
   - настройки.

5. Основные сценарии:
   - создание заявки/заказа;
   - изменение статуса;
   - назначение ответственного;
   - уведомление;
   - просмотр истории;
   - экспорт/отчёт.

6. Критерии готовности:
   - проект запускается локально;
   - миграции выполняются;
   - seed data создаются;
   - ключевые сценарии проходят;
   - тесты проходят;
   - нет критичных security issues;
   - README объясняет запуск и демо.

7. Итоговый результат:
   - код;
   - структура проекта;
   - инструкция запуска;
   - список реализованных функций;
   - список ограничений;
   - идеи для следующей версии, но НЕ реализовывать их.

15. Приклад: “ван-гогівський” застосунок для клінінгу

Домен: невелика клінінгова компанія.

Продукт: вебзастосунок для заявок, розрахунку вартості, призначення виконавців і контролю статусів.

Сутності:

• клієнт;
• об’єкт прибирання;
• заявка;
• послуга;
• виконавець;
• зміна;
• рахунок;
• статус;
• коментар.

Екрани:

• публічна форма заявки;
• калькулятор вартості;
• адмін-панель заявок;
• календар виконавців;
• картка клієнта;
• звіт щодо виконаних робіт;
• налаштування послуг і цін.

Чому підходить методу:

• зрозумілий бізнес-процес;
• низька регуляторна складність;
• можна зробити без складних API;
• цінність легко пояснити власнику бізнесу;
• продукт можна продати як white-label кільком компаніям.

Межа першого мазка:

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

16. Головна небезпека методу

Головна небезпека — сплутати швидкість із цінністю. AI може швидко генерувати код, але швидко створений код не дорівнює корисному продукту. Stack Overflow 2025 прямо показує, що розробники масово використовують AI, але стикаються з “майже правильними” рішеннями та складним налагодженням AI-generated коду. (Stack Overflow Insights)

Тому метод Ван Гога має мати три обов’язкові фільтри:

1. Доменний фільтр Застосунок вирішує реальну, зрозумілу, продавану проблему.

2. Інженерний фільтр Застосунок проходить тести, security checks і базову UX-перевірку.

3. Ринковий фільтр Застосунок можна продати, впровадити або хоча б показати потенційному клієнту без сорому рівня “я це зробив о 3 ночі, і тепер воно дивиться на мене”.

17. Підсумкове формулювання ідеї

Метод Ван Гога — це технологія швидкої генерації завершених вебзастосунків, заснована на портфельному створенні малих продуктових артефактів. Він використовує AI-агентів для зняття випадкової складності розробки: коду, шаблонів, інтерфейсів, тестів, документації та деплою. Людина залишається відповідальною за сутнісну складність: вибір домену, розуміння болю, обмеження форми, прийняття результату та ринковий відбір.

Метод не обіцяє вічних вебзастосунків. Він пропонує реалістичнішу річ: створювати такі застосунки, які мають шанс бути достатньо завершеними, щоб їх можна було використовувати або купити без довгої розробки. Їхня “вічність” досягається не відсутністю змін у світі, а правильною межею: маленький домен, ясна модель, мінімум залежностей, версія як завершений об’єкт.

У цьому сенсі вебзастосунок стає не нескінченним проєктом, а цифровою картиною бізнес-процесу. Не все стане шедевром. Більшість не стане. Але за високої швидкості, дисципліни, серії та ринкового відбору з’являється шанс створити не один роздутий продукт, а цілу галерею працюючих рішень.

І ось це вже не “вайб-кодинг”. Це фабрика швидких програмних артефактів. Майже цивілізовано, що для веброзробки саме по собі рідкісна подія.