Когда-то у меня уже был блог. Потом, как это часто бывает, жизнь стала насыщеннее, список задач длиннее, а мысль «надо бы его нормально перезапустить» тихо жила где-то на фоне лет десять. Самый жизненный момент всей истории: проект годами жил только в голове, а теперь его можно собрать за чашкой кофе. Как? С помощью Codex.
Если вы маркетолог и вам нужен блог, лендинг или маленький сайт, это не значит, что сначала нужно срочно стать продактом, разработчиком и техлидом в одном лице. В моём случае это был ровно такой кейс: я наконец перезапустила moskovka.su в минималистичный блог на Astro и сделала это с Codex без знаний программирования.
Эта история не про то, как ИИ «магически пишет код». Она про работу маркетолога: ставить понятные задачи, принимать продуктовые решения и получать результат там, где раньше пришлось бы искать разработчика, собирать подрядчиков или откладывать идею на потом.
Как Codex работает, если вы не разработчик
Если коротко, Codex для меня работал как технический исполнитель, с которым можно разговаривать на нормальном человеческом языке. Я не объясняла устройство фреймворков на уровне инженера. Я объясняла задачу так, как объяснила бы коллеге:
- что именно я хочу получить;
- что для меня важно в результате;
- чего точно не надо делать;
- в каком порядке мы идём;
- в какой момент нужно моё утверждение.
Для меня это и есть главный сдвиг. Раньше в похожей задаче был бы обычный маршрут: придумать, что нужно, найти человека на техническую часть, синхронизироваться, подождать, ещё раз синхронизироваться и снова подождать. С Codex часть этой цепочки исчезает. Вы ставите задачу и редактируете результат, вместо того чтобы внезапно полюбить программирование.
Что я задала в начале, чтобы не потерять контроль
Самое полезное, что я сделала в начале, это задала правила работы. Не стек. Не дизайн. Не список страниц. Сначала именно правила.
Я сразу сформулировала процесс так:
- Сначала обсуждаем изменения в чате.
- Потом составляем план.
- Я утверждаю план.
- Только после этого начинается реализация.
- После каждого заметного изменения сразу делаем коммит.
Эти правила делают работу с ИИ безопаснее и полезнее для недевелопера. Вы не отдаёте задачу в чёрный ящик, а управляете рамкой: что обсуждаем, что считаем готовым, когда двигаемся дальше.
Ошибки по пути тоже были, и это нормально. В какой-то момент задача была понята не совсем так, как я имела в виду, но в таких историях важен не сам факт ошибки, а скорость реакции. Если вы видите, что система поехала чуть не туда, не надо героически делать вид, что всё под контролем. Нужно вовремя скорректировать курс.
Это хороший урок для маркетолога: вам не нужно знать, как устроен весь стек. Зато нужно ловить момент, когда система неверно поняла задачу, и уточнять направление.
Как выглядела работа на практике
Моя задача по смыслу была простой: пересобрать moskovka.su в минималистичный блог на Astro, с лентой постов на главной, статьями в Markdown и черновиками, которые можно смотреть до публикации.
Дальше моя роль сместилась к ограничениям и решениям. Мы зафиксировали несколько вещей:
- полностью перезапустить сайт на
Astro; - старый код не мигрировать, а убрать;
- хранить статьи локально в
Markdown; - сделать на старте именно блог, а не «медиа-платформу на будущее»;
- вывести ленту постов прямо на главную
/; - не добавлять
React,CMSи серверную логику до появления реальной необходимости.
Почему это важно. Когда вы не разработчик, очень велик соблазн компенсировать неуверенность количеством опций: «а вдруг потом понадобится», «а может, сразу CMS», «а вдруг нужен React». На практике это чаще всего и тормозит запуск.
Мне помогал такой принцип: первая версия должна решать сегодняшнюю задачу, а не все гипотетические задачи 2027 года. Для блога это означало выбрать минимальный рабочий фундамент, который можно собрать, проверить и уже использовать.
За одну рабочую сессию у меня появился нормальный блоговый фундамент: главная лента, страницы постов, контентная схема, черновики, базовый шаблон и вся обязательная мелочь вроде RSS, robots.txt и 404. Если перевести это с технического языка на маркетинговый, то произошло вот что: идея перестала быть задачей «когда-нибудь потом» и стала рабочим активом.
Что здесь важно именно маркетологу
Если вас пугает код, в этой истории хорошая новость: начинать нужно не с кода. Не нужно чинить каждый технический нюанс и не нужно знать весь стек изнутри. Важнее другое: понимать, влияет ли проблема на результат, замечать, когда система свернула не туда, и вовремя это проговаривать. Если чего-то не знаете, лучше спросить, чем делать вид, что всё под контролем.
Как не потерять нить проекта
Ещё одна вещь, которая оказалась очень полезной, — проектная память. Когда блог уже был собран, я завела рабочий контур, где фиксировался контекст проекта:
- что это за проект;
- какой у него стек;
- какие решения уже приняты;
- как устроена структура;
- по каким правилам мы продолжаем работу.
Параллельно появился живой лог, куда по ходу работы складывались решения, наблюдения и будущие идеи для статьи. Для меня это способ не начинать каждую следующую сессию с нуля.
В таком формате маркетолог не становится разработчиком, но получает гораздо больше самостоятельности.
Когда Codex особенно полезен маркетологу
На моём примере видно, где такие инструменты особенно полезны:
- когда нужно собрать небольшой digital-актив: блог, спецпроект, лендинг или внутреннюю страницу;
- когда результат уже понятен, и дело осталось за кодом;
- когда идею не хочется откладывать ещё на полгода;
- когда важно сделать и сохранить контроль над тем, как устроен проект.
Если у вас уже есть насмотренность в маркетинге, контенте, упаковке и пользовательских сценариях, этого часто достаточно, чтобы хорошо работать с Codex. Ваше преимущество — умение формулировать задачу, видеть критерии качества и отсеивать лишнее.
Что я бы советовала попробовать первым
Если вы хотите начать применять Codex в своей работе, не начинайте с большой технической революции. Начните с маленькой реальной задачи, где результат можно увидеть за одну-две сессии: блог, промостраница, шаблон для публикаций, аккуратная контентная структура.
Главное, что я бы взяла из этого кейса: вам не нужно сначала разобраться во всём. Нужно понимать, какой результат вы хотите получить, уметь задать рамку работы и не бояться уточнять по ходу.
Для меня ценность не сводится к тому, что Codex «сделал сайт сам». Главное: идея, которая много лет жила где-то на фоне, наконец превратилась в рабочий блог. Это практический результат, с которым можно идти дальше. Так Codex перестаёт быть игрушкой и становится помощником в работе.