Каждый уважающий себя программист на этом моменте должен сказать, что Claude Code лучше, чем Codex, потому что... я так и не понял, если честно, но поскольку на работе мне дали именно Codex, коим я максимально доволен, то предлагаю вашему вниманию тройку промптов, которые подойдут, наверное, для всех проектов. Промпты необычайно тупы и каждый дойдет до них сам, но тем не менее:
1. Посмотри, насколько у меня проект production-ready
Это мой любимый промпт, который я кидаю по нескольку раз на день. На нём Codex запускает полный аудит вашего проекта. Находит косяки, ранжирует их по степени серьезности. Строит план работ на несколько недель вперед и предлагает что-то из них начать делать.
На самом деле я не встречал более эффективного промпта, который подходит везде. Потому что, если, например, вы пилите стартап и у вас нет никакого легаси, то он сделает всё, что вам нужно. А если вы запустили его в проект, который кормит всю вашу семью, то он просто покажет, что там не так, как можно его улучшить и где что добавить и вы дальше уже сами решите, что с ним делать. План работ он, естественно, способен выполнить за день.
2. Предыдущий промпт, отправленный несколько раз или "Давай"
Наверное, каждый пользователь Codex знает, что тот сперва строит план, потом показывает его вам на согласование и потом делает. Поэтому один раз скинуть промпт недостаточно, нужно будет потом несколько раз написать "давай", "продолжи", "сделай все, что нужно" и пр. Великий ум понимает, что можно сделать это сразу, не дожидаясь, пока тебе покажут план, на который ты скажешь "ок". Тогда серия ваших промптов встанет в очередь и всё выполнится.
По сути это техника, которая позволяет загрузить Codex на часик другой. Сейчас я почти всегда отправляю все промпты по 2 раза. ИИ наверное считает меня очень тупым, но это он делает мою работу, а не я его. Или нет?
3. Проверь, что все тесты (юнит, интеграционное, под нагрузкой и мутационное) на месте, замерь покрытие с помощью какой-нибудь библиотеки, увеличь покрытие, разберись с мутантами и опиши всю документацию, включая патчноуты и пр.
Тут комментировать особо нечего. Тесты писать некогда, документацию тоже. Документация - хорошо, мутационное тестирование - очень хорошо. Разработка через нейронку лучше всего идет, когда она test-driven. В конце концов, как еще вы поймете что Codex своими изменениями ничего не убил? Этот промпт тоже рекомундую отправить паровозиком несколько раз.
В результате у вас будет достойный проект с тестами, которые вам всегда было некогда писать.
Телеграм канал автора, где он что‑то пишет про ML, NLP и разработку
P.S. Мой знакомый, работающий на Antropic заявил, что Codex лучше, чем Claude code.
P.S.S. Если у вас есть хорошие практики по работе с Сodex, прошу поделиться.
Real_Egor
я в своей работе использую несколько специализированных промпто для контроля качества
1) Проведи глубокий аудит безопасности потоков данных: найди потенциальные утечки чувствительной информации и нарушения границ доверия
(смотрит на потенциальные кражи, некачественно собранную защиту, неправильное распределение по контурам безопасности и т.п.)
2) Выполни поиск уязвимостей контроля доступа (Broken Access Control) и векторов инъекций: проверь наличие IDOR (Insecure Direct Object Reference), путей горизонтальной и вертикальной эскалации привилегий, а также строгость серверной валидации бизнес-состояния (Client-Side Enforcement bypassing).
(ищет все потенциальные места для инъекций, нерешенные или упущенные блокировки перехвата управления, проверки полученных с фронт-энда запросов на соответствие текущему состоянию базы и наличия прав на запрос и на авторизацию)
3) Проанализируй end-to-end сценарии на предмет логических уязвимостей и состояний процессов: выяви тупиковые состояния (dead states), необработанные граничные случаи (edge cases) и возможные пути обхода бизнес-логики при прерывании сессии или нестандартном порядке запросов.
(сквозной анализ от первого нажатия до завершения сессии с учетом дерева потенциальных действий, тут лучше иметь изначально хотя бы кратко описанный сценарий пользователя, но даже без него они отлично его представляют и проверяют на "сквозноту")
4) Проведи теоретический Chaos-инжиниринг: выяви точки отказа (SPOF), проверь наличие и корректность паттернов "повторные попытки выполнения", "резервные сценарии работы", "предохранители при отказах". Опиши сценарии каскадного падения системы и выяви, где отсутствие плавной / изящной деградации приведет к неработоспособности всего функционала при неработоспособности одной компоненты / сервиса
(проверяет модули на устойчивость при незапланированных ситуациях, проверит что произойдет в случае отключения каждой из компоненты)
5) Выполни аудит производительности и потребления ресурсов: найди проблемы бесконечных запросов к базе данных, неоптимальные индексы, потенциальные утечки памяти, незакрытые соединения и места, уязвимые к атакам исчерпания ресурсов.
(тут все просто - анализ на то, что система не повесит сервак в аварийных случаях)
---
суть промптов (направление проверки) я уже давно выучил. А перед каждым использованием я скидываю в отдельный чат его краткий вид и прошу расписать подробнее гемини, а потом уже вставляю. Так что запуск "двухэтапный", чтобы не держать в голове все термины
Общая проблема единого запроса "проверь на production-ready" в том, что модель выберет каждый раз свой способ проверки, неконтролируемый, а скорее навязанный прошлым диалогом. А даже если посмотрит "сверху", то с большой вероятностью она не будет выписывать все - найдет первые 5-10-15 ошибок и про них напшет. И уж тем более она маловероятно будет проводить "стресс-устойчивость к форс-мажорам", "работоспособность сквозных сценариев" и "защищенность от точечных попыток обращаться с системой незадокументированными способами".
P.S. Не забудь заставить модель надеть маску или супер-тестировщика, или эксперта-разработчика или гуру-архитектора. А то под ролью "физика-теоретика" или "маркетолога" она эти проверки выполнит... спустя рукава -)