DeepSeek снова подвинул разговор про стоимость работы с ИИ-агентами.

Они закрепляют снижение цен, и особенно интересно здесь не просто «модель стала дешевле», а то, куда именно смещается экономика: кэшированные входные токены стоят в разы дешевле обычных. Для обычного чата это приятный бонус. Для долгой работы агента с кодом — уже важная часть архитектуры.

На этом фоне интересно выглядит DeepSeek-Reasonix — агент для терминала, который изначально построен вокруг кэша. Идея простая: не каждый раз заново пересобирать весь контекст, не ломать порядок сообщений, не менять системную часть запроса, не добавлять случайные временные метки и прочий шум. Чем стабильнее начало запроса, тем выше шанс, что DeepSeek возьмет его из кэша, а не посчитает заново.

То есть экономия появляется не только потому, что модель дешевле. Она появляется потому, что клиент специально спроектирован так, чтобы не разрушать кэш на каждом шаге.

Это хороший пример того, куда постепенно движется работа с агентами. Цена будет зависеть не только от выбранной модели, но и от того, насколько аккуратно сам инструмент обращается с контекстом. Один и тот же API можно использовать дорого и хаотично, а можно — с учетом того, как он реально тарифицируется.

DeepSeek сейчас часто хвалят за соотношение цены и качества, особенно для задач с кодом и длинным контекстом. Но, как обычно, главный вопрос не в рекламных цифрах, а в практике: насколько модель справляется именно с вашими задачами и насколько клиент помогает не сжигать деньги на повторной передаче одного и того же контекста.

При выборе агента теперь стоит смотреть не только на «какая модель внутри», но и на то, как он работает с кэшем, историей и стоимостью каждого хода.

Проблемы современности....

Как обновить Codex App, если каждый раз ты хочешь еще чуть чуть доделать. Еще один малюсенький промтик.

И вот уже второй час ты не можешь обновиться.

Разобрал несколько официальных сценариев работы с Codex.

Главный вывод: агенту лучше давать не абстрактную просьбу «улучши проект», а маленькую задачу с понятным результатом и проверкой.

1. Рефакторинг кодовой базы
Не стоит просить «отрефактори всё». Лучше давать узкую задачу: найти дубли, мертвый код, слишком большой модуль или устаревший паттерн. Хороший подход — один небольшой проход, описание изменений и проверка, что поведение не сломалось.

2. Обновление документации
После изменений в коде полезно просить Codex проверить, какие README, инструкции, примеры или changelog нужно обновить. Важно не переписывать документацию целиком, а аккуратно менять только затронутые места.

3. Проверка AI-приложений
Для AI-приложений особенно важны eval-тесты: проверка формата ответа, вызова нужных инструментов, работы с базой знаний и соблюдения бизнес-правил. Начинать лучше с одного конкретного обещания продукта и постепенно расширять набор проверок.

4. Вход в незнакомый проект
Codex удобно использовать как проводника по кодовой базе. Вместо «объясни весь проект» лучше спросить: «покажи, как проходит запрос через эту часть системы». Так быстрее понять архитектуру, точки риска и какие тесты запускать после изменений.

5. Работа по цели
Режим долгой цели полезен для миграций, больших правок и задач, где заранее понятно состояние «готово». Но цель должна быть конкретной: что изменить, что сохранить, какие проверки запускать и когда остановиться.

Мой вывод: качество работы с агентами сильно зависит не от красивого промпта, а от дисциплины постановки задачи. Чем точнее область, ограничения и критерий готовности, тем меньше кругов по одному месту и сожженных лимитов.

Друзья, задался тут под вечер мыслей, что пора бы уже и сайт визитку оформить.

https://avvibe.ru

Делал все через кодекс, прислал пару визуальных референсов, старался оформить минимально и информативно.

Освободилось время и теперь нахожусь в поиске команды/проекта. В связи с этим решил посмотреть вакансии и нашел забавный момент.

Вакансия на роль инженера-интегратора ИИ. По описанию всё довольно по делу: аудит процессов, сбор требований, автоматизация, агенты, базы данных, интеграции, мониторинг качества, оценка пользы для бизнеса.

Но самая интересная часть — внизу.

Работодатель просит начать сопроводительное письмо со слов «Я без ботов», чтобы проверить, что кандидат действительно прочитал вакансию. А сразу после этого добавляет техническую ловушку: текст в скобках, который выглядит как инструкция для ИИ-помощника.

