Как выбрать первый процесс для Codex и не ломать всю компанию
Идея “AI-native компании” легко звучит слишком большой. Кажется, что нужно сразу менять структуру, роли, процессы, управление и софт. В таком масштабе Codex превращается не в инструмент, а в лозунг. А лозунги плохо работают в операционке.
В ручном Telegram-источнике для журнала была полезная формула: не надо пытаться все сломать и сделать заново сразу. Лучше взять один процесс, создать петлю обратной связи, довести до конца, потом брать следующий. Это ровно тот язык, на котором Codex становится понятен владельцу проекта.
OpenAI Academy описывает Codex как инструмент повседневной работы. Значит, первый вопрос не “как внедрить ИИ”, а “какую повторяемую работу мы дадим Codex первой”.
Что здесь меняется
Codex не обязан сразу управлять компанией. Он может начать с маленького контура: принять вход, вернуть артефакт, пройти проверку, сохранить решение. Если этот контур работает, компания получает реальный опыт, а не презентацию про трансформацию.
Главное:Первый процесс для Codex должен быть частым, болезненным, безопасным и проверяемым. Не начинайте с революции: начните с одного контура, который можно довести до результата.
Как выбрать первый процесс
Первый процесс должен быть достаточно частым, достаточно болезненным и достаточно безопасным. Частый — чтобы быстро накопить примеры. Болезненный — чтобы выигрыш был заметен. Безопасный — чтобы ошибка не уничтожала отношения с клиентом, деньги или репутацию.
Хорошие кандидаты: первичный разбор входящих писем, подготовка статуса проекта, сбор материалов для встречи, черновик клиентского ответа, поиск расхождений в документе, обновление карточки продукта, проверка публикации перед выпуском. Плохие кандидаты: финальное юридическое решение, обещание клиенту, увольнение человека, финансовое одобрение без проверки.
Рабочий запрос
Помоги выбрать первый процесс для Codex.
Вот список повторяющихся работ: [список].
Оцени каждую по пяти критериям:
- частота;
- боль;
- безопасность;
- понятность входа;
- проверяемость результата.
Выбери один процесс для первого цикла.
Опиши:
- что я даю Codex;
- что Codex возвращает;
- как я проверяю;
- какой риск остается;
- когда считать эксперимент успешным.| Критерий | Хороший первый процесс | Плохой первый процесс |
|---|---|---|
| частота | повторяется каждую неделю | случается раз в квартал |
| проверка | человек быстро видит ошибку | ошибка проявится через месяц |
| риск | можно откатить | нельзя откатить |
| вход | есть письма, файлы, таблицы | все в голове |
| результат | понятный артефакт | “стало как-то лучше” |
Такой запрос полезен тем, что Codex не “внедряет ИИ”, а помогает выбрать маленькую рабочую петлю. Владелец проекта получает не лозунг, а первый эксперимент.
Как не сломать компанию
У AI-native подхода есть соблазн: если агент может многое, надо сразу перестроить все. Это почти всегда плохая идея. Компания держится не только на процессах, но и на доверии, привычках, неформальных договоренностях, личной ответственности. Если заменить все сразу, люди перестанут понимать, кто за что отвечает.
Лучше идти через последовательные контуры. Один процесс — один владелец — один формат входа — один формат результата — одна проверка. Когда контур стабилен, можно брать следующий. Это медленнее на вид, но быстрее по факту, потому что меньше поломок.
Где Codex особенно уместен
Codex хорош там, где нужно работать с файлами, правилами, журналами решений и повторяемыми проверками. Он может собрать папку процесса, создать шаблон, проверить результат, написать короткую инструкцию, обновить журнал. Для владельца проекта это означает: Codex становится не “приложением для программистов”, а способом держать процесс в руках.
Пример первого процесса: статус проекта
Статус проекта часто кажется мелкой административной задачей, но именно с него удобно начинать. Есть входы: переписка, задачи, файлы, дедлайны, обещания. Есть выход: короткий статус для клиента или команды. Есть проверка: человек быстро видит, не перепутал ли Codex факты. Риск умеренный: статус можно исправить до отправки.
Запрос может выглядеть так:
Собери еженедельный статус проекта.
Используй переписку, список задач и журнал решений.
Верни:
- что сделано;
- что заблокировано;
- какие обещания требуют внимания;
- какие решения нужны от человека;
- черновик сообщения клиенту.
Не отправляй сообщение сам.Такой процесс дает быстрый выигрыш: меньше ручного сведения, меньше забытых обещаний, больше прозрачности. И при этом человек остается в точке отправки.
Как расширять после первого успеха
Если статус проекта работает стабильно, можно добавить второй процесс. Например, подготовку встречи или разбор входящих заявок. Но расширять нужно только после того, как первый контур прошел несколько циклов. Иначе компания набирает слишком много недоделанных автоматизаций.
У каждого нового процесса должны быть свои границы: вход, выход, проверка, человеческое решение, журнал изменений. Если границы не описаны, Codex будет импровизировать, а владелец проекта снова окажется в хаосе.
Ошибка “сразу все”
Самая частая ошибка — дать Codex слишком широкую задачу: “посмотри наш бизнес и автоматизируй”. Это звучит амбициозно, но почти не проверяется. Агент может написать убедительный план, но не создать устойчивый рабочий результат. Лучше попросить его выбрать один процесс и объяснить, почему именно он безопасен для первого цикла.
Первый успех должен быть скучным и полезным. Скучным — потому что его можно повторить. Полезным — потому что он освобождает внимание владельца проекта.
Через месяц именно такие скучные контуры становятся основой настоящей AI-native работы: не презентация, а привычка каждую неделю превращать один кусок хаоса в проверяемый результат, который можно спокойно показать команде и клиенту.
