Как быстро пролетели шесть месяцев! Продолжаю рассказывать о том, как решил сделать пет-проект: НормЦРМ. Сам я ремесленник-одиночка и пользовался ограниченным набором инструментов для ведения дел: Google Таблицы, да Windows-заметки. Решил все эти данные свести воедино в рамках собственной црмки.
Я не разработчик, а проектировщик интерфейсов (UX/UI-дизайнер). Опыта в программировании совсем немного. Поэтому пет-проект был мне особенно интересен. Я уже двадцать лет готовлю проектную документацию для других — а в этот раз для себя.
Сейчас расскажу, что сделал по проекту за последние полгода, как мне в этом помогли ChatGPT и Codex, как изменился процесс работы и почему это поначалу было скучно и грустно — а теперь с каждым днём жизни проекта всё интереснее и веселее.
Введение
В конце июля 2025 я рассказал Хабру о том, как спроектировал и завайбкодил первую версию проекта.
Сегодня «ЦРМ нормального фрилансера» называется «Норм ЦРМ», потому что у людей очень разное представление о том, кто такие фрилансеры, а проект подойдёт и самозанятым, и предпринимателям, и тем, кто хотел бы привести свои дела в порядок, работая на нескольких работах сразу.
Можно сказать, что сейчас это система управления клиентами, проектами и задачами. А до воронок и действительно црм-ной части я до сих пор не добрался.
Codex
Я попробовал Codex (Кодекс). Это нейронка от OpenAI. Она даётся впридачу к платной подписке ChatGPT Plus за 20 баксов в месяц (именно поэтому я и не пробовал других нейронок, а сразу остановился на этой). И она предназначена для программирования. Отличие Кодекса от ЧатаГПТ в том, что первый смотрит в репозиторий моего проекта.
О, как это меня ускорило! Если раньше я для разработки каждой небольшой функции скидывал ЧатуГПТ несколько страниц кода для контекста, то теперь я могу ставить задачи таким же языком, каким ставлю их живым разработчикам.
Мой обновлённый рабочий процесс
Сначала пара слов об общих моментах. У меня в работе постоянно находится два списка задач. Первый — это исправление ошибок и рефакторинг (когда я оптимизирую уже существующий код). Тут работа простая: попользовался проектом, увидел, что что-то не так (что-то неудобно или работает не так, как задумано) — сделал несколько мелких правок и двигаешься дальше.
Второй список задач — внедрение новых разделов и функций. Тут уже работа по полному циклу: проектирование, разработка, тестирование, доработки, перевод, релиз.
Расскажу о рабочем процессе в рамках именно второго списка задач.
Планирование и учёт времени. Ещё в начале рабочего дня я захожу в НормЦРМ, открываю раздел «Мой день» и добавляю туда задачи, на которых хотел бы сфокусироваться. Работа над пет-проектом у меня ведётся в свободное от основной работы время, поэтому список задач на день смешанный.
Возьму реальный пример. Одна из моих текущих задач — «Проектирование и разработка загрузки файлов в НормЦРМ». Я её добавляю в проект «НормЦРМ», указываю предполагаемое время на выполнение (допустим, 5 часов).
Когда приступаю к задаче — запускаю тайм-трекер в НормЦРМ — и начинаю работу. После того, как я завёл такую привычку — могу видеть, как часто ошибаюсь в прогнозах на выполнение задач (сверяя результат по тайм-трекеру с запланированным временем), а также сколько времени на работу уходит в среднем каждый день.
Проектирование. Тут ничего не поменялось. Я всё так же открываю Axure, делаю интерактивный прототип, прорабатываю все состояния для всех элементов во всех сценариях и смотрю, как это выглядит.
Все эти месяцы я поддерживаю прототип в актуальном состоянии и до сих пор не представляю, как можно заниматься разработкой без проектирования.
Честно признаюсь: в последние полгода подзабил на документ с функциональной спецификацией. Но понимаю, что в будущем мне это аукнется, поэтому держу в планах задачу по актуализации.
Все важные моменты, которые не отобразить в прототипе, я фиксирую там же в виде заметок на жёлтых «стикерах».
Постановка задачи на разработку в Codex. Описываю Кодексу, что нужно сделать. Описание состоит из трёх логических частей.
Введение в контекст на уровне смыслов. Например: «Среди моих клиентов много компаний с большим количеством сотрудников. В рамках наших совместных проектов эти сотрудники играют разные роли. Я хочу иметь возможность вести каталог контрагентов (юрлиц, ИП, самозанятых) и указывать их сотрудников в качестве участников проектов с той или другой стороны».
Описание функций и разделов к реализации. Эта часть мало чем отличается от содержания моих функциональных спецификаций. Я перечисляю разделы, их содержимое и все нюансы, связанные с ними.
Здесь важно не называть одни и те же разделы и функции разными именами, а также не лениться и предоставлять как можно больше контекста для повышения точности постановки задачи.
Помню, был советский комикс про Бертрама Компостера, где котик просил профессора почистить картошку. А профессор отыгрывал роль глупого робота, брал тряпочку и чистил картошку до тех пор, пока котик не научился просить брать нож в правую руку, картошку в левую и дальше по алгоритму.Уточнения, связанные с генерацией результата. Я часто забываю это сделать — и потом получаю файлы миграций там, где они мне не нужны. Или файлы переводов. Или скрипты и модальные окна вне инклюдов. А можно добавить в конце: «Миграции я буду делать через терминал на деве, поэтому не нужно их готовить. Переводы тоже. Не забудь, что мы стараемся не хранить любые потенциально сквозные элементы внутри основных шаблонов, а создаём для них новые (иконки, модальные окна и т.п.)»
Промпты иногда получаются внушительных размеров. И тут мне ну очень помогает навык слепой печати. При скорости в 400—500 символов в минуту постановка задачи кажется не такой мучительной (впрочем равно как и написание подобных статей).
Ожидание, пока Codex выполнит работу. После того, как я сформулировал задачу и отправил её Кодексу — он начинает думать. Как я уже говорил, он смотрит в репозиторий проекта на Гитхабе, поэтому мне не нужно показывать ему никакого кода вручную. Сначала он выкачивает из репозитория код, затем разворачивает его где-то у себя, затем приступает к работе.
В зависимости от сложности задачи он может думать от пары минут до пары десятков минут. Пока что самое большое количество строк кода, которое я получал от него на выходе, не превышало 1600, а время на размышления — 22 минуты.
В 2026 году 20 минут — это очень долго. Поэтому у меня всегда есть пул задач, которыми я могу заниматься во время ожидания. В основном, вношу правки и доработки в интерактивный прототип в Axure. Теоретически я также мог бы работать над актуализацией функциональной спецификации, но вот пока всё никак.
Анализ результата работы Codex. В итоге получаю сообщение от Кодекса на русском или английском языке (никогда не предугадаешь), что именно было сделано по моей задаче, а также перечень файлов, в которые были внесены изменения.
Слева вижу диффы — изменения в код по сравнению со старыми версиями.
Я пробегаюсь глазами по каждому файлу и по каждой строчке с изменениями, чтобы понять, как именно Codex реализовал тот или иной функционал.
Сначала смотрю на модель, затем на вьюхи и в конце на код шаблонов и стилей.
Несмотря на то, что самому написать такой код было бы трудно и долго, его чтение мне даётся легко. Если это что-то на питоне — я считываю всё на 90%. Если html/css — на 100%. А вот с js уже сложнее. Некоторые скрипты занимают сотни строк, понимаю я их процентов на 60-70 и могу что-то пропустить, доверившись нейронке.
Корректировка результата работы Codex. Обычно я сразу вижу, если что-то сделано не так. Тут бывало всякое. Изредка вместо создания полностью рабочей функции, Кодекс выдаёт только фронтовую часть с шаблонами и стилями. Тогда отправляю ему вдогонку промпт: «Мне нужно сделать работающую функцию, а не только фронт». И после этого он доводит дело до конца.
Иногда замечаю, что в шаблон вставлено огромное количество кода, который можно было бы вынести в инклюд, и прошу его попра��ить это.
А иногда, совсем редко, вижу, что Codex просто забил на какую-то мою просьбу и не выполнил тот или иной пункт из поставленной задачи. Ну совсем как реальный сотрудник!
Кстати, забавное. Я ведь вижу его рассуждения в процессе работы. И вот там мелькает текст наподобие: «Сказать пользователю, что ошибку, о которой он пишет, исправить невозможно и требуется дополнительное расследование». А потом, в итоговом сообщении он просто опускает эту часть и ничего мне не говорит.
Обычно после корректирующего промпта Кодекс думает поменьше и со второй попытки уже выдаёт нужный результат.
Перенос результата в dev и локальное тестирование. И тут не надо надо мной смеяться. Мой dev (окружение, в которой я занимаюсь разработкой и тестированием проекта до его релиза на боевой сервер) — это мой компьютер. В репозитории есть только одна ветка — main. И я ни разу не пользовался функцией отправки диффов Кодексом сразу в гит.
Я открываю диффы в интерфейсе Кодекса и построчно, ручками, переношу их к себе в IDE. Это мне помогает досконально разбираться в получившемся коде и, если я чего-то не понимаю, задавать уточняющие вопросы ChatGPT. Сейчас мне это нужно всё меньше, но когда я переношу код к себе именно таким способом — у меня возникает ощущение контроля.
Посмотрим, что изменится через полгода, но пока так.
На деве я сначала обновляю файл модели (если в эту итерацию он обновляется), затем создаю и применяю миграции через терминал. После этого уже обновляю или добавляю вьюхи, шаблоны и стили.
Тут же смотрю, как это выглядит в браузере, и создаю заметки, связанные с дальнейшими улучшениями и исправлениями ошибок.
И тут проявляется неудобство моего подхода, которое я не исправляю просто потому, что оно не достаточно большое. Если в процессе переноса вижу, что Кодекс где-то сильно накосячил, то мне нужно делать ещё один корректирующий промпт. И результате этого промпта я получу новую пачку диффов, которые сравниваются с репозиторием, а не девом.
Тут-то мне бы и придумать отдельную тестовую ветку для Кодекса, но я пока обхожусь без этого. Просто в конце корректирующего промпта прошу отдельно: «Перечисли, пожалуйста, файлы, в которые ты внесёшь изменения в результате этой правки».
Деплой. У меня всё тот же деплой, который я настроил более полугода назад. Отправил в гит — а оттуда всё автоматически разворачивается на сервере.
Здесь скажу только, что, пока в проекте мало пользователей, я довольно смело выкатываю сырые обновления, тестирую их прямо на проде, а затем повторяю весь цикл с Кодексом для того, чтобы причесать результат.
Обычно мои коммиты выглядят так: «Тайм-трекер, первая версия», «Тайм-трекер, вторая версия», «Тайм-трекер, релизная версия с переводом», «Тайм-трекер, теперь точно релизная версия». Разумеется, я вставляю гораздо больше деталей в коммиты, здесь для простоты просто передаю суть.
Что я успел сделать за полгода
Перечислю функции. Это не хотелки и не прототипы. Всё перечисленное я использую каждый день в реальной работе:
Управление шаблонами писем в админке. С использованием переменных (подгружаются в виде JSON) и мультиязычностью;
Управление контентом в админке. Статичные страницы (главная, дорожная карта), соглашения (пользовательское, политика конфиденциальности) с контролем версий, блог, редиректы. Всё это с поддержкой нескольких языков и с учётом SEO;
Приём платежей, управление тарифами (интеграция с Робокассой). Триалы, пожизненные доступы. Промо-коды (процентные и абсолютные) с ограничениями по активациям или периодам;
Календарь встреч. С переносами, отменами (и их инициаторами), связью с проектами и контактами. Наконец-то у меня есть статистика, сколько часов я потратил на переговоры по тому или иному клиенту или кто постоянно переносит встречи;
Система, которая следит за тем, помнит ли о нас тот или иной клиент;
Система, которая следит за тем, доволен ли тот или иной клиент уровнем сервиса;
Контрагенты, сотрудники, счета. Их связь с проектами и контактами;
Тайм-трекер (система учёта времени). Зная, как многие не любят даже мысли о тайм-трекинге, сделал его полностью отключаемым в админке;
«Мой день» — раздел, где можно запланировать сегодняшний день и видеть, что в целом происходит (какие встречи будут сегодня, какие клиенты о вас уже позабыли или недовольны уровнем сервиса).
Ну и ещё много всего по мелочам.
За полтора месяца работы с Кодексом я по объёму сделал столько же, сколько за предыдущие пять месяцев без него.
Ещё немного деталей
Кодекс я использую в браузере, хотя мог бы встроить в IDE. Я сам не тестировал, но друг рассказал, что в случае с IDE используется уже другой тариф и тарификация ведётся по количеству токенов. И там, где я использую Кодекс бесплатно в рамках платной подписки на ChatGPT, мне пришлось бы платить пару сотен долларов за то же самое;
К сегодняшнему дню в Github Actions у НормЦРМ уже 268 workflow runs. Если поначалу у меня то тут, то там возникали проблемы с деплоями, то сейчас ошибки появляются не чаще раза в пару недель;
Я работаю в одиночку, без команды — и это меня сильно ускоряет. Например, тайм-трекер я сделал за 7 часов (и за один подход). От проектирования до финального протестированного релиза. Моя старая команда выполняла бы такую задачу не меньше двух недель (из-за согласований и потерь в передаче информации);
Стараюсь работать маленькими итерациями. Раньше мне казалось странным делать деплой, в котором я правлю внешний вид какого-нибудь отдельностоящего элемента. А теперь, наоборот, дроблю работу везде, где это имеет смысл;
Вот как выглядит распределение времени в работе над проектом:
40% — проектирование;
30% — разработка и деплой;
30% — тестирование и планирование.
Скоро всем этим циферкам придётся немножко подвинуться, впустив в свои ряды такой пункт как «Продвижение»;
То, что я делаю — это чисто вайб-кодинг, сам я кода почти не касаюсь. Но есть два нюанса. Первый: архитектура проекта и его организация — это моё видение проектировщика информационных систем. Нейронки из коробки предлагали что-то менее системное (в основном потому, что не знали стратегических планов на проект). Второй: если меня лишить нейронок, то я смогу продолжить работу над кодом проекта. Раз в 10-20 медленнее, но смогу;
После каждого релиза новых функций я созваниваюсь с другом Антоном Григорьевым (UX/UI-дизайнером, автором UX Notes) и показываю их ему. Это помогает и в тестировании (когда я обо что-то спотыкаюсь во время демонстрации), и в сборе обратной связи (когда Антон чего-то не понимает из интерфейса и задаёт вопросы). Одна из лучших моих привычек по проекту;
Бывают ситуации, когда Codex не справляется с поставленной задачей. Чаще всего это выглядит так: какая-то функция в его коде не работает и после двух-трёх корректирующих промптов ничего не меняется. Тогда я иду в ChatGPT 5.2, даю ему полный контекст и прошу помочь. И ЧатГПТ всегда помогал. Не было ни одного раза, когда он не справился бы.
Выводы и ощущения
Перестало быть скучно. Сегодня, когда я уже не заливаю фундамент, а работаю над функциями, которые реально облегчают мою фрилансерскую жизнь, — каждый маленький результат приносит радость. За работу сажусь не за счёт дисциплины, а за счёт радостного предвкушения.
Кстати, задумываясь над созданием другого пет-проекта, прям руки опускаю, когда понимаю, что потребуется не меньше месяца работы просто на то, чтобы построить заново и запустить базовые вещи: регистрацию и вход, работу с контентом, написать соглашения, интегрировать оплату, настроить SEO и кучу подобных мелочей. Даже если я буду буквально копировать-вставлять уже готовые решения, это всё равно займёт время.
А ещё понимаю, что с двумя проектами, если я улучшу что-нибудь в базовом функционале в одном, то придётся дублировать это и во втором (если, конечно, не делать для них единую платформу с общей регистрацией и личными кабинетами).
Хочется вспомнить слова, которыми закончил предыдущую часть этой статьи:
Разработчиком я, разумеется, не стал. Но стал человеком, который может придумать, спроектировать, запрототипировать и собрать собственный инструмент. В одиночку. Те, кто такое уже проделывали — принимайте в свои ряды новичка! А те, кто ещё ждут своего часа — пробуйте. Сегодня это намного проще, чем несколько лет назад, несмотря на то, что технологии становятся всё сложнее.
Кое-что поменялось с тех пор. Хоть я и до сих пор не стал разработчиком, но уже не тот проектировщик интерфейсов, которым был полгода назад. Получилось что-то вроде проектировщика на максималках. Нынешним клиентам могу не только сделать прототип в Axure и описать его в функциональной спецификации, но и завайбкодить рабочий прототип MVP продукта (Python, Django, PostgreSQL + html/css + deploy) в сроки, доступные только тем, кто работает в одиночку. Я всё ещё не справлюсь без нейронок и мне не хватает опыта в боевых условиях, но давайте вернёмся к этому вопросу ещё через полгодика?
Иии… останавливаю тайм-трекер!
Полезные ссылки:
Получившийся проект (НормЦРМ): normcrm.ru
Книга нормального фрилансера. Она бесплатная. И это не какая-то брошюрка-лид-магнит. Я писал её два года. Уже больше десяти тысяч человек прочитали. Ни одного негативного или нейтрального отзыва — только позитив
Мой Телеграм-канал о работе на фрилансе и проектировании интерфейсов
