У Ван Гога скорость была не культом небрежности, а способом сохранить живую структуру впечатления. Он не думал, что хорошая картина рождается “по-быстрому” из пустоты: наоборот, писал, что для схватывания сути вещей нужно долго и упорно работать. Но когда образ уже созрел, он считал опасным бесконечно его полировать: в письмах к Тео он восхищался старыми мастерами за то, что они писали быстро, “сразу клали” форму на холст и, если работа получалась, оставляли её в покое; отдельно он формулировал принцип “писать в один заход, насколько возможно”. В другом письме он прямо связывал быстроту с природой самого наблюдения: красивые эффекты света в природе требуют быстрой руки, потому что момент уходит, а чрезмерная доработка убивает жизненность. То есть минимальное время на картину у Ван Гога — это не экономия труда, а защита первичного видения от распада под давлением перфекционизма, критики и бесконечных правок.

Отсюда возникает важное следствие для 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-агентов для снятия случайной сложности разработки: кода, шаблонов, интерфейсов, тестов, документации и деплоя. Человек остаётся ответственным за сущностную сложность: выбор домена, понимание боли, ограничение формы, принятие результата и рыночный отбор.

Метод не обещает вечных веб-приложений. Он предлагает более реалистичную вещь: создавать такие приложения, у которых есть шанс быть достаточно завершёнными, чтобы их можно было использовать или купить без долгой разработки. Их “вечность” достигается не отсутствием изменений в мире, а правильной границей: маленький домен, ясная модель, минимум зависимостей, версия как завершённый объект.

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

И вот это уже не “вайб-кодинг”. Это фабрика быстрых программных артефактов. Почти цивилизованно, что для веб-разработки само по себе редкое событие.