Прочитал разбор атаки Clinejection — довольно показательная история про безопасность AI-инструментов.
Исследователь показал, что у Cline был GitHub workflow, где Claude автоматически триажил новые issues. Звучит удобно: бот читает issue и помогает команде разбирать входящие баги.
Проблема в том, что заголовок issue напрямую подставлялся в prompt. Без какой-либо фильтрации. В итоге злоумышленник мог просто написать специальный текст — и агент воспринимал его как инструкцию.
Дальше начинается цепочка: prompt injection → выполнение команды → отравление кэша CI → кража токенов публикации. Через это можно было получить доступ к релиз-пайплайну и опубликовать вредоносную версию инструмента для миллионов разработчиков.
Самый интересный инсайт — проблема вообще не в модели.
Проблема в архитектуре.
Когда агенту дают доступ к инструментам, CI и секретам, любой текст становится потенциальной точкой входа. Issue, PR, README, комментарий в коде — всё это может оказаться «инструкцией» для агента.
Поэтому мало написать функционал сервиса. Нужно сразу думать, какие текстовые входы могут управлять агентом и что он имеет право делать.
Похоже, безопасность агентных систем — это отдельная инженерная дисциплина, которая активно начинает формироваться.
PS понравилась картинка, взял у автора статьи на habr, ссылка есть, автору за статью респект и уважение.
Исследователь показал, что у Cline был GitHub workflow, где Claude автоматически триажил новые issues. Звучит удобно: бот читает issue и помогает команде разбирать входящие баги.
Проблема в том, что заголовок issue напрямую подставлялся в prompt. Без какой-либо фильтрации. В итоге злоумышленник мог просто написать специальный текст — и агент воспринимал его как инструкцию.
Дальше начинается цепочка: prompt injection → выполнение команды → отравление кэша CI → кража токенов публикации. Через это можно было получить доступ к релиз-пайплайну и опубликовать вредоносную версию инструмента для миллионов разработчиков.
Самый интересный инсайт — проблема вообще не в модели.
Проблема в архитектуре.
Когда агенту дают доступ к инструментам, CI и секретам, любой текст становится потенциальной точкой входа. Issue, PR, README, комментарий в коде — всё это может оказаться «инструкцией» для агента.
Поэтому мало написать функционал сервиса. Нужно сразу думать, какие текстовые входы могут управлять агентом и что он имеет право делать.
Похоже, безопасность агентных систем — это отдельная инженерная дисциплина, которая активно начинает формироваться.
PS понравилась картинка, взял у автора статьи на habr, ссылка есть, автору за статью респект и уважение.
👍3🤔1💯1
Последние пару дней активно гоняю gpt-5.4 в кодинге.
В основном на реальных задачах — правки в проекте, мелкие фичи, рефакторинг. Первое ощущение — модель стала работать намного спокойнее.
Раньше многие модели любили «размахиваться»: переписать полфайла, предложить новую архитектуру, поменять структуру проекта. иногда это полезно, но чаще ломает поток разработки.
С 5.4 ощущение другое. Она чаще делает локальные изменения, старается не трогать лишнее и аккуратно вписывается в существующий код. Активно использует git worktree, а затем еще пару раз все проверить, прежде чем мерджить в основную ветку.
Если даёшь чёткую инструкцию — модель реально держится в её границах. Не начинает импровизировать и не пытается «улучшить всё вокруг». По ощущениям это ближе к работе с аккуратным коллегой, чем с генератором идей.
Интересно, что некоторые разработчики отмечают, что модель стала проще управляться и лучше подходит для длинных агентных workflow. При этом прогресс на бенчмарках выглядит скорее эволюционным, а не резким скачком.
Мне кажется, что основной апгрейд 5.4 — не интеллект, а управляемость.
А для реальной разработки это, возможно, даже важнее.
В основном на реальных задачах — правки в проекте, мелкие фичи, рефакторинг. Первое ощущение — модель стала работать намного спокойнее.
Раньше многие модели любили «размахиваться»: переписать полфайла, предложить новую архитектуру, поменять структуру проекта. иногда это полезно, но чаще ломает поток разработки.
С 5.4 ощущение другое. Она чаще делает локальные изменения, старается не трогать лишнее и аккуратно вписывается в существующий код. Активно использует git worktree, а затем еще пару раз все проверить, прежде чем мерджить в основную ветку.
Если даёшь чёткую инструкцию — модель реально держится в её границах. Не начинает импровизировать и не пытается «улучшить всё вокруг». По ощущениям это ближе к работе с аккуратным коллегой, чем с генератором идей.
Интересно, что некоторые разработчики отмечают, что модель стала проще управляться и лучше подходит для длинных агентных workflow. При этом прогресс на бенчмарках выглядит скорее эволюционным, а не резким скачком.
Мне кажется, что основной апгрейд 5.4 — не интеллект, а управляемость.
А для реальной разработки это, возможно, даже важнее.
❤1👍1
Друзья, выложил стрим от 14 февраля 2026.
Всем приятного просмотра
https://youtu.be/-7gLuyQG_2k?si=XJWVKGH-RaXwyRwn
Всем приятного просмотра
https://youtu.be/-7gLuyQG_2k?si=XJWVKGH-RaXwyRwn
Потихоньку я привожу в порядок свой роутер, о котором рассказывал ранее.
Пока будем работать только с GPT-5.4 через терминальный клиент Claude Code CLI.
Кому это будет интересно - людям, кто хочет попробовать себя в вайб кодинге и не хочет заморачиваться с подпискам.
Сам я тестирую уже на реальном продакшене, но не готов гарантировать стабильность другим, по этому лучше, если пока роутер будет все же как учебный полигон, где вы можете что-то протестировать.
Хочу предоставить доступ на время теста для 5 человек, с каждого будет взят взнос по 1000 рублей (одна тысяча рублей), которые пойдут на закупки аккаунтов и оплату сервера.
Проведем анализ стабильности канала, поищем какие то баги, посмотрим сколько реально тратят 5 человек лимитов. Нужна аналитика, для аналитики нужны данные реального использования.
Пишите в лс или в комментариях. Кто уже писал, пожалуйста, напомните о себе.
Если у вас есть друзья / знакомые, кто только начинает, перешлите этот пост, может быть кому то реально поможет.
Пока будем работать только с GPT-5.4 через терминальный клиент Claude Code CLI.
Кому это будет интересно - людям, кто хочет попробовать себя в вайб кодинге и не хочет заморачиваться с подпискам.
Сам я тестирую уже на реальном продакшене, но не готов гарантировать стабильность другим, по этому лучше, если пока роутер будет все же как учебный полигон, где вы можете что-то протестировать.
Хочу предоставить доступ на время теста для 5 человек, с каждого будет взят взнос по 1000 рублей (одна тысяча рублей), которые пойдут на закупки аккаунтов и оплату сервера.
Проведем анализ стабильности канала, поищем какие то баги, посмотрим сколько реально тратят 5 человек лимитов. Нужна аналитика, для аналитики нужны данные реального использования.
Пишите в лс или в комментариях. Кто уже писал, пожалуйста, напомните о себе.
Если у вас есть друзья / знакомые, кто только начинает, перешлите этот пост, может быть кому то реально поможет.
🔥4
Сегодня наблюдал интересный момент при работе с агентом во время разработки.
Я дал довольно простую инструкцию: оформить дизайн-документ и начинать реализацию без ожидания моего подтверждения. Раньше подобные вещи обычно требовали ручного контроля — проверить план, подтвердить шаги, потом уже запускать код.
Агент отреагировал иначе.
Он сначала сохранил дизайн и план, затем автоматически переключился в режим реализации. Поднял изолированное рабочее дерево через git worktrees, подключил сабагентов и начал выполнять план в текущей сессии.
Фактически он сам собрал рабочий пайплайн:
дизайн → план → изолированная среда → выполнение.
Самый интересный момент — постепенно исчезает необходимость микроменеджмента. Раньше агентам нужно было говорить каждый следующий шаг. Теперь достаточно задать направление и границы.
По факту начинаешь больше управлять процессом, чем отдельными действиями.
Пока выглядит так, что агенты постепенно переходят из режима «инструмента» в режим «исполнителя».
Интересно посмотреть, как далеко это зайдет, когда таких агентов станет не один, а целый рой.
Ниже прикладываю цепочку действий от агента (прям да, прям скопировал из чата, только удалил пару системных строк и путей проекта):
Я дал довольно простую инструкцию: оформить дизайн-документ и начинать реализацию без ожидания моего подтверждения. Раньше подобные вещи обычно требовали ручного контроля — проверить план, подтвердить шаги, потом уже запускать код.
Агент отреагировал иначе.
Он сначала сохранил дизайн и план, затем автоматически переключился в режим реализации. Поднял изолированное рабочее дерево через git worktrees, подключил сабагентов и начал выполнять план в текущей сессии.
Фактически он сам собрал рабочий пайплайн:
дизайн → план → изолированная среда → выполнение.
Самый интересный момент — постепенно исчезает необходимость микроменеджмента. Раньше агентам нужно было говорить каждый следующий шаг. Теперь достаточно задать направление и границы.
По факту начинаешь больше управлять процессом, чем отдельными действиями.
Пока выглядит так, что агенты постепенно переходят из режима «инструмента» в режим «исполнителя».
Интересно посмотреть, как далеко это зайдет, когда таких агентов станет не один, а целый рой.
Ниже прикладываю цепочку действий от агента (прям да, прям скопировал из чата, только удалил пару системных строк и путей проекта):
● Использую writing-plans для перехода от дизайна к плану реализации после сохранения дизайна.
● Skill(superpowers:writing-plans)
⎿ Successfully loaded skill
● Сначала сохраню дизайн и план, потом перейду к реализации по этому плану в текущей сессии.
● Сохраню дизайн и план в docs/plans, затем начну реализацию по плану в этой сессии.
● Использую subagent-driven-development для выполнения плана в этой сессии и using-git-worktrees для изолированной реализации.
● Skill(superpowers:subagent-driven-development)
⎿ Successfully loaded skill
● Skill(superpowers:using-git-worktrees)
⎿ Successfully loaded skill
● Я использую using-git-worktrees skill, чтобы поднять изолированное рабочее дерево, и subagent-driven-development для выполнения плана в этой сессии.
🔥4❤1
Сегодня поймал приятный момент в работе.
Недавно пришло несколько интересных коммерческих проектов. Тот самый тип задач, где понимаешь — будет много экспериментов, архитектуры и неожиданных решений.
Отдельно ловлю себя на мысли, насколько мотивирует сам факт выбора. Когда клиент выбирает тебя из десятков, а то и сотни других людей, это автоматически повышает планку. Хочется копать глубже, пробовать новые подходы и вытаскивать из инструментов максимум.
Сегодня как раз был небольшой эксперимент: оставил агенту проект на ночь.
Перед уходом запустил ему задачу на максимальный рефакторинг. Прямо в промпте прописал: я оффлайн до утра, составь план, получи все разрешения сейчас и работай автономно.
Агент подготовился довольно системно.
Создал отдельный worktree, поднял новую ветку под рефакторинг и сразу обозначил границы — какие файлы трогать нельзя, где можно делать cleanup, где допустимы частые checkpoint-коммиты.
Интересный момент всплыл на самом старте.
Первые baseline-проверки упали не из-за кода, а из-за окружения. В backend не было pytest, а frontend тесты запускались не из правильной директории. То есть проблема инфраструктуры, а не логики проекта.
И это как раз хороший пример того, как агент рассуждает.
Он не остановился на ошибке, а сам классифицировал её как environment issue и просто скорректировал стратегию запуска проверок.
Дальше план у него довольно взрослый: baseline → sanitation конфигов и секретов → распутывание backend → разделение большого combined-сервера → зачистка legacy → затем frontend.
По факту выглядит как полноценная ночная смена разработчика.
Утром будет интересно посмотреть, насколько далеко он реально продвинется без участия человека.
Недавно пришло несколько интересных коммерческих проектов. Тот самый тип задач, где понимаешь — будет много экспериментов, архитектуры и неожиданных решений.
Отдельно ловлю себя на мысли, насколько мотивирует сам факт выбора. Когда клиент выбирает тебя из десятков, а то и сотни других людей, это автоматически повышает планку. Хочется копать глубже, пробовать новые подходы и вытаскивать из инструментов максимум.
Сегодня как раз был небольшой эксперимент: оставил агенту проект на ночь.
Перед уходом запустил ему задачу на максимальный рефакторинг. Прямо в промпте прописал: я оффлайн до утра, составь план, получи все разрешения сейчас и работай автономно.
Агент подготовился довольно системно.
Создал отдельный worktree, поднял новую ветку под рефакторинг и сразу обозначил границы — какие файлы трогать нельзя, где можно делать cleanup, где допустимы частые checkpoint-коммиты.
Интересный момент всплыл на самом старте.
Первые baseline-проверки упали не из-за кода, а из-за окружения. В backend не было pytest, а frontend тесты запускались не из правильной директории. То есть проблема инфраструктуры, а не логики проекта.
И это как раз хороший пример того, как агент рассуждает.
Он не остановился на ошибке, а сам классифицировал её как environment issue и просто скорректировал стратегию запуска проверок.
Дальше план у него довольно взрослый: baseline → sanitation конфигов и секретов → распутывание backend → разделение большого combined-сервера → зачистка legacy → затем frontend.
По факту выглядит как полноценная ночная смена разработчика.
Утром будет интересно посмотреть, насколько далеко он реально продвинется без участия человека.
👍7
Сегодня планировал провести стрим, но придётся его отменить.
Немного приболел — обычная простуда, ничего серьёзного, но голос уже начинает подводить. Поймал себя на мысли, что если всё-таки выйти в эфир, половина стрима будет состоять из шмыганья и кашля.
А стримы я всё-таки делаю ради нормального разговора, обсуждения идей и экспериментов, а не ради формального «включил камеру — и ладно».
Поэтому решил не мучить ни себя, ни вас. Иногда лучше честно отменить стрим, чем провести его на 30% энергии и с постоянными паузами.
Пока буду восстанавливаться — накидайте в комментариях идеи для следующих стримов. Что разобрать? Какие инструменты или эксперименты с агентами посмотреть?
И ещё одна мысль, которую сейчас кручу в голове. Наткнулся на plane — по сути self-host аналог linear, но с открытым кодом.
Интересно посмотреть на такие инструменты именно в контексте работы с AI-агентами. Когда проект становится сложнее, обычные заметки и markdown уже не тянут — нужна нормальная система постановки задач.
Есть ощущение, что такие штуки могут стать удобным слоем для оркестрации агентной разработки.
Буду дальше копать.
Немного приболел — обычная простуда, ничего серьёзного, но голос уже начинает подводить. Поймал себя на мысли, что если всё-таки выйти в эфир, половина стрима будет состоять из шмыганья и кашля.
А стримы я всё-таки делаю ради нормального разговора, обсуждения идей и экспериментов, а не ради формального «включил камеру — и ладно».
Поэтому решил не мучить ни себя, ни вас. Иногда лучше честно отменить стрим, чем провести его на 30% энергии и с постоянными паузами.
Пока буду восстанавливаться — накидайте в комментариях идеи для следующих стримов. Что разобрать? Какие инструменты или эксперименты с агентами посмотреть?
И ещё одна мысль, которую сейчас кручу в голове. Наткнулся на plane — по сути self-host аналог linear, но с открытым кодом.
Интересно посмотреть на такие инструменты именно в контексте работы с AI-агентами. Когда проект становится сложнее, обычные заметки и markdown уже не тянут — нужна нормальная система постановки задач.
Есть ощущение, что такие штуки могут стать удобным слоем для оркестрации агентной разработки.
Буду дальше копать.
Наткнулся на интересную статью про Cursor и текущую гонку AI-инструментов для разработки.
История любопытная: команда Cursor провела внутренний митинг с довольно прямым слайдом — “War Time”. Причина простая — рынок начал резко меняться. Anysphere построили один из самых быстрорастущих AI-редакторов, но теперь столкнулись с новой реальностью: разработчикам может вообще перестать быть нужен редактор кода.
Появляются инструменты вроде Claude Code и других агентных систем, которые работают не как IDE, а как исполнитель задач.
Ты просто описываешь задачу, а система сама пишет код, запускает команды, редактирует файлы и делает коммиты. Получается странный сдвиг. Раньше IDE была центром разработки. Теперь она постепенно становится просто одним из интерфейсов для агента.
Основная мысль из всей этой истории — конкуренция уже не между редакторами.
Она между платформами управления AI-агентами, которые пишут код.
IDE никуда не исчезнут. Но похоже, что их роль становится менее критичной, чем раньше.
Интересно посмотреть, как это будет выглядеть через год.
Как говорит в меме, каждый день мы все дальше отбога ручного написания кода.
PS GPT-5.4 именно так представляет обложку про эту статью. Возмжно Opus что-то нашептал ему об инсайдах из Пентагона.
История любопытная: команда Cursor провела внутренний митинг с довольно прямым слайдом — “War Time”. Причина простая — рынок начал резко меняться. Anysphere построили один из самых быстрорастущих AI-редакторов, но теперь столкнулись с новой реальностью: разработчикам может вообще перестать быть нужен редактор кода.
Появляются инструменты вроде Claude Code и других агентных систем, которые работают не как IDE, а как исполнитель задач.
Ты просто описываешь задачу, а система сама пишет код, запускает команды, редактирует файлы и делает коммиты. Получается странный сдвиг. Раньше IDE была центром разработки. Теперь она постепенно становится просто одним из интерфейсов для агента.
Основная мысль из всей этой истории — конкуренция уже не между редакторами.
Она между платформами управления AI-агентами, которые пишут код.
IDE никуда не исчезнут. Но похоже, что их роль становится менее критичной, чем раньше.
Интересно посмотреть, как это будет выглядеть через год.
Как говорит в меме, каждый день мы все дальше от
PS GPT-5.4 именно так представляет обложку про эту статью. Возмжно Opus что-то нашептал ему об инсайдах из Пентагона.
🔥3😁2🤝1
Сегодня беседовали с агентом о проекте.
Обычная рабочая сессия: я описываю идею, он задаёт вопросы, уточняет детали, постепенно формируем план. Всё выглядело как обычное обсуждение архитектуры.
В какой-то момент он задал свой любимый вопрос — какой вариант лучше использовать. Что-то из серии: "рекомендую такой подход, но можно и так".
Честно говоря, иногда множество таких уточнений начинают звучать как фоновый шум. Я особо не вчитывался и просто ответил: "да, ок, продолжи дальше".
Иногда все же стоит читать, что пишет агент... ибо дальше поток действий пошел БЕЗ ОСТАНОВКИ,
Агент составил план, разбил его на задачи, создал отдельный worktree, ветку, подготовил окружение… и просто начал реализовывать.
Я несколько раз возвращался в терминал проверить, что происходит — а он всё ещё работает.
В итоге процесс занял (внимание, обратите внимание) 04:27:09. Все верно, Четыре часа, двадцать семь минут и девять секунд. 29 задач в плане, 28 выполнено. Последняя задача была верификация результата и пуш на гит, для этого он все же остановился и спросил.
Самый интересный момент, Я просто ответил ему на автомате - ок, продолжи.
Похоже, именно в этот момент я случайно выпустил джина из бутылки.
Обычная рабочая сессия: я описываю идею, он задаёт вопросы, уточняет детали, постепенно формируем план. Всё выглядело как обычное обсуждение архитектуры.
В какой-то момент он задал свой любимый вопрос — какой вариант лучше использовать. Что-то из серии: "рекомендую такой подход, но можно и так".
Честно говоря, иногда множество таких уточнений начинают звучать как фоновый шум. Я особо не вчитывался и просто ответил: "да, ок, продолжи дальше".
Иногда все же стоит читать, что пишет агент... ибо дальше поток действий пошел БЕЗ ОСТАНОВКИ,
Агент составил план, разбил его на задачи, создал отдельный worktree, ветку, подготовил окружение… и просто начал реализовывать.
Я несколько раз возвращался в терминал проверить, что происходит — а он всё ещё работает.
В итоге процесс занял (внимание, обратите внимание) 04:27:09. Все верно, Четыре часа, двадцать семь минут и девять секунд. 29 задач в плане, 28 выполнено. Последняя задача была верификация результата и пуш на гит, для этого он все же остановился и спросил.
Самый интересный момент, Я просто ответил ему на автомате - ок, продолжи.
Похоже, именно в этот момент я случайно выпустил джина из бутылки.
🤔3😁2🔥1
Попробовал использовать репозиторий pinchtab для парсинга.
Изначально искал что-то попроще, без платных API и прокси-зоопарка. в итоге наткнулся на него — выглядит как легкий слой над браузерной автоматизацией, но с акцентом именно на сбор данных.
В процессе теста оказалось, что он не просто дергает HTML, а реально эмулирует поведение браузера: ждет загрузку, подгружает динамику, нормально работает с JS. для некоторых сайтов это критично.
В целом результат получился довольно стабильный. данные вытягиваются без сильных костылей, меньше проблем с "пустыми" ответами.
Сейчас уже нет смысла бороться с сайтами на уровне raw HTML. если страница живет на JS, проще сразу идти в сторону эмуляции браузера, чем пытаться обходить это вручную.
Пока выглядит как рабочий инструмент, буду работать с ним дальше.
Изначально искал что-то попроще, без платных API и прокси-зоопарка. в итоге наткнулся на него — выглядит как легкий слой над браузерной автоматизацией, но с акцентом именно на сбор данных.
В процессе теста оказалось, что он не просто дергает HTML, а реально эмулирует поведение браузера: ждет загрузку, подгружает динамику, нормально работает с JS. для некоторых сайтов это критично.
В целом результат получился довольно стабильный. данные вытягиваются без сильных костылей, меньше проблем с "пустыми" ответами.
Сейчас уже нет смысла бороться с сайтами на уровне raw HTML. если страница живет на JS, проще сразу идти в сторону эмуляции браузера, чем пытаться обходить это вручную.
Пока выглядит как рабочий инструмент, буду работать с ним дальше.
👍4
сегодня снова вернулся к идее поработать через codex cli.
частично это вынужденный шаг — сейчас активно перехожу на gpt-5.4, потому что мой аккаунт в anthropic попал под волну банов. решил использовать это как повод пересобрать свой рабочий сетап. Особенно, при учете, что у меня настроен роутер на OpenAi подписки.
в какой-то момент откладывал codex cli — ощущался сыроватым и не всегда предсказуемым. но сейчас стало интересно проверить, как он ведёт себя в реальной работе и в связке с родной моделью.
такие инструменты потенциально глубже интегрируются в workflow. меньше прослоек, меньше костылей, быстрее старт. в codex это чувствуется: он довольно быстро подхватывает контекст и начинает действовать без лишних уточнений.
на этом фоне вспоминается опыт с claude code cli. там нравилась возможность работать без постоянных подтверждений действий — на сервере это сильно упрощает процесс. плюс ощущалась сила за счёт экосистемы: больше инструментов, больше гибкости, проще расширять.
но при этом в некоторых сценариях работа через gpt-5.4 превращалась в длинную фазу уточнений перед стартом. модель слишком тщательно собирала контекст, прежде чем что-то делать.
по факту сейчас это не столько сравнение моделей, сколько сравнение среды вокруг них: как быстро можно стартовать, какие есть инструменты, и насколько удобно их комбинировать.
в cli-инструментах решает связка: модель + tooling + возможность расширения. и отдельно — баланс между скоростью старта и уровнем контроля.
буду дальше копать в сторону дополнительных инструментов и смотреть, получится ли собрать более удобный и быстрый сетап вокруг codex.
частично это вынужденный шаг — сейчас активно перехожу на gpt-5.4, потому что мой аккаунт в anthropic попал под волну банов. решил использовать это как повод пересобрать свой рабочий сетап. Особенно, при учете, что у меня настроен роутер на OpenAi подписки.
в какой-то момент откладывал codex cli — ощущался сыроватым и не всегда предсказуемым. но сейчас стало интересно проверить, как он ведёт себя в реальной работе и в связке с родной моделью.
такие инструменты потенциально глубже интегрируются в workflow. меньше прослоек, меньше костылей, быстрее старт. в codex это чувствуется: он довольно быстро подхватывает контекст и начинает действовать без лишних уточнений.
на этом фоне вспоминается опыт с claude code cli. там нравилась возможность работать без постоянных подтверждений действий — на сервере это сильно упрощает процесс. плюс ощущалась сила за счёт экосистемы: больше инструментов, больше гибкости, проще расширять.
но при этом в некоторых сценариях работа через gpt-5.4 превращалась в длинную фазу уточнений перед стартом. модель слишком тщательно собирала контекст, прежде чем что-то делать.
по факту сейчас это не столько сравнение моделей, сколько сравнение среды вокруг них: как быстро можно стартовать, какие есть инструменты, и насколько удобно их комбинировать.
в cli-инструментах решает связка: модель + tooling + возможность расширения. и отдельно — баланс между скоростью старта и уровнем контроля.
буду дальше копать в сторону дополнительных инструментов и смотреть, получится ли собрать более удобный и быстрый сетап вокруг codex.
👍2
продолжу делиться опытом работы с codex cli, подключённый через прокси-роутер.
задача была простая: собрать 50 поисковых запросов по товарам клиента, разбить на 5 пакетов и отдать 5 агентам на параллельный прогон. дальше — собрать логи, сравнить поведение, поправить ошибки и снова в цикл.
ощущается как нормальный рабочий пайплайн. агенты сами идут вперёд, меньше уточняют, быстрее сходятся к результату. особенно заметно на повторных прогонах — после фиксов поведение стабилизируется без ручного контроля каждого шага.
и вот что оказалось неожиданным — сильно влияет не только модель, но и cli-клиент. раньше вообще не придавал этому значения.
codex cli — по сути родной терминальный клиент от openai под gpt-модели. и в нём та же самая модель ведёт себя иначе, чем в claude code или opencode: меньше “болтает”, больше делает.
поведение модели определяется не только её версией, но и интерфейсом, через который ты с ней работаешь.
пока выглядит так, что для итеративных задач и агентных циклов codex cli даёт гораздо более предсказуемый результат.
а еще субагентам даются имена: Dewey [worker], Ampere [worker], Feynman [explorer], Carver [explorer], Bacon [explorer]
задача была простая: собрать 50 поисковых запросов по товарам клиента, разбить на 5 пакетов и отдать 5 агентам на параллельный прогон. дальше — собрать логи, сравнить поведение, поправить ошибки и снова в цикл.
ощущается как нормальный рабочий пайплайн. агенты сами идут вперёд, меньше уточняют, быстрее сходятся к результату. особенно заметно на повторных прогонах — после фиксов поведение стабилизируется без ручного контроля каждого шага.
и вот что оказалось неожиданным — сильно влияет не только модель, но и cli-клиент. раньше вообще не придавал этому значения.
codex cli — по сути родной терминальный клиент от openai под gpt-модели. и в нём та же самая модель ведёт себя иначе, чем в claude code или opencode: меньше “болтает”, больше делает.
поведение модели определяется не только её версией, но и интерфейсом, через который ты с ней работаешь.
пока выглядит так, что для итеративных задач и агентных циклов codex cli даёт гораздо более предсказуемый результат.
а еще субагентам даются имена: Dewey [worker], Ampere [worker], Feynman [explorer], Carver [explorer], Bacon [explorer]
👍2❤1
Друзья, количество подписчиков на моем youtube канале теперь ровно столько же подписчиков, сколько и в телеграмме.
Спасибо за подписку, спасибо за доверие и за ваше внимание.
Спасибо за подписку, спасибо за доверие и за ваше внимание.
👍2
наткнулся на интересную штуку, концепция Grace для работы с кодом в больших контекстах через LLM.
по сути это подход к тому, как не “захлёбываться” в длинном коде. вместо того чтобы скармливать модели весь репозиторий, он разбивает задачу на управляемые куски и прогоняет их через итерации с уточнением.
интересный момент, делается акцент не на одном проходе генерации, а на цикле: модель предлагает изменения → оценивает → уточняет → снова пробует. выглядит как попытка приблизить поведение к нормальному инженерному процессу, а не к “одному выстрелу”.
ещё одна деталь, работа с контекстом становится явной. не просто “влезло / не влезло в окно”, а осознанное управление тем, какие части кода участвуют в каждом шаге.
проблема больших контекстов решается не увеличением окна, а архитектурой процесса вокруг модели.
пока выглядит довольно логично. надо попробовать применить это в агентном пайплайне и посмотреть, как поведёт себя на реальном проекте.
не реклама (там такой каналище, куда мне), а знак уважение за информацию, канал автора
по сути это подход к тому, как не “захлёбываться” в длинном коде. вместо того чтобы скармливать модели весь репозиторий, он разбивает задачу на управляемые куски и прогоняет их через итерации с уточнением.
интересный момент, делается акцент не на одном проходе генерации, а на цикле: модель предлагает изменения → оценивает → уточняет → снова пробует. выглядит как попытка приблизить поведение к нормальному инженерному процессу, а не к “одному выстрелу”.
ещё одна деталь, работа с контекстом становится явной. не просто “влезло / не влезло в окно”, а осознанное управление тем, какие части кода участвуют в каждом шаге.
проблема больших контекстов решается не увеличением окна, а архитектурой процесса вокруг модели.
пока выглядит довольно логично. надо попробовать применить это в агентном пайплайне и посмотреть, как поведёт себя на реальном проекте.
не реклама (там такой каналище, куда мне), а знак уважение за информацию, канал автора
🔥3❤1🕊1
поймал себя на странном ощущении. сижу, у меня открыто 4 терминала, в каждом что-то происходит — тесты, агенты, прогоны, фиксы. всё шевелится само по себе, я почти не вмешиваюсь.
в какой-то момент ощутил тот самый вайб из современных сериалов про хакеров, только без лишнего пафоса. просто рабочая среда, где ты больше наблюдаешь за системой, чем напрямую пишешь код.
интересный момент — сами агенты уже не требуют постоянного контроля. они идут по задачам, исправляют, проверяют, возвращаются в цикл. раньше это выглядело как демо, сейчас — как нормальный рабочий процесс.
по факту роль немного сместилась. ты меньше проверяешь каждую строчку и больше держишь в голове общий вектор: куда движется проект, что сейчас делает каждый поток, где может поехать логика.
сейчас узким местом становится не код, а внимание. если теряешь картину целиком, начинаешь тормозить сильнее, чем любые ошибки в реализации.
пока выглядит так, что дальше придётся учиться не писать какой стек использовать, а думать шире.
в какой-то момент ощутил тот самый вайб из современных сериалов про хакеров, только без лишнего пафоса. просто рабочая среда, где ты больше наблюдаешь за системой, чем напрямую пишешь код.
интересный момент — сами агенты уже не требуют постоянного контроля. они идут по задачам, исправляют, проверяют, возвращаются в цикл. раньше это выглядело как демо, сейчас — как нормальный рабочий процесс.
по факту роль немного сместилась. ты меньше проверяешь каждую строчку и больше держишь в голове общий вектор: куда движется проект, что сейчас делает каждый поток, где может поехать логика.
сейчас узким местом становится не код, а внимание. если теряешь картину целиком, начинаешь тормозить сильнее, чем любые ошибки в реализации.
пока выглядит так, что дальше придётся учиться не писать какой стек использовать, а думать шире.
👍2🔥1😍1
Супер утренний пост. Пошел проверять почту, увидел такое письмо.
У меня на роутере крутятся gpt plus подписки. Посмотрю эти дни, за сколько лимиты будут сжигаться.
Скорее всего, это Ж-ж-ж не спроста и конкуренты поджимают. Недавно Антропики подняли лимиты в ночные часы по Америке.
Вот что конкуренция животворящая делает.
У меня на роутере крутятся gpt plus подписки. Посмотрю эти дни, за сколько лимиты будут сжигаться.
Скорее всего, это Ж-ж-ж не спроста и конкуренты поджимают. Недавно Антропики подняли лимиты в ночные часы по Америке.
Вот что конкуренция животворящая делает.
👍3
расскажу про несколько похожих проектов: gsd-2 и superpowers. оба крутятся вокруг одной идеи — собрать вокруг агента не просто промпт, а полноценную среду с навыками, планированием и переиспользуемыми кусками логики.
по факту это уже не “один агент с большим контекстом”, а скорее набор инструментов, которые агент подгружает по мере работы. что-то вроде плагинов, но ближе к dev-окружению: есть структуры планов, есть skills, есть разделение на подзадачи.
интересно, что похожий паттерн начал встречаться всё чаще. появляются проекты, где:
— агент не хранит всё в голове
— логика выносится в отдельные модули
— поведение становится более предсказуемым между запусками
особенно заметно на длинных задачах. когда агент работает не 5 минут, а час+, без такой структуры он начинает “плыть”.
мы постепенно уходим от идеи “умной модели” к идее “системы вокруг модели”. сама модель уже не центр, а скорее исполнитель внутри инфраструктуры.
и ощущение, что дальше всё будет двигаться именно в эту сторону: больше инструментов, больше orchestration, меньше надежды на один большой промпт.
по факту это уже не “один агент с большим контекстом”, а скорее набор инструментов, которые агент подгружает по мере работы. что-то вроде плагинов, но ближе к dev-окружению: есть структуры планов, есть skills, есть разделение на подзадачи.
интересно, что похожий паттерн начал встречаться всё чаще. появляются проекты, где:
— агент не хранит всё в голове
— логика выносится в отдельные модули
— поведение становится более предсказуемым между запусками
особенно заметно на длинных задачах. когда агент работает не 5 минут, а час+, без такой структуры он начинает “плыть”.
мы постепенно уходим от идеи “умной модели” к идее “системы вокруг модели”. сама модель уже не центр, а скорее исполнитель внутри инфраструктуры.
и ощущение, что дальше всё будет двигаться именно в эту сторону: больше инструментов, больше orchestration, меньше надежды на один большой промпт.
👍2
в одном из чатом прочитал о том, как хранить данные под RAG, чтобы он не разваливался на реальных задачах.
интересное сравнение: чистый векторный поиск против гибридных схем — когда к эмбеддингам добавляется SQL или граф.
вектора реально хорошо тянут семантику. даже абстракции начинают ловить. если чанки нормально размечены (с ссылками, связями), то это частично заменяет граф.
но как только дело доходит до точных фактов — цифры, таблицы, конкретные значения — всё начинает плыть. эмбеддинги для этого просто не подходят.
отсюда и появляются гибриды. например sqlite + вектора (тот же sqlite-vec) — можно комбинировать поиск. или более тяжёлый вариант: DuckDB + vss + графовые расширения.
кратко посмотрел DuckDB и ощущается как более инженерное решение. быстрее sqlite, удобный attach для работы с несколькими базами, можно строить ETL прямо на SQL без усложнения кода.
плюс графовые запросы из коробки (через расширения), что для Graph RAG сильно упрощает жизнь.
основная мысль, дело не в «выбрать правильную базу», а в том, что чистый векторный RAG — это тупик. рано или поздно всё равно придёшь к гибридной модели.
дальше интересно попробовать это на более сложных агентных пайплайнах.
интересное сравнение: чистый векторный поиск против гибридных схем — когда к эмбеддингам добавляется SQL или граф.
вектора реально хорошо тянут семантику. даже абстракции начинают ловить. если чанки нормально размечены (с ссылками, связями), то это частично заменяет граф.
но как только дело доходит до точных фактов — цифры, таблицы, конкретные значения — всё начинает плыть. эмбеддинги для этого просто не подходят.
отсюда и появляются гибриды. например sqlite + вектора (тот же sqlite-vec) — можно комбинировать поиск. или более тяжёлый вариант: DuckDB + vss + графовые расширения.
кратко посмотрел DuckDB и ощущается как более инженерное решение. быстрее sqlite, удобный attach для работы с несколькими базами, можно строить ETL прямо на SQL без усложнения кода.
плюс графовые запросы из коробки (через расширения), что для Graph RAG сильно упрощает жизнь.
основная мысль, дело не в «выбрать правильную базу», а в том, что чистый векторный RAG — это тупик. рано или поздно всё равно придёшь к гибридной модели.
дальше интересно попробовать это на более сложных агентных пайплайнах.
❤2👍1
сегодня словил странный эффект — у меня внезапно сбросились недельные лимиты в codex.
ничего не менял: те же аккаунты, просто в какой-то момент usage стал как будто с нуля.
пошёл проверять — никаких официальных анонсов от OpenAI нет. ни про изменения лимитов, ни про пересчёт, ни про апдейты квот.
по ощущениям это либо баг в трекинге, либо какая-то внутренняя пересинхронизация биллинга. возможно что-то перекатили на стороне инфраструктуры.
интересный момент — такие штуки довольно сильно влияют на рабочие процессы. если ты строишь пайплайны под фиксированные лимиты, такие “сбросы” ломают предсказуемость.
буду смотреть, откатится ли обратно или начнёт считаться новая неделя.
ничего не менял: те же аккаунты, просто в какой-то момент usage стал как будто с нуля.
пошёл проверять — никаких официальных анонсов от OpenAI нет. ни про изменения лимитов, ни про пересчёт, ни про апдейты квот.
по ощущениям это либо баг в трекинге, либо какая-то внутренняя пересинхронизация биллинга. возможно что-то перекатили на стороне инфраструктуры.
интересный момент — такие штуки довольно сильно влияют на рабочие процессы. если ты строишь пайплайны под фиксированные лимиты, такие “сбросы” ломают предсказуемость.
буду смотреть, откатится ли обратно или начнёт считаться новая неделя.
👍1
наткнулся на интересный кейс во время чтения одной статьи.
на сайте pdf был спрятан за подпиской — классическая схема: сначала даётся кусок, дальше заглушка. решил не заморачиваться вручную и просто отдал задачу агенту.
он написал парсер. с первого раза не получилось, но за пару итераций он разобрался, как именно устроена защита, нашёл уязвимость в логике загрузки и спокойно скачал полный файл.
без какого-то “хакинга”, просто через анализ поведения клиента и ответов сервера.
самое интересное — это даже не результат, а процесс. агент не просто исполнял команды, а перебирал гипотезы: где режется контент, как формируется запрос, что возвращает backend при разных условиях.
по факту он действовал как человек, который методично обходит ограничения, только быстрее и без усталости.
текущие механизмы защиты часто рассчитаны на человека, а не на агента. и то, что раньше требовало времени и навыков, сейчас превращается в задачу на несколько итераций.
выглядит так, что в ближайшее время защита должна будет эволюционировать не просто технически, а концептуально — с учётом того, что “пользователь” теперь может быть ИИ агентом.
на сайте pdf был спрятан за подпиской — классическая схема: сначала даётся кусок, дальше заглушка. решил не заморачиваться вручную и просто отдал задачу агенту.
он написал парсер. с первого раза не получилось, но за пару итераций он разобрался, как именно устроена защита, нашёл уязвимость в логике загрузки и спокойно скачал полный файл.
без какого-то “хакинга”, просто через анализ поведения клиента и ответов сервера.
самое интересное — это даже не результат, а процесс. агент не просто исполнял команды, а перебирал гипотезы: где режется контент, как формируется запрос, что возвращает backend при разных условиях.
по факту он действовал как человек, который методично обходит ограничения, только быстрее и без усталости.
текущие механизмы защиты часто рассчитаны на человека, а не на агента. и то, что раньше требовало времени и навыков, сейчас превращается в задачу на несколько итераций.
выглядит так, что в ближайшее время защита должна будет эволюционировать не просто технически, а концептуально — с учётом того, что “пользователь” теперь может быть ИИ агентом.
🔥4
Сегодня раскопал один занятный артефакт в проекте.
Файл на ~12k строк. Один. service.py. Сначала даже переспросил себя, не баг ли это в grep.
Начал разбирать и стало понятно, как это выросло. В него постепенно складывали всё: orchestration, state transitions, эвристики, writeback, read-model, даже куски интеграционного слоя. Каждый раз «быстрее дописать сюда, чем отделять».
И вот тут интересный момент, писал конечно это не я руками, а агент. Но вопросов к нему нет. Вообще. Н и к а к и х.
Потому что каждый раз, когда он предлагал вариант «сделать быстро и здесь», я говорил: да, ок, погнали дальше. Новые фичи, новые куски логики, без остановки на рефакторинг.
По факту это не «агент нагенерил монолит». Это я его туда целенаправленно привёл. Каюсь, Каюсь.
В итоге файл стал сразу всем: domain service, policy engine и почти integration layer. Самое коварное, что в моменте это удобно. Один entrypoint, всё рядом, быстро двигаешься. А потом любое изменение начинает цеплять полсистемы, и уже непонятно, где заканчивается одна логика и начинается другая.
Возросла скорость написания кода с агентами, но и технический долг тоже копится быстрее, а контроль границ — всё ещё на тебе.
Теперь план простой: аккуратно резать, выделять модули и возвращать архитектуру под контроль.
UPD. картинки мне делает chatGPT, нравится его акценты - все в огне )
Файл на ~12k строк. Один. service.py. Сначала даже переспросил себя, не баг ли это в grep.
Начал разбирать и стало понятно, как это выросло. В него постепенно складывали всё: orchestration, state transitions, эвристики, writeback, read-model, даже куски интеграционного слоя. Каждый раз «быстрее дописать сюда, чем отделять».
И вот тут интересный момент, писал конечно это не я руками, а агент. Но вопросов к нему нет. Вообще. Н и к а к и х.
Потому что каждый раз, когда он предлагал вариант «сделать быстро и здесь», я говорил: да, ок, погнали дальше. Новые фичи, новые куски логики, без остановки на рефакторинг.
По факту это не «агент нагенерил монолит». Это я его туда целенаправленно привёл. Каюсь, Каюсь.
В итоге файл стал сразу всем: domain service, policy engine и почти integration layer. Самое коварное, что в моменте это удобно. Один entrypoint, всё рядом, быстро двигаешься. А потом любое изменение начинает цеплять полсистемы, и уже непонятно, где заканчивается одна логика и начинается другая.
Возросла скорость написания кода с агентами, но и технический долг тоже копится быстрее, а контроль границ — всё ещё на тебе.
Теперь план простой: аккуратно резать, выделять модули и возвращать архитектуру под контроль.
UPD. картинки мне делает chatGPT, нравится его акценты - все в огне )
😁2