DevFM

Периодически я рассказываю о классных мероприятиях – и вот одно из них – infra.conf'26 – конференция про создание и эксплуатацию высоконагруженных систем и инфраструктуры. Мне конечно же интересны темы, связанные с ИИ 🙂 Активное развитие ИИ внесло существенные коррективы: послушаем, с какими новыми вызовами сталкиваются ребята и как с этим справляются. Мероприятие пройдёт 4 июня. Приходите – будет классно 🙂

Как подготовить кодовую базу к работе с агентом Очередная интересная статья от Антропика. На этот раз – о том, как подготовить свою кодовую базу к работе с агентом. И одно дело, когда у тебя небольшой проектик, а другое – когда у тебя миллионы-миллионы строк кода, причём некоторые из них последний раз трогались в 2007-м. Как агенту во всём этом ориентироваться? Индустрия много крутилась вокруг индексирования кода – у того же Cursor есть такой функционал. Но ребята идут в другую сторону. И говорят: успех – в качественной обвязке, она же harness. В неё входят: CLAUDE.md (он же AGENTS.md), hooks, skills, plugins, поддержка LSP и MCP-серверы. То есть если подготовить проект, агент сможет хорошо в нём ориентироваться. Дальше – чеклист, как это сделать: 1. Подготовьте CLAUDE.md для своего проекта. Если у вас огромный проект или монорепа – имеет смысл сделать отдельный CLAUDE.md для разных директорий, а в корневом оставить только общую картину мира. Обычно агент сам разбирается в структуре, но если вы знаете, что ваш проект – клубок, в корневом CLAUDE.md стоит сделать навигацию: коротенько, где что смотреть. Частая ошибка – класть в CLAUDE.md информацию, которая нужна не всегда, а под конкретный сценарий. По сути это то, что можно вынести в скилл. 2. Настройте hooks. Можно повесить хуки на подгрузку нужного контекста, на запуск линтеров и форматтеров. И в целом сделайте так, чтобы агент умел гонять проверки и тесты только по той части проекта, над которой идёт работа, – это быстрее и не засоряет контекст. Частая ошибка здесь – пытаться сделать промптом то, что можно было сделать обычной автоматикой. Если можно автоматикой – всегда делайте автоматикой. 3. Для повторяющихся, понятных задач сделайте скиллы. А также подключите к агенту LSP-сервер. 4. Поддерживайте .ignore-файл, чтобы в контекст агента не попадала ненужная информация – например, autogenerated или third-party код. 5. Раз в несколько месяцев пересматривайте CLAUDE.md и подобные артефакты. Это живой документ, который нужно периодически чистить: что-то становится неактуальным, модели становятся умнее, и какая-то информация им уже просто не нужна. Я помню времена, когда все автогенерировали эти артефакты – получалась такая фигня, что лучше уж их отсутствие, чем помойка. 6. У всего этого хозяйства должен быть ответственный – тот, кто поддерживает и следит за актуальностью. Обратите внимание: пункты 5 и 6 – процессные. И, пожалуй, они самые сложные и самые важные (и скучные). По сути это всё про классические процессы в команде, в которые нужно встроить новые практики. Так что если у вас процессы уже настроены и вы знаете, как это делать – вам будет проще :) #ai