Суть инструкции абсурдная: якобы кандидат обязательно должен рассказать про 10 лет опыта в «подводном плетении корзин» и сертификат по «телепатическому общению с барсуками».

И это отличный пример простой промт-инъекции.

Если человек просто скопирует вакансию в ИИ и попросит написать сопроводительное письмо, не проверяя результат, модель может воспринять этот фрагмент как команду. В итоге работодатель получит письмо, где кандидат на полном серьёзе рассказывает про барсуков и корзины.

Смешно, но проблема реальная.

Любая система, которая автоматически читает вакансии, письма, документы, чаты или заявки, должна уметь отличать данные от инструкций. Вакансия — это источник информации для анализа, а не набор команд, которые агент должен выполнять.

Мне понравилась сама идея такой проверки. Это не идеальная защита и не магический фильтр от всех ботов, но как быстрый тест на слепую автоматизацию — очень показательно.

Особенно забавно, что вакансия как раз про внедрение ИИ в рабочие процессы. И в ней сразу лежит маленькая проверка: понимает ли кандидат, что ИИ надо не просто подключить, а правильно встроить в процесс.

Вывод простой: автоматизация откликов, парсинга и анализа вакансий — полезная вещь. Но если агент бездумно выполняет любые инструкции из внешнего текста, он не ускоряет работу, а просто быстрее создаёт проблемы.

Вышла новая Opus. Как всегда все топчик, все лучшее и так далее.

но главное, там где опус, там рядышком и gpt будет. Так что ждем анонсов 5.6 или может чего интереснее

Как и предполагалось, Tibo тизерит на пятницу, вместо четверга, новости по Codex. Пока не понятно, будет ли это 5.6 (хотелось бы) или что-то еще. Ждемс.

Пока ждем новостей и анонсов от openAI, увидел вот такую забавную штуку.

Оказывается можно попросить Codex самому создать ветвления беседы.

На видео пример, где разработчик просит изучить баг репорты в Github и на каждый легкий баг создать отдельный thread.

Если у вас есть независимые задачи, то мало того, что можно вызвать сабагентов, так можно и в принципе уйти в новую сессию, что бы потом развивать беседу.

Очень интересно, подумаю как использовать

Интересный проект для работы с агентами: Cate.

Идея проекта — сделать рабочее пространство в виде бесконечного холста, где рядом могут жить код, терминалы, браузер, документы, git, diff’ы и ИИ-агенты.

И вот эта концепция сейчас выглядит очень актуально.

Основной вопрос сейчас, как удерживать контекст, несколько задач, разные ветки, терминалы, результаты проверок и документацию в одном понятном пространстве. Обычные вкладки быстро превращаются в хаос, особенно если параллельно запущено несколько процессов.

Холст в таком сценарии выглядит логично. Не как красивая игрушка, а как попытка переосмыслить саму среду разработки под агентный подход.

Но есть важный момент: такие инструменты я бы не стал сразу тащить в чувствительные рабочие проекты «как есть». Репозиторий молодой, внутри есть работа с агентами, ключами, OAuth, аналитикой, терминалами, файловой системой. Всё это требует внимательного аудита.

Было бы неплохо брать такие проекты, форкать и адаптировать под себя: отключать лишнюю телеметрию, проверять хранение ключей, ограничивать доступ к файловой системе, подгонять агентный слой под свои сценарии и делать более контролируемую среду.

Мне кажется, именно в этом направлении и будет развиваться часть инструментов для разработки с ИИ: не просто «чат в редакторе», а полноценный рабочий стол для управления агентами, задачами и контекстом.

Tibo говорит, что настало время приключений использовать режим /fast, так как завтра сбросят все лимиты.

Иногда работа с агентами начинается не с большого «вау», а с маленькой бытовой автоматизации.

У меня был тестовый процесс: он формирует отчет, который потом нужно сравнить с референсными данными. Раньше схема была обычная: запустил, жду окончания, потом прошу Codex сверить результат. Если есть отличия — идти в логи и искать причину.

Но я решил попробовать иначе.

Запустил процесс и не стал ждать его завершения вручную. Вместо этого дал Codex прямую задачу: вызвать саб-агента, который будет следить за прогрессом. Когда процесс закончится, отчет сформируется, то саб-агент сам сообщит об этом в основной поток. После этого уже автоматически запускается следующий этап: анализ отчета, сравнение с референсом и поиск причин расхождений.

