Субботнее развлекательное

Бывает сидишь себе спокойно в общественном месте, а какой-то неразумный человек включает видяшку на полную громкость. Без наушников. ААА!!!

Нашёлся человек, который решил эту проблему по-инженерному – написал STFU.

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

Исходники тоже есть – можно глянуть.

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

Не могу не поделиться. Александр Поломодов часто пишет и выступает про System Design. Особенно много внимания уделяет System Design интервью.

И вот он собрал многие материалы в одном месте – сделал сайт , посвящённый этой теме.

Если вам актуально – очень рекомендую заглянуть. Надеюсь, проект будет развиваться.

Управление изменениями
Книга "Управление изменениями без потрясений и конфликтов" Адизеса

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

Помимо практики, мне нравится читать книги, которые под эту практику подводят теорию. Знания становятся более структурированными.

Одна из областей, где давно хотел систематизировать знания – понимание особенностей людей. Какие бывают типы, как они действуют, принимают решения. Интуитивно понимаю, что делать, но четкой структуры не было. Решил начать с классики – Адизеса.

Природа изменений
Адизес начинает с того, что изменения неизбежны, а любое изменение порождает проблемы. И эти проблемы необходимо решать – пока никаких открытий:)

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

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

Они по-разному понимают одни и те же слова. "Да" для одного типа – это действительно "да". Для другого может означать "может быть". А для третьего – вежливый способ сказать "нет".

Когда начинаешь понимать эти особенности, многие рабочие недоразумения начинают выглядеть иначе, всё становится более предсказуемым.

Конфликт как норма
А раз люди разные – конфликт неизбежен. Один хочет делать сейчас, другой хочет сначала всё продумать, третий хочет менять направление, четвёртый хочет чтобы все договорились. Адизес утверждает, что конфликт – по сути необходимое условие хорошего решения. Плохо не когда команда спорит, а когда не спорит – значит кто-то молчит или всем всё равно.

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

CAPI: почему недостаточно быть правым
Допустим, команда прошла через конструктивный конфликт и нашла хорошее решение. Достаточно ли этого, чтобы изменение произошло?

Адизес вводит концепцию CAPI – Coalesced Authority, Power, Influence. Authority – это формальное право говорить "да" или "нет". Power – возможность поощрять или наказывать. Influence – способность убеждать без принуждения. Чтобы изменение реально случилось, нужно собрать все три компонента. Можно быть правым и иметь лучшее решение – но если нет полномочий, власти или влияния, ничего не произойдёт.

Менеджерская результативность – это по сути способность собрать нужный CAPI под свои задачи.

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

#books

Продолжая разговор о книге Адизеса хочется еще поделиться парочкой цитат, которые выписал, пока читал книгу.

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

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

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

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

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

Проблема новоиспеченных тимлидов, которых поставили, нагрузили обязанностями, а вот про полномочия и власть – забыли. Кого нанимать? Не твое. Решение о премии? Не твое. Приоритеты менять? Согласуй сначала. Еще что-то хочешь внедрить – тоже согласуй. И вот у тебя куча обязанностей, а полномочий и власти – нет.

#books

Пятничное развлекательное

Из каждого утюга появляются фреймворки с идеей: поручил задачу агенту – и он пошёл её делать под ключ, используя кучу инструментов и саб-агентов, пока не сделает. Я такие штуки периодически тестирую.

Результат можете посмотреть на картинке 😬

Мультиагенты – может не надо?

Сейчас мультиагентность – одна из самых горячих тем. Фреймворки, оркестраторы, архитектуры с несколькими взаимодействующими агентами.

И вот Anthropic выпустили статью, которая мне очень зашла. Потому что мне кажется они достаточно критично подошли к вопросу – по-инженерному. Не нужно городить мультиагентность, пока не убедились, что она вам реально нужна.

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