Скилл поверх MCP Я уже писал про Skills. А недавно попалось отличное видео от ребят из Supabase, где раскрывают интересную мне тему – skills over mcp. Докладчик говорит так: вот есть у вас MCP – по сути просто набор тулов, чтобы агент ходил в ваш сервис. Но это просто тулы. Агент по-прежнему не знает хороших практик, принятых для сервиса, не знает его нюансов. И вот тут поверх MCP появляется скилл – который эти практики и нюансы агенту и приносит. По замерам ребят, в такой связке агент заметно лучше справляется с задачами. Дальше – несколько мыслей из видео, которые во многом совпадают с моим опытом. Описывайте явные сценарии. В видео это прямо подчёркивается: вы хорошо знаете свой продукт, знаете популярные сценарии и то, как их правильно выполнять – вот это и опишите. Относитесь к скиллу как к документации для себя. Если при описании сценария вы понимаете, что что-то уже есть в доке – дайте агенту явную ссылку: вот здесь про это написано. Не нужно впихивать всё в одно место и дублировать. Тут полностью согласен: поддерживать актуальную доку и так сложно, а в двух местах – нереально. Кстати, ребята предложили подход, который я нигде раньше не встречал – давать агенту доступ к доке по ssh. Что важно – выносите в SKILL.md. Ссылки ссылками, а следующий тезис такой: если что-то может быть пропущено агентом – оно может быть пропущено. Progressive disclosure у скиллов – это одновременно и фишка, и проблема. По опыту ребят, агент не пойдёт за раз по всем ссылкам из references. Поэтому если для вас что-то категорически важно – не прячьте это вглубь, выносите прямо в SKILL.md. Они так сделали с security-проверками, которые агент обязан выполнить. И ещё одна мысль, которую я часто повторяю: работа над скиллом – это итеративный процесс. Нельзя один раз сказать агенту "сделай скилл" и считать, что всё готово. В видео автор честно говорит, что последние пару месяцев только и занимался, что докручивал скилл. Забавно, что в этой всей ai-движухе порой получаешь противоречивые советы. И когда спрашивают: а как лучше? Совет-то я дать могу, но главный совет – экспериментируйте. Как оно сработает в вашем случае – заранее сложно сказать. #ai

Создаем свои скиллы (часть 4) Что касается создания своих скиллов – тут я обычно беру skill-creator от Anthropic. Очень мощная штука: проводит по всему флоу создания, задаёт уточняющие вопросы и помогает написать евалы – чтобы при доработке скилла сразу видеть, что старые сценарии не сломались. Скиллов общего назначения сейчас супер много, и, как по мне, имеет смысл находить что-то популярное и местами подточить под себя. Сам я пишу скиллы под около-рутинные задачи – там, где хочу передать агенту экспертизу. Например, на работе периодически нужно делать релиз-ноты – и в продукте, и на информационных площадках. Процесс довольно топорный: 1. Достать из таск-трекера то, что вошло в релиз 2. Методом пристального взгляда отфильтровать то, что важно пользователям 3. Сформулировать всё на пользовательском языке, перевести на английский 4. Найти в кодовой базе json, который отвечает за релиз-ноты, и дописать нужное – то же самое для английского ... N. Закоммитить, запушить N+1. Взять эти релиз-ноты, расписать подробнее по шаблону и разложить по площадкам Руками это задача на час минимум. Топорно с агентом – минут пятнадцать. Со скиллом – три минуты. Или, например, скилл для постов: проверить грамматику, поставить нужный тег и опубликовать из Obsidian, применив телеграммное форматирование (вручную это очень заморочно). Аналогично есть скилл для моего таск-менеджера TickTick. Надиктовал задачу – а он уже знает, в какое место её положить, какую дату поставить, какие теги навесить. Очень удобно. Ещё пара моментов: – Скиллы стоит делать от сценариев. Обычно сначала просто решаешь задачу через агента, а потом понимаешь, что это можно обернуть в скилл – Не жди, что заработает с первого раза – особенно на сложных скиллах. Это инкрементальный процесс: нашёл, где не работает – подточил, написал евал – и так из раза в раз – skill.md не резиновый. Общая рекомендация Anthropic – не больше 5000 токенов, но и это кажется дофигамба. Держим skill.md маленьким, остальное выносим в references – Не пиши в скилле общеизвестное. Как понять, что лишнее? Только опытным путём: есть сомнения – удаляешь кусок информации и смотришь, как работает. Опять же, skill-creator при прогоне евалов сам подсказывает, что можно улучшить #devfm #ai

Где брать скиллы (часть 3) С тем, как устроены скиллы, разобрались, даже в движении. А где их брать? Мне нравится простой каталог skills.sh. Удобно, что можно отсортировать по популярности или посмотреть, что сейчас набирает обороты – можно позалипать, вдохновиться. Из тех, чем сам пользуюсь: frontend-design – уже про него рассказывал. Лучший способ получить адекватный дизайн, когда дизайнера рядом нет. brainstorming – запускаешь перед началом работы над задачей, и агент начинает задавать уточняющие вопросы. После 5–6 вопросов требования становятся заметно полнее. На практике брейншторм почти всегда поднимает что-то, о чём не подумал или отложил на потом. pptx – скилл от антропика для работы с презентациями. Два режима: с нуля (чтобы было не вырви глаз) или создать по существующему шаблону – очень удобно. У ребят есть аналогичные скиллы и для pdf, docx, xlsx – тоже стоит присмотреться. playwright-skill – никогда написание тестов не было таким простым и бесплатным. Если необходимость unit-тестов для агента ещё под вопросом, то полноценные e2e – мастхев, и плейрайт-скилл сильно облегчает задачу. Делитесь, какими скиллами пользуетесь – интересно собрать подборку. #devfm #ai

