В каждой шутки, лишь доля шутки.
Сейчас никого уже не удивишь агентами на реальных задачах, а это много параллельных вызовов, длинные контексты, постоянные ретраи.
И внезапно упираешься не в качество моделей, а в банальную экономику: счётчик токенов становится главным ограничением.
Текущий рост спроса перекрывался демпингом со стороны провайдеров. Бесплатные кредиты, дешёвые тарифы, «поиграться и привыкнуть». Сейчас нагрузка растёт быстрее, чем вводятся новые мощности. И это начинает выравнивать цены вверх.
По факту оказалось, что токены — это не абстрактная метрика, а дефицитный ресурс. Особенно если строишь агентные системы, где один пользовательский запрос превращается в десятки внутренних.
Дешёвые токены были фазой роста, а не нормой. Дальше придётся проектировать системы с учётом стоимости как первого класса ограничения, а не постфактум.
Похоже, оптимизация промптов и архитектуры снова становится не «хорошей практикой», а необходимостью.
Сейчас никого уже не удивишь агентами на реальных задачах, а это много параллельных вызовов, длинные контексты, постоянные ретраи.
И внезапно упираешься не в качество моделей, а в банальную экономику: счётчик токенов становится главным ограничением.
Текущий рост спроса перекрывался демпингом со стороны провайдеров. Бесплатные кредиты, дешёвые тарифы, «поиграться и привыкнуть». Сейчас нагрузка растёт быстрее, чем вводятся новые мощности. И это начинает выравнивать цены вверх.
По факту оказалось, что токены — это не абстрактная метрика, а дефицитный ресурс. Особенно если строишь агентные системы, где один пользовательский запрос превращается в десятки внутренних.
Дешёвые токены были фазой роста, а не нормой. Дальше придётся проектировать системы с учётом стоимости как первого класса ограничения, а не постфактум.
Похоже, оптимизация промптов и архитектуры снова становится не «хорошей практикой», а необходимостью.
👍4😁1
OpenAI тихо выкатила новый realtime-стек в Audio Playground.
Появились модели:
—
—
—
Без большого анонса или отдельного релиза. Просто новые модели начали появляться в интерфейсе и API.
Самый интересный момент — вместе с этим OpenAI показала первые аудио-бенчмарки.
На Big Bench Audio Intelligence:
А на Audio MultiChallenge Instruction Following:
48.5% против 34.7%.
То есть речь уже не только про распознавание голоса.
Судя по тестам, модели заметно лучше понимают аудио-инструкции, удерживают контекст разговора и работают с длинными голосовыми взаимодействиями.
По факту начинает ломаться старая схема:
speech-to-text → LLM → text-to-speech
Realtime-модели постепенно превращаются в отдельный класс систем, где голос, понимание, ответы и tool calling работают внутри одного потока.
И это уже намного ближе к нормальным голосовым агентам, а не просто «озвученному чат-боту».
Отдельно интересно появление
Похоже, OpenAI начинает двигаться в сторону постоянного realtime-перевода и мультиязычных диалогов без переключения пайплайнов.
Пока всё это раскатывается довольно тихо.
Но выглядит как подготовка к следующему крупному обновлению Voice Mode в ChatGPT.
Теперь интересно посмотреть, насколько стабильно это будет работать в длинных диалогах, перебиваниях и агентных сценариях с постоянными вызовами инструментов.
Появились модели:
—
gpt-realtime-2—
gpt-realtime-whisper—
gpt-realtime-translateБез большого анонса или отдельного релиза. Просто новые модели начали появляться в интерфейсе и API.
Самый интересный момент — вместе с этим OpenAI показала первые аудио-бенчмарки.
На Big Bench Audio Intelligence:
gpt-realtime-2 показывает ~96.6% против ~81.4% у realtime-1.5.А на Audio MultiChallenge Instruction Following:
48.5% против 34.7%.
То есть речь уже не только про распознавание голоса.
Судя по тестам, модели заметно лучше понимают аудио-инструкции, удерживают контекст разговора и работают с длинными голосовыми взаимодействиями.
По факту начинает ломаться старая схема:
speech-to-text → LLM → text-to-speech
Realtime-модели постепенно превращаются в отдельный класс систем, где голос, понимание, ответы и tool calling работают внутри одного потока.
И это уже намного ближе к нормальным голосовым агентам, а не просто «озвученному чат-боту».
Отдельно интересно появление
gpt-realtime-translate.Похоже, OpenAI начинает двигаться в сторону постоянного realtime-перевода и мультиязычных диалогов без переключения пайплайнов.
Пока всё это раскатывается довольно тихо.
Но выглядит как подготовка к следующему крупному обновлению Voice Mode в ChatGPT.
Теперь интересно посмотреть, насколько стабильно это будет работать в длинных диалогах, перебиваниях и агентных сценариях с постоянными вызовами инструментов.
👍6
Похоже, OpenAI готовит более глубокую интеграцию Codex прямо в мобильное приложение ChatGPT.
Поводом для спекуляций стал пост Сэма Альтмана “call me maybe”, где он цитирует официальный аккаунт ChatGPT с визуалом, который многие восприняли как тизер. Отдельно обсуждается формулировка: использовать ChatGPT на телефоне, чтобы продолжать работу с Codex, пока компьютер остаётся включённым.
Главная идея, что с развитием агентов уже не нужно постоянно сидеть за компьютером, чтобы контролировать работу.
Агент может выполнять задачу на десктопе или в облаке, а вы — проверить прогресс с телефона, дать уточнение, остановить неудачный ход или поставить следующую задачу по дороге, в магазине или на прогулке.
Полностью заменить компьютер для серьёзной разработки или корпоративной работы это не сможет. Но возможность оперативно реагировать и управлять агентом с телефона — это уже большой сдвиг в том, как будет выглядеть работа с AI-инструментами.
Поводом для спекуляций стал пост Сэма Альтмана “call me maybe”, где он цитирует официальный аккаунт ChatGPT с визуалом, который многие восприняли как тизер. Отдельно обсуждается формулировка: использовать ChatGPT на телефоне, чтобы продолжать работу с Codex, пока компьютер остаётся включённым.
Главная идея, что с развитием агентов уже не нужно постоянно сидеть за компьютером, чтобы контролировать работу.
Агент может выполнять задачу на десктопе или в облаке, а вы — проверить прогресс с телефона, дать уточнение, остановить неудачный ход или поставить следующую задачу по дороге, в магазине или на прогулке.
Полностью заменить компьютер для серьёзной разработки или корпоративной работы это не сможет. Но возможность оперативно реагировать и управлять агентом с телефона — это уже большой сдвиг в том, как будет выглядеть работа с AI-инструментами.
👍2
https://chatgpt.com/codex/switch-to-codex/
openAI добавили в Codex возможность мигрировать данных из Claude Code в Codex. Самое время присоединиться к нашему клубу chatGPT!
Друзья, я стал писать больше на общие темы, это связанно в первую очередь с рабочей нагрузкой. Знакомства дают контакты, контакты проекты.
С одной стороны я много пробую, тестирую, с другой без контекста проекта сложно описать почему было сделано то или иное, а контекст рассказывать особо пока нельзя.
Но хочу поделиться буквально пару фраз. Если вам нужно сделать какие то агнетские действия, вроде вызова tool или loop action - смело изучайте и форкайте PI-AI агента, хорошая минималистичная база. Еще конечно же стоит посмотреть и изучить Hermes.
Повторю мысль: не тащите все как есть, без разбору и оглядки. Попросите своего кодового агента изучить репозиторий, опишите свои задачи и спросите. как это можно реализовать, используя эти агенты как референс.
Таким образом вы сможете закрыть продакшен потребности на минимальном коде, и при этом не клонируя все и вся.
openAI добавили в Codex возможность мигрировать данных из Claude Code в Codex. Самое время присоединиться к нашему клубу chatGPT!
Друзья, я стал писать больше на общие темы, это связанно в первую очередь с рабочей нагрузкой. Знакомства дают контакты, контакты проекты.
С одной стороны я много пробую, тестирую, с другой без контекста проекта сложно описать почему было сделано то или иное, а контекст рассказывать особо пока нельзя.
Но хочу поделиться буквально пару фраз. Если вам нужно сделать какие то агнетские действия, вроде вызова tool или loop action - смело изучайте и форкайте PI-AI агента, хорошая минималистичная база. Еще конечно же стоит посмотреть и изучить Hermes.
Повторю мысль: не тащите все как есть, без разбору и оглядки. Попросите своего кодового агента изучить репозиторий, опишите свои задачи и спросите. как это можно реализовать, используя эти агенты как референс.
Таким образом вы сможете закрыть продакшен потребности на минимальном коде, и при этом не клонируя все и вся.
Chatgpt
Switch to Codex
Switch to Codex the moment rate limits hit—connect your existing project and keep coding without interruption. Seamlessly migrate your workflow for faster, more reliable continuous development.
👍4
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