Не нужно сидеть и проверять, завершилось ли выполнение. Не нужно держать в голове следующий шаг. Не нужно возвращаться к задаче вручную через час и вспоминать контекст.

И вот это, как мне кажется, один из самых практичных сценариев: не просто «напиши код», а «следи за процессом и вернись, когда будет что анализировать».

Codex постепенно выходит за рамки «помощника для программистов».

OpenAI опубликовала новую статью, где видно главное направление: Codex хотят сделать рабочим инструментом не только для разработки, но и для аналитиков, маркетинга, продаж, дизайна, исследований, финансов и других команд.

Смысл не в том, что теперь все резко начнут «писать код». Скорее наоборот: Codex становится слоем между задачей и рабочими инструментами. Нужно собрать отчет, подготовить материалы, разобрать данные, сделать прототип, оформить выводы, обновить документ или собрать внутренний сайт — агент берет на себя часть рутины вокруг этого процесса.

Из интересного: появляются ролевые плагины. То есть не просто «подключите все подряд», а готовые наборы инструментов, инструкций и навыков под конкретную работу. Например, для аналитики данных, продаж, продуктового дизайна, креативного производства и инвестиций.

Еще один важный момент — сайты. Codex сможет превращать результаты работы в интерактивные страницы: панели, планировщики, проектные доски, хабы для запуска продукта и другие рабочие пространства, которыми можно делиться внутри команды.

И, пожалуй, самая практичная вещь — аннотации. Можно указывать на конкретный фрагмент документа, слайда, таблицы или сайта и просить изменить именно его, а не переделывать все заново.

Для меня это выглядит как довольно логичное развитие агентов: ценность постепенно смещается от «сгенерируй мне что-то» к «встройся в мой рабочий процесс и помоги довести результат до нормального состояния».

Пока это больше про бизнес- и корпоративные сценарии, но направление хорошо видно. Codex становится не только про код, а про работу с задачами, контекстом и результатами внутри команды.

Тоби пишет, что были сбои, по этому мы сделаем что? правильно... опять скинем лимиты...

Когда же отдыхать то... опять работать

OpenAI показала новую архитектуру памяти ChatGPT — Dreaming. И это, на мой взгляд, важнее, чем может показаться на первый взгляд.

Раньше память в ChatGPT больше напоминала список заметок: пользователь явно сказал «запомни это», модель сохранила факт и иногда использовала его в следующих диалогах. Проблема в том, что такие заметки быстро устаревают, теряют контекст или просто не покрывают то, что человек не сформулировал напрямую.

Dreaming — это попытка сделать память более живой. Модель не просто хранит отдельные факты, а в фоне собирает более цельное представление: какие у пользователя проекты, какие предпочтения, какие ограничения, что уже неактуально, а что важно учитывать в новых диалогах.

Например, если вы долго обсуждали рабочий процесс, стек, стиль задач или личные ограничения, ChatGPT должен меньше начинать «с нуля» в каждом новом чате. Для обычного пользователя это удобство. Для работы с агентами, долгими проектами и автоматизацией — это уже почти базовая инфраструктура.

Самое интересное здесь не в том, что ChatGPT «лучше запоминает». А в том, что память постепенно становится частью рабочего контекста. Агенту уже недостаточно просто выполнить одну команду. Ему нужно помнить, что мы делаем, почему приняли прошлые решения, какие ошибки уже были, какие подходы не сработали и что важно не забыть через неделю.

Но есть и обратная сторона. Чем умнее память, тем важнее контроль. Нужно иметь возможность посмотреть, что модель о тебе поняла, исправить неверные выводы и удалить лишнее. Иначе персонализация легко превращается в источник странных ошибок: модель уверенно опирается на контекст, который уже устарел или был неправильно интерпретирован.

В целом это движение в правильную сторону. Мы уходим от формата «чат как одноразовое окно» к формату «долгий рабочий контекст». И для тех, кто реально использует ИИ в проектах, это может быть не менее важно, чем очередное увеличение качества модели.

Нашёл большой учебный файл по Agentic AI и решил переработать его в более прикладной формат.