Что там с MCP Когда придумали MCP – это было чудо чудесное. Агент общается с любым внешним сервисом через единый протокол, и тебе не нужно писать обвязку под каждую интеграцию. MCP-серверы стали городить как не в себя. Потом начали вылезать технические нюансы. Описания тулов жрут контекст – подключил несколько серверов, и половина окна занята ещё до первого запроса. Ещё одна проблема, которую я часто вижу на практике. Владелец сервиса, который пишет свой MCP, просто повторяет в нём свой API. В итоге появляются десятки тулов, между которыми агент путается. И вот вышло новое видео от Anthropic – про текущее состояние MCP и планы дальше. MCP – это про коммуникацию с внешними сервисами, и в этой области он реально полезен. А проблема забитого контекста – это не про протокол, а про клиента. Решается с помощью progressive disclosure: нужные тулы подгружаются на лету, по аналогии со скиллами. Ближайшие планы: – Stateless transport – чтобы MCP-сервера можно было хостить как обычный stateless REST. Сейчас streamable HTTP плохо масштабируется – Server discovery – клиент автоматически находит MCP-сервер сайта по well-known URL. Заходит браузер или агент на сайт – и сразу видит, есть ли у него MCP – Skills over MCP – сервер сможет отдавать не только тулы, но и инструкции с доменными знаниями. То есть сервер сам учит агента, как им пользоваться – TypeScript и Python SDK – с учётом набитых шишек ребята будут активно переделывать SDK В общем MCP никуда не исчезают, а продолжают развиваться в своей нише. #ai

Все ли так классно со скиллами - часть 2 В моём окружении скиллы едут и бибикают – периодически слышу: теперь ни рулы, ни MCP не нужны, скиллы всё заменят. Давайте разбираться. Skills vs rules/agents.md Идея звучит соблазнительно: все командные правила кладём в скиллы, агент сам подтянет нужный. На эту тему ребята из Vercel недавно выпустили статью. У них была задача дать ai-агентам актуальную документацию по собственному API. Сравнили два подхода – скиллы и agents.md. Получилось любопытно. Скилл периодически не срабатывал. Что ожидаемо – обещание "агент сам подтянет скилл, когда нужно" оказалось зыбкой почвой. Если же в промпте прямо написать "используй скилл" – срабатывает чаще, но появляется сайд-эффект: агент якорится на документации из скилла и перестаёт смотреть контекст проекта. С agents.md такой истории не случилось. По сути, убирается точка принятия решения – информация всегда в контексте, и гадать "а надо ли сходить за докой" не приходится. А чтобы контекст не переполнялся, в agents.md кладут не всю доку, а сжатый индекс – указатель, где смотреть по какой функциональности. Вывод: скиллы хорошо работают под конкретные сценарии – скилл по проведению ревью, скилл миграции. А для пассивных знаний о проекте лучше подходят rules/agents.md. Skills + CLI vs MCP Следующий заход, который я слышу всё чаще: давайте выкинем MCP, обернём походы во внешние сервисы в cli-утилиты, а в скилл положим инструкцию, как дергать cli. Идея – блеск. Ну по крайней мере на первый взгляд. Во многом разделяю позицию автора статьи – делать так не стоит. MCP – это по сути абстракция над API. LLM не нужно знать, как устроен сервис: достаточно вызвать service.do_x(), а MCP-сервер делает всё остальное. Коннектор между моделью и сервисом, где все шероховатости спрятаны. А когда ту же задачу пытаются переложить на скиллы, начинаются нюансы: – К скиллу нужно ещё доставить cli-утилиту. А если в окружении нет консоли – всё, приехали – Обновление непрозрачное: не до конца понятно, как раскатывать обновления скиллов – Аутентификация – туман войны, как параноидально управлять токенами изнутри скилла – до конца неясно – Скиллы обещают экономить контекст, но это не всегда так. Нужен тебе буквально один вызов, а в контекст улетает весь SKILL.md – Поддержка скиллов у агентов вроде есть, но у каждого свои нюансы. Универсальности, на которую хотелось бы рассчитывать, нет Итого: скиллы – не замена MCP, а другой инструмент под другие задачи. А что имеет смысл попробовать – skill over MCP. MCP остаётся слоем соединения с сервисом, а Skill добавляется поверх как слой знаний о том, как этим MCP правильно пользоваться. В следующем посте посмотрим, что сейчас происходит с MCP. #ai

