Привет! Я зарабатываю разработкой с 2003 года и за это время успел увидеть несколько смен эпох в индустрии. Сейчас мне особенно интересно исследовать границы применимости AI и решать прикладные задачи с помощью вайбкодинга.
Я завел этот канал по двум причинам.
Первая: мне хочется фиксировать свой опыт. Чтобы то, что я читаю, проверяю и понимаю, не растворялось, а оставалось в виде заметок и выводов.
Вторая: я хочу собрать людей, которые тоже тестируют подходы на практике. В обсуждениях часто всплывают вещи, до которых в одиночку доходишь намного дольше.
Помимо того, что я использую AI на работе, у меня есть два сайд-проекта:
1. Branchline — специализированный язык программирования для преобразования данных. Проект большой: интерпретатор, виртуальная машина, CLI, документация, много тестов, бенчмарки, онлайн-песочница и сравнение с другим специализированным языком. Всё это написано с помощью промптов и чем больше развивается проект, тем более внимательно нужно их составлять.
Проект открытый: https://github.com/ehlyzov/branchline-public
2. Умный планировщик — пока закрытый проект, который я делаю с другом. Идея заключается в том, чтобы использовать LLM как "внешнюю память" для рутинных дел и повторяющихся задач, чтобы меньше держать это в голове и меньше тратить энергии на контроль.
Что в канале будет:
1. Выжимка моего опыта и всякие gems которые неизбежно появляются если работаешь с чем-то достаточно долго.
2. Обзоры и выжимки из актуальных статей
3. Обзоры актуальных инструментов
4. Иногда — философия и футуризм. Как вайбкодинг влияет на мышление и что нас всех ждет в итоге.
Чего в канале не будет:
1. Магии, "10 промптов, чтобы кодить как сеньор" и прочей чуши.
2. Советов без проверки
Присоединяйтесь и добро пожаловать!
Я завел этот канал по двум причинам.
Первая: мне хочется фиксировать свой опыт. Чтобы то, что я читаю, проверяю и понимаю, не растворялось, а оставалось в виде заметок и выводов.
Вторая: я хочу собрать людей, которые тоже тестируют подходы на практике. В обсуждениях часто всплывают вещи, до которых в одиночку доходишь намного дольше.
Помимо того, что я использую AI на работе, у меня есть два сайд-проекта:
1. Branchline — специализированный язык программирования для преобразования данных. Проект большой: интерпретатор, виртуальная машина, CLI, документация, много тестов, бенчмарки, онлайн-песочница и сравнение с другим специализированным языком. Всё это написано с помощью промптов и чем больше развивается проект, тем более внимательно нужно их составлять.
Проект открытый: https://github.com/ehlyzov/branchline-public
2. Умный планировщик — пока закрытый проект, который я делаю с другом. Идея заключается в том, чтобы использовать LLM как "внешнюю память" для рутинных дел и повторяющихся задач, чтобы меньше держать это в голове и меньше тратить энергии на контроль.
Что в канале будет:
1. Выжимка моего опыта и всякие gems которые неизбежно появляются если работаешь с чем-то достаточно долго.
2. Обзоры и выжимки из актуальных статей
3. Обзоры актуальных инструментов
4. Иногда — философия и футуризм. Как вайбкодинг влияет на мышление и что нас всех ждет в итоге.
Чего в канале не будет:
1. Магии, "10 промптов, чтобы кодить как сеньор" и прочей чуши.
2. Советов без проверки
Присоединяйтесь и добро пожаловать!
👍1🔥1💔1💘1
Мой текущий стек
Autonomous Code Agent: Codex (plus-подписка)
MCP: Playwright
Terminal: warp
Shell: fish
Editor: Idea + Zed
Я в основном использую командую строку для формулирования задач и текстовые файлы. Соответственно кодекс запущен в отдельном терминале или внутри Zed.
Типичная ситуация — я запускаю много агентов, часто в разных репозиториях, чтобы в сжатое время выполнить несколько изменений над которыми я заранее подумал. Это требует пояснений в AGENTS.md иначе кодекс будет ругаться, а его ранние версии могли просто откатить чужие правки. Проблема известна и решается незамысловатыми инструкциями. Свои я взял из блога Питера Штайнбергера и их реализацию можно посмотреть в репозитории.
В целом, последняя статья Питера довольно хорошо описывает мой опыт вайбкодинга. Рекомендую прочитать статью целиком (и другие статьи автора!), супер краткую и вольную выжимку приведу тут:
1. GPT 5.2 настолько крутой, что ему не нужны никакие plan и act режимы. Можно просто писать в диалоге, что нужно сделать и велик шанс что это будет сделано с первой попытки. Конечно для сложных задач всё еще хорошо попросить сначала записать план (в Branchline я использую для этого директорию /research), а затем его выполнить.
2. Сам процесс кодирования больше не является узким место в разработке. Теперь основное бутылочное горлышко — скорость инференса моделей и человеческое мышление.
3. Роль разработчика теперь больше смещается в сторону верификации результатов кода полученного от агента. Процесс получения прототипа фичи стал супердешевый и сейчас часто можно двигаться шажками — написать прототип, походить и подумать, затем написать корректирующий и развивающий промпт.
Autonomous Code Agent: Codex (plus-подписка)
MCP: Playwright
Terminal: warp
Shell: fish
Editor: Idea + Zed
Я в основном использую командую строку для формулирования задач и текстовые файлы. Соответственно кодекс запущен в отдельном терминале или внутри Zed.
Типичная ситуация — я запускаю много агентов, часто в разных репозиториях, чтобы в сжатое время выполнить несколько изменений над которыми я заранее подумал. Это требует пояснений в AGENTS.md иначе кодекс будет ругаться, а его ранние версии могли просто откатить чужие правки. Проблема известна и решается незамысловатыми инструкциями. Свои я взял из блога Питера Штайнбергера и их реализацию можно посмотреть в репозитории.
В целом, последняя статья Питера довольно хорошо описывает мой опыт вайбкодинга. Рекомендую прочитать статью целиком (и другие статьи автора!), супер краткую и вольную выжимку приведу тут:
1. GPT 5.2 настолько крутой, что ему не нужны никакие plan и act режимы. Можно просто писать в диалоге, что нужно сделать и велик шанс что это будет сделано с первой попытки. Конечно для сложных задач всё еще хорошо попросить сначала записать план (в Branchline я использую для этого директорию /research), а затем его выполнить.
2. Сам процесс кодирования больше не является узким место в разработке. Теперь основное бутылочное горлышко — скорость инференса моделей и человеческое мышление.
3. Роль разработчика теперь больше смещается в сторону верификации результатов кода полученного от агента. Процесс получения прототипа фичи стал супердешевый и сейчас часто можно двигаться шажками — написать прототип, походить и подумать, затем написать корректирующий и развивающий промпт.
✍1👍1
Готовлю на завтра пост с рассуждениями, а пока вот вам три опроса.
1) Business Insider от 12 января. Не очень понятно что именно они хотели сказать. Но есть какие-то циферки и частные мнения. Пока просто отметим, что из 167 опрошенных людей удалось найти 28 кто заявил, что отказался от использования AI в работе. Остальные так или иначе используют.
2) Шикарная статья "A Survey of Vibe Coding with Large Language Models" (взял картинку оттуда) на архиве
Шикарна она тем, что там есть формальное описание системы состоящей из человека, проекта и кодирующего агента (нужно как-то правильно перевести coding agent, но пока пусть будет так) и есть любимая мной глава "Влияние на будущее и открытые вызовы". Эту статью хочется разобрать подробнее, что я и попробую сделать на этой неделе.
3. Недавний отчёт от небезызвестной Sonar: https://www.sonarsource.com/state-of-code-developer-survey-report.pdf
Много графиков, но самое ключевое — 42% кода сегодня сделано в соавторстве с AI (оставим пока как именно это считалось), по прогнозам в 2027 вырастет до 65% (а я ставлю на все 99!).
Ну и то наблюдение, что 72% разработчиков которые попробовали работу с AI теперь используют его ежедневно. А основная проблема сейчас — доверие к коду. Как проверять, что сделано то что нужно, если ты до этого учился писать код?(а не ограничения)
4) И завершим отечественным опросом на приличной выборке в 475 человек. Приживаемость в 64% при условии, что использовать ИИ-агенты в режиме блокировки требует определенных усилий — впечатляет.
1) Business Insider от 12 января. Не очень понятно что именно они хотели сказать. Но есть какие-то циферки и частные мнения. Пока просто отметим, что из 167 опрошенных людей удалось найти 28 кто заявил, что отказался от использования AI в работе. Остальные так или иначе используют.
2) Шикарная статья "A Survey of Vibe Coding with Large Language Models" (взял картинку оттуда) на архиве
Шикарна она тем, что там есть формальное описание системы состоящей из человека, проекта и кодирующего агента (нужно как-то правильно перевести coding agent, но пока пусть будет так) и есть любимая мной глава "Влияние на будущее и открытые вызовы". Эту статью хочется разобрать подробнее, что я и попробую сделать на этой неделе.
3. Недавний отчёт от небезызвестной Sonar: https://www.sonarsource.com/state-of-code-developer-survey-report.pdf
Много графиков, но самое ключевое — 42% кода сегодня сделано в соавторстве с AI (оставим пока как именно это считалось), по прогнозам в 2027 вырастет до 65% (а я ставлю на все 99!).
Ну и то наблюдение, что 72% разработчиков которые попробовали работу с AI теперь используют его ежедневно. А основная проблема сейчас — доверие к коду. Как проверять, что сделано то что нужно, если ты до этого учился писать код?
4) И завершим отечественным опросом на приличной выборке в 475 человек. Приживаемость в 64% при условии, что использовать ИИ-агенты в режиме блокировки требует определенных усилий — впечатляет.
❤1👍1
Всё снова меняется
Пробую резюмировать прочитанное за последний месяц и ответить на вопрос, что дальше.
Спойлер:следить за базаром как никогда ранее
Пока самое точное сравнение происходящего — переход от ручной переписи книг к книгопечатанию. Когда-то знания были дорогими и штучными. Потом — дешёвыми и массовыми.
Сейчас роль печатного станка играет LLM и человеку для получения популярной и не очень информации не обязательно даже уметь гуглить, модель подстроится под запрос и напишет так чтобы было понятно, а потом еще и уточнит 100500 раз.
Проблема в том, что сейчас мало кто понимает, как с этим работать в контексте проектирования и разработки сложных систем.
Использование агентов для написания кода в пределе ломает классический SDLC. Анализ, разработка и реализация схлопываются по времени. В некоторых случаях — с ростом качества. Зато резко возрастает значение проверки критических мест, валидации и доставки изменений. Старые процессы здесь перестают работать, а новые только-только появляются.
На этом фоне "вайбкодинг" – броское, но довольно пустое слово. То, что делает профессиональный инженер, и то, что делает человек без системного мышления, это совсем разные процессы.
Архитектура и аналитика становятся не бонусом, а точкой входа. Либо ты задаёшь структуру и ограничения и управляешь генерацией, либо бесконечно правишь результат.
Второй путь ломается сразу, как только система становится больше того, что один человек способен удержать в голове. "Площадь поверхности" растёт быстрее, чем внимание.
Я не верю в долгую жизнь сложных техник промптинга. Все эти шаблоны и ритуалы – временный налог на слабость текущих моделей. Рано или поздно модели станут понимать намерение без специальных слов.
Зато я верю, что инженеру придётся мыслить выше синтаксиса языков. Работать на уровне абстракций, ограничений и архитектурных идей. Через естественный язык и формальные понятия. Но при этом _необходимо_ будет понимать эти понятия в гораздо больше степени, чем это было необходимо ранее. Ранее сложность того, что я создавал была ограничена моими когнитивными способностями и навыками программирования и я не мог писать код быстрее, чем понимал его. Сейчас это не так. Ей богу кажется еще пару лет и модели придется искусственно ограничивать в производительности, чтобы человек (а скорее к тому времени уже специализированная команда) мог успевать осмыслять происходящее.
Таким образом, считаю, что понимание архитектуры, алгоритмической сложности, умение быстро "доигрывать" предложения модели и вести constraint-based (вот как перевести?) диалог с ИИ становятся ключевыми навыками. И это то, на развитии чего необходимо концентрироваться в первую очередь.
Пробую резюмировать прочитанное за последний месяц и ответить на вопрос, что дальше.
Спойлер:
Пока самое точное сравнение происходящего — переход от ручной переписи книг к книгопечатанию. Когда-то знания были дорогими и штучными. Потом — дешёвыми и массовыми.
Сейчас роль печатного станка играет LLM и человеку для получения популярной и не очень информации не обязательно даже уметь гуглить, модель подстроится под запрос и напишет так чтобы было понятно, а потом еще и уточнит 100500 раз.
Проблема в том, что сейчас мало кто понимает, как с этим работать в контексте проектирования и разработки сложных систем.
Использование агентов для написания кода в пределе ломает классический SDLC. Анализ, разработка и реализация схлопываются по времени. В некоторых случаях — с ростом качества. Зато резко возрастает значение проверки критических мест, валидации и доставки изменений. Старые процессы здесь перестают работать, а новые только-только появляются.
На этом фоне "вайбкодинг" – броское, но довольно пустое слово. То, что делает профессиональный инженер, и то, что делает человек без системного мышления, это совсем разные процессы.
Архитектура и аналитика становятся не бонусом, а точкой входа. Либо ты задаёшь структуру и ограничения и управляешь генерацией, либо бесконечно правишь результат.
Второй путь ломается сразу, как только система становится больше того, что один человек способен удержать в голове. "Площадь поверхности" растёт быстрее, чем внимание.
Я не верю в долгую жизнь сложных техник промптинга. Все эти шаблоны и ритуалы – временный налог на слабость текущих моделей. Рано или поздно модели станут понимать намерение без специальных слов.
Зато я верю, что инженеру придётся мыслить выше синтаксиса языков. Работать на уровне абстракций, ограничений и архитектурных идей. Через естественный язык и формальные понятия. Но при этом _необходимо_ будет понимать эти понятия в гораздо больше степени, чем это было необходимо ранее. Ранее сложность того, что я создавал была ограничена моими когнитивными способностями и навыками программирования и я не мог писать код быстрее, чем понимал его. Сейчас это не так. Ей богу кажется еще пару лет и модели придется искусственно ограничивать в производительности, чтобы человек (а скорее к тому времени уже специализированная команда) мог успевать осмыслять происходящее.
Таким образом, считаю, что понимание архитектуры, алгоритмической сложности, умение быстро "доигрывать" предложения модели и вести constraint-based (вот как перевести?) диалог с ИИ становятся ключевыми навыками. И это то, на развитии чего необходимо концентрироваться в первую очередь.
🔥2
Душераздирающая история как сжечь половину недельных токенов.
Решил я тут оптимизировать работу с числами в Branchline.
Проблема тут вот в чем. Нам приходит JSON и например в качестве ввода что-то вроде такого:
Это довольно объёмная задача для ИИ и затрагивает несколько модулей — лексер, парсер, интерпретатор, документацию и тесты.
И обычно, я пишу я пишу условие, которое запрещает изменять тесты, но в этот раз (человеческий фактор) я его опустил. И codex (gpt-5.2-codex / high) поменяв логику работы с числами, просто подогнала тесты под то что получилось, а получилось, например что
Решил я тут оптимизировать работу с числами в Branchline.
Проблема тут вот в чем. Нам приходит JSON и например в качестве ввода что-то вроде такого:
{ score: 1 } сейчас в языке мы это считываем как byte, но при этом при любом неосторожном движении (типа деления) преобразуем в аналог BigDecimal. Это жутко не оптимально и хочется, чтобы с одной стороны, работа с числами была для пользователя простой (т.е. идеально иметь один числовой тип), с другой стороны, гоняем это мы всё на JVM и хочется чтобы для математических операций использовались нативные типы всегда когда это возможно. Это довольно объёмная задача для ИИ и затрагивает несколько модулей — лексер, парсер, интерпретатор, документацию и тесты.
И обычно, я пишу я пишу условие, которое запрещает изменять тесты, но в этот раз (человеческий фактор) я его опустил. И codex (gpt-5.2-codex / high) поменяв логику работы с числами, просто подогнала тесты под то что получилось, а получилось, например что
ROUND(1.0, 0) == 1.0 на основании того что сигнатура ROUND сохраняющая тип параметра, лучше чем то, что было (а было неявное приведение к целочисленному при ROUND(x, 0)). И в целом я даже не возражаю, действительно осмысленно. Но блин, втихую подменять тесты — это зло. Модель всегда при желании может подогнать тесты так, чтобы они пропускали её правки. При этом если подстелить заранее — то выиграть в скорости можно весьма существенно. А если недостаточно подумать — то больно.🤔2❤🔥1
Привет! Долго думал, про что написать, потому что тем довольно много, и когда пытаешься ухватиться за что-то, то это "что-то" фрактально превращается в выбор еще больший, чем в начале.
Но, кажется, любой канал про вайбкодинг будет не полон без описаний техник промптинга. На этом я и сконцентрируюсь, потому что техник много, часть из них уже имеют устоявшиеся названия (meta-prompting, few shots, zero-shot, etc.) и самое главное — они супер наглядны: всё, что будет в следующих постах можно (и рекомендуется) проверить на своих примерах на доступных вам моделях. Я работаю на gpt-5.2 (thinking standard) .
Несколько популярных статей для самостоятельного изучения (англ.):
1. Руководство от codex
2. Руководство от Anthropic
3. Хорошая подборка техник и статей по работе с моделями
Для погружения (может быть сложно без математической подготовки!): https://arxiv.org/pdf/2311.11482v6
В них вводятся некоторые важные термины типа "деградация контекста" (context rot) и ограничения текущих моделей. Сейчас мы находимся в начале пути, модели сильно не совершенны и их эффективное использование — это приобретаемый навык. При этом, на мой взгляд, навык полезный, он позволяет нам лучше ставить задачи и управлять вниманием в ситуации ограниченного контекста. Думается мне, такое ценно не только в контексте взаимодействия с AI, но и в целом для взаимодействия с любыми мыслящими существами.
Итак, рассмотрим два промпта:
А) Сделай мне план внедрения RAG для команды.
Б) Роль: архитектор LLM-систем.
Цель: план внедрения RAG на 6 недель для команды из 5 инженеров.
Контекст: источники — Confluence + Git, стек — Python, бюджет ограничен.
Выход: таблица (Неделя / Deliverables / Риски / Метрики).
Критерии: план должен включать оценку качества (eval), безопасность, процесс обновления базы знаний.
Проверка: в конце перечисли 5 рисков и меры.
Вопросы: если не хватает данных — задай до 5 вопросов.
Я не буду здесь приводить ответы, т.к. это очень много буков, но вы можете выполнить эти промпты (или составить пример под себя) в вашей любимой модели и самостоятельно убедиться, что ответ на второй промпт гораздо более специфичен. Это ожидаемо, т.к. сам запрос намного более конкретен, разрешает модели задавать вопросы и задает ограничения. Второй промпт существенно более сложный и требует от инженера понимания целевой системы. При этом, инженер опирается на свое внутренние знание предметной области и не использует возможности модели.
Что же делать если понимания нет и хочется больше узнать какие вообще возможны ограничения? Например, использовать мета-промптинг.
Я в последнее время часто прошу модель аргументированно критиковать мои промпты, т.к. это часто даёт интересные результаты и помогает мне лучше понять чего я на самом деле хочу. Например, можно сделать так:
(1/2)👇👇👇 вторая часть в комментах
Но, кажется, любой канал про вайбкодинг будет не полон без описаний техник промптинга. На этом я и сконцентрируюсь, потому что техник много, часть из них уже имеют устоявшиеся названия (meta-prompting, few shots, zero-shot, etc.) и самое главное — они супер наглядны: всё, что будет в следующих постах можно (и рекомендуется) проверить на своих примерах на доступных вам моделях. Я работаю на gpt-5.2 (thinking standard) .
Несколько популярных статей для самостоятельного изучения (англ.):
1. Руководство от codex
2. Руководство от Anthropic
3. Хорошая подборка техник и статей по работе с моделями
Для погружения (может быть сложно без математической подготовки!): https://arxiv.org/pdf/2311.11482v6
В них вводятся некоторые важные термины типа "деградация контекста" (context rot) и ограничения текущих моделей. Сейчас мы находимся в начале пути, модели сильно не совершенны и их эффективное использование — это приобретаемый навык. При этом, на мой взгляд, навык полезный, он позволяет нам лучше ставить задачи и управлять вниманием в ситуации ограниченного контекста. Думается мне, такое ценно не только в контексте взаимодействия с AI, но и в целом для взаимодействия с любыми мыслящими существами.
Итак, рассмотрим два промпта:
А) Сделай мне план внедрения RAG для команды.
Б) Роль: архитектор LLM-систем.
Цель: план внедрения RAG на 6 недель для команды из 5 инженеров.
Контекст: источники — Confluence + Git, стек — Python, бюджет ограничен.
Выход: таблица (Неделя / Deliverables / Риски / Метрики).
Критерии: план должен включать оценку качества (eval), безопасность, процесс обновления базы знаний.
Проверка: в конце перечисли 5 рисков и меры.
Вопросы: если не хватает данных — задай до 5 вопросов.
Я не буду здесь приводить ответы, т.к. это очень много буков, но вы можете выполнить эти промпты (или составить пример под себя) в вашей любимой модели и самостоятельно убедиться, что ответ на второй промпт гораздо более специфичен. Это ожидаемо, т.к. сам запрос намного более конкретен, разрешает модели задавать вопросы и задает ограничения. Второй промпт существенно более сложный и требует от инженера понимания целевой системы. При этом, инженер опирается на свое внутренние знание предметной области и не использует возможности модели.
Что же делать если понимания нет и хочется больше узнать какие вообще возможны ограничения? Например, использовать мета-промптинг.
Я в последнее время часто прошу модель аргументированно критиковать мои промпты, т.к. это часто даёт интересные результаты и помогает мне лучше понять чего я на самом деле хочу. Например, можно сделать так:
Роль: редактор промптов.
Исходный промпт:
"Сделай мне план внедрения RAG для команды."
Сначала:
A) Критика в 5 пунктах: какие допущения вынуждена сделать модель и к чему это приведёт.
B) Список недостающих параметров (2 категории: обязательно / желательно).
Затем:
C) Перепиши промпт так, чтобы минимизировать допущения.
D) Добавь self-check: модель должна отметить, какие пункты она не смогла закрыть из-за отсутствия данных.
Не пиши ответ на исходный промпт.
(1/2)👇👇👇 вторая часть в комментах
❤1
Привет! Закончилась рабочая неделя и настало время рассмотресть оставшиеся ключевые техники.
Сегодня будет пример на "цепочку мыслей" (CoT, chain of thoughts), "дерево вариантов" (ToT, tree of thoughts) и "верификация" (verification). Предположим что мы решаем прикладную задачу — реализовать функционал отмены сообщения в чате в течении 10 секунд с момента отправки. Изучив матчать мы пришли к трем теоретически подходящим для нас вариантам:
1. Сервер ждет 10 секунд и только после этого отправляет сообщение адресату.
2. Разрешить в течении 10 секунд отправку корректирующее сообщение, которое применится уже на устройстве адресата.
3. Что-то типа двухфазного коммита, когда пользователь отправляет сообщение + автоматически отправляет подтверждение через 10 секунд. Получатель видит что сообщение написано/пишется, но получает текст только после подтверждение.
Если в этот момент мы пойдем через прямой запрос "реализуй мне фичу Х" и сетка не угадает с нашими желаниями, то мы сожгем кучу токенов на исправление. Токены — новое время, их нужно беречь.
Поэтому мы просим модель сравнить три варианта по важным для нас критериям (их можно верифицировать отдельно). Просим указать критерии сравнения и поставить вариантам оценку — это "дерево вариантов". При этом каждый вариант должен быть рассмотрен по конкретным аспектам — это вариант "цепочки мыслей". Затем просим покритиковть и тут же предложить варианты ответов на критику — это стадия верификации.
Итоговый промпт может выглядеть так:
Пример немного искуственный т.к. в реальной работе существенно больше контекста + просится мета-промптинг. Но для иллюстрации техники сойдёт.
Итак — варианты, последовательность действий, верификация. Это всё может улучшить результат генерации и натолкнуть на правильные мысли.
Сегодня будет пример на "цепочку мыслей" (CoT, chain of thoughts), "дерево вариантов" (ToT, tree of thoughts) и "верификация" (verification). Предположим что мы решаем прикладную задачу — реализовать функционал отмены сообщения в чате в течении 10 секунд с момента отправки. Изучив матчать мы пришли к трем теоретически подходящим для нас вариантам:
1. Сервер ждет 10 секунд и только после этого отправляет сообщение адресату.
2. Разрешить в течении 10 секунд отправку корректирующее сообщение, которое применится уже на устройстве адресата.
3. Что-то типа двухфазного коммита, когда пользователь отправляет сообщение + автоматически отправляет подтверждение через 10 секунд. Получатель видит что сообщение написано/пишется, но получает текст только после подтверждение.
Если в этот момент мы пойдем через прямой запрос "реализуй мне фичу Х" и сетка не угадает с нашими желаниями, то мы сожгем кучу токенов на исправление. Токены — новое время, их нужно беречь.
Поэтому мы просим модель сравнить три варианта по важным для нас критериям (их можно верифицировать отдельно). Просим указать критерии сравнения и поставить вариантам оценку — это "дерево вариантов". При этом каждый вариант должен быть рассмотрен по конкретным аспектам — это вариант "цепочки мыслей". Затем просим покритиковть и тут же предложить варианты ответов на критику — это стадия верификации.
Итоговый промпт может выглядеть так:
Нужно спроектировать функцию отмены отправки в чате: после отправки есть 10 секунд, чтобы отменить. Клиенты — веб и мобильный. Есть пуш-уведомления.
Рассмотри строго три реализации и не предлагай дополнительных:
А) Задержка доставки
Б) Отзыв после доставки
В) Черновик → подтверждение
Для каждого варианта опиши по пунктам:
1) Что видит отправитель и получатель по шагам.
2) Что делаем с уведомлениями: когда отправляем и что, если уведомление уже ушло, а потом была отмена.
3) Граница 10 секунд: гонка "отмена против подтверждения", повторы запросов, идемпотентность.
4) Плохая сеть/офлайн, два устройства у отправителя, групповой чат.
5) Что логировать и какие метрики поставить.
Оцени каждый вариант по шкале 1-5:
- однозначность поведения
- понятность пользователю
- устойчивость к сети и нескольким устройствам
- целостность истории переписки
- дебажность по логам и метрикам
Сделай таблицу: вариант / оценки / короткие причины.
Выбери лучший вариант и объясни выбор в 5-7 строк.
После выбора:
- найди 10 дыр, которые могут сломать дизайн
- для каждой: риск -> минимальная правка -> тест (сценарий + ожидаемое поведение),
- затем обнови описание выбранного варианта с учётом правок (коротко).
Пример немного искуственный т.к. в реальной работе существенно больше контекста + просится мета-промптинг. Но для иллюстрации техники сойдёт.
Итак — варианты, последовательность действий, верификация. Это всё может улучшить результат генерации и натолкнуть на правильные мысли.
⚡1👍1
Привет! Недавно вышла новость, что OpenAI депрекейтит свои прошлые модели такие как GPT4o и GPT4.1. По этому поводу хочется обсудить что делать, когда приложение работает на конкретной модели, а эта модель по тем или иным причинам становится недоступной и нужно проверять как приложение будет работать с тем, что пришло на замену.
Что может сломаться? Структура данных, если модель общалась с человеком, то могут поменяться её тон и стиль. Также можно сломаться экономическая составляющая — например, полететь юнит-экономика из-за взлетевшей стоимости диалога с моделью.
Как проверить что всё ок? Как вариант — на каждый пайплайн нужно иметь тесты закрепляющие желательное поведение. Подходы описаны много где — openai, langchain и в целом всё, что позволяет делать пайплайны должно уметь и умеет их оценивать.
Если пройтись по верхам, то у нас есть два класса автоматизированных тестов:
1. Детерминированные/контрактные тесты — смотрим на вход и выход пайплайна и проверяем формат, ограничения и наличие фиксированные значений.
2. Недетерминированные — тесты, которые проверяет другая модель. Такие подходы собраны под общим названием LLM-as-a-Judge. Здесь проверяем "адекватность" тестируемой модели, степень понимания инструкций, интонацию и всё, что сложно формализовать. Например, насколько четко дан ответ.
На каждый пайплайн нужно сделать набор тестов закрывающих обычные и проблемные сценарии. Кроме того, те же самые тесты можно использовать когда мы меняем пайплайн и хотим убедиться что изменения повлияли в нужную сторону. Сами тесты можно и нужно вайбкодить, разумеется.
В первом комментарии будет пример такого теста из AI-планировщика на котором мы с товарищем тестируем свои продуктовые навыки.
Что может сломаться? Структура данных, если модель общалась с человеком, то могут поменяться её тон и стиль. Также можно сломаться экономическая составляющая — например, полететь юнит-экономика из-за взлетевшей стоимости диалога с моделью.
Как проверить что всё ок? Как вариант — на каждый пайплайн нужно иметь тесты закрепляющие желательное поведение. Подходы описаны много где — openai, langchain и в целом всё, что позволяет делать пайплайны должно уметь и умеет их оценивать.
Если пройтись по верхам, то у нас есть два класса автоматизированных тестов:
1. Детерминированные/контрактные тесты — смотрим на вход и выход пайплайна и проверяем формат, ограничения и наличие фиксированные значений.
2. Недетерминированные — тесты, которые проверяет другая модель. Такие подходы собраны под общим названием LLM-as-a-Judge. Здесь проверяем "адекватность" тестируемой модели, степень понимания инструкций, интонацию и всё, что сложно формализовать. Например, насколько четко дан ответ.
На каждый пайплайн нужно сделать набор тестов закрывающих обычные и проблемные сценарии. Кроме того, те же самые тесты можно использовать когда мы меняем пайплайн и хотим убедиться что изменения повлияли в нужную сторону. Сами тесты можно и нужно вайбкодить, разумеется.
В первом комментарии будет пример такого теста из AI-планировщика на котором мы с товарищем тестируем свои продуктовые навыки.
Openai
Retiring GPT-4o, GPT-4.1, GPT-4.1 mini, and OpenAI o4-mini in ChatGPT
On February 13, 2026, alongside the previously announced retirement of GPT‑5 (Instant, Thinking, and Pro), we will retire GPT‑4o, GPT‑4.1, GPT‑4.1 mini, and OpenAI o4-mini from ChatGPT. In the API, there are no changes at this time.
❤1😱1
Вдогонку к предыдущему посту — сильный материал от Anthropic: Demystifying evals for AI agents.
Статью стоит прочитать целиком, а ниже — выжимка и ключевые определения:
Задача (Task) — тест-кейс с заданными входами и критериями успеха
Запуск (Trial) — одна попытка выполнения задачи
Оценщик (Grader) — логика оценки; у одной задачи может быть несколько оценщиков
Проверка (Assertion) — конкретная проверка внутри оценщика
Итог (Outcome) — итоговое состояние среды после выполнения задачи
Экспериментальный контур оценивания (evaluation harness) — инфраструктура, которая запускает задачи end-to-end, выдаёт инструкции и инструменты, пишет трассы/логи, запускает оценщика и агрегирует результаты
Исполнительная среда агента (agent harness) — система, которая делает модель агентом: обрабатывает входы, оркестрирует вызовы инструментов и возвращает результат; ведь при оценки агента фактически тестируется связка среды и модели
Ключевые метрики — те, которые отделяют регресс от вариативности:
pass@k — вероятность получить хотя бы один успешный результат за k попыток
pass^k — вероятность того, что все k попыток будут успешны
Рекомендации:
Не фиксировать конкретные инструменты и путь решения (это делает тесты хрупкими), фиксировать итог (outcome).
Если задача многокомпонентная — вводить частичные баллы: агент, который понял задачу и сделал половину шагов, лучше агента, который сразу “проехал мимо”, и это должно отражаться в метрике.
Изоляция каждой попытки: одинаковое стартовое состояние для каждого запуска.
Не забывать про транскрипты: это основной способ проверить, что мы упёрлись не в агента, а в криво построенного оценщика или неоднозначную постановку задачи.
Статью стоит прочитать целиком, а ниже — выжимка и ключевые определения:
Задача (Task) — тест-кейс с заданными входами и критериями успеха
Запуск (Trial) — одна попытка выполнения задачи
Оценщик (Grader) — логика оценки; у одной задачи может быть несколько оценщиков
Проверка (Assertion) — конкретная проверка внутри оценщика
Итог (Outcome) — итоговое состояние среды после выполнения задачи
Экспериментальный контур оценивания (evaluation harness) — инфраструктура, которая запускает задачи end-to-end, выдаёт инструкции и инструменты, пишет трассы/логи, запускает оценщика и агрегирует результаты
Исполнительная среда агента (agent harness) — система, которая делает модель агентом: обрабатывает входы, оркестрирует вызовы инструментов и возвращает результат; ведь при оценки агента фактически тестируется связка среды и модели
Ключевые метрики — те, которые отделяют регресс от вариативности:
pass@k — вероятность получить хотя бы один успешный результат за k попыток
pass^k — вероятность того, что все k попыток будут успешны
Рекомендации:
Не фиксировать конкретные инструменты и путь решения (это делает тесты хрупкими), фиксировать итог (outcome).
Если задача многокомпонентная — вводить частичные баллы: агент, который понял задачу и сделал половину шагов, лучше агента, который сразу “проехал мимо”, и это должно отражаться в метрике.
Изоляция каждой попытки: одинаковое стартовое состояние для каждого запуска.
Не забывать про транскрипты: это основной способ проверить, что мы упёрлись не в агента, а в криво построенного оценщика или неоднозначную постановку задачи.
Anthropic
Demystifying evals for AI agents
👀1
<slowpoke_mode>Срочные новости!</slowpoke_mode>
https://chatgpt.com/codex — OpenAI выпустили приложение и временно увеличили лимиты —как раз вовремя всегда в тему!
Из интересного — приложение умеет выполнять задачи в отдельном working tree с настраиваемыми инит-скриптами и таким образом изменения становятся полностью изолированными. И можно сразу запускать задачи в облаке.
Про изоляцию изменений — пока не понял насколько это прикольно, но интуитивно нравится. Найду удачный сценарий — напишу тут.
https://chatgpt.com/codex — OpenAI выпустили приложение и временно увеличили лимиты —
Из интересного — приложение умеет выполнять задачи в отдельном working tree с настраиваемыми инит-скриптами и таким образом изменения становятся полностью изолированными. И можно сразу запускать задачи в облаке.
Про изоляцию изменений — пока не понял насколько это прикольно, но интуитивно нравится. Найду удачный сценарий — напишу тут.
❤🔥1👍1😁1