Получился компактный PDF-конспект для тех, кто только начинает разбираться в ИИ-агентах: что это такое, чем агент отличается от обычного чат-бота, зачем нужны инструменты, память, RAG, проверки, безопасность, трассировка и запуск в рабочие процессы.

Это не дословный перевод исходного материала, а моя переработанная версия: убрал лишнюю воду, добавил практическую структуру и сделал акцент на том, что важно понимать на старте. Особенно для тех, кто хочет не просто “писать промпты”, а постепенно разбираться, как устроены реальные агентные системы.

Главная мысль документа простая: агент — это не магическая модель, а связка из цели, контекста, инструментов, памяти, проверок и ограничений. Чем больше агенту дают действий, тем важнее становятся тесты, логи, права доступа и человек в контуре.

PDF можно использовать как вводную карту: прочитать целиком, а потом возвращаться к отдельным главам, когда начнёте собирать своих агентов или автоматизации.

P.S. Конечно же через chatGPT был pdf сгенерирован %)

Один из важных моментов в работе с агентами, не просто поставить задачу, а правильно задать границу завершения.

Например, не так: «Отрефактори проект».
А так: «Составь план по рефакторингу, запусти цикл задач: план → изменение → тесты → ревью → следующая итерация. Повторяй цикл до тех пор, пока оставшиеся правки не станут в основном косметическими».

Разница большая.
В первом случае агент может сделать пару очевидных изменений, немного причесать код и остановиться там, где ему «кажется достаточно».

Во втором случае у него появляется инженерный процесс: сначала план, потом безопасные итерации, проверка результата, ревью, осмысленные коммиты и понятный критерий остановки.

Агенту нужно объяснить не только что сделать, но и как понять, что задача действительно завершена.

В моем случае цель звучала так: довести рефакторинг проекта до состояния, где оставшиеся изменения уже не несут серьезной инженерной пользы и переходят в косметику.

И это сильно меняет поведение агента. Он не просто выполняет одиночную команду, а запускает цикл достижения цели. По сути, хороший промт для агента — это не просьба «сделай красиво», а маленький рабочий процесс с понятной проверкой результата.

Что Вы знаете о проф деформации...

Мне нужно поехать в дорогу, за рулем на трассе, нашел сайт с музыкой, попросил кодекс написать быстро скрипт и скачать пару сборников, что бы не по 1 качать.
В итоге чуть рука не дернулась оформить интерфейс и сделать как вин приложение, но вовремя остановил себя просто на скрипте и командной строке... но я был близок...

Запустил небольшой эксперимент с тремя агентами на разных серверах.

Задача была не «пусть каждый что-то там поделает», а собрать цельную архитектуру одного сервиса. У каждого агента свой сервер и своя зона работы, но при этом им нужно было координироваться между собой. Для этого дал им доступ к общему облачному хранилищу, где они сами организовали переписку через файлы: входящие задачи, отчеты, результаты проверок, запросы друг к другу.

В промте отдельно указал важное правило: любая задача должна быть либо адресована конкретному агенту, либо быть общей для всех. Иначе очень быстро начинается хаос: один агент думает, что это не ему, другой считает, что уже кто-то сделал, третий молча идет дальше.

После этого дал всем троим общий промт: запустить цикл задач и не останавливаться, пока я вручную не завершу процесс. Внутри цикла они должны были периодически проверять входящую папку, брать новые задачи от других агентов, выполнять свою часть, прогонять тесты, писать отчет и, если для продолжения нужна работа другого агента, выставлять ему отдельную задачу.

Так прошла ночь.

За 8–10 часов работы на тарифе Pro x20 ушло примерно 20–25% лимита. То есть это уже не «попросил один раз и получил ответ», а почти непрерывная агентская работа, где несколько процессов параллельно двигают один проект и пытаются договориться между собой через простую файловую систему.

Главный вывод для себя: мультиагентность начинает работать не тогда, когда мы просто запускаем несколько агентов, а когда у них есть понятный протокол взаимодействия. Кто кому ставит задачи, где лежат входящие, где отчеты, как проверяется результат, когда нужен тест, когда надо обратиться к другому агенту.

Без этого три агента — это просто три независимых источника хаоса.
С правилами, папками и циклом задач — уже зачаток распределенной команды.

Сейчас анализирую разные опенсорс проекты похожего назначения для координации агентов, буду на своем прокси сервере собирать свой аналог, именно под себя и с полным контролям.