Скиллы в агентах – часть 1: база Скиллы для агентов продолжают набирать популярность. Поэтому хочется пройтись по этой теме. Первая часть – база. Скилл – это модульная инструкция для агента, которая подгружается в контекст по необходимости. По сути – ещё один способ заставить агента работать так, как вам надо. Но с парой важных отличий. Модульность Скилл – это обычная папка. Внутри обязательный SKILL.md – основная инструкция, которую читает агент: что делает скилл, когда его применять и как именно действовать. Рядом можно положить что угодно: референсы, примеры, вспомогательные скрипты, которые агент вызывает по ходу работы.

my-skill/ ├── SKILL.md ├── references/ │ └── examples.md └── scripts/ └── helper.py

В SKILL.md обязателен фронтматтер с двумя полями – name и description. Progressive disclosure В отличие от правил (rules) или agents.md, которые грузятся в начале каждой сессии, тело скилла в контекст не попадает. Изначально там только name и description из фронтматтера – буквально пара строк. Агент сам решает, нужен ли скилл под текущую задачу, и только тогда подтягивает содержимое. Думаю, именно поэтому скиллы набирают такую популярность. В проектах, которые я видел, бывает куча рулов, которые грузятся по умолчанию, и контекст забит ещё до того, как ты начал работать. С MCP та же история (хотя с этим пытаются бороться – писал тут). Добавил несколько MCP-серверов, и добрая часть контекстного окна уходит под описания тулов, которые в этой сессии даже не пригодятся. Всё это осложняется тем, что обычный пользователь агентов не сразу поймёт, в чём у него проблема, будет страдать и не понимать, почему агент тупит на ровном месте. Скиллы этой боли лишены. Можно иметь десятки скиллов – и практически нулевую нагрузку на контекст, пока они реально не понадобятся. А значит, в агента можно паковать большое количество экспертизы: как у вас устроены миграции, как правильно собрать релиз, как команда делает код-ревью. Чтобы лучше разобраться, как работают скиллы – подготовил визуализацию. В следующем посте посмотрим, а так ли всё хорошо с этими вашими скиллами. #devfm #ai

Время летит – прошло ещё несколько занятий на курсе CTO от Стратоплана. За это время успели посмотреть разные темы: от информационной безопасности до найма и развития ключевых сотрудников. Но больше всего меня впечатлил блок про финансовый менеджмент и построение финансовых моделей. Обычно, будучи тимлидом, руководителем отдела, ты редко сталкиваешься с деньгами напрямую – бюджеты где-то далеко, P&L кто-то другой считает, а ты управляешь людьми и проектами. Тикеты двигаются, релизы случаются – супер. У меня эта тема давненько лежала где-то в личном бэклоге – надо бы разобраться, но понятное дело – всегда находится что-то более приоритетное, плюс когда не погружён в тему – непонятно с чего начинать. В общем, сам вряд ли когда возьмёшься. А тут звёзды сошлись – рассказали на занятиях. Разобрали базовую терминологию – что такое P&L, как устроен управленческий и бухгалтерский учёт, чем они отличаются, какие ещё учёты бывают. Изучили баланс, отчёт о прибылях и убытках. Потом перешли к финансовым моделям, даже попробовали составить фин модель на практике – и тут мозги реально поплавились. С первого раза очень сложно, мало что понятно, но очень интересно.

