В далеком 2013 году я опубликовал здесь статью "С камерой в облака". Она собрала 250 тыс. просмотров и, надеюсь, принесла реальную пользу.
К сожалению, так и не дописал тогда 3-ю часть, но сегодня возвращаюсь с похожим опытом, правда из совершенно другой отрасли.
Кому будет полезна эта статья?
Основателям, которые привыкли опираться на свои команды разработки, но текущие мощности/бюджеты отложили некоторые проекты в долгий ящик
Новичкам, которые не чувствуют сил закодить первую версию своего продукта, и нет бюджета, чтобы заплатить разработчикам
Стартапам, которые застряли в привлечении раунда на разработку прототипа или MVP
В чем уникальность материала?
Я не являюсь программистом и ориентируюсь на читателя, не обладающего специальными знаниями (хотя технический склад ума вам определенно тут понадобится).
За 6 месяцев я прошел путь создания продукта без программирования до конца, построив 2 полноценных сервиса. Понятно, что за это время моё понимание кода существенно выросло.
Каждый из созданных сервисов, это 30 - 40 таблиц в БД, 50 компонентов, около 100 тыс. строк кода. То есть, это не демо-версии или проекты "за выходные".
В первом сервисе реализована интеграция с OpenAI для "осмысления" пользовательского контента. Для этого используются векторная база данных, эмбеддинги и действия с ними.
Во втором сервисе реализована внутренняя система счетов с двойными проводками, идемпотентностью и подключена платежка для приема онлайн-оплат.
Я не описываю здесь некий магический способ создать решение, не погружаясь в код вообще, но этот материал делает возможным создание продукта без предварительного изучения языков программирования. То есть, вам придется смотреть в код, даже править его иногда вручную и контроллировать, но вы сможете это.
Кому не зайдёт?
Вы просто листаете из любопытства
Имеете принциапиальные позиции (типа "против ИИ" или вайбкодинга и т.п.)
Вы можете и сами закодить продукт (ощущаете, что вы "в другом лагере")
Вам кажется сложным сделать платежную карту, использовать VPN и т.п. (материал все же для тех, кому действительно нужен результат)
Предисловие
Сейчас популярна идея полностью автоматической разработки: описать продукт текстом и получить готовое приложение. Сервисы вроде Bolt.new или Lovable иногда действительно могут собрать простой прототип.
Но когда речь идёт о продукте для проверки реальных гипотез, мы хотим, чтобы все было на высоком уровне: UI/UX, скорость работы, кэширование, масштабирование и возможность подключения реальных разработчиков к этому коду вдальнейшем.
По моему опыту, даже сильные модели вроде Opus хорошо справляются с backend-логикой и структурой базы данных, но заметно хуже с frontend-архитектурой. Они часто создают лишний код, плохо разбивают систему на компоненты и игнорируют вопросы производительности на стороне клиента.
Поэтому я не использую полностью автоматические генераторы, ведь магии никакой нет - если даже Opus внутри моего Курсора запутывает фронтэнд, то же будет происходить и в любом другом продукте, использующем LLM.
В этой серии применяется другой подход: IDE со встроенными ИИ-агентами. ИИ помогает писать код и планировать задачи, но архитектуру и ключевые решения контролирует человек.
Почему я выбрал именно Курсор? Просто прочитал, что он построен на базе популярного решения VS Code. Подумал, что это хороший варинат. Не думаю, что Antigravity хуже, плюс минус будет то же самое, так как качество решения здесь определяется именно используемой моделью, а сам редактор - просто оболочка, дающая модели доступ к файлам проекта и вашему окружению.
Введение
История началась летом 2025 года, когда я обсуждал с DeepSeek идею, не покидающую меня 10 лет: социальную сеть предпочтений, где пользователи получают рекомендации на основе совпадения личных рейтингов (рестораны, отели, страны, хобби, и всё на свете). И, вдруг, он сказал:
Давай сделаем это. Лучше использовать next.js.
Через 3 месяца я презентовал продукт топ-менеджменту одной корпорации, причем они меня сами попросили. И ведь, несмотря на 20 лет опыта в ИТ как основателя, у меня такого никогда не было. А недавно я довел до запуска еще один проект, лежавший в папке годами (считал реализацию сложной и дорогой, а тему довольно рискованной, чтобы вкладывать в это деньги).
В этой серии я соберу весь полученный опыт, реальные промпты, настройки и подводные камни. Но прежде чем двигаться дальше, нужно ответить на самый важный вопрос:
А стоит ли вам вообще это пробовать?
Кратко - да, если вы ориентируетесь в этих понятиях:
frontend
backend
базы данных
HTML
CSS
JavaScript
базовые концепции React
Базовое понимание есть? Переходите к следующей части.
Если эти термины звучат незнакомо, лучше разобраться сейчас. То, что увидите ниже, не покажется вам чем-то типа листания рилсов, но взвесьте - мне этот путь сэкономил около 30 млн. рублей и пару лет разработки, работы с подрядчиками, набора команды.
Навигация:
Frontend и Backend
Frontend — это часть вашего сервиса, которую видит пользователь:
сайт в браузере
мобильное приложение
браузерное расширение
любой интерфейс, где пользователь нажимает кнопки или читает информацию
Backend — это часть вашего сервиса, которая остается работать на серверах где-то в интернете.
Он отвечает за:
обработку данных
авторизацию пользователей
работу с базой данных
Когда пользователь нажимает кнопку, frontend отправляет запрос backend-у. Backend обрабатывает запрос и возвращает ответ.
Это взаимодействие выглядит примерно так:
Пользователь → Frontend → Backend → База данных → Backend → Frontend → Пользователь
На практике frontend взаимодействует с backend через API-маршруты (API routes, "руты"): специальные URL-адреса, к которым отправляются запросы:
/api/articles /api/login /api/create-article
Когда frontend обращается к такому адресу, сервер выполняет нужный код:
проверяет пользователя
обращается к базе данных
обрабатывает данные
и возвращает результат.
Например, frontend может отправить запрос:
GET /api/articles?author_id=535
Backend принимает этот запрос, получает статьи пользователя №535 из базы данных и возвращает их обратно frontend-у.
Что такое база данных
База данных хранит информацию, с которой работает приложение. Принцип очень похож на Excel или Google Sheets. База данных — это как файл с таблицами. Каждая таблица — лист в этом файле.
Например:
Таблица Пользователи
id | name | |
1 | Алиса | alice@email.com |
2 | Борис | boris@email.com |
Таблица Статьи
id | user_id | title |
1 | 1 | Статья Алисы 1 |
2 | 1 | Статья Алисы 2 |
3 | 2 | Статья Бориса |
В этом примере каждый пользователь может создавать много статей.
Такая простая структура связанных таблиц лежит в основе большинства систем. В вашем сервисе может быть 30 - 50 таблиц, даже если сейчас вам кажется, что их будет три.
В реальности все немного сложнее, есть индексы, ключи, права доступа, но ИИ это настроит сам, причем довольно неплохо. Абсолютное большинство проблем в коде, как я говорил, связаны со фронтэндом.
HTML — структура страницы
HTML определяет, что именно находится на странице:
заголовки
текст
кнопки
изображения
контейнеры
Пример:
<div> <h1>Привет</h1> <p>Это параграф</p> </div>
HTML-элементы образуют вложенную структуру, которая называется DOM.
div ├── h1 └── p
Любая веб-страница в браузере — это по сути большое дерево элементов.
CSS — как всё выглядит
Если HTML отвечает за структуру, то CSS отвечает за внешний вид.
Он определяет:
цвета
шрифты
отступы
расположение элементов
Пример:
/* CSS класс для стиля заголовка */ .title { color: blue; font-size: 32px; }
Применяется так:
<!-- HTML заголовок, использующий CSS класс выше --> <h1 class="title">Привет</h1>
Несколько классов CSS
В CSS один элемент может иметь несколько классов:
<!-- кнопка с несколькими классами --> <button class="button button-primary button-large"> Отправить </button>
Каждый класс отвечает за свою часть оформления.
/* радиус скругления углов кнопки */ .button { border-radius: 6px; } /* цвет надписи и фона */ .button-primary { background: blue; color: white; } /* размер кнопки (отсутпы от текста до границ) */ .button-large { padding: 16px 24px; }
Это гибко, но в больших проектах стили могут начать запутываться. Поэтому многие современные проекты используют Tailwind CSS.
Tailwind
Здесь вместо больших CSS-файлов используются готовые utility-классы:
<button class="bg-blue-500 text-white px-6 py-3 rounded-lg"> Submit </button> <!-- bg-blue-500 = синий фон --> <!-- text-white = белый текст --> <!-- px-6 = горизонтальный отступ --> <!-- py-3 = вертикальный отступ --> <!-- rounded-lg = сильно скругленные углы -->
Каждый класс — это маленькое правило.
Интересно, что AI-инструменты вроде Cursor обычно гораздо лучше генерируют интерфейсы именно с Tailwind, чем с обычным CSS.
Если явно не указать Cursor использовать Tailwind, он может начать вставлять стили прямо внутрь элементов:
<!-- намертво встроенный в кнопку стиль --> <button style="background: blue; padding: 12px;">
Сначала это будет у вас работать. Но позже становится неудобно — любое изменение дизайна требует правки сотен мест в коде. А с CSS-классами можно изменить дизайн всего приложения, поменяв всего несколько общих стилей.
JavaScript и TypeScript
HTML определяет структуру страницы. CSS определяет как она выглядит. А JavaScript определяет поведение.
JavaScript позволяет интерфейсу реагировать на действия пользователя.
// когда пользователь нажимает кнопку, показываем сообщение button.addEventListener("click", () => { alert("Hello!"); });
TypeScript — это, по сути, JavaScript с дополнительной системой типов.
JavaScript:
// простая функция, которая складывает два числа function add(a, b) { return a + b; }
TypeScript:
// та же функция, но с явными типами // a и b должны быть числами // функция возвращает число function add(a: number, b: number): number { return a + b; }
Большинство современных приложений используют TypeScript, потому что он предотвращает множество ошибок в крупных системах.
Почему мы будем использовать Next.js
В остальной части этой серии мы будем создавать примерное приложение с помощью Next.js. Next.js — это фреймворк, построенный поверх React. React сосредоточен на создании пользовательских интерфейсов. Next.js добавляет такие вещи, как:
маршрутизация (routing)
серверный рендеринг
API-эндпоинты
структуру проекта
инструменты сборки
Вам не обязательно глубоко понимать внутреннее устройство Next.js. Но полезно понимать, как устроены React-приложения. К счастью, основные идеи очень просты. Нужно понять всего три вещи:
components
props
hooks
React-компоненты
React-приложения строятся из компонентов. Компонент — это переиспользуемая часть интерфейса.
Напри��ер:
кнопки
навигационные панели
блоки комментариев
модальные окна
Пример компонента:
// простой React-компонент // он отображает кнопку function Button() { return <button>Click me</button> }
Теперь его можно использовать где угодно:
<Button /> <Button /> <Button />
Крупные приложения превращаются в деревья компонентов, вложенных друг в друга.
Props
Props — это входные параметры, которые передаются в компонент:
// простой компонент кнопки // он показывает текст, переданный в props.label function Button(props) { return <button>{props.label}</button> }
Использование:
// один и тот же компонент можно использовать с разными текстами <Button label="Save" /> <Button label="Delete" /> <Button label="Cancel" />
Hooks
Hooks позволяют компонентам хранить состояние и реагировать на действия пользователя.
Пример:
// useState создаёт состояние внутри компонента // "count" хранит текущее значение // "setCount" — функция для его изменения const [count, setCount] = useState(0)
Теперь компонент может изменять своё внутреннее состояние.
// при нажатии кнопки счётчик увеличивается на 1 // текст автоматически обновляется <button onClick={() => setCount(count + 1)}> Clicked {count} times </button>
Хуки делают компоненты интерактивными.
Резюме
Если вы никогда раньше не сталкивались с этим, я понимаю ваше чувство.
Но вам не нужно осваивать вс�� это на уровне профи. Нужно лишь понять сам принцип. Если у вас техническое мышление, и вы способны уловить эти идеи, путь становится гораздо проще.
Вместо того чтобы случайно просить AI что-то сгенерировать, вы сможете направлять его правильно. А это огромная разница.
Перед тем, как перейти ко второй части
Убедитесь, что вы примерно понимаете:
разницу между frontend и backend
базы данных как набор таблиц
структуру HTML
CSS-классы и стили
поведение JavaScript
React-компоненты, props и hooks
Что дальше?
Во второй части этой серии мы перейдём от теории к практике. Но прежде чем писать код, нужно принять ряд важных решений.
Как именно мы будем строить систему?
какие инструменты использовать
какая архитектура лучше работает с AI-разработкой
какие решения могут создать проблемы в будущем
Вперед, на следующий уровень погружения