Важно также понимать цену вопроса: по оценкам Anthropic, такие системы потребляют в 3-10 раз больше токенов. Контекст дублируется между агентами, добавляются координационные сообщения, результаты нужно резюмировать при передаче.

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

– Задачи можно параллелить. Исследование нескольких источников, тестирование разных компонентов, проверка независимых гипотез. В подобных задачах мало общего контекста. Тут важно, что параллельность — это не про скорость, а про тщательность. Токенов потратится больше, зато покрытие будет полнее.

– Специализация улучшает выбор инструментов. Агент с 20+ тулами начинает путаться. Разделение по контексту использования снижает ошибки.

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

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

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

Нюанс из практики: без явных инструкций агент склонен объявлять успех после пары поверхностных проверок. Поэтому верификатору важно чётко прописать, что именно проверять.

Такой паттерн применяется в spec-kit. Там после формирования плана запускается отдельная проверка на соответствие критериям.

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

#ai

Влияние AI-агентов на обучение в разработке

Очередная интересная статья от Anthropic на горячую тему. Ребята попытались понять, как применение AI-агентов влияет на обучение разработчиков.

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

По скорости группа с AI закончила всего на 2 минуты быстрее, эта разница статистически незначима – то есть выигрыша на этой задаче не было. А вот по тесту разница уже ощутимая: 50% у группы с AI против 67% у контрольной. Разница 17 процентных пунктов.

Самый большой разрыв оказался именно в отладке – способности находить и диагностировать ошибки. И это логично: группа без AI сама натыкалась на баги и сама их разруливала, а с AI этот этап просто пропускался.

Помимо циферок, ребята записывали сессии и смотрели паттерны поведения. И тут любопытное наблюдение: дело не в самом AI-агенте, а в том, как его используют.

Те, кто показал слабые результаты, делегировали агенту почти всё: полная автоматизация с самого начала, постепенное сползание от вопросов к "сделай за меня", или отладка через агента вместо самостоятельного разбора.

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

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

Считаю здорово, что такие исследования появляются, но ребята сами говорят, что это просто капля в море – ещё очень много белых пятен, которые необходимо исследовать.

Но, друзья, от этого и особенно интересно, не так ли?

#ai

Стратоплан CTO: 5 занятий спустя

Прошло 5 занятий по специальности СТО в Стратоплане, делюсь промежуточными впечатлениями. (начало тут)

Каждое занятие состоит из лекционной и практической частей.

Лекции. Тут всё зависит от лектора. В теории обычно всё понятно: вот так проводи 1-on-1, вот так делай стратегию, вот так управляй ожиданиями. Но когда сталкиваешься с этим на практике – узнаешь много нюансов и подводных камней.

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

Практика – это тот аспект, который мне особенно нравится. После прослушивания теории даётся кейс, который необходимо решить. Сначала ты его обдумываешь индивидуально, а потом всех распределяют по группам и вы в группе обсуждаете решение. Я бы сказал, что групповое обсуждение кейса – это самое ценное. Когда ты с квалифицированными ребятами обсуждаешь кейс, и люди делятся решениями, которые тебе не пришли в голову – это прям круто. Только ради этого стоит приходить 🙂

Продукт на миллион строк кода – и ни одной написанной человеком

Как же быстро меняется сфера разработки. Помню, как в начале 2024 года начал разрабатывать с использованием LLM. Тогда ещё не было никаких агентов, не было и расширений для сред разработки. Был обычный чат. Копируешь код из чата, вставляешь в проект, руками правишь. Но уже тогда мне казалось это чудом чудесным.

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

Прочитал отличную статью от OpenAI – где ребята делятся опытом разработки внутреннего продукта только с использованием агентов. Три инженера, ~1500 пулл-реквестов, порядка миллиона строк кода. Ноль строк ручного кода.

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