Из маленьких лайфхаков – я перестал пытаться самостоятельно ориентироваться в незнакомых интерфейсах. Открываешь что-то новое, и вместо того чтобы шариться по менюшкам – просто делаешь скриншот и отправляешь агенту. Тот шуршит пару секунд и подсказывает, куда именно тыкать. На днях настраивал Cloudflare. Кто пользовался – знает, что их панель делали хищники для чужих. Раньше бы полчаса ковырялся по вкладкам. А тут – скрин, в агента, и через несколько секунд пошаговая инструкция, где найти нужное. Аналогично с Фигмой – я в ней нечастый гость. Нужно было скопировать себе чужой проект, и я понятия не имел, как это делается. Скриншот → агент → готово. Тот же паттерн кстати с ридмишками проектов. Открываю README, начинаю вчитываться, пытаюсь понять что за проект, как запустить... а потом бью себя по рукам – зачем? Скидываю агенту, и через минуту у меня полная картина: что за проект, как развернуть, какие есть нюансы. И можно задать уточняющие вопросы, если что-то непонятно. По сути, появился новый навык – не разбираться самому, а делегировать первичное понимание. И это прям очень круто! #ai #devfm

Голосовой ввод – настоящий геймченджер Сам удивляюсь, почему так долго откладывал попробовать управление агентами через голосовой ввод – на днях нужно было много всего сделать, и я подумал, а почему бы и нет, должно получиться быстрее. Неоднократно слышал про Handy – с него и начал. В пару кликов всё настроил: выбрал модель, которая будет работать локально, назначил хоткей на включение режима слушания, и в общем-то всё. Ну что могу сказать – это чудо чудесное, теперь просто не могу остановиться. Последние пару дней все коммуникации с агентами идут через Handy. Из дополнительных приятностей: раньше иногда было лень писать и думал, ааай агент сам разберётся, а потом агент не разбирался и приходилось расхлёбывать – теперь нет никаких проблем, что-то хочешь уточнить – просто продиктуй. Есть ещё классная фича – постпроцессинг: после транскрибации текст отправляется в LLM и обрабатывается согласно твоему промпту – например, более лаконично переформулировать то, что только что надиктовал, убрать слова-паразиты. И теперь я пошёл дальше – надиктовываю вообще всё. Нужно оставить коммент в таске – надиктовал, нужно написать сообщение в телегу – надиктовал. Теперь в офисе постоянно приходится сидеть в переговорках, чтобы не мешать рядом сидящим коллегам. Люто рекомендую 🙂 #постанадиктован

Я продолжаю экспериментировать с разными штуками, которые позволяют запускать автономную работу агента и выполнять поставленные задачи "под ключ". А то начитаешься всякого на реддите, что "если у вас агент ничем не занят, то вы делаете что-то не так" 🙂 Сейчас пробую Ralphex. Очень любопытная штуковина – под капотом используется Claude Code, но поверх накручена полноценная система управления процессом работы агента. Начинается всё по классике – нужно любым удобным способом составить план выполнения задачи. Можно использовать встроенную команду plan. Качественный план для агента – это важно, а здесь особенно важно, потому что когда процесс запущен – вклиниться и что-то подправить уже не получится. Далее просто запускаю ralphex и машина начинает шуршать – выполнять план по шагам, отмечать прогресс, писать тесты. Последний этап – код-ревью. Если у вас в наличии Codex – то он призывается для ревью. Вообще забавно наблюдать, когда один агент чехвостит другого. На самом деле – там много интересного происходит под капотом – рекомендую поэкспериментировать. #ai #agents

