Каникулы ещё не закончились – самое время спокойно почитать что-нибудь полезное.
Собрал подборку лучших постов за прошедший год – если пропустили или хотите вернуться к избранному:
– Зачем нужен шаблонный сервис и пример такого сервиса на FastAPI
– Чтобы провести встречу продуктивно, нужно постараться. Мы написали, что сами применяем на практике
– Видео про роли в крупном проекте – аналитики, разработчики, тестировщики и как всё это живёт вместе
– Набор заметок о том, зачем нужны архитектурные схемы, как их составлять и где проходят зоны ответственности
– Пост-стенание на тему код-ревью
– Революционный метод организации рабочих чатов
– Сайт с сериалами на разных языках и бот для изучения иностранного языка методом карточек
– Мой опыт работы с ai-агентами
– Приём, который помогает быстрее принимать решения в команде
– Как не забивать на написание постмитов
– Статья о том, как написать своего первого ai-агента
– Советы и антипаттерны при работе с Postgres
– Очень крутой курс по System Design, который искренне рекомендую
#devfm #backup
Собрал подборку лучших постов за прошедший год – если пропустили или хотите вернуться к избранному:
– Зачем нужен шаблонный сервис и пример такого сервиса на FastAPI
– Чтобы провести встречу продуктивно, нужно постараться. Мы написали, что сами применяем на практике
– Видео про роли в крупном проекте – аналитики, разработчики, тестировщики и как всё это живёт вместе
– Набор заметок о том, зачем нужны архитектурные схемы, как их составлять и где проходят зоны ответственности
– Пост-стенание на тему код-ревью
– Революционный метод организации рабочих чатов
– Сайт с сериалами на разных языках и бот для изучения иностранного языка методом карточек
– Мой опыт работы с ai-агентами
– Приём, который помогает быстрее принимать решения в команде
– Как не забивать на написание постмитов
– Статья о том, как написать своего первого ai-агента
– Советы и антипаттерны при работе с Postgres
– Очень крутой курс по System Design, который искренне рекомендую
#devfm #backup
Telegram
DevFM
Шаблонный сервис
Я всячески люблю, когда разработка идёт предсказуемо – и многое для этого делаю.
Давно хотел написать пост о важности шаблонного сервиса, но не было хорошего примера под рукой. И тут мой коллега выложил наш шаблонный сервис на FastAPI…
Я всячески люблю, когда разработка идёт предсказуемо – и многое для этого делаю.
Давно хотел написать пост о важности шаблонного сервиса, но не было хорошего примера под рукой. И тут мой коллега выложил наш шаблонный сервис на FastAPI…
❤7👍6🔥6⚡4
Еще один способ работать с ai-агентами
Завтра начинаем работать, но никогда не поздно начать то, что давно откладывал.
Сейчас AI-агенты, действительно, умеют многое. И если с большими проектами всё ещё бывает непросто, то для MVP или пет-проекта – это супер классный инструмент.
Общее понимание уже сформировалось: чтобы с агентом получилось что-то толковое, нужно сначала составить план, проверить его, зафиксировать – и только потом просить агента работать по этому плану. Для не очень больших задач это работает. Но все равно несет серьезную ментальную нагрузку – все учесть, ничего не забыть.
Когда стартуешь что-то с нуля или добавляешь большую фичу в существующий проект – хочется чего-то более структурированного. И тут появляются инструменты для автоматизации всего флоу.
Рекомендую попробовать spec-kit.
Суть в том, что он расширяет и формализует классический пайплайн планирования. Общий флоу выглядит так:
– описываешь свои хотелки: что нужно и зачем, без привязки к стеку
– дальше – технический план: архитектура, стек, решения, все это дело ревьюишь, уточняешь
– затем декомпозиция на задачи с учётом зависимостей
– в конце – реализация по этим задачам и разумеется ревью этого добра
Главный плюс такого подхода – он сам подталкивает к определённому флоу, чтобы ничего не забыть. Явно подсказывает следующий шаг. Если прервался – можно продолжить с того же места. Поддерживается разными агентами: Claude Code, Copilot, Cursor и другими.
Мне нравится пробовать на пет-проектах то, что давно откладывал. Делегировать то, в чём скучно разбираться самому.
Например, чтобы подбить статистику по популярным постам, я сделал небольшой сервис tganalytics – собирает информацию из любого публичного канала в Telegram и позволяет сортировать посты по популярности.
Из полезного:
– когда подписываешься на новый канал – удобно посмотреть самые популярные посты
– бэкап собственного канала
– база для RAG и собственной базы знаний
– выгрузка контента – я так делаю для кулинарных каналов
Если интересно – заходите, попробуйте. А если что-то не полетит – приходите, поправлю.
Среди похожих инструментов для работы с агентами стоит посмотреть на SuperClaude, но мне он показался переусложненным.
#ai
Завтра начинаем работать, но никогда не поздно начать то, что давно откладывал.
Сейчас AI-агенты, действительно, умеют многое. И если с большими проектами всё ещё бывает непросто, то для MVP или пет-проекта – это супер классный инструмент.
Общее понимание уже сформировалось: чтобы с агентом получилось что-то толковое, нужно сначала составить план, проверить его, зафиксировать – и только потом просить агента работать по этому плану. Для не очень больших задач это работает. Но все равно несет серьезную ментальную нагрузку – все учесть, ничего не забыть.
Когда стартуешь что-то с нуля или добавляешь большую фичу в существующий проект – хочется чего-то более структурированного. И тут появляются инструменты для автоматизации всего флоу.
Рекомендую попробовать spec-kit.
Суть в том, что он расширяет и формализует классический пайплайн планирования. Общий флоу выглядит так:
– описываешь свои хотелки: что нужно и зачем, без привязки к стеку
– дальше – технический план: архитектура, стек, решения, все это дело ревьюишь, уточняешь
– затем декомпозиция на задачи с учётом зависимостей
– в конце – реализация по этим задачам и разумеется ревью этого добра
Главный плюс такого подхода – он сам подталкивает к определённому флоу, чтобы ничего не забыть. Явно подсказывает следующий шаг. Если прервался – можно продолжить с того же места. Поддерживается разными агентами: Claude Code, Copilot, Cursor и другими.
Мне нравится пробовать на пет-проектах то, что давно откладывал. Делегировать то, в чём скучно разбираться самому.
Например, чтобы подбить статистику по популярным постам, я сделал небольшой сервис tganalytics – собирает информацию из любого публичного канала в Telegram и позволяет сортировать посты по популярности.
Из полезного:
– когда подписываешься на новый канал – удобно посмотреть самые популярные посты
– бэкап собственного канала
– база для RAG и собственной базы знаний
– выгрузка контента – я так делаю для кулинарных каналов
Если интересно – заходите, попробуйте. А если что-то не полетит – приходите, поправлю.
Среди похожих инструментов для работы с агентами стоит посмотреть на SuperClaude, но мне он показался переусложненным.
#ai
🔥13👍10⚡4❤1
Я в целом скептически отношусь к курсам. Но так вышло, что как-то время от времени присматривался к курсам Стратоплана – и тут ребята сами предложили пройти у них обучение на курсе CTO.
Сначала подумал: столько в меня не влезет. А потом решил – почему бы и нет. Впихнуть невпихуемое – это мое:)
Хочу структурировать имеющиеся знания, проверить их актуальность и пообщаться с людьми со схожими запросами. Такой осознанный нетворкинг.
Поступление состоит из двух этапов.
Первый – кейс-интервью и эссе о себе. Кейсы я люблю. Это вообще популярный формат собесов на руководящие позиции – и, на мой взгляд, хороший способ понять, как человек думает.
Правда, решать кейсы в вакууме мне сложно. Сложно вжиться в абстрактную ситуацию с безликими героями. И тут для себя выработал лайфхак: отбросить мишуру и перенести суть проблемы на свой проект. Вместо безликих героев назначить своих коллег – и кейс сразу играет новыми красками. Начинают приходить хорошие идеи и решения.
Второй этап – что-то вроде собеседования. Но по сути это просто обсуждение твоего опыта, чтобы подобрать группу, с которой будешь плотно работать в процессе.
В итоге я попал на курс, любопытно, что из этого получится. Буду делиться полезными инсайтами.
Сначала подумал: столько в меня не влезет. А потом решил – почему бы и нет. Впихнуть невпихуемое – это мое:)
Хочу структурировать имеющиеся знания, проверить их актуальность и пообщаться с людьми со схожими запросами. Такой осознанный нетворкинг.
Поступление состоит из двух этапов.
Первый – кейс-интервью и эссе о себе. Кейсы я люблю. Это вообще популярный формат собесов на руководящие позиции – и, на мой взгляд, хороший способ понять, как человек думает.
Правда, решать кейсы в вакууме мне сложно. Сложно вжиться в абстрактную ситуацию с безликими героями. И тут для себя выработал лайфхак: отбросить мишуру и перенести суть проблемы на свой проект. Вместо безликих героев назначить своих коллег – и кейс сразу играет новыми красками. Начинают приходить хорошие идеи и решения.
Второй этап – что-то вроде собеседования. Но по сути это просто обсуждение твоего опыта, чтобы подобрать группу, с которой будешь плотно работать в процессе.
В итоге я попал на курс, любопытно, что из этого получится. Буду делиться полезными инсайтами.
Школа менеджмента STRATOPLAN
Курс «СТО» - Школа менеджмента STRATOPLAN
Практический тренинг-симулятор для текущих и будущих технических директоров
🔥21❤15👍15👎4🌭1
Когда у задачи нет даты
Я уже рассказывал, как организую свои задачи. Сегодня про один приём, который мне сильно помогает.
В любом таск-менеджере есть стандартные триггеры для взятия задачи в работу: приоритет, дедлайн, напоминание на конкретную дату. Всё это работает, когда ты точно знаешь, когда задача станет актуальной.
Но есть такие задачи, которые не привязаны к дате – они привязаны к событию.
Примеры из жизни: “когда поеду в Сочи – сходить в такое то место”, “когда будет синк по проекту – обсудить текущий CI/CD”. У этих задач нет конкретной даты, и непонятно, куда их складывать. Если просто кинуть в общий список – они точно потеряются. Если поставить произвольную дату – будут раздражать напоминаниями не в тот момент и постоянно еще придется переносить.
И вот тут мне помогают теги. Я размечаю такие задачи по событию: #сочи, #ретро, #созвон-с-заказчиком. Когда событие наступает – открываю нужный тег и вижу всё, что хотел сделать или обсудить.
Иногда у события есть конкретная дата – например, еженедельный 121 с коллегой. Казалось бы, можно вести отдельный списочек для каждого человека и перед встречей туда заглядывать. Но на практике это неудобно: нужно помнить, где этот список лежит, каждый раз туда заходить, что-то добавлять. А с тегами проще — в любой момент кидаешь задачу в общий инбокс, помечаешь #вася, и забываешь. На открываешь заметки по конкретному тегу – всё перед глазами.
В общем мне такой прием помогает. Пользуетесь ли чем-то подобным?
#devfm #productivity
Я уже рассказывал, как организую свои задачи. Сегодня про один приём, который мне сильно помогает.
В любом таск-менеджере есть стандартные триггеры для взятия задачи в работу: приоритет, дедлайн, напоминание на конкретную дату. Всё это работает, когда ты точно знаешь, когда задача станет актуальной.
Но есть такие задачи, которые не привязаны к дате – они привязаны к событию.
Примеры из жизни: “когда поеду в Сочи – сходить в такое то место”, “когда будет синк по проекту – обсудить текущий CI/CD”. У этих задач нет конкретной даты, и непонятно, куда их складывать. Если просто кинуть в общий список – они точно потеряются. Если поставить произвольную дату – будут раздражать напоминаниями не в тот момент и постоянно еще придется переносить.
И вот тут мне помогают теги. Я размечаю такие задачи по событию: #сочи, #ретро, #созвон-с-заказчиком. Когда событие наступает – открываю нужный тег и вижу всё, что хотел сделать или обсудить.
Иногда у события есть конкретная дата – например, еженедельный 121 с коллегой. Казалось бы, можно вести отдельный списочек для каждого человека и перед встречей туда заглядывать. Но на практике это неудобно: нужно помнить, где этот список лежит, каждый раз туда заходить, что-то добавлять. А с тегами проще — в любой момент кидаешь задачу в общий инбокс, помечаешь #вася, и забываешь. На открываешь заметки по конкретному тегу – всё перед глазами.
В общем мне такой прием помогает. Пользуетесь ли чем-то подобным?
#devfm #productivity
Telegram
DevFM
Ведение дел – мой опыт
Часто начинающие тим лиды имеют сложности с тайм-менеджментом. У них появляются новые зоны ответственности, новые задачи, интерапты, о которых они раньше и не слышали, больше общения с людьми. В общем, совершенно новый опыт.
Что уж…
Часто начинающие тим лиды имеют сложности с тайм-менеджментом. У них появляются новые зоны ответственности, новые задачи, интерапты, о которых они раньше и не слышали, больше общения с людьми. В общем, совершенно новый опыт.
Что уж…
👍9❤7🔥4
Кто такие Skills в ai-агентах?
AI-агенты ехают и бибикают в индустрии. Использование MCP уже стало для всех обыденностью, но с ними есть известная проблема – они жрут токены. Если подключено несколько MCP-серверов, то только начав диалог с агентом, половина контекста может улететь.
И вот тут недавно появилась интересная штука – Skills.
Сначала я подумал: ну что за зверь такой? Есть же уже команды, субагенты, MCP. Зачем нам еще Skills?
Одна из главных фишек – скилы грузятся на лету и поэтапно, а не всё сразу.
Три уровня загрузки:
– Level 1 – Metadata. Загружается всегда при старте. Это просто name и description из YAML-шапки. Claude знает только, что скилл существует и когда его использовать
– Level 2 – Instructions. Загружается, когда скилл триггерится. Основное тело SKILL.md с инструкциями и воркфлоу
– Level 3 – Resources. Загружается по необходимости. Дополнительные файлы, скрипты, шаблоны
То есть если у вас скилл для написания e2e-тестов – он подгрузится только когда речь зайдёт об e2e. До этого момента в контексте болтается только одна строчка с описанием.
Что внутри скилла
Скилл – это не просто файлик с инструкциями. Это директория с модульной структурой. Можно разбивать знания на отдельные файлы – агент подгрузит только то, что нужно для конкретной задачи. Можно добавлять скрипты – и тогда в контекст попадёт только результат выполнения, а не сам код.
Скилы сейчас поддерживаются всеми основными агентами: Cursor, Claude Code, Codex.
Я, например, использую:
– Playwright Skill – описываешь задачу на естественном языке, агент сам пишет и выполняет автоматизацию браузера. Открывается реальное окно, видишь что происходит, получаешь скриншоты и логи
– Frontend Design Skill – на тот случай, когда нет дизайнера, но хочется сделать достаточно хорошо. По умолчанию агенты генерируют типичный дизайн сильно так себе. Скилл содержит рекомендации по типографике, цветам, анимациям – и результат становится заметно лучше
#ai
AI-агенты ехают и бибикают в индустрии. Использование MCP уже стало для всех обыденностью, но с ними есть известная проблема – они жрут токены. Если подключено несколько MCP-серверов, то только начав диалог с агентом, половина контекста может улететь.
И вот тут недавно появилась интересная штука – Skills.
Сначала я подумал: ну что за зверь такой? Есть же уже команды, субагенты, MCP. Зачем нам еще Skills?
Одна из главных фишек – скилы грузятся на лету и поэтапно, а не всё сразу.
Три уровня загрузки:
– Level 1 – Metadata. Загружается всегда при старте. Это просто name и description из YAML-шапки. Claude знает только, что скилл существует и когда его использовать
– Level 2 – Instructions. Загружается, когда скилл триггерится. Основное тело SKILL.md с инструкциями и воркфлоу
– Level 3 – Resources. Загружается по необходимости. Дополнительные файлы, скрипты, шаблоны
То есть если у вас скилл для написания e2e-тестов – он подгрузится только когда речь зайдёт об e2e. До этого момента в контексте болтается только одна строчка с описанием.
Что внутри скилла
Скилл – это не просто файлик с инструкциями. Это директория с модульной структурой. Можно разбивать знания на отдельные файлы – агент подгрузит только то, что нужно для конкретной задачи. Можно добавлять скрипты – и тогда в контекст попадёт только результат выполнения, а не сам код.
Скилы сейчас поддерживаются всеми основными агентами: Cursor, Claude Code, Codex.
Я, например, использую:
– Playwright Skill – описываешь задачу на естественном языке, агент сам пишет и выполняет автоматизацию браузера. Открывается реальное окно, видишь что происходит, получаешь скриншоты и логи
– Frontend Design Skill – на тот случай, когда нет дизайнера, но хочется сделать достаточно хорошо. По умолчанию агенты генерируют типичный дизайн сильно так себе. Скилл содержит рекомендации по типографике, цветам, анимациям – и результат становится заметно лучше
#ai
🔥12⚡8❤6
Правило трёх итераций – когда диалог зашел в тупик
Бывает обсуждаете что-то с коллегой или смежниками, не можете договориться. Обмениваетесь аргументами раз, два, три – и всё никак. Такой словесный пинг-понг получается.
И в этом потоке обсуждения почему-то кажется, что ещё одна итерация – и точно договоримся. Ещё раз объясню свою позицию, приведу новый аргумент, и собеседник наконец поймёт.
На практике обычно так не работает. Если за три итерации обмена мнениями вы не сдвинулись с места – скорее всего, дальше будете ходить по кругу. Каждый повторяет свои аргументы чуть другими словами, но позиции не меняются. И это продолжается, пока просто не закончится отведённое на встречу время. А потом все разойдутся с ощущением, что встреча была ни о чем, ни к чему не пришли.
Поэтому после трех итераций – полезно притормозить. Что-то явно не так. Может, нужны артефакты – данные, метрики, примеры из прода. Может, не хватает контекста, который есть у кого-то третьего. А может, ваш собеседник просто упёрся – и тогда нужна эскалация или человек, у которого есть полномочия рассудить разногласия. Отложите, соберите отсутствующие пазлики и вернитесь к вопросу.
Три итерации – и тормозим, работает удивительно хорошо.
#devfm
Бывает обсуждаете что-то с коллегой или смежниками, не можете договориться. Обмениваетесь аргументами раз, два, три – и всё никак. Такой словесный пинг-понг получается.
И в этом потоке обсуждения почему-то кажется, что ещё одна итерация – и точно договоримся. Ещё раз объясню свою позицию, приведу новый аргумент, и собеседник наконец поймёт.
На практике обычно так не работает. Если за три итерации обмена мнениями вы не сдвинулись с места – скорее всего, дальше будете ходить по кругу. Каждый повторяет свои аргументы чуть другими словами, но позиции не меняются. И это продолжается, пока просто не закончится отведённое на встречу время. А потом все разойдутся с ощущением, что встреча была ни о чем, ни к чему не пришли.
Поэтому после трех итераций – полезно притормозить. Что-то явно не так. Может, нужны артефакты – данные, метрики, примеры из прода. Может, не хватает контекста, который есть у кого-то третьего. А может, ваш собеседник просто упёрся – и тогда нужна эскалация или человек, у которого есть полномочия рассудить разногласия. Отложите, соберите отсутствующие пазлики и вернитесь к вопросу.
Три итерации – и тормозим, работает удивительно хорошо.
#devfm
❤11🔥5⚡3👍2
Субботнее развлекательное
Бывает сидишь себе спокойно в общественном месте, а какой-то неразумный человек включает видяшку на полную громкость. Без наушников. ААА!!!
Нашёлся человек, который решил эту проблему по-инженерному – написал STFU.
Идея простая: открываешь сайт, и он начинает дублировать любой звук вокруг. С небольшой задержкой. То есть человек слышит своё же видео дважды – и это настолько раздражает, что скорее всего он сам выключит свою херабору.
Исходники тоже есть – можно глянуть.
Бывает сидишь себе спокойно в общественном месте, а какой-то неразумный человек включает видяшку на полную громкость. Без наушников. ААА!!!
Нашёлся человек, который решил эту проблему по-инженерному – написал STFU.
Идея простая: открываешь сайт, и он начинает дублировать любой звук вокруг. С небольшой задержкой. То есть человек слышит своё же видео дважды – и это настолько раздражает, что скорее всего он сам выключит свою херабору.
Исходники тоже есть – можно глянуть.
GitHub
GitHub - Pankajtanwarbanna/stfu: stfu
stfu. Contribute to Pankajtanwarbanna/stfu development by creating an account on GitHub.
🔥25❤8👍6
RAG на практике
RAG – наверное, второе по популярности слово в индустрии после ai-aгент. Всем нужен RAG.
Наткнулся на статью победителя RAG Challenge. Это соревнование, где нужно было за 2.5 часа спарсить 100 PDF-отчётов (до 1000 страниц каждый) и построить QA-систему. Автор занял первое место. В статье описал весь пайплайн, показал код, рассказал, на какие грабли наступил – получилось очень интересно и практично.
Парсинг
Первый этап – превратить PDF в текст. Казалось бы, стандартная задача. Автор перепробовал пару десятков парсеров и пришёл к выводу: нормальных не существует. Таблицы разваливаются, многоколоночный текст путается. Пришлось форкнуть Docling и допиливать руками.
Индексация
Дальше текст нарезается на куски и складывается в векторную базу для поиска. Ключевое решение – отдельная база на каждую компанию. Зачем мешать метрики разных компаний в одну кучу? Область поиска сразу сужается в 100 раз.
Поиск
Векторный поиск возвращает топ-N результатов, но ранжирует их довольно грубо – при векторизации часть смысла теряется. В итоге в топ-10 попадает релевантная информация, но не всегда на первых местах.
Логичная идея – добавить классический текстовый поиск (BM25) и скомбинировать результаты. Автор попробовал – не зашло. Гибридный поиск чаще ухудшал качество, чем улучшал.
Зато сработал другой подход: достаём топ-30 из векторного поиска и просим gpt-4o-mini оценить релевантность каждого куска. Получается точнее, чем любой алгоритмический реранкинг. И стоит меньше цента на вопрос.
Генерация ответа
Чем больше правил даёшь модели в одном промпте, тем хуже она им следует. Модель начинает что-то игнорировать или путать.
Решение – роутинг, в зависимости от типа ожидаемого ответа вопрос уходит в разные промпты. В каждом – только релевантные правила.
Ещё одна проблема: модели дообучены быть полезными. Если в контексте нет прямого ответа, модель склонна притянуть что-то похожее за уши вместо честного – не знаю.
Помогает Structured Output + Chain of Thought: модель сначала рассуждает в отдельном поле, анализирует контекст с разных сторон, и только потом даёт ответ. Это заметно снижает количество галлюцинаций.
Неоднозначность
Отдельная история – что вообще считать правильным ответом. «Who is the CEO?» – звучит просто. Но CEO это только Chief Executive Officer? Или Managing Director тоже подходит? А President? И таких вопросов в бизнес-области может быть мильон.
Автор называет это – порогом свободы интерпретации. И его приходится калибровать с заказчиком вручную, разбирая edge cases.
Вывод такой, что для построения RAG нет одного магического решения. Качество складывается из мелочей на каждом этапе. И чем глубже понимаешь задачу – тем точнее можешь эти мелочи настроить.
Статью очень рекомендую.
#ai
RAG – наверное, второе по популярности слово в индустрии после ai-aгент. Всем нужен RAG.
Наткнулся на статью победителя RAG Challenge. Это соревнование, где нужно было за 2.5 часа спарсить 100 PDF-отчётов (до 1000 страниц каждый) и построить QA-систему. Автор занял первое место. В статье описал весь пайплайн, показал код, рассказал, на какие грабли наступил – получилось очень интересно и практично.
Парсинг
Первый этап – превратить PDF в текст. Казалось бы, стандартная задача. Автор перепробовал пару десятков парсеров и пришёл к выводу: нормальных не существует. Таблицы разваливаются, многоколоночный текст путается. Пришлось форкнуть Docling и допиливать руками.
Индексация
Дальше текст нарезается на куски и складывается в векторную базу для поиска. Ключевое решение – отдельная база на каждую компанию. Зачем мешать метрики разных компаний в одну кучу? Область поиска сразу сужается в 100 раз.
Поиск
Векторный поиск возвращает топ-N результатов, но ранжирует их довольно грубо – при векторизации часть смысла теряется. В итоге в топ-10 попадает релевантная информация, но не всегда на первых местах.
Логичная идея – добавить классический текстовый поиск (BM25) и скомбинировать результаты. Автор попробовал – не зашло. Гибридный поиск чаще ухудшал качество, чем улучшал.
Зато сработал другой подход: достаём топ-30 из векторного поиска и просим gpt-4o-mini оценить релевантность каждого куска. Получается точнее, чем любой алгоритмический реранкинг. И стоит меньше цента на вопрос.
Генерация ответа
Чем больше правил даёшь модели в одном промпте, тем хуже она им следует. Модель начинает что-то игнорировать или путать.
Решение – роутинг, в зависимости от типа ожидаемого ответа вопрос уходит в разные промпты. В каждом – только релевантные правила.
Ещё одна проблема: модели дообучены быть полезными. Если в контексте нет прямого ответа, модель склонна притянуть что-то похожее за уши вместо честного – не знаю.
Помогает Structured Output + Chain of Thought: модель сначала рассуждает в отдельном поле, анализирует контекст с разных сторон, и только потом даёт ответ. Это заметно снижает количество галлюцинаций.
Неоднозначность
Отдельная история – что вообще считать правильным ответом. «Who is the CEO?» – звучит просто. Но CEO это только Chief Executive Officer? Или Managing Director тоже подходит? А President? И таких вопросов в бизнес-области может быть мильон.
Автор называет это – порогом свободы интерпретации. И его приходится калибровать с заказчиком вручную, разбирая edge cases.
Вывод такой, что для построения RAG нет одного магического решения. Качество складывается из мелочей на каждом этапе. И чем глубже понимаешь задачу – тем точнее можешь эти мелочи настроить.
Статью очень рекомендую.
#ai
Хабр
Как я победил в RAG Challenge: от нуля до SoTA за один конкурс
Автор - DarkBones Предисловие В этом посте я расскажу про подход, благодаря которому я занял первое место в обеих призовых номинациях и в общем SotA рейтинге. В чём суть RAG Challenge? Нужно создать...
👍13⚡5❤5🔥1😁1
Не могу не поделиться. Александр Поломодов часто пишет и выступает про System Design. Особенно много внимания уделяет System Design интервью.
И вот он собрал многие материалы в одном месте – сделал сайт , посвящённый этой теме.
Если вам актуально – очень рекомендую заглянуть. Надеюсь, проект будет развиваться.
И вот он собрал многие материалы в одном месте – сделал сайт , посвящённый этой теме.
Если вам актуально – очень рекомендую заглянуть. Надеюсь, проект будет развиваться.
System Design Space
System Design Space — Проектируй лучшие системы и проходи интервью
Изучай System Design для создания надёжных масштабируемых систем и успешного прохождения технических собеседований.
👍17🔥7⚡5👎1
Встречайте новый формат инженерного диалога
T-Sync Conf — офлайн-конференция от Группы «Т-Технологии» для опытных инженеров. 7 февраля в Москве на площадке TAU соберутся платформенные, security- и дата-инженеры, аналитики, DevOps-, SRE-, CI/CD-, AI-, ML-, R&D- и DX -специалисты.
Как все устроено:
— Контуры — тематические зоны, каждая из которых раскрывает отдельный слой инженерной реальности: AI, Data, R&D, Security, Platform и другие направления.
— Вместо классических докладов — круглые столы, стенды, хакатон, воркшопы и мастер-классы.
— Инженерные решения изнутри — возможность посмотреть, как устроены технологии в Т-Банке и других компаниях, и пообщаться напрямую с теми, кто их создает.
А еще много практики, интересных знакомств и живых систем.
Успейте подать заявку
T-Sync Conf — офлайн-конференция от Группы «Т-Технологии» для опытных инженеров. 7 февраля в Москве на площадке TAU соберутся платформенные, security- и дата-инженеры, аналитики, DevOps-, SRE-, CI/CD-, AI-, ML-, R&D- и DX -специалисты.
Как все устроено:
— Контуры — тематические зоны, каждая из которых раскрывает отдельный слой инженерной реальности: AI, Data, R&D, Security, Platform и другие направления.
— Вместо классических докладов — круглые столы, стенды, хакатон, воркшопы и мастер-классы.
— Инженерные решения изнутри — возможность посмотреть, как устроены технологии в Т-Банке и других компаниях, и пообщаться напрямую с теми, кто их создает.
А еще много практики, интересных знакомств и живых систем.
Успейте подать заявку
👍5❤4⚡4
Управление изменениями
Книга "Управление изменениями без потрясений и конфликтов" Адизеса
Хорошая база позволяет принимать решения в сложных ситуациях. Когда у тебя есть структура в голове, ты не смотришь на новую проблему как на что-то уникальное – всегда есть нюансы, но ты уже примерно понимаешь, как действовать.
Помимо практики, мне нравится читать книги, которые под эту практику подводят теорию. Знания становятся более структурированными.
Одна из областей, где давно хотел систематизировать знания – понимание особенностей людей. Какие бывают типы, как они действуют, принимают решения. Интуитивно понимаю, что делать, но четкой структуры не было. Решил начать с классики – Адизеса.
Природа изменений
Адизес начинает с того, что изменения неизбежны, а любое изменение порождает проблемы. И эти проблемы необходимо решать – пока никаких открытий:)
PAEI: разные люди – разное восприятие
Чтобы решать проблемы и проводить изменения, нужно сначала спланировать, а потом воплотить решение. И для этого нужны разные роли – Адизес называет их PAEI. Не буду раскрывать модель подробно, это лучше читать в оригинале, но суть в том, что разные типы людей буквально живут в разных системах координат.
Они по-разному расставляют приоритеты: одному важно сделать результат здесь и сейчас, другому – выстроить порядок и процессы, третьему – увидеть новые возможности, четвёртому – чтобы команда была согласна и двигалась вместе.
Они по-разному понимают одни и те же слова. "Да" для одного типа – это действительно "да". Для другого может означать "может быть". А для третьего – вежливый способ сказать "нет".
Когда начинаешь понимать эти особенности, многие рабочие недоразумения начинают выглядеть иначе, всё становится более предсказуемым.
Конфликт как норма
А раз люди разные – конфликт неизбежен. Один хочет делать сейчас, другой хочет сначала всё продумать, третий хочет менять направление, четвёртый хочет чтобы все договорились. Адизес утверждает, что конфликт – по сути необходимое условие хорошего решения. Плохо не когда команда спорит, а когда не спорит – значит кто-то молчит или всем всё равно.
Но конфликт бывает конструктивным и деструктивным. Разница – во взаимном уважении и доверии. Если они есть, разногласия ведут к лучшим решениям. Если нет – то ничего хорошего не получится.
CAPI: почему недостаточно быть правым
Допустим, команда прошла через конструктивный конфликт и нашла хорошее решение. Достаточно ли этого, чтобы изменение произошло?
Адизес вводит концепцию CAPI – Coalesced Authority, Power, Influence. Authority – это формальное право говорить "да" или "нет". Power – возможность поощрять или наказывать. Influence – способность убеждать без принуждения. Чтобы изменение реально случилось, нужно собрать все три компонента. Можно быть правым и иметь лучшее решение – но если нет полномочий, власти или влияния, ничего не произойдёт.
Менеджерская результативность – это по сути способность собрать нужный CAPI под свои задачи.
В книге раскрываются и другие интересные темы, но именно это показалось особенно интересным.
#books
Книга "Управление изменениями без потрясений и конфликтов" Адизеса
Хорошая база позволяет принимать решения в сложных ситуациях. Когда у тебя есть структура в голове, ты не смотришь на новую проблему как на что-то уникальное – всегда есть нюансы, но ты уже примерно понимаешь, как действовать.
Помимо практики, мне нравится читать книги, которые под эту практику подводят теорию. Знания становятся более структурированными.
Одна из областей, где давно хотел систематизировать знания – понимание особенностей людей. Какие бывают типы, как они действуют, принимают решения. Интуитивно понимаю, что делать, но четкой структуры не было. Решил начать с классики – Адизеса.
Природа изменений
Адизес начинает с того, что изменения неизбежны, а любое изменение порождает проблемы. И эти проблемы необходимо решать – пока никаких открытий:)
PAEI: разные люди – разное восприятие
Чтобы решать проблемы и проводить изменения, нужно сначала спланировать, а потом воплотить решение. И для этого нужны разные роли – Адизес называет их PAEI. Не буду раскрывать модель подробно, это лучше читать в оригинале, но суть в том, что разные типы людей буквально живут в разных системах координат.
Они по-разному расставляют приоритеты: одному важно сделать результат здесь и сейчас, другому – выстроить порядок и процессы, третьему – увидеть новые возможности, четвёртому – чтобы команда была согласна и двигалась вместе.
Они по-разному понимают одни и те же слова. "Да" для одного типа – это действительно "да". Для другого может означать "может быть". А для третьего – вежливый способ сказать "нет".
Когда начинаешь понимать эти особенности, многие рабочие недоразумения начинают выглядеть иначе, всё становится более предсказуемым.
Конфликт как норма
А раз люди разные – конфликт неизбежен. Один хочет делать сейчас, другой хочет сначала всё продумать, третий хочет менять направление, четвёртый хочет чтобы все договорились. Адизес утверждает, что конфликт – по сути необходимое условие хорошего решения. Плохо не когда команда спорит, а когда не спорит – значит кто-то молчит или всем всё равно.
Но конфликт бывает конструктивным и деструктивным. Разница – во взаимном уважении и доверии. Если они есть, разногласия ведут к лучшим решениям. Если нет – то ничего хорошего не получится.
CAPI: почему недостаточно быть правым
Допустим, команда прошла через конструктивный конфликт и нашла хорошее решение. Достаточно ли этого, чтобы изменение произошло?
Адизес вводит концепцию CAPI – Coalesced Authority, Power, Influence. Authority – это формальное право говорить "да" или "нет". Power – возможность поощрять или наказывать. Influence – способность убеждать без принуждения. Чтобы изменение реально случилось, нужно собрать все три компонента. Можно быть правым и иметь лучшее решение – но если нет полномочий, власти или влияния, ничего не произойдёт.
Менеджерская результативность – это по сути способность собрать нужный CAPI под свои задачи.
В книге раскрываются и другие интересные темы, но именно это показалось особенно интересным.
#books
🔥7👍5⚡3
Продолжая разговор о книге Адизеса хочется еще поделиться парочкой цитат, которые выписал, пока читал книгу.
Простая мысль, но в жизни часто бывает иначе: люди блокируют решения, не имея полномочий их принимать. И нужно четко понимать с кем ты работаешь и кто тебе нужен, чтобы протащить свое решение.
Очень часто это вижу и проговариваю с теми, кто приходит посоветоваться. Будь ты хоть миллион раз прав – если был агрессивен, раздражен или токсичен, тебя уже не будут слушать. Будут цепляться за форму, а не за содержание. Поэтому очень важно следить за тем, как ты доносишь свою точку зрения.
Проблема новоиспеченных тимлидов, которых поставили, нагрузили обязанностями, а вот про полномочия и власть – забыли. Кого нанимать? Не твое. Решение о премии? Не твое. Приоритеты менять? Согласуй сначала. Еще что-то хочешь внедрить – тоже согласуй. И вот у тебя куча обязанностей, а полномочий и власти – нет.
#books
Если в ответ на ваше предложение босс говорит "нет", спросите, имеет ли он право говорить "да". Если ему не позволено говорить "да", то выясните, кто обладает этим правом. Только этот человек и должен иметь право говорить "нет"
Простая мысль, но в жизни часто бывает иначе: люди блокируют решения, не имея полномочий их принимать. И нужно четко понимать с кем ты работаешь и кто тебе нужен, чтобы протащить свое решение.
Всякий раз, не соглашаясь с собеседником, уделяйте больше внимания тому, как вы выражаете несогласие, а не тому, что составляет его суть
Очень часто это вижу и проговариваю с теми, кто приходит посоветоваться. Будь ты хоть миллион раз прав – если был агрессивен, раздражен или токсичен, тебя уже не будут слушать. Будут цепляться за форму, а не за содержание. Поэтому очень важно следить за тем, как ты доносишь свою точку зрения.
Менеджеры результативны тогда, когда имеют достаточно полномочий, власти и влияния для выполнения своих обязанностей
Проблема новоиспеченных тимлидов, которых поставили, нагрузили обязанностями, а вот про полномочия и власть – забыли. Кого нанимать? Не твое. Решение о премии? Не твое. Приоритеты менять? Согласуй сначала. Еще что-то хочешь внедрить – тоже согласуй. И вот у тебя куча обязанностей, а полномочий и власти – нет.
#books
Telegram
DevFM
Управление изменениями
Книга "Управление изменениями без потрясений и конфликтов" Адизеса
Хорошая база позволяет принимать решения в сложных ситуациях. Когда у тебя есть структура в голове, ты не смотришь на новую проблему как на что-то уникальное – всегда…
Книга "Управление изменениями без потрясений и конфликтов" Адизеса
Хорошая база позволяет принимать решения в сложных ситуациях. Когда у тебя есть структура в голове, ты не смотришь на новую проблему как на что-то уникальное – всегда…
👍12⚡5🔥5❤2
Мультиагенты – может не надо?
Сейчас мультиагентность – одна из самых горячих тем. Фреймворки, оркестраторы, архитектуры с несколькими взаимодействующими агентами.
И вот Anthropic выпустили статью, которая мне очень зашла. Потому что мне кажется они достаточно критично подошли к вопросу – по-инженерному. Не нужно городить мультиагентность, пока не убедились, что она вам реально нужна.
Ребята говорят, что видели, как команды месяцами строят сложные мультиагентные архитектуры – а потом выясняется, что улучшенный промпт на одном агенте даёт тот же результат.
Важно также понимать цену вопроса: по оценкам Anthropic, такие системы потребляют в 3-10 раз больше токенов. Контекст дублируется между агентами, добавляются координационные сообщения, результаты нужно резюмировать при передаче.
Когда действительно есть смысл
– Много лишнего контекста. Когда подзадача генерирует тысячи токенов, из которых нужна пара строк. Отдельный агент отработает в чистом контексте и вернёт только релевантное.
– Задачи можно параллелить. Исследование нескольких источников, тестирование разных компонентов, проверка независимых гипотез. В подобных задачах мало общего контекста. Тут важно, что параллельность — это не про скорость, а про тщательность. Токенов потратится больше, зато покрытие будет полнее.
– Специализация улучшает выбор инструментов. Агент с 20+ тулами начинает путаться. Разделение по контексту использования снижает ошибки.
Как делить
Интуитивно хочется разделить по ролям: один планирует, другой реализует бекенд, третий фронтенд, и ещё один пишет тесты. Но это создаёт эффект испорченного телефона – на каждой передаче теряется контекст и нюансы.
Anthropic предлагают другой принцип: группировать по требуемому контексту, а не по типу работы. Если двум задачам нужна одна и та же информация – пусть их делает один агент. Если задаче нужен изолированный контекст – можно вынести в отдельного.
Верификационный агент
Отдельно в статье выделяют простой паттерн: основной агент делает работу, отдельный проверяет результат. Это хорошо работает, потому что для проверки нужен минимум контекста – только результат и критерии.
Нюанс из практики: без явных инструкций агент склонен объявлять успех после пары поверхностных проверок. Поэтому верификатору важно чётко прописать, что именно проверять.
Такой паттерн применяется в spec-kit. Там после формирования плана запускается отдельная проверка на соответствие критериям.
Ну и главный посыл очень простой: перед тем как что-то делать, спроси себя, зачем ты это делаешь, какие от этого профиты.
#ai
Сейчас мультиагентность – одна из самых горячих тем. Фреймворки, оркестраторы, архитектуры с несколькими взаимодействующими агентами.
И вот Anthropic выпустили статью, которая мне очень зашла. Потому что мне кажется они достаточно критично подошли к вопросу – по-инженерному. Не нужно городить мультиагентность, пока не убедились, что она вам реально нужна.
Ребята говорят, что видели, как команды месяцами строят сложные мультиагентные архитектуры – а потом выясняется, что улучшенный промпт на одном агенте даёт тот же результат.
Важно также понимать цену вопроса: по оценкам Anthropic, такие системы потребляют в 3-10 раз больше токенов. Контекст дублируется между агентами, добавляются координационные сообщения, результаты нужно резюмировать при передаче.
Когда действительно есть смысл
– Много лишнего контекста. Когда подзадача генерирует тысячи токенов, из которых нужна пара строк. Отдельный агент отработает в чистом контексте и вернёт только релевантное.
– Задачи можно параллелить. Исследование нескольких источников, тестирование разных компонентов, проверка независимых гипотез. В подобных задачах мало общего контекста. Тут важно, что параллельность — это не про скорость, а про тщательность. Токенов потратится больше, зато покрытие будет полнее.
– Специализация улучшает выбор инструментов. Агент с 20+ тулами начинает путаться. Разделение по контексту использования снижает ошибки.
Как делить
Интуитивно хочется разделить по ролям: один планирует, другой реализует бекенд, третий фронтенд, и ещё один пишет тесты. Но это создаёт эффект испорченного телефона – на каждой передаче теряется контекст и нюансы.
Anthropic предлагают другой принцип: группировать по требуемому контексту, а не по типу работы. Если двум задачам нужна одна и та же информация – пусть их делает один агент. Если задаче нужен изолированный контекст – можно вынести в отдельного.
Верификационный агент
Отдельно в статье выделяют простой паттерн: основной агент делает работу, отдельный проверяет результат. Это хорошо работает, потому что для проверки нужен минимум контекста – только результат и критерии.
Нюанс из практики: без явных инструкций агент склонен объявлять успех после пары поверхностных проверок. Поэтому верификатору важно чётко прописать, что именно проверять.
Такой паттерн применяется в spec-kit. Там после формирования плана запускается отдельная проверка на соответствие критериям.
Ну и главный посыл очень простой: перед тем как что-то делать, спроси себя, зачем ты это делаешь, какие от этого профиты.
#ai
👍10🔥7🌭4❤1
Влияние AI-агентов на обучение в разработке
Очередная интересная статья от Anthropic на горячую тему. Ребята попытались понять, как применение AI-агентов влияет на обучение разработчиков.
Эксперимент такой: 52 джуниора решали задачу с использованием незнакомой библиотеки – половина с AI-агентом, половина без. После выполнения задачи участники проходили тест на понимание материала: отладка, чтение кода, написание кода и концептуальное понимание.
По скорости группа с AI закончила всего на 2 минуты быстрее, эта разница статистически незначима – то есть выигрыша на этой задаче не было. А вот по тесту разница уже ощутимая: 50% у группы с AI против 67% у контрольной. Разница 17 процентных пунктов.
Самый большой разрыв оказался именно в отладке – способности находить и диагностировать ошибки. И это логично: группа без AI сама натыкалась на баги и сама их разруливала, а с AI этот этап просто пропускался.
Помимо циферок, ребята записывали сессии и смотрели паттерны поведения. И тут любопытное наблюдение: дело не в самом AI-агенте, а в том, как его используют.
Те, кто показал слабые результаты, делегировали агенту почти всё: полная автоматизация с самого начала, постепенное сползание от вопросов к "сделай за меня", или отладка через агента вместо самостоятельного разбора.
А у тех, кто показал хорошие результаты, паттерны другие: генерировали код, но потом сами его ревьюили и спрашивали "почему так", просили код сразу с объяснениями и изучали, или вообще задавали только концептуальные вопросы, а код и баги разбирали сами.
Отсюда напрашивается гипотеза: AI усиливает продуктивность там, где знания уже есть, но тормозит формирование новых. Ты быстрее закрываешь задачу – но не особо усваиваешь, что было сделано.
Считаю здорово, что такие исследования появляются, но ребята сами говорят, что это просто капля в море – ещё очень много белых пятен, которые необходимо исследовать.
Но, друзья, от этого и особенно интересно, не так ли?
#ai
Очередная интересная статья от Anthropic на горячую тему. Ребята попытались понять, как применение AI-агентов влияет на обучение разработчиков.
Эксперимент такой: 52 джуниора решали задачу с использованием незнакомой библиотеки – половина с AI-агентом, половина без. После выполнения задачи участники проходили тест на понимание материала: отладка, чтение кода, написание кода и концептуальное понимание.
По скорости группа с AI закончила всего на 2 минуты быстрее, эта разница статистически незначима – то есть выигрыша на этой задаче не было. А вот по тесту разница уже ощутимая: 50% у группы с AI против 67% у контрольной. Разница 17 процентных пунктов.
Самый большой разрыв оказался именно в отладке – способности находить и диагностировать ошибки. И это логично: группа без AI сама натыкалась на баги и сама их разруливала, а с AI этот этап просто пропускался.
Помимо циферок, ребята записывали сессии и смотрели паттерны поведения. И тут любопытное наблюдение: дело не в самом AI-агенте, а в том, как его используют.
Те, кто показал слабые результаты, делегировали агенту почти всё: полная автоматизация с самого начала, постепенное сползание от вопросов к "сделай за меня", или отладка через агента вместо самостоятельного разбора.
А у тех, кто показал хорошие результаты, паттерны другие: генерировали код, но потом сами его ревьюили и спрашивали "почему так", просили код сразу с объяснениями и изучали, или вообще задавали только концептуальные вопросы, а код и баги разбирали сами.
Отсюда напрашивается гипотеза: AI усиливает продуктивность там, где знания уже есть, но тормозит формирование новых. Ты быстрее закрываешь задачу – но не особо усваиваешь, что было сделано.
Считаю здорово, что такие исследования появляются, но ребята сами говорят, что это просто капля в море – ещё очень много белых пятен, которые необходимо исследовать.
Но, друзья, от этого и особенно интересно, не так ли?
#ai
Anthropic
How AI assistance impacts the formation of coding skills
Anthropic is an AI safety and research company that's working to build reliable, interpretable, and steerable AI systems.
👍22⚡4❤4🔥1