Как создавался Norepo: от «стрелки вверх» в чате до флота агентов
Norepo родился не из красивой идеи, а из тупой рутины: жмёшь стрелку вверх, Enter, «продолжай работать» — и по кругу. История со-создателя о том, как инструмент для себя стал платформой.
Редакция Operon, Команда ·
Norepo родился не из красивой идеи и даже не из «боли» в привычном смысле. Он родился из тупой рутины. Claude уже неплохо писал код, но работа с ним превращалась в бесконечный цикл: жмёшь стрелку вверх, Enter, отправляешь «продолжай работать» — и так по кругу. Не хватало структуры, и никак не удавалось объяснить ИИ контекст всего проекта целиком. Из этого раздражения и вырос инструмент, который сегодня называется Operon. Мы поговорили с его со-создателем Сашей Шиновым о том, как это было на самом деле — без глянца.
Не «переехать на ИИ», а быть готовым к нему
Первая мысль, из которой всё пошло, звучала так: современная разработка должна не «переехать на ИИ», а быть готовой переехать. «Мы называем это AI-friendly-проектами — когда код изначально структурирован так, чтобы ИИ мог полностью понять контекст», — объясняет Шинов.
Следующим шагом появилась первая версия Operon. Проверка вышла показательной: на ней за неделю с нуля пересобрали большой продукт — и полностью выкинули предыдущую версию с горой легаси. После этого команда стала делать через Operon вообще всё, и довольно быстро возникла мысль, что инструмент применим куда шире, чем внутри одной команды.
Две идеи, один продукт
Norepo вырос из двух разных идей. Одна — Кирилла: сегодня можно и нужно делать ИИ-версию каждого специалиста, будь то менеджер, SEO-специалист, тестировщик или разработчик. Вторая — Саши, уже и конкретнее: инструмент, который реализует текущие проекты быстрее и дешевле и стирает границу между бизнесом и разработкой. Прямой канал между идеей и её воплощением.
Первая версия была почти кустарной — банальный канал общения Claude Code с Кириллом через чат в Telegram. Работал на ноутбуке, не круглосуточно, совсем не идеально. Шаг за шагом он рос и в итоге превратился в систему, которая делает то, что хочет предприниматель, — без участия разработчиков и без установки Claude Code на устройство пользователя.
Тогда роли и распределились. Кирилл взял на себя продукт: давал ТЗ, предлагал фичи, стал продуктологом. Саша решал технические задачи и без конца переписывал промпты. Тарифную сетку и экономику считали и обсуждали вместе — и, по словам Шинова, не перестают. «Сегодня нет конкурентоспособных продуктов, которые сделали один раз, зафиксировали и остановились, чтобы дальше только продавать», — говорит он.
Почему доска, а не билдер
Когда встал вопрос формы, соблазн сделать «конструктор сайтов» был, но команда сознательно пошла другим путём. «Это то, как работают серьёзные живые команды, — говорит Шинов. — Operon делает то, на что компании иногда сливают миллионы долларов в год и над чем трудятся тысячи людей».
Ключевая идея была не в том, чтобы сделать ещё один инструмент для разработчика — таких много. Идея была дать предпринимателю канал: взять его экспертизу и идею, дать инфраструктуру и мощности и превратить это в работающий продукт без найма и без попыток разобраться в программировании. «Вы просто общаетесь с Operon и получаете результат — как если бы общались с менеджером, который сам разберётся, кто в команде какую работу выполнит», — описывает Шинов. Поэтому агенты и работают через ветки и pull request с обязательным ревью: это не поза, а то, как устроены современные команды — хоть с Operon, хоть без него. Что вообще такое агент, который берёт задачу и доводит до PR, разбирали отдельно: что такое AI-агент-разработчик.
Claude как мозги, но не как замок
Внутри Operon стоит Claude — и это осознанный выбор, но не пожизненная привязка. «По факту Claude — это просто мозги нашей разработки, вокруг него построена большая система, и его можно заменить на другие решения, если понадобится. Но сегодня никто не пишет код лучше моделей Anthropic», — говорит Шинов, оговариваясь, что это его оценка.
Отсюда же вытекает архитектура с контейнерами: держать всё в одном контейнере на одной подписке нельзя — пользователи должны быть изолированы друг от друга. Так что «мозги» одни, а рабочие пространства у всех свои.
Что пришлось переделывать
Первый вариант продукта был устроен иначе, чем сегодня: большое ТЗ нарезалось планировщиком на этапы и выполнялось одной длинной сессией за раз. «Это подходило только для старта, и то не идеально, — вспоминает Шинов. — Мы довольно быстро ушли в атомарные задачи и планирование через доску».
Самый показательный разворот — история с онбордингом. Сначала хотели дать пользователю ставить решателя задач на своё устройство и сделали сложный подробный онбординг. Практика убила эту идею: для не-программиста установка занимала часа два, и то под присмотром. В итоге от подхода отказались полностью — теперь всё работает целиком на инфраструктуре Operon. «Ошибок было невероятно много, каждый день, их все невозможно вспомнить, — честно говорит Шинов. — Мы просто пользовались инструментом и продолжаем, он меняется ежедневно».
Самое трудное — ревьюер
На вопрос о самой сложной технической задаче Шинов отвечает без пафоса: тестировщик-ревьюер. «Это до сих пор не до конца решённая задача — во многом потому, что я очень хочу сделать его действительно качественно».
Здесь он вспоминает своего преподавателя по программированию: «Нужно быть в два раза умнее, чтобы найти все ошибки в коде и исправить их, чем чтобы просто написать этот код, — поэтому никогда не пиши код на пределе ума». В шутке было зерно правды, и на ревьюере оно проявляется в полный рост. Почему приёмка вообще становится главным узким местом агентской разработки, разбирали отдельно: чек-лист ревью работы AI-агента.
Итеративность и честный шторм
Глянцевой истории «придумали и сразу получилось» здесь нет. «Практически ничего не получалось с первого раза — всё выходило со второго или десятого, — говорит Шинов. — И то, что было хорошо вчера, плохо сегодня. Чаще всего переделываются промпты для постановки и решения задач».
На вопрос, был ли момент, когда казалось, что не взлетит, он отвечает честно: «Я как на волнах с этим продуктом — моё мнение по этому поводу буквально штормит». Это, пожалуй, и есть самая правдивая характеристика того, как делается живой продукт.
Момент, когда сказали «этим будут пользоваться другие»
Точка, после которой Operon перестал быть внутренним инструментом, оказалась прозаичной. «Когда начали подключать первых тестовых пользователей, пришлось выявить и поправить массу вещей, — говорит Шинов. — А "этим будут пользоваться другие" мы сказали ровно тогда, когда прикрутили платёжку».
Отдельная особенность — dogfooding: команда делает Operon с помощью самого Operon. «Быть разработчиком инструмента, которым пользуешься, очень удобно: берёшь и исправляешь его, если нужно. Самое опасное тут — забывать, что у других пользователей такой опции нет». А ещё изменился темп: после того как Claude Code плотно вошёл в работу, задач стало не меньше, а на порядок больше. «Самое сложное — держать всё это в фокусе и делать параллельно всё сразу».
Что впереди
Планы Шинов формулирует сдержанно и по делу: довести ревьюера-тестировщика и постепенно покрыть все роли, «чтобы Operon'у не был нужен никто, кроме автора продукта». Горизонт при этом не фиксируют жёстко — его будут определять опыт пользователей и их запросы. «Будем опираться на данные». Как выглядит старт проекта на платформе с точки зрения пользователя — в гайде с чего начинать проект в Norepo.
Что в итоге
- Norepo вырос не из красивой идеи, а из рутины работы с ИИ и желания дать ей структуру.
- Продукт собрали две идеи — «ИИ-версия каждого специалиста» и «прямой канал от идеи к реализации».
- Форму выбрали не как у билдера, а как у живой команды: доска, агенты, ветки, pull request, ревью.
- Самое трудное — ревьюер; самое честное — что продукт меняется ежедневно и делается итерациями.
Начать бесплатно: 2 задачи в неделю, без карты — norepo.ai. Как это устроено для основателя — на странице для основателей.