Вот и прошёл AI Dev Day. Классное получилось мероприятие. Делюсь выжимкой моего доклада. Первая часть была посвящена тому, как мы разрабатываем агента в среде разработки. Когда мы начинали, было много скепсиса к агентам, поэтому главной ставкой были фичи, связанные с бесшовным входом в разработку с агентом. Но настоящим вызовом стал адопшен – нужно было сделать так, чтобы агентом начали реально пользоваться. Писали доку, гайдлайны, проводили воркшопы – в общем было очень потно, но в то же время приятно было видеть, как в результате растёт аудиторная метрика. Ещё один важный момент, влияющий на адопшен, который подтверждается как нашими внутренними исследованиями, так и исследованиями DORA – важно, чтобы были прозрачные политики безопасности, чтобы люди понимали, что можно отправлять в агентов, а что нет. Вообще агентов сейчас разрабатывают кажется все кому не лень, и при этом по ощущениям не так часто говорят о качестве. Об этом была вторая часть доклада – как подходить к качеству через офлайн и онлайн-метрики на примере еще одного агента для написания запросов к данным. Для офлайн-метрик мы используем валидационный датасет – прогоняем на нём агента, чтобы не выкатить изменения, которые ухудшают пользовательский опыт. Но одних офлайн-метрик недостаточно, потому что реальных сценариев сильно больше, чем мы можем собрать в датасете. И говоря уже об онлайн-метриках, важно их строить от сценариев использования. Первое на что смотрим – CJM, так появляются метрики, основанные на пользовательских сценариев. А чтобы сформировать более точечные метрики, мы регулярно разбираем весь фидбек по работе нашего агента – это дорого, но позволяет понимать, что реально происходит в продукте. По результатам таких разборов тоже появляются метрики – например, мы заметили фейковый тул-колинг, пошли разбираться из-за чего такое происходит, а заодно появилась метрика, насколько эта проблема актуальна для наших пользователей. И ещё заканчивая о метриках – важно не забывать их валидировать, действительно ли метрика измеряет то, что нужно. Иногда об этом забывают, а потом удивляются :) А кто любит движуху вокруг LLM – 21 марта будет ещё один любопытный митап в офлайн и онлайн форматах. #devfm #ai

Куда податься начинающим разработчикам Часто дискутирую на тему, как AI влияет на начинающих разработчиков и как правильно учиться в новых реалиях. Прочитал приятную статью от создателя htmx – стоит ли сейчас идти в разработчики? Автор говорит: да, и делится своими мыслями. Первое, о чем говорит автор – нужно самостоятельно писать код. Полностью разделяю эту мысль. Если не писать код, то и читать его не будешь уметь. А во времена AI умение читать код становится ещё более важным навыком. Более того, когда не умеешь писать код – у тебя нет понимания, как делать правильно. В итоге просто не сможешь контролировать то, что разрабатываешь. При этом AI может быть очень полезен для начинающих. Раньше можно было надолго закопаться в проблеме, даже не зная с какой стороны зайти. AI как раз может помочь – не генерировать за тебя, а подсказать направление. Автор приводит пример AGENTS.md – инструкцию для агента, после которой тот помогает разбираться, а не просто генерирует готовый код. А вот какие навыки будут важны. Коммуникативные навыки. С агентом, с людьми, письменная и устная. Понимание бизнес-домена. Тут понравилась забавная мысль. Со стороны бизнеса сейчас порой слышим: всё, нам не нужны разработчики. Автор немного хихикает: это нам, разработчикам, теперь не нужны люди от бизнеса :) А если серьезно, то я думаю спрос на разработчиков будет только расти. Мы уже не первый раз проходим подобное: 4GL-языки, визуальное программирование, nocode-платформы. Каждый раз слышали, что теперь-то разработчики не нужны, и каждый раз оказывалось, что нужны и даже больше, чем раньше. Архитектурные навыки. Но навыки не тех архитекторов, которые не пишут код и считают себя архитекторами, а тот навык проектирования, который со временем появляется у разработчика. А завершается статья вопросом, как джунам находить работу. Автор считает, что пробиваться через сайты подбора – скорее лотерея. И советует старое доброе: семья, друзья, друзья друзей. Пока читал эту часть статьи подумалось, что еще хорошо могут работать стажировки. Когда компании целенаправленно ищут начинающих инженеров и дают возможность развиваться на настоящих боевых задачах. У нас, например, в Яндексе сейчас идёт набор на стажировки по большому количеству направлений. В общем, выдыхаем – разработчики всё так же будут нужны. #ai