От написания кода – к проверке работоспособности
В какой-то момент ребята упёрлись не в генерацию кода, а в проверку того, что он работает. И начали строить автономный луп – подключили Chrome DevTools, чтобы агент сам проверял UI через DOM-снапшоты и скриншоты. Подняли локальный стек метрик и логов, чтобы агент мог полностью отслеживать происходящее.

Документация стала критичной
Первым подходом было запихнуть все инструкции в один большой AGENTS.md. Предсказуемо не сработало – контекст дефицитный ресурс, и когда важно всё, важно ничего.

Рабочий подход оказался такой: короткий AGENTS.md (~100 строк) работает как оглавление с указателями на документацию в репозитории. Дизайн-доки, архитектура, планы, технический долг – всё версионировано и лежит рядом с кодом.

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

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

Сборка мусора для техдолга
Когда генерируется столько кода, агент воспроизводит паттерны, которые уже есть в репозитории – включая неудачные. Сначала команда тратила каждую пятницу на ручную чистку AI slop – дублирующиеся хелперы, невалидированные данные, расползающиеся паттерны. Такой подход не масштабировался.
В итоге поставили фоновые задачи – агент регулярно сканирует репозиторий, ищет отклонения от заданных архитектурных правил и делает исправления. По сути – непрерывная сборка мусора для кодовой базы.

#ai

Ютуб подсунул любопытное видео.

Сейчас в области AI накопилась куча терминов – LLM, RAG, Embeddings, Guardrails и ещё много всякого. Ребята попытались разложить всё это в одну удобную табличку, чтобы навести порядок в голове.

Посмотрел с удовольствием. А видео в начале поста – для поднятия настроения :)

#ai

Заходите – будет интересно

Когда плотно работаешь в какой-то области, всегда интересно подсмотреть – а как делают другие? Что у них там интересного происходит?

Ребята уже второй раз организовывают митап AI Dev Day. Главная идея – поделиться опытом, как AI-инструменты внедряются в процесс разработки.

Мне особенно интересно послушать, как в других компаниях разрабатывают кодовых ассистентов. И еще тема, которая цепляет – опыт внедрения метрик для оценки AI в цикле разработки. Как это делать правильно – кажется, никто еще не знает.

Ну а я поделюсь нашим опытом: как мы развиваем агента для разработчиков в IDE. Как продвигаем инструмент внутри компании и растим адопшен. Отдельно расскажу про агента за пределами IDE на примере YQL-агента – как адаптировать к внутреннему домену, как оценивать качество и где брать для этого данные.

Мероприятие пройдёт 15 марта офлайн, но будет онлайн-трансляция. Регистрируйтесь, приходите, буду рад пообщаться.

#devfm #ai

Куда податься начинающим разработчикам

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

Прочитал приятную статью от создателя htmx – стоит ли сейчас идти в разработчики? Автор говорит: да, и делится своими мыслями.

Первое, о чем говорит автор – нужно самостоятельно писать код. Полностью разделяю эту мысль. Если не писать код, то и читать его не будешь уметь. А во времена AI умение читать код становится ещё более важным навыком. Более того, когда не умеешь писать код – у тебя нет понимания, как делать правильно. В итоге просто не сможешь контролировать то, что разрабатываешь.

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

А вот какие навыки будут важны.

Коммуникативные навыки. С агентом, с людьми, письменная и устная.

Понимание бизнес-домена. Тут понравилась забавная мысль. Со стороны бизнеса сейчас порой слышим: всё, нам не нужны разработчики. Автор немного хихикает: это нам, разработчикам, теперь не нужны люди от бизнеса :)

А если серьезно, то я думаю спрос на разработчиков будет только расти. Мы уже не первый раз проходим подобное: 4GL-языки, визуальное программирование, nocode-платформы. Каждый раз слышали, что теперь-то разработчики не нужны, и каждый раз оказывалось, что нужны и даже больше, чем раньше.

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

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

В общем, выдыхаем – разработчики всё так же будут нужны.

#ai