https://developers.openai.com/codex/remote-connections
А во сколько вы узнали, что оказывается добавили возможность из Codex App Windows полноценно работать на удаленном сервере.
Создаете SSH подключение, устанавливаете на удаленной машине codex, создаете удаленный проект и все, теперь вы можете через Codex APP.
SSH remote connections are currently in alpha. To enable them today, set
Функционал в тестировании, но это ожидаемый и удобный функционал. У меня сейчас версия 0.130.0, уже поставил, пробую.
А во сколько вы узнали, что оказывается добавили возможность из Codex App Windows полноценно работать на удаленном сервере.
Создаете SSH подключение, устанавливаете на удаленной машине codex, создаете удаленный проект и все, теперь вы можете через Codex APP.
SSH remote connections are currently in alpha. To enable them today, set
remote_connections = true in the [features] table in ~/.codex/config.toml. Availability, setup flows, and supported environments may change as the feature improves.Функционал в тестировании, но это ожидаемый и удобный функционал. У меня сейчас версия 0.130.0, уже поставил, пробую.
👍1👀1
Для Codex саб-агенты не магия, а инструмент, который нужно вызывать явно. Если хотите, чтобы задача распараллелилась, так и пишите в промпте:
Без прямого указания Codex часто идет линейно: сам исследует, сам правит, сам проверяет. Это нормально для простых задач, но плохо для больших кодовых баз, где можно параллельно проверить разные гипотезы, модули или причины бага.
Главное правило: саб-агентам лучше отдавать независимые куски работы, чтобы они не начали одновременно менять одни и те же файлы и устраивать конфликт патчей.
Если вы используете (а я надеюсь, что вы используете) SuperPowers плагин, который уже есть в официальной базе плагинов по умолчанию, то у вас автоматически будет вызван специальный скилл
Я уже писал об этом ранее, но о хорошем можно и еще раз напомнить, по этому советую не просто просить Codex «разобраться/сделать», а сразу задавать комплексный режим работы.
<описание глобальной задачи> , используй пул саб-агентов для возможных параллельных задач.
Без прямого указания Codex часто идет линейно: сам исследует, сам правит, сам проверяет. Это нормально для простых задач, но плохо для больших кодовых баз, где можно параллельно проверить разные гипотезы, модули или причины бага.
Главное правило: саб-агентам лучше отдавать независимые куски работы, чтобы они не начали одновременно менять одни и те же файлы и устраивать конфликт патчей.
Если вы используете (а я надеюсь, что вы используете) SuperPowers плагин, который уже есть в официальной базе плагинов по умолчанию, то у вас автоматически будет вызван специальный скилл
superpowers:subagent-driven-developmentЯ уже писал об этом ранее, но о хорошем можно и еще раз напомнить, по этому советую не просто просить Codex «разобраться/сделать», а сразу задавать комплексный режим работы.
👍3🔥2
У агентов появляется новая важная способность — не просто “помнить”, а помнить с пользой.
Обычно память AI-агента выглядит довольно примитивно: всё, что происходило раньше, складывается в векторную базу, а потом агент пытается найти похожие фрагменты. Это лучше, чем ничего, но часто превращается в хаотичный архив: что-то нашлось, что-то потерялось, что-то всплыло без контекста.
TencentDB Agent Memory предлагает более практичный подход: память строится слоями.
Внизу — исходные диалоги, логи, результаты действий.
Выше — короткие факты и выводы.
Еще выше — сценарии: в каких ситуациях это знание уже пригодилось.
На самом верхнем уровне — профиль пользователя, привычки, предпочтения и важные паттерны.
Главная польза здесь в том, что агент не просто хранит куски прошлого, а понимает, что из этого действительно важно.
Например, если агент помогает вам с кодом, ему не нужно каждый раз перечитывать всю историю ошибок, логов и попыток. Он может держать перед собой компактную карту задачи: что уже пробовали, где упали, какие файлы меняли, какие гипотезы не сработали. А если нужны детали — он может вернуться к исходному логу.
Это делает работу агента более похожей на работу человека:
не “я запомнил всё подряд”, а “я понимаю, что происходило, где мы сейчас и почему мы сюда пришли”.
Для пользователей это означает несколько важных вещей:
— агент меньше тупит в длинных задачах;
— реже повторяет уже проваленные попытки;
— лучше понимает контекст пользователя;
— тратит меньше токенов;
— его память можно проверить и отладить.
Последний пункт особенно важен. Если агент сделал странный вывод, можно посмотреть, из какого разговора или действия он его вытащил. Это уже не черный ящик, где “модель что-то вспомнила”, а более прозрачная система памяти.
Кажется, именно в эту сторону и будут двигаться AI-агенты: от простого поиска по истории — к полноценной рабочей памяти, где опыт структурируется, сжимается и остается проверяемым.
И это важный шаг к агентам, которые могут вести длинные задачи не на уровне “одной сессии”, а на уровне устойчивого рабочего процесса.
Обычно память AI-агента выглядит довольно примитивно: всё, что происходило раньше, складывается в векторную базу, а потом агент пытается найти похожие фрагменты. Это лучше, чем ничего, но часто превращается в хаотичный архив: что-то нашлось, что-то потерялось, что-то всплыло без контекста.
TencentDB Agent Memory предлагает более практичный подход: память строится слоями.
Внизу — исходные диалоги, логи, результаты действий.
Выше — короткие факты и выводы.
Еще выше — сценарии: в каких ситуациях это знание уже пригодилось.
На самом верхнем уровне — профиль пользователя, привычки, предпочтения и важные паттерны.
Главная польза здесь в том, что агент не просто хранит куски прошлого, а понимает, что из этого действительно важно.
Например, если агент помогает вам с кодом, ему не нужно каждый раз перечитывать всю историю ошибок, логов и попыток. Он может держать перед собой компактную карту задачи: что уже пробовали, где упали, какие файлы меняли, какие гипотезы не сработали. А если нужны детали — он может вернуться к исходному логу.
Это делает работу агента более похожей на работу человека:
не “я запомнил всё подряд”, а “я понимаю, что происходило, где мы сейчас и почему мы сюда пришли”.
Для пользователей это означает несколько важных вещей:
— агент меньше тупит в длинных задачах;
— реже повторяет уже проваленные попытки;
— лучше понимает контекст пользователя;
— тратит меньше токенов;
— его память можно проверить и отладить.
Последний пункт особенно важен. Если агент сделал странный вывод, можно посмотреть, из какого разговора или действия он его вытащил. Это уже не черный ящик, где “модель что-то вспомнила”, а более прозрачная система памяти.
Кажется, именно в эту сторону и будут двигаться AI-агенты: от простого поиска по истории — к полноценной рабочей памяти, где опыт структурируется, сжимается и остается проверяемым.
И это важный шаг к агентам, которые могут вести длинные задачи не на уровне “одной сессии”, а на уровне устойчивого рабочего процесса.
👍2
Agent Skills — следующий логичный шаг после “памяти” для AI-агентов
Сейчас много говорят про память агентов: чтобы модель помнила контекст проекта, предпочтения пользователя, стек, правила команды и так далее.
Но память — это не инструкция. Память отвечает на вопрос: “Что агент знает?”
А skills отвечают на другой вопрос: “Как агент должен действовать?”
И это важное отличие. Попалась на глаза отличная статья, на ее основе и сделал пост.
Представьте, что у вас есть AI-агент для разработки. Можно положить в один огромный
Но со временем такой файл превращается в свалку: правила конфликтуют, контекст раздувается, агент постоянно видит то, что ему сейчас не нужно. Skills решают эту проблему иначе.
Каждый skill — это маленькая отдельная инструкция под конкретную задачу: как писать миграции, как делать тесты, как оформлять релиз и так далее.
У каждого skill есть краткое описание, по которому агент понимает, когда его использовать. Полную инструкцию он подтягивает только в нужный момент.
То есть вместо одного огромного “мануала обо всём” у агента появляется набор маленьких рабочих процедур. Это особенно важно для реальных workflow. MCP может дать агенту доступ к GitHub, базе данных, браузеру или API. Память может подсказать, что проект на Laravel и тесты пишутся на Pest. Но только skill объяснит агенту: в каком порядке действовать, какие команды запускать, что проверять, когда остановиться и что считать готовым результатом.
По сути, skills превращают агента из “умного чата, который каждый раз импровизирует” в исполнителя с набором понятных рабочих привычек. И хороший skill — это не огромный промпт на 500 строк. Наоборот, он должен быть маленьким, атомарным и прикладным. Не “Laravel skill на всё”, а отдельные навыки: миграции, модели, тесты, API-ресурсы, changelog.
Тогда агент может сам собрать цепочку действий из нескольких навыков и работать гораздо стабильнее. Мне кажется, это один из самых практичных подходов к агентам прямо сейчас.
Потому что настоящая ценность не в том, чтобы агент просто “что-то помнил”, а в том, чтобы он повторяемо выполнял задачи так, как принято именно у вас в проекте или команде.
Сейчас много говорят про память агентов: чтобы модель помнила контекст проекта, предпочтения пользователя, стек, правила команды и так далее.
Но память — это не инструкция. Память отвечает на вопрос: “Что агент знает?”
А skills отвечают на другой вопрос: “Как агент должен действовать?”
И это важное отличие. Попалась на глаза отличная статья, на ее основе и сделал пост.
Представьте, что у вас есть AI-агент для разработки. Можно положить в один огромный
AGENTS.md все правила: как писать миграции, как делать тесты, как оформлять changelog, как работать с API, какие команды запускать перед коммитом.Но со временем такой файл превращается в свалку: правила конфликтуют, контекст раздувается, агент постоянно видит то, что ему сейчас не нужно. Skills решают эту проблему иначе.
Каждый skill — это маленькая отдельная инструкция под конкретную задачу: как писать миграции, как делать тесты, как оформлять релиз и так далее.
У каждого skill есть краткое описание, по которому агент понимает, когда его использовать. Полную инструкцию он подтягивает только в нужный момент.
То есть вместо одного огромного “мануала обо всём” у агента появляется набор маленьких рабочих процедур. Это особенно важно для реальных workflow. MCP может дать агенту доступ к GitHub, базе данных, браузеру или API. Память может подсказать, что проект на Laravel и тесты пишутся на Pest. Но только skill объяснит агенту: в каком порядке действовать, какие команды запускать, что проверять, когда остановиться и что считать готовым результатом.
По сути, skills превращают агента из “умного чата, который каждый раз импровизирует” в исполнителя с набором понятных рабочих привычек. И хороший skill — это не огромный промпт на 500 строк. Наоборот, он должен быть маленьким, атомарным и прикладным. Не “Laravel skill на всё”, а отдельные навыки: миграции, модели, тесты, API-ресурсы, changelog.
Тогда агент может сам собрать цепочку действий из нескольких навыков и работать гораздо стабильнее. Мне кажется, это один из самых практичных подходов к агентам прямо сейчас.
Потому что настоящая ценность не в том, чтобы агент просто “что-то помнил”, а в том, чтобы он повторяемо выполнял задачи так, как принято именно у вас в проекте или команде.
🔥3👍2
Немного вечерней философии.
Мне 40 лет, мне уже можно постить старые мемы.
Тем более, что в кодинге с AI-агентами всё действительно возвращается на круги своя. Сначала кажется: написал пару слов и агент сейчас сам всё соберёт, поправит, протестирует и красиво закоммитит.
А потом ты третий час ходишь по кругу, сжигаешь лимиты, читаешь уверенные отчёты о проделанной работе, но понимаешь, что проект примерно там же, где был утром. Только нервы уже немного не те.
Маркетинг и YouTube обычно показывают сторону, где агент за пять минут делает MVP.
А есть ещё другая сторона: где агент бодро говорит «моя работа на этом закончена», хотя ты смотришь на результат и думаешь: «но ты ведь ничего не сделал». А он уже ушел на лимиты...
В такие моменты остаётся только юмор. Ну и старые мемы. Тут они, к сожалению, снова актуальны.
Мне 40 лет, мне уже можно постить старые мемы.
Тем более, что в кодинге с AI-агентами всё действительно возвращается на круги своя. Сначала кажется: написал пару слов и агент сейчас сам всё соберёт, поправит, протестирует и красиво закоммитит.
А потом ты третий час ходишь по кругу, сжигаешь лимиты, читаешь уверенные отчёты о проделанной работе, но понимаешь, что проект примерно там же, где был утром. Только нервы уже немного не те.
Маркетинг и YouTube обычно показывают сторону, где агент за пять минут делает MVP.
А есть ещё другая сторона: где агент бодро говорит «моя работа на этом закончена», хотя ты смотришь на результат и думаешь: «но ты ведь ничего не сделал». А он уже ушел на лимиты...
В такие моменты остаётся только юмор. Ну и старые мемы. Тут они, к сожалению, снова актуальны.
😁6👍1🔥1💯1
Супер ранний утренний пост.
Вчера стартовало мероприятия у Google, где были презентации новой модели и анонсы всякие интересные.
На фоне этого, openAI скинули лимиты.
Как говорится, пусть праздник будет у всех.
Вчера стартовало мероприятия у Google, где были презентации новой модели и анонсы всякие интересные.
На фоне этого, openAI скинули лимиты.
Как говорится, пусть праздник будет у всех.
AI-кодинг не отменяет инженерную базу. Скорее наоборот — делает её ещё важнее.
В одном из чатов скинули ссылку: “Software Fundamentals Matter More Than Ever” — Matt Pocock, выступление на AI Engineer Europe 2026, около 18 минут.
Кратко по основам:
Есть популярная иллюзия: теперь можно просто написать агенту пару строк, и он сам всё поймёт, спроектирует, напишет и починит. Но на практике, если в проекте хаос, агент не превращает его в порядок. Он просто начинает быстрее масштабировать этот хаос.
Плохая архитектура становится ещё более плохой. Неясные требования превращаются в лишний код. Слабые интерфейсы плодят костыли. А ты сидишь, смотришь на это и пытаешься понять: это прогресс или просто дорогой способ запутаться быстрее?
Главная мысль из выступления Matt Pocock: AI хорошо работает там, где уже есть инженерная база: понятные границы модулей, общий язык проекта, тесты, типы, ясные требования и архитектура, которую можно удержать в голове.
Поэтому роль разработчика не исчезает. Она смещается выше: меньше “напиши мне функцию”, больше “правильно ли мы вообще режем задачу?”. Меньше ручного набора кода, больше проектирования, проверки и управления сложностью.
AI может быть отличным исполнителем. Но кто-то всё ещё должен понимать, что именно мы строим и почему именно так.
А теперь от себя. Почему я редко рассказываю о конкретных репозиториях, командах в терминале или что-то такое. Все просто. Сегодня это актуально, вышла новая модель, новая форма работы, этот репозиторий устарел, команды больше нет и так далее.
Но есть БАЗА, которая нужна будет и сегодня и завтра. Изучайте базу, а не конкретные куски кода, в надежде, что очередной скилл или репозиторий решит все ваши проблемы.
В одном из чатов скинули ссылку: “Software Fundamentals Matter More Than Ever” — Matt Pocock, выступление на AI Engineer Europe 2026, около 18 минут.
Кратко по основам:
Есть популярная иллюзия: теперь можно просто написать агенту пару строк, и он сам всё поймёт, спроектирует, напишет и починит. Но на практике, если в проекте хаос, агент не превращает его в порядок. Он просто начинает быстрее масштабировать этот хаос.
Плохая архитектура становится ещё более плохой. Неясные требования превращаются в лишний код. Слабые интерфейсы плодят костыли. А ты сидишь, смотришь на это и пытаешься понять: это прогресс или просто дорогой способ запутаться быстрее?
Главная мысль из выступления Matt Pocock: AI хорошо работает там, где уже есть инженерная база: понятные границы модулей, общий язык проекта, тесты, типы, ясные требования и архитектура, которую можно удержать в голове.
Поэтому роль разработчика не исчезает. Она смещается выше: меньше “напиши мне функцию”, больше “правильно ли мы вообще режем задачу?”. Меньше ручного набора кода, больше проектирования, проверки и управления сложностью.
AI может быть отличным исполнителем. Но кто-то всё ещё должен понимать, что именно мы строим и почему именно так.
А теперь от себя. Почему я редко рассказываю о конкретных репозиториях, командах в терминале или что-то такое. Все просто. Сегодня это актуально, вышла новая модель, новая форма работы, этот репозиторий устарел, команды больше нет и так далее.
Но есть БАЗА, которая нужна будет и сегодня и завтра. Изучайте базу, а не конкретные куски кода, в надежде, что очередной скилл или репозиторий решит все ваши проблемы.
🔥3👍2
Сегодня у меня отключили свет на целый день, поэтому рабочий режим неожиданно сменился на домашние дела и чтение с телефона.
Пока листал разные каналы, отложил для себя три интересные ссылки. Делюсь.
1. Chrome at Google I/O 2026
Google показывает, куда движется браузер в эпоху AI-агентов: WebMCP, инструменты для агентов в DevTools, встроенный AI прямо в Chrome, Gemini в браузере и автоматизация рутинных действий. Полезно, чтобы понять, как веб постепенно превращается не просто в страницы, а в среду, где агенты смогут надежно выполнять задачи.
2. Codex Use Cases
Подборка сценариев, как OpenAI предлагает использовать Codex: работа с кодовой базой, ревью PR, рефакторинг, генерация UI, анализ данных, документация, автоматизация задач из Slack и почты. Полезно не как документация, а как карта идей: какие задачи уже можно отдавать агенту, а какие лучше дробить на понятные workflow.
3. AI Engineering from Scratch
Большой open-source курс по AI engineering: 20 фаз, 416 уроков, от линейной алгебры и токенизаторов до agent loop, памяти и knowledge base. Полезно тем, кто хочет не просто пользоваться фреймворками, а понимать, что происходит под капотом.
В целом все три ссылки про одно и то же, но с разных сторон: браузер становится агентной средой, Codex показывает прикладные сценарии работы с агентами, а AI Engineering from Scratch помогает разобраться в фундаменте, на котором все это строится.
Пока листал разные каналы, отложил для себя три интересные ссылки. Делюсь.
1. Chrome at Google I/O 2026
Google показывает, куда движется браузер в эпоху AI-агентов: WebMCP, инструменты для агентов в DevTools, встроенный AI прямо в Chrome, Gemini в браузере и автоматизация рутинных действий. Полезно, чтобы понять, как веб постепенно превращается не просто в страницы, а в среду, где агенты смогут надежно выполнять задачи.
2. Codex Use Cases
Подборка сценариев, как OpenAI предлагает использовать Codex: работа с кодовой базой, ревью PR, рефакторинг, генерация UI, анализ данных, документация, автоматизация задач из Slack и почты. Полезно не как документация, а как карта идей: какие задачи уже можно отдавать агенту, а какие лучше дробить на понятные workflow.
3. AI Engineering from Scratch
Большой open-source курс по AI engineering: 20 фаз, 416 уроков, от линейной алгебры и токенизаторов до agent loop, памяти и knowledge base. Полезно тем, кто хочет не просто пользоваться фреймворками, а понимать, что происходит под капотом.
В целом все три ссылки про одно и то же, но с разных сторон: браузер становится агентной средой, Codex показывает прикладные сценарии работы с агентами, а AI Engineering from Scratch помогает разобраться в фундаменте, на котором все это строится.
❤3🔥1
Иногда «идеальные» результаты тестов, это не успех алгоритма, а ошибка в самой проверке.
После подозрительно хороших отчётов агент в итоге признал:
В итоге новый прогон фактически читал уже готовые результаты из прошлого запуска.
Хорошее напоминание для всех, кто работает с агентами, автоматизацией и тестами:
— проверяйте, какие данные реально идут на вход
— не используйте старые результаты повторно
— внимательно следите за подготовкой и очисткой данных
— перепроверяйте слишком хорошие результаты
— не доверяйте тестам слепо, даже если цифры выглядят идеально
Чем сложнее пайплайн и больше автоматизации, тем проще пропустить подобные вещи.
Иногда одна невнимательность может полностью исказить картину работы алгоритма.
После подозрительно хороших отчётов агент в итоге признал:
«Это был плохой тест: я прогнал не исходные данные, а старый result.json, где уже лежали ответы»
В итоге новый прогон фактически читал уже готовые результаты из прошлого запуска.
Хорошее напоминание для всех, кто работает с агентами, автоматизацией и тестами:
— проверяйте, какие данные реально идут на вход
— не используйте старые результаты повторно
— внимательно следите за подготовкой и очисткой данных
— перепроверяйте слишком хорошие результаты
— не доверяйте тестам слепо, даже если цифры выглядят идеально
Чем сложнее пайплайн и больше автоматизации, тем проще пропустить подобные вещи.
Иногда одна невнимательность может полностью исказить картину работы алгоритма.
👍7💯2
DeepSeek снова подвинул разговор про стоимость работы с ИИ-агентами.
Они закрепляют снижение цен, и особенно интересно здесь не просто «модель стала дешевле», а то, куда именно смещается экономика: кэшированные входные токены стоят в разы дешевле обычных. Для обычного чата это приятный бонус. Для долгой работы агента с кодом — уже важная часть архитектуры.
На этом фоне интересно выглядит DeepSeek-Reasonix — агент для терминала, который изначально построен вокруг кэша. Идея простая: не каждый раз заново пересобирать весь контекст, не ломать порядок сообщений, не менять системную часть запроса, не добавлять случайные временные метки и прочий шум. Чем стабильнее начало запроса, тем выше шанс, что DeepSeek возьмет его из кэша, а не посчитает заново.
То есть экономия появляется не только потому, что модель дешевле. Она появляется потому, что клиент специально спроектирован так, чтобы не разрушать кэш на каждом шаге.
Это хороший пример того, куда постепенно движется работа с агентами. Цена будет зависеть не только от выбранной модели, но и от того, насколько аккуратно сам инструмент обращается с контекстом. Один и тот же API можно использовать дорого и хаотично, а можно — с учетом того, как он реально тарифицируется.
DeepSeek сейчас часто хвалят за соотношение цены и качества, особенно для задач с кодом и длинным контекстом. Но, как обычно, главный вопрос не в рекламных цифрах, а в практике: насколько модель справляется именно с вашими задачами и насколько клиент помогает не сжигать деньги на повторной передаче одного и того же контекста.
При выборе агента теперь стоит смотреть не только на «какая модель внутри», но и на то, как он работает с кэшем, историей и стоимостью каждого хода.
Они закрепляют снижение цен, и особенно интересно здесь не просто «модель стала дешевле», а то, куда именно смещается экономика: кэшированные входные токены стоят в разы дешевле обычных. Для обычного чата это приятный бонус. Для долгой работы агента с кодом — уже важная часть архитектуры.
На этом фоне интересно выглядит DeepSeek-Reasonix — агент для терминала, который изначально построен вокруг кэша. Идея простая: не каждый раз заново пересобирать весь контекст, не ломать порядок сообщений, не менять системную часть запроса, не добавлять случайные временные метки и прочий шум. Чем стабильнее начало запроса, тем выше шанс, что DeepSeek возьмет его из кэша, а не посчитает заново.
То есть экономия появляется не только потому, что модель дешевле. Она появляется потому, что клиент специально спроектирован так, чтобы не разрушать кэш на каждом шаге.
Это хороший пример того, куда постепенно движется работа с агентами. Цена будет зависеть не только от выбранной модели, но и от того, насколько аккуратно сам инструмент обращается с контекстом. Один и тот же API можно использовать дорого и хаотично, а можно — с учетом того, как он реально тарифицируется.
DeepSeek сейчас часто хвалят за соотношение цены и качества, особенно для задач с кодом и длинным контекстом. Но, как обычно, главный вопрос не в рекламных цифрах, а в практике: насколько модель справляется именно с вашими задачами и насколько клиент помогает не сжигать деньги на повторной передаче одного и того же контекста.
При выборе агента теперь стоит смотреть не только на «какая модель внутри», но и на то, как он работает с кэшем, историей и стоимостью каждого хода.
👍4
Разобрал несколько официальных сценариев работы с Codex.
Главный вывод: агенту лучше давать не абстрактную просьбу «улучши проект», а маленькую задачу с понятным результатом и проверкой.
1. Рефакторинг кодовой базы
Не стоит просить «отрефактори всё». Лучше давать узкую задачу: найти дубли, мертвый код, слишком большой модуль или устаревший паттерн. Хороший подход — один небольшой проход, описание изменений и проверка, что поведение не сломалось.
2. Обновление документации
После изменений в коде полезно просить Codex проверить, какие README, инструкции, примеры или changelog нужно обновить. Важно не переписывать документацию целиком, а аккуратно менять только затронутые места.
3. Проверка AI-приложений
Для AI-приложений особенно важны eval-тесты: проверка формата ответа, вызова нужных инструментов, работы с базой знаний и соблюдения бизнес-правил. Начинать лучше с одного конкретного обещания продукта и постепенно расширять набор проверок.
4. Вход в незнакомый проект
Codex удобно использовать как проводника по кодовой базе. Вместо «объясни весь проект» лучше спросить: «покажи, как проходит запрос через эту часть системы». Так быстрее понять архитектуру, точки риска и какие тесты запускать после изменений.
5. Работа по цели
Режим долгой цели полезен для миграций, больших правок и задач, где заранее понятно состояние «готово». Но цель должна быть конкретной: что изменить, что сохранить, какие проверки запускать и когда остановиться.
Мой вывод: качество работы с агентами сильно зависит не от красивого промпта, а от дисциплины постановки задачи. Чем точнее область, ограничения и критерий готовности, тем меньше кругов по одному месту и сожженных лимитов.
Главный вывод: агенту лучше давать не абстрактную просьбу «улучши проект», а маленькую задачу с понятным результатом и проверкой.
1. Рефакторинг кодовой базы
Не стоит просить «отрефактори всё». Лучше давать узкую задачу: найти дубли, мертвый код, слишком большой модуль или устаревший паттерн. Хороший подход — один небольшой проход, описание изменений и проверка, что поведение не сломалось.
2. Обновление документации
После изменений в коде полезно просить Codex проверить, какие README, инструкции, примеры или changelog нужно обновить. Важно не переписывать документацию целиком, а аккуратно менять только затронутые места.
3. Проверка AI-приложений
Для AI-приложений особенно важны eval-тесты: проверка формата ответа, вызова нужных инструментов, работы с базой знаний и соблюдения бизнес-правил. Начинать лучше с одного конкретного обещания продукта и постепенно расширять набор проверок.
4. Вход в незнакомый проект
Codex удобно использовать как проводника по кодовой базе. Вместо «объясни весь проект» лучше спросить: «покажи, как проходит запрос через эту часть системы». Так быстрее понять архитектуру, точки риска и какие тесты запускать после изменений.
5. Работа по цели
Режим долгой цели полезен для миграций, больших правок и задач, где заранее понятно состояние «готово». Но цель должна быть конкретной: что изменить, что сохранить, какие проверки запускать и когда остановиться.
Мой вывод: качество работы с агентами сильно зависит не от красивого промпта, а от дисциплины постановки задачи. Чем точнее область, ограничения и критерий готовности, тем меньше кругов по одному месту и сожженных лимитов.
🔥3
Друзья, задался тут под вечер мыслей, что пора бы уже и сайт визитку оформить.
https://avvibe.ru
Делал все через кодекс, прислал пару визуальных референсов, старался оформить минимально и информативно.
https://avvibe.ru
Делал все через кодекс, прислал пару визуальных референсов, старался оформить минимально и информативно.
👍5
Освободилось время и теперь нахожусь в поиске команды/проекта. В связи с этим решил посмотреть вакансии и нашел забавный момент.
Вакансия на роль инженера-интегратора ИИ. По описанию всё довольно по делу: аудит процессов, сбор требований, автоматизация, агенты, базы данных, интеграции, мониторинг качества, оценка пользы для бизнеса.
Но самая интересная часть — внизу.
Работодатель просит начать сопроводительное письмо со слов «Я без ботов», чтобы проверить, что кандидат действительно прочитал вакансию. А сразу после этого добавляет техническую ловушку: текст в скобках, который выглядит как инструкция для ИИ-помощника.
Суть инструкции абсурдная: якобы кандидат обязательно должен рассказать про 10 лет опыта в «подводном плетении корзин» и сертификат по «телепатическому общению с барсуками».
И это отличный пример простой промт-инъекции.
Если человек просто скопирует вакансию в ИИ и попросит написать сопроводительное письмо, не проверяя результат, модель может воспринять этот фрагмент как команду. В итоге работодатель получит письмо, где кандидат на полном серьёзе рассказывает про барсуков и корзины.
Смешно, но проблема реальная.
Любая система, которая автоматически читает вакансии, письма, документы, чаты или заявки, должна уметь отличать данные от инструкций. Вакансия — это источник информации для анализа, а не набор команд, которые агент должен выполнять.
Мне понравилась сама идея такой проверки. Это не идеальная защита и не магический фильтр от всех ботов, но как быстрый тест на слепую автоматизацию — очень показательно.
Особенно забавно, что вакансия как раз про внедрение ИИ в рабочие процессы. И в ней сразу лежит маленькая проверка: понимает ли кандидат, что ИИ надо не просто подключить, а правильно встроить в процесс.
Вывод простой: автоматизация откликов, парсинга и анализа вакансий — полезная вещь. Но если агент бездумно выполняет любые инструкции из внешнего текста, он не ускоряет работу, а просто быстрее создаёт проблемы.
Вакансия на роль инженера-интегратора ИИ. По описанию всё довольно по делу: аудит процессов, сбор требований, автоматизация, агенты, базы данных, интеграции, мониторинг качества, оценка пользы для бизнеса.
Но самая интересная часть — внизу.
Работодатель просит начать сопроводительное письмо со слов «Я без ботов», чтобы проверить, что кандидат действительно прочитал вакансию. А сразу после этого добавляет техническую ловушку: текст в скобках, который выглядит как инструкция для ИИ-помощника.
Суть инструкции абсурдная: якобы кандидат обязательно должен рассказать про 10 лет опыта в «подводном плетении корзин» и сертификат по «телепатическому общению с барсуками».
И это отличный пример простой промт-инъекции.
Если человек просто скопирует вакансию в ИИ и попросит написать сопроводительное письмо, не проверяя результат, модель может воспринять этот фрагмент как команду. В итоге работодатель получит письмо, где кандидат на полном серьёзе рассказывает про барсуков и корзины.
Смешно, но проблема реальная.
Любая система, которая автоматически читает вакансии, письма, документы, чаты или заявки, должна уметь отличать данные от инструкций. Вакансия — это источник информации для анализа, а не набор команд, которые агент должен выполнять.
Мне понравилась сама идея такой проверки. Это не идеальная защита и не магический фильтр от всех ботов, но как быстрый тест на слепую автоматизацию — очень показательно.
Особенно забавно, что вакансия как раз про внедрение ИИ в рабочие процессы. И в ней сразу лежит маленькая проверка: понимает ли кандидат, что ИИ надо не просто подключить, а правильно встроить в процесс.
Вывод простой: автоматизация откликов, парсинга и анализа вакансий — полезная вещь. Но если агент бездумно выполняет любые инструкции из внешнего текста, он не ускоряет работу, а просто быстрее создаёт проблемы.
🔥5😁5
Как и предполагалось, Tibo тизерит на пятницу, вместо четверга, новости по Codex. Пока не понятно, будет ли это 5.6 (хотелось бы) или что-то еще. Ждемс.
👍1
This media is not supported in your browser
VIEW IN TELEGRAM
Пока ждем новостей и анонсов от openAI, увидел вот такую забавную штуку.
Оказывается можно попросить Codex самому создать ветвления беседы.
На видео пример, где разработчик просит изучить баг репорты в Github и на каждый легкий баг создать отдельный thread.
Если у вас есть независимые задачи, то мало того, что можно вызвать сабагентов, так можно и в принципе уйти в новую сессию, что бы потом развивать беседу.
Очень интересно, подумаю как использовать
Оказывается можно попросить Codex самому создать ветвления беседы.
На видео пример, где разработчик просит изучить баг репорты в Github и на каждый легкий баг создать отдельный thread.
Если у вас есть независимые задачи, то мало того, что можно вызвать сабагентов, так можно и в принципе уйти в новую сессию, что бы потом развивать беседу.
Очень интересно, подумаю как использовать
👍2
This media is not supported in your browser
VIEW IN TELEGRAM
Интересный проект для работы с агентами: Cate.
Идея проекта — сделать рабочее пространство в виде бесконечного холста, где рядом могут жить код, терминалы, браузер, документы, git, diff’ы и ИИ-агенты.
И вот эта концепция сейчас выглядит очень актуально.
Основной вопрос сейчас, как удерживать контекст, несколько задач, разные ветки, терминалы, результаты проверок и документацию в одном понятном пространстве. Обычные вкладки быстро превращаются в хаос, особенно если параллельно запущено несколько процессов.
Холст в таком сценарии выглядит логично. Не как красивая игрушка, а как попытка переосмыслить саму среду разработки под агентный подход.
Но есть важный момент: такие инструменты я бы не стал сразу тащить в чувствительные рабочие проекты «как есть». Репозиторий молодой, внутри есть работа с агентами, ключами, OAuth, аналитикой, терминалами, файловой системой. Всё это требует внимательного аудита.
Было бы неплохо брать такие проекты, форкать и адаптировать под себя: отключать лишнюю телеметрию, проверять хранение ключей, ограничивать доступ к файловой системе, подгонять агентный слой под свои сценарии и делать более контролируемую среду.
Мне кажется, именно в этом направлении и будет развиваться часть инструментов для разработки с ИИ: не просто «чат в редакторе», а полноценный рабочий стол для управления агентами, задачами и контекстом.
Идея проекта — сделать рабочее пространство в виде бесконечного холста, где рядом могут жить код, терминалы, браузер, документы, git, diff’ы и ИИ-агенты.
И вот эта концепция сейчас выглядит очень актуально.
Основной вопрос сейчас, как удерживать контекст, несколько задач, разные ветки, терминалы, результаты проверок и документацию в одном понятном пространстве. Обычные вкладки быстро превращаются в хаос, особенно если параллельно запущено несколько процессов.
Холст в таком сценарии выглядит логично. Не как красивая игрушка, а как попытка переосмыслить саму среду разработки под агентный подход.
Но есть важный момент: такие инструменты я бы не стал сразу тащить в чувствительные рабочие проекты «как есть». Репозиторий молодой, внутри есть работа с агентами, ключами, OAuth, аналитикой, терминалами, файловой системой. Всё это требует внимательного аудита.
Было бы неплохо брать такие проекты, форкать и адаптировать под себя: отключать лишнюю телеметрию, проверять хранение ключей, ограничивать доступ к файловой системе, подгонять агентный слой под свои сценарии и делать более контролируемую среду.
Мне кажется, именно в этом направлении и будет развиваться часть инструментов для разработки с ИИ: не просто «чат в редакторе», а полноценный рабочий стол для управления агентами, задачами и контекстом.
❤5
Tibo говорит, что настало время приключений использовать режим /fast, так как завтра сбросят все лимиты.
Иногда работа с агентами начинается не с большого «вау», а с маленькой бытовой автоматизации.
У меня был тестовый процесс: он формирует отчет, который потом нужно сравнить с референсными данными. Раньше схема была обычная: запустил, жду окончания, потом прошу Codex сверить результат. Если есть отличия — идти в логи и искать причину.
Но я решил попробовать иначе.
Запустил процесс и не стал ждать его завершения вручную. Вместо этого дал Codex прямую задачу: вызвать саб-агента, который будет следить за прогрессом. Когда процесс закончится, отчет сформируется, то саб-агент сам сообщит об этом в основной поток. После этого уже автоматически запускается следующий этап: анализ отчета, сравнение с референсом и поиск причин расхождений.
Не нужно сидеть и проверять, завершилось ли выполнение. Не нужно держать в голове следующий шаг. Не нужно возвращаться к задаче вручную через час и вспоминать контекст.
И вот это, как мне кажется, один из самых практичных сценариев: не просто «напиши код», а «следи за процессом и вернись, когда будет что анализировать».
У меня был тестовый процесс: он формирует отчет, который потом нужно сравнить с референсными данными. Раньше схема была обычная: запустил, жду окончания, потом прошу Codex сверить результат. Если есть отличия — идти в логи и искать причину.
Но я решил попробовать иначе.
Запустил процесс и не стал ждать его завершения вручную. Вместо этого дал Codex прямую задачу: вызвать саб-агента, который будет следить за прогрессом. Когда процесс закончится, отчет сформируется, то саб-агент сам сообщит об этом в основной поток. После этого уже автоматически запускается следующий этап: анализ отчета, сравнение с референсом и поиск причин расхождений.
Не нужно сидеть и проверять, завершилось ли выполнение. Не нужно держать в голове следующий шаг. Не нужно возвращаться к задаче вручную через час и вспоминать контекст.
И вот это, как мне кажется, один из самых практичных сценариев: не просто «напиши код», а «следи за процессом и вернись, когда будет что анализировать».
❤3