Заходите – будет интересно Когда плотно работаешь в какой-то области, всегда интересно подсмотреть – а как делают другие? Что у них там интересного происходит? Ребята уже второй раз организовывают митап AI Dev Day. Главная идея – поделиться опытом, как AI-инструменты внедряются в процесс разработки. Мне особенно интересно послушать, как в других компаниях разрабатывают кодовых ассистентов. И еще тема, которая цепляет – опыт внедрения метрик для оценки AI в цикле разработки. Как это делать правильно – кажется, никто еще не знает. Ну а я поделюсь нашим опытом: как мы развиваем агента для разработчиков в IDE. Как продвигаем инструмент внутри компании и растим адопшен. Отдельно расскажу про агента за пределами IDE на примере YQL-агента – как адаптировать к внутреннему домену, как оценивать качество и где брать для этого данные. Мероприятие пройдёт 15 марта офлайн, но будет онлайн-трансляция. Регистрируйтесь, приходите, буду рад пообщаться. #devfm #ai

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

Чем отличается RAG по туториалу от реальной системы Собрать RAG или агента по туториалу — легко. А довести до пользователя так, чтобы он не сломался — нет. Но в реальной эксплуатации начинаются сюрпризы: галлюцинации, нестабильное качество, высокий latency, неожиданные счета за API, агент зацикливается или принимает странные решения. Всё вроде работает — но бизнесу этим пользоваться нельзя. RAG и агенты требуют продуманного системного дизайна. Нужно уметь выбирать архитектуру под задачу и собирать из компонентов систему, которая выдержит реальную нагрузку. Поэтому DL-инженеры из DeepSchool сделали курс «RAG и AI-агенты», программу про переход от прототипа к рабочим системам. После обучения вы сможете: • выбирать архитектуру под задачу, нагрузку, бюджет • проектировать и собирать production-ready RAG и агентские системы с измеримыми метриками • настраивать качество: query rewriting, reranking, гибридный поиск, tool-use, memory • разбираться в системном дизайне и деплое • чётко формулировать задачу, определять границы MVP и осознанно выбирать компромиссы в реализации Программа для ML/DL-инженеров и backend-разработчиков, которые работали с LLM и хотят строить системы для реальных пользователей. Для подписчиков моего канала до 6 марта действует скидка 25% 🔥 Изучайте подробности на сайте и оставляйте заявку! Реклама. ИП Фатыхов Тимур Маратович, ИНН 540132430312, Erid 2VtzqwnxPtG

Продукт на миллион строк кода – и ни одной написанной человеком Как же быстро меняется сфера разработки. Помню, как в начале 2024 года начал разрабатывать с использованием LLM. Тогда ещё не было никаких агентов, не было и расширений для сред разработки. Был обычный чат. Копируешь код из чата, вставляешь в проект, руками правишь. Но уже тогда мне казалось это чудом чудесным. Ещё буквально полгода назад помню скепсис вокруг агентской движухи. И вот мы находимся в точке, когда целые продукты разрабатываются полностью агентами. Прочитал отличную статью от OpenAI – где ребята делятся опытом разработки внутреннего продукта только с использованием агентов. Три инженера, ~1500 пулл-реквестов, порядка миллиона строк кода. Ноль строк ручного кода. Роль инженера сместилась Я давно уже об этом думаю, и это подтверждается. Работа разработчика становится другой: понимание бизнеса, того, как что должно работать, и создание условий, в которых агент сможет эффективно работать. Когда что-то ломалось, ребята не просили агента «попробовать ещё раз» – а шли разбираться, какой возможности ему не хватает. От написания кода – к проверке работоспособности В какой-то момент ребята упёрлись не в генерацию кода, а в проверку того, что он работает. И начали строить автономный луп – подключили Chrome DevTools, чтобы агент сам проверял UI через DOM-снапшоты и скриншоты. Подняли локальный стек метрик и логов, чтобы агент мог полностью отслеживать происходящее. Документация стала критичной Первым подходом было запихнуть все инструкции в один большой AGENTS.md. Предсказуемо не сработало – контекст дефицитный ресурс, и когда важно всё, важно ничего. Рабочий подход оказался такой: короткий AGENTS.md (~100 строк) работает как оглавление с указателями на документацию в репозитории. Дизайн-доки, архитектура, планы, технический долг – всё версионировано и лежит рядом с кодом. Вообще интересно, насколько возросла важность документации – и даже больше: актуальной документации. Когда мы разрабатывали агента, по нашим замерам явно видели – качество работы агента падает, если документация устаревшая. В OpenAI пришли к тому же выводу и сделали отдельного агента, который регулярно сканирует документацию на устаревшие фрагменты и открывает PR на исправление. По сути – CI для документации. Архитектурные ограничения Жёсткая слоистая архитектура, строгие границы зависимостей, кастомные линтеры – всё то, что обычно откладывают. С агентами это стало необходимостью с первого дня. Ограничения – это то, что позволяет агентам двигаться быстро и не разваливать кодовую базу. Сборка мусора для техдолга Когда генерируется столько кода, агент воспроизводит паттерны, которые уже есть в репозитории – включая неудачные. Сначала команда тратила каждую пятницу на ручную чистку AI slop – дублирующиеся хелперы, невалидированные данные, расползающиеся паттерны. Такой подход не масштабировался. В итоге поставили фоновые задачи – агент регулярно сканирует репозиторий, ищет отклонения от заданных архитектурных правил и делает исправления. По сути – непрерывная сборка мусора для кодовой базы. #ai