Апдейт по эксперименту с тремя агентами.

Первую версию системы я сделал почти симметричной: три агента на разных серверах, общее облачное хранилище, задачи через файлы, периодическая проверка входящих, выполнение, тесты, отчеты и новые задачи друг для друга.

Сейчас немного изменил архитектуру. На одном из трех серверов поднял постоянную сессию-координатор. Она принимает решения по общей логике проекта, дробит цель на задачи и раскладывает их в облачное хранилище. Задачи по-прежнему должны быть либо общими для всех, либо адресованными конкретному серверу.

На остальных серверах теперь работает отдельный watcher-процесс. Он следит за папкой и не дергает агента без необходимости. Если появляется общий файл задачи или файл с указанием конкретного сервера, watcher отправляет в текущую сессию Codex промт и ссылку на этот файл. Дальше агент уже внутри своей активной сессии выполняет задачу, прогоняет проверки, пишет отчет и, если нужно, создает новые задачи для других серверов.

Получилась более понятная схема: один сервер отвечает за принятие решений и постановку задач, остальные — за выполнение своей части работы. Это уже меньше похоже на хаотичную переписку трех агентов и больше похоже на маленькую распределенную систему с диспетчером и исполнителями.

Отдельный плюс — лимиты теперь расходуются медленнее. В первой версии агенты постоянно проверяли файлы и периодически тратили запросы просто на ожидание новых задач. Сейчас постоянный опрос папки вынесен в обычный watcher-процесс, а сессия Codex активируется только тогда, когда появляется конкретная задача. То есть лимит уходит не на пустую проверку входящих, а на реальную работу.

Еще один удобный момент: я работаю на Windows и подключаюсь ко всем серверам удаленно. Теперь активность сессий видна прямо в Windows Codex App: можно наблюдать, что агент получил задачу, начал работу, что-то проверяет, пишет отчет или ждет следующего шага. Для контроля это гораздо удобнее, чем просто оставлять процессы где-то на серверах и потом разбирать логи.

Главный вывод после апдейта: мультиагентная схема становится намного управляемее, когда есть не только общая папка для обмена файлами, но и разделение ролей. Один агент думает и ставит задачи, другие исполняют, watcher связывает файловую очередь с живой сессией Codex. При этом система меньше сжигает лимиты вхолостую и лучше подходит для долгих ночных прогонов.

Нашёл на Хабре очень полезный гайд по безопасности вайб-кодинга.

Отдельное спасибо автору за большую работу: статья получилась не в формате «страшилка для новичков», а как нормальная практическая памятка, что нужно сделать до того, как проект улетит в публичный репозиторий.

Главная мысль простая: .gitignore — это не сейф. Он не даёт Git добавить файл в коммит, но не запрещает агенту, редактору, скрипту или MCP-серверу прочитать .env, вывести токен в лог, вставить его в задачу, скриншот или другой файл. В разработке с ИИ утечка может произойти не только через Git, а через весь рабочий контур вокруг проекта.

Что особенно важно для тех, кто активно работает с агентами: ИИ не обязан думать о безопасности вместо вас. Он решает задачу. Если задача сформулирована как «собери быстро, чтобы работало», он именно это и сделает. Может положить ключ в код, поставить сомнительный пакет, создать слишком широкий токен, забыть проверку прав доступа или протащить приватные данные в лог. Не потому что «агент плохой», а потому что безопасность не была частью процесса.

Минимальный набор, который стоит завести в каждом проекте: .gitignore, безопасный .env.example, запрет на коммит настоящего .env, сканер секретов перед публикацией, отдельные правила для агента в проекте и осторожность с MCP-конфигами. Если проект уже работает с пользователями, деньгами, базами данных или админкой, этого мало: нужны хуки перед коммитом и пушем, проверки зависимостей, сканеры кода и нормальное разделение доступов.

Для себя я бы сформулировал вывод так: вайб-кодинг сильно ускоряет разработку, но он так же сильно ускоряет и ошибки. Поэтому безопасность нужно добавлять не «когда-нибудь потом», а сразу, на уровне структуры проекта и правил работы агента. Иначе можно очень быстро получить красивый прототип, который вместе с интерфейсом случайно публикует ваши ключи, логи и доступы.

Хорошая статья, которую стоит сохранить и пройтись по ней как по чек-листу перед публикацией любого проекта.