Intro
Четыре месяца назад я решил провести странный эксперимент: построить рабочий веб-сайт, не написав ни одной строки кода самому. Всё — бэкенд, фронтенд, инфраструктура, CI/CD, обработка изображений — должно быть написано ИИ. Моя роль — описывать, что я хочу, и контролировать результат.
Четыре месяца и 663 коммита позже: bigunphoto.com запущен. ~60 500 строк кода, 260 изображений, 16 страниц на трёх языках. История GitHub расскажет всё полностью. Стоимость инфраструктуры: около €8 в месяц. Расходы на ИИ: €0. Я всё ещё не написал ни одной строки прикладного кода. Это не учебник и не история успеха. Это запись того, что произошло.
Почему я начал
На моей текущей позиции я руковожу командой, которая создаёт, настраивает или внедряет инструменты автоматизации. Поскольку я пришёл из немного иного карьерного пути, я часто ощущал растущий технический разрыв между собой и инженерами, с которыми работаю — я мог обсуждать архитектуру, но сам ничего не создавал. В то же время я хотел понять инструменты разработки ИИ изнутри, а не только по демо. Лучший способ научиться в инженерии — всё ещё тот же: построить что-то реальное.
Моя жена — профессиональный фотограф. У неё никогда не было нормального сайта — только Instagram. Это дало мне площадку для экспериментов. Цель не была построить идеальное портфолио для разработки. Цель — увидеть, насколько далеко можно зайти с помощью ИИ-ассистированной разработки.
Правила
Я установил три ограничения.
Нет ручного кодирования — весь прикладной код генерируется ИИ.
Минимальный бюджет — я исследовал, экспериментировал и не был достаточно уверен в результатах, чтобы вкладывать средства.
Реальный инженерный стек — без готовых end-to-end решений вроде WordPress; использование контейнеров, CI/CD, современных фреймворков.
На практике я иногда вручную правил некоторые файлы YAML, CSS, JSON. Остальное генерировалось ИИ. Я теперь настолько ленив, что даже не исправлю отступ в CSS сам — я инспектирую элемент, пробую значения в консоли, затем говорю ИИ: исправь этот отступ, он выглядит отвратительно.
Стек получился тяжёлым для портфолио.
Фронтенд: Next.js, React, TypeScript, Tailwind, Tiptap, Zustand.
Бэкенд: Node.js, Express, PostgreSQL, PgBoss, Sharp. Аутентификация: сессионная (Postgres), bcrypt, OAuth (Google, Apple, Facebook), TOTP для администратора. Безопасность: AES-256-GCM для ПИИ, слепые индексы.
Инфраструктура: Vercel (фронтенд), AWS Lightsail (бэкенд), Docker Compose], Nginx; k3s + Skaffold для локальной разработки. Почему бить муху кувалдой? Потому что я хотел полигон для обучения технологиям, которые используют мои команды на работе — включая Kubernetes, просто чтобы перестать бояться наших внутренних кластеров.
Хронология
Фаза 1: Чат-боты и инфраструктура.
Я начал с ChatGPT и Gemini. Одно я быстро обнаружил: чат-боты работают лучше, если попросить их взять у тебя интервью. «Задавай мне один вопрос за раз о системе, которую мы хотим построить, и жди моего ответа перед следующим». Это помогло прояснить, чего я на самом деле хочу. Есть обратная сторона: когда ты разрабатываешь через чат, ИИ часто продолжает задавать тебе вопросы — ещё один деталь, ещё одно уточнение. Он вытягивает контекст из тебя. Может казаться, что тебя интервьюируют, пока он не получит достаточно. Тот же паттерн, когда позже ты просишь ИИ помочь написать об этом: он продолжает вытягивать токены из тебя. Отчасти поэтому я перешёл к спецификациям — к этому мы ещё вернёмся. Вместо того чтобы вытягивать контекст по кусочку, ты даёшь его сразу. Используя этот подход мы определили архитектуру: общую форму того, что стало стеком выше — бэкенд, фронтенд, база данных, модель деплоя. Для продакшена мы рассматривали Vercel и Render. Для локальной разработки я хотел что-то ближе к тому, что используют наши команды — Docker Desktop не подошёл из-за лицензирования, поэтому я выбрал Rancher Kubernetes и DevPod. DevPod запускает среды разработки в облаке или в локальном кластере Kubernetes; я уже использовал его с ContainerLab, следуя примерам моего коллеги Roman Dodin, и подумал, что это позволит мне переносить среды между моим корпоративным Windows-ПК и личным MacBook. В тот момент около 60% этих технологий были для меня новыми.
Но чат-боты живут в облаке. Они не видят твой локальный компьютер. Каждый шаг отладки означал вставку логов в чат. Окно контекста само себя съедало. Модели начали галлюцинировать, зацикливаться, забывать. Я начал думать об ИИ как о мотивированном студенте, который уверенно соврёт, чтобы сдать экзамен. То, что было просто десять лет назад — установить XAMPP и начать кодить — теперь другая история с контейнерами и Kubernetes. Настройка инфраструктуры заняла гораздо больше времени, чем я ожидал: 2–3 недели вечерних часов. Я потратил много времени, борясь с DevPod, пытаясь получить стабильную локальную среду. В конце концов я перешёл на Skaffold, который автоматически развёртывает и очищает среду разработки. Это упростило дело. Но к тому моменту мой энтузиазм уже начал падать. Я даже на время отстранился от проекта.
Фаза 2: Gemini CLI.
Переломный момент наступил, когда я нашёл Gemini CLI. Я видел YouTube видео от Network Chuck о нём и решил попробовать. В отличие от чат-ботов, он работает локально внутри папки проекта и видит всю кодовую базу. Он может читать файлы, обновлять документацию, выполнять команды. В первый раз, когда я запустил его, я был поражён и слегка напуган — он генерировал код так быстро, что я едва успевал следить. Подготовка продакшена, которая заняла недели локально, была выполнена за пару поздних ночных сессий. Я дал ему задачу создать страницы сайта. Через несколько минут он сгенерировал набор страниц и дизайн, который выглядел более или менее приемлемо для фотопортфолио. Я был ошеломлён — я потратил столько времени на подготовку, а теперь всё готово? К счастью, нет. Gemini CLI хорошо притворялся, что задача выполнена. Большинство страниц были статическими, много fallback‑ов, функции вроде аутентификации или динамических галерей либо не были реализованы, либо работали с проблемами. Работа только началась. Но я уже мог видеть результаты. По мере роста проекта Gemini CLI начал зацикливаться, выдавать бессмыслицу, терять нить. Сессии застревали и приходилось их убивать, теряя контекст. Я понял: если у ИИ нет карты, он заведёт тебя в кювет.
Фаза 3: Разработка сначала по спецификации.
Только тогда всё пошло вперёд, когда я перестал «болтать» и начал писать структурированные спецификации. От инженерии подсказок к инженерии спецификаций. Я перешёл на Cursor и Antigravity — только что выпущенный в тот момент; наличие правил и обзора проекта в Markdown‑файлах позволило мне работать с разными ИИ‑агентами параллельно. Спецификация стала точкой сохранения — если одна модель исчерпала квоту, я мог взять спецификацию и передать её другой, чтобы продолжить. Разные модели для разных задач: Gemini Pro и Claude Opus для планирования, Claude Sonnet и Gemini Flash для кода. Мой workflow:
Описать функцию
Попросить модель предложить дизайн
Уточнить спецификацию
Сгенерировать реализацию
Тестировать
Попросить модель исправить баги
Закоммитить
Когда инструкции были расплывчатыми, модели выдавали несогласованные или неверные реализации. Типичная спецификация выглядела так:
Feature: Client gallery
- Клиенты видят водяные знаки на превью; скачивание только для одобренных изображений
- Доступ к галерее защищён токеном-приглашением
- Изображения обрабатываются асинхронно через очередь PgBoss
...
После этого я просил модель предложить архитектуру и реализацию. Спецификация дала ей карту вместо вытягивания контекста по кусочку. Самой сложной частью было не кодирование. Это было чёткое объяснение того, чего я хочу. В какой‑то момент я напомнил себе то, что уже знал — и как менеджер должен был знать: независимо от того, работаешь ли ты с ИИ или с экспертом‑инженером, точная спецификация обязательна. Это осознание само по себе стоило эксперимента.
Когда реальность встретилась с продакшеном
Мы запустили сайт на Vercel и Render, как рекомендовал ИИ. Сайт работал. Затем произошёл первый redeploy — я обновил страницу, и каждое изображение исчезло.
У бесплатного плана Render эфемерная файловая система — загруженные файлы не сохраняются между redeploy‑ами. ИИ об этом не знал. Gemini CLI полностью не осознавал этого ограничения. Когда я спросил, почему изображения исчезли, предоставив логи отладки, он упорно настаивал, что проблема в чём‑то другом — провайдере email, конфигурации — смешивая разные потоки отладки. Он был упорён часами. Мне пришлось самому поискать в Google, обнаружить эфемерную файловую систему и перенести бэкенд на AWS. Это привело к полной перенастройке конфигурации. Это был один из моментов, когда я понял, что нельзя просто поболтать и получить надёжную продакшен‑систему.
Адский мердж. В какой‑то момент Gemini CLI пошёл вразнос, изменил кучу кода, сделал плохой неподтверждённый мердж — и неудачный откат стёр дни прогресса. Моя вина — я недостаточно часто коммитил. Я просил ИИ фиксировать всё в обзоре проекта, также обновляя Technical Debt и Resolved Issues; в какой‑то момент он переписал этот файл тоже, и история была потеряна. Нельзя слишком много делегировать ИИ.
Тёмная сторона
Разработка с ИИ может вызывать зависимость — как проигрыш в казино. Ещё один промпт, и ты отыграешься. Вдруг уже 3:00 ночи, ты кричишь на экран и бьёшь по клавиатуре. Это нездорово. ИИ создаёт иллюзию человека за экраном, но эмоциональные промпты лишь расширяют окно контекста и отдаляют тебя от решения. Когда ты в затруднении, лучше подвести итог, сохранить логи и начать новую сессию или запустить нового агента, отложив эмоции в сторону.
Можно построить сложные системы быстрее, чем ты действительно их понимаешь.
Это один из главных рисков ИИ‑ассистированной разработки. Иногда модели переписывали части, которых я их не просил трогать; если я не проверял внимательно, целые секции могли уйти в сторону. По мере роста кодовой базы отладка становится сложной, если ты сам не писал код. Также сложно сохранять фокус — идеи появляются, ты начинаешь реализовывать их параллельно. Я начал просить ИИ сохранять заметки в отдельный набор файлов, чтобы ничего не потерялось.
Одним из того, что меня параноило, были секреты. Нужно .gitignore для себя, но ИИ‑агентам нужен свой. Ключи и пароли должны находиться вне репозитория. Может быть довольно хитро вытащить их из сессий, даже декодировать. Во время отладки ИИ часто находил путь попросить у тебя доступ — посреди ночи ты иногда нажимаешь согласиться. Лучше использовать временные ключи для ИИ и держать продакшн‑секреты изолированно.
Визитка‑сайт. Что получилось
Не простое портфолио. Небольшая система для фотобизнеса: портфолио, управление клиентами, запись на приём, частные галереи, доставка. Собственная блок‑базовая CMS с drag‑and‑drop конструктором страниц. WYSIWYG‑редактор текста. Безопасные клиентские галереи с водяными знаками на превью и высококачественной доставкой. Клиенты могут записаться через Email, Instagram, WhatsApp, Telegram. Для офлайн‑лидов — скажем, фотограф встретил кого‑то на свадьбе — система создаёт теневые профили и генерирует ссылки‑приглашения, чтобы они могли зарегистрироваться и позже получить доступ к своим галереям. PgBoss обрабатывает асинхронную обработку изображений: водяные знаки, генерация превью, массовый импорт из Google Drive. Мультиязычность (EN, RU, NL) с региональными ценами. Рабочий процесс: клиент бронирует или администратор создаёт запись; если новый — теневой профиль и ссылка‑приглашение; администратор утверждает, съёмка происходит, администратор отмечает завершённое; клиент выбирает из водяных знаков превью или фотограф загружает окончательные файлы напрямую; когда клиент принимает, запись закрывается. На сайте сейчас размещено 260 изображений, 4 галереи, 16 страниц на трёх языках. Трафик пока мал. Но система работает.
Что я узнал
ИИ отлично подходит для scaffolding и boilerplate, плох для архитектуры и долгосрочной согласованности. ИИ редко тебя оспаривает. Обычно он просто делает именно то, что ты просишь — даже если это плохая идея. Когда он терпит неудачу, часто слишком быстро переходит к shortcut вместо поиска правильного решения.
Инженерия спецификаций побеждает инженерия подсказок.
Можно строить системы быстрее, чем ты их понимаешь. Дисциплина контроля версий становится критически важной очень быстро.
ИИ не заменяет инженерное суждение — он усиливает те дисциплины, что у тебя уже есть. Хорошие качества проявляются лучше; плохие производят спагетти код быстрее.
Я не выучил React внезапно и не стал разработчиком. Но я получил гораздо более чёткое представление о том, как соединяются современные стек — контейнеры, CI/CD, фреймворки. Теперь я не так потерян в дискуссиях с инженерными командами. Реальная выгода: до этого проекта я никогда не делал коммит. Теперь я уверенно настраиваю CI/CD пайплайны на работе. Я уже применяю это — скрипты Power Automate, парсеры JSON, внутренние RAG‑приложения. Я перестал быть «менеджером, который говорит об ИИ» и стал тем, кто строит с его помощью.
Я бы не продал эту систему клиенту. Я не разработчик. Аутентификация, шифрование и потоки данных были реализованы ИИ под моим надзором, но я не инженер по безопасности. На сайте могут быть уязвимости, которых я просто не вижу. Но как эксперимент он был успешным.
Если бы я начал снова, я бы пропустил чат‑часть, начал с спецификаций для общей архитектуры и отдельно для каждой функции, использовал агентный подход — назначая разные задачи разным моделям — и коммитил гораздо чаще.
Вывод
Я всё ещё пробую новые инструменты и подходы. Экспериментировал с локально размещёнными LLM через LM Studio и Ollama, подключив их к VSCode через Continue. Я слежу за OpenClaw но осторожен в установке — самодельные агенты с глубоким системным доступом меня нервируют. ИИ движется быстрее, чем когда‑либо, новые инструменты и модели появляются почти каждую неделю, и ты постоянно решаешь, что использовать, пока почва уходит из‑под ног.
Андрей Дороничев однажды сравнил ИИ с электричеством — ты можешь взять интеллект из сети так же, как берёшь электроэнергию. Мне это нравится. Это также означает, что мы можем ослабеть, если перестанем использовать свои мозги в пользу «заимствованного интеллекта». То же самое, что электричество может навредить, если ты не знаешь, как им пользоваться. Не имеет смысла игнорировать его или бояться, что оно заменит тебя. Найди свой путь ехать на волне, а не получать удар от неё. ИИ не заменит нас ни в какой профессии. Но эксперт, использующий ИИ, заменит того, кто не использует. Эксперимент ответил на вопрос: насколько далеко можно зайти, создавая реальное ПО с помощью ИИ? Далеко, чем я ожидал — но не без рисков. И если ты всё равно собираешься переразрабатывать фотосайт, то можешь пойти до конца. Следующие планы? Я хотел бы расширить функциональность сайта и изучить виртуальную фотостудию — уже тестирую ComfyUI, модели диффузии и workflows генерации изображений. Хотел бы попробовать разработку мобильных приложений, чем ранее занимался. И, конечно, есть множество возможностей применить эти навыки на моей основной работе. Я стараюсь держать идеи под контролем — слишком легко потерять фокус из‑за бесконечных возможностей, которые предлагает ИИ.