Стратоплан CTO: 5 занятий спустя Прошло 5 занятий по специальности СТО в Стратоплане, делюсь промежуточными впечатлениями. (начало тут) Каждое занятие состоит из лекционной и практической частей. Лекции. Тут всё зависит от лектора. В теории обычно всё понятно: вот так проводи 1-on-1, вот так делай стратегию, вот так управляй ожиданиями. Но когда сталкиваешься с этим на практике – узнаешь много нюансов и подводных камней. Поэтому важно, когда у лектора много опыта в том, что он рассказывает – делится подводными камнями, что работает, а что нет. И это круто, когда берёшь мысль на заметку, записываешь – подумать поглубже. Пару раз бывало, что часть лекции сводилась к описанию: вот есть такой подход, вот так он устроен. Мне не всегда это нравится, но если не слышал о таком подходе – будет полезно узнать, куда покопать самостоятельно глубже. Практика – это тот аспект, который мне особенно нравится. После прослушивания теории даётся кейс, который необходимо решить. Сначала ты его обдумываешь индивидуально, а потом всех распределяют по группам и вы в группе обсуждаете решение. Я бы сказал, что групповое обсуждение кейса – это самое ценное. Когда ты с квалифицированными ребятами обсуждаешь кейс, и люди делятся решениями, которые тебе не пришли в голову – это прям круто. Только ради этого стоит приходить 🙂

Влияние AI-агентов на обучение в разработке Очередная интересная статья от Anthropic на горячую тему. Ребята попытались понять, как применение AI-агентов влияет на обучение разработчиков. Эксперимент такой: 52 джуниора решали задачу с использованием незнакомой библиотеки – половина с AI-агентом, половина без. После выполнения задачи участники проходили тест на понимание материала: отладка, чтение кода, написание кода и концептуальное понимание. По скорости группа с AI закончила всего на 2 минуты быстрее, эта разница статистически незначима – то есть выигрыша на этой задаче не было. А вот по тесту разница уже ощутимая: 50% у группы с AI против 67% у контрольной. Разница 17 процентных пунктов. Самый большой разрыв оказался именно в отладке – способности находить и диагностировать ошибки. И это логично: группа без AI сама натыкалась на баги и сама их разруливала, а с AI этот этап просто пропускался. Помимо циферок, ребята записывали сессии и смотрели паттерны поведения. И тут любопытное наблюдение: дело не в самом AI-агенте, а в том, как его используют. Те, кто показал слабые результаты, делегировали агенту почти всё: полная автоматизация с самого начала, постепенное сползание от вопросов к "сделай за меня", или отладка через агента вместо самостоятельного разбора. А у тех, кто показал хорошие результаты, паттерны другие: генерировали код, но потом сами его ревьюили и спрашивали "почему так", просили код сразу с объяснениями и изучали, или вообще задавали только концептуальные вопросы, а код и баги разбирали сами. Отсюда напрашивается гипотеза: AI усиливает продуктивность там, где знания уже есть, но тормозит формирование новых. Ты быстрее закрываешь задачу – но не особо усваиваешь, что было сделано. Считаю здорово, что такие исследования появляются, но ребята сами говорят, что это просто капля в море – ещё очень много белых пятен, которые необходимо исследовать. Но, друзья, от этого и особенно интересно, не так ли? #ai