Когда-то у меня уже был блог. Потом, как это часто бывает, жизнь стала насыщеннее, список задач длиннее, а мысль «надо бы его нормально перезапустить» тихо жила где-то на фоне лет десять. И вот это, пожалуй, самый жизненный момент всей истории: проект, который годами жил только в голове, теперь можно собрать за чашкой кофе. Как? С помощью 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 «сделал сайт сам». Ценность в другом: идея, которая много лет жила где-то на фоне, наконец превратилась в рабочий блог. И вот это уже не красивая теория про AI, а вполне практический результат, с которым можно идти дальше. Именно это превращает Codex из игрушки в настоящего помощника.