اکنون در دسترس! پژوهش تلگرام ۲۰۲۵ — مهمترین بینشهای سال 
DevFM
رفتن به کانال در Telegram
О разработке: AI, технологии, инструменты, system design, процессы, команды Для связи @sa_bul
نمایش بیشتر2 837
مشترکین
+324 ساعت
+67 روز
+5830 روز
در حال بارگیری داده...
کانالهای مشابه
ابر برچسبها
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
ژوئن '26
ژوئن '26
+5
در 0 کانالها
مه '26
+70
در 1 کانالها
Get PRO
آوریل '26
+63
در 2 کانالها
Get PRO
مارس '26
+334
در 4 کانالها
Get PRO
فوریه '26
+114
در 3 کانالها
Get PRO
ژانویه '26
+41
در 0 کانالها
Get PRO
دسامبر '25
+24
در 1 کانالها
Get PRO
نوامبر '25
+27
در 2 کانالها
Get PRO
اکتبر '25
+18
در 1 کانالها
Get PRO
سپتامبر '25
+38
در 0 کانالها
Get PRO
اوت '25
+17
در 0 کانالها
Get PRO
ژوئیه '25
+43
در 3 کانالها
Get PRO
ژوئن '25
+31
در 1 کانالها
Get PRO
مه '25
+35
در 0 کانالها
Get PRO
آوریل '25
+37
در 1 کانالها
Get PRO
مارس '25
+295
در 11 کانالها
Get PRO
فوریه '250
در 6 کانالها
Get PRO
ژانویه '250
در 2 کانالها
Get PRO
دسامبر '24
+88
در 2 کانالها
Get PRO
نوامبر '24
+15
در 1 کانالها
Get PRO
اکتبر '24
+17
در 1 کانالها
Get PRO
سپتامبر '24
+33
در 1 کانالها
Get PRO
اوت '24
+58
در 3 کانالها
Get PRO
ژوئیه '240
در 1 کانالها
Get PRO
ژوئن '240
در 0 کانالها
Get PRO
مه '240
در 0 کانالها
Get PRO
آوریل '240
در 0 کانالها
Get PRO
مارس '240
در 0 کانالها
Get PRO
فوریه '24
+16
در 0 کانالها
Get PRO
ژانویه '24
+20
در 0 کانالها
Get PRO
دسامبر '23
+27
در 0 کانالها
Get PRO
نوامبر '23
+30
در 0 کانالها
Get PRO
اکتبر '23
+52
در 0 کانالها
Get PRO
سپتامبر '23
+54
در 0 کانالها
Get PRO
اوت '23
+42
در 0 کانالها
Get PRO
ژوئیه '23
+135
در 0 کانالها
Get PRO
ژوئن '23
+170
در 0 کانالها
Get PRO
مه '23
+97
در 0 کانالها
Get PRO
آوریل '23
+91
در 0 کانالها
Get PRO
مارس '23
+101
در 0 کانالها
Get PRO
فوریه '23
+126
در 0 کانالها
Get PRO
ژانویه '23
+243
در 0 کانالها
Get PRO
دسامبر '22
+155
در 0 کانالها
Get PRO
نوامبر '22
+144
در 0 کانالها
Get PRO
اکتبر '22
+203
در 0 کانالها
Get PRO
سپتامبر '22
+845
در 0 کانالها
| تاریخ | رشد مشترکین | اشارات | کانالها | |
| 03 ژوئن | +3 | |||
| 02 ژوئن | +2 | |||
| 01 ژوئن | 0 |
پستهای کانال
Периодически я рассказываю о классных мероприятиях – и вот одно из них – infra.conf'26 – конференция про создание и эксплуатацию высоконагруженных систем и инфраструктуры.
Мне конечно же интересны темы, связанные с ИИ 🙂
Активное развитие ИИ внесло существенные коррективы: послушаем, с какими новыми вызовами сталкиваются ребята и как с этим справляются.
Мероприятие пройдёт 4 июня. Приходите – будет классно 🙂
| 2 | Как подготовить кодовую базу к работе с агентом
Очередная интересная статья от Антропика. На этот раз – о том, как подготовить свою кодовую базу к работе с агентом.
И одно дело, когда у тебя небольшой проектик, а другое – когда у тебя миллионы-миллионы строк кода, причём некоторые из них последний раз трогались в 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 | 1 168 |
| 3 | Скилл поверх MCP
Я уже писал про Skills. А недавно попалось отличное видео от ребят из Supabase, где раскрывают интересную мне тему – skills over mcp.
Докладчик говорит так: вот есть у вас MCP – по сути просто набор тулов, чтобы агент ходил в ваш сервис. Но это просто тулы. Агент по-прежнему не знает хороших практик, принятых для сервиса, не знает его нюансов. И вот тут поверх MCP появляется скилл – который эти практики и нюансы агенту и приносит. По замерам ребят, в такой связке агент заметно лучше справляется с задачами.
Дальше – несколько мыслей из видео, которые во многом совпадают с моим опытом.
Описывайте явные сценарии. В видео это прямо подчёркивается: вы хорошо знаете свой продукт, знаете популярные сценарии и то, как их правильно выполнять – вот это и опишите.
Относитесь к скиллу как к документации для себя. Если при описании сценария вы понимаете, что что-то уже есть в доке – дайте агенту явную ссылку: вот здесь про это написано. Не нужно впихивать всё в одно место и дублировать. Тут полностью согласен: поддерживать актуальную доку и так сложно, а в двух местах – нереально. Кстати, ребята предложили подход, который я нигде раньше не встречал – давать агенту доступ к доке по ssh.
Что важно – выносите в SKILL.md. Ссылки ссылками, а следующий тезис такой: если что-то может быть пропущено агентом – оно может быть пропущено. Progressive disclosure у скиллов – это одновременно и фишка, и проблема. По опыту ребят, агент не пойдёт за раз по всем ссылкам из references. Поэтому если для вас что-то категорически важно – не прячьте это вглубь, выносите прямо в SKILL.md. Они так сделали с security-проверками, которые агент обязан выполнить.
И ещё одна мысль, которую я часто повторяю: работа над скиллом – это итеративный процесс. Нельзя один раз сказать агенту "сделай скилл" и считать, что всё готово. В видео автор честно говорит, что последние пару месяцев только и занимался, что докручивал скилл.
Забавно, что в этой всей ai-движухе порой получаешь противоречивые советы. И когда спрашивают: а как лучше? Совет-то я дать могу, но главный совет – экспериментируйте. Как оно сработает в вашем случае – заранее сложно сказать.
#ai | 1 045 |
| 4 | Создаем свои скиллы (часть 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 | 1 114 |
| 5 | Где брать скиллы (часть 3)
С тем, как устроены скиллы, разобрались, даже в движении. А где их брать?
Мне нравится простой каталог skills.sh. Удобно, что можно отсортировать по популярности или посмотреть, что сейчас набирает обороты – можно позалипать, вдохновиться.
Из тех, чем сам пользуюсь:
frontend-design – уже про него рассказывал. Лучший способ получить адекватный дизайн, когда дизайнера рядом нет.
brainstorming – запускаешь перед началом работы над задачей, и агент начинает задавать уточняющие вопросы. После 5–6 вопросов требования становятся заметно полнее. На практике брейншторм почти всегда поднимает что-то, о чём не подумал или отложил на потом.
pptx – скилл от антропика для работы с презентациями. Два режима: с нуля (чтобы было не вырви глаз) или создать по существующему шаблону – очень удобно. У ребят есть аналогичные скиллы и для pdf, docx, xlsx – тоже стоит присмотреться.
playwright-skill – никогда написание тестов не было таким простым и бесплатным. Если необходимость unit-тестов для агента ещё под вопросом, то полноценные e2e – мастхев, и плейрайт-скилл сильно облегчает задачу.
Делитесь, какими скиллами пользуетесь – интересно собрать подборку.
#devfm #ai | 1 533 |
| 6 | Что там с 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 | 1 980 |
| 7 | Все ли так классно со скиллами - часть 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 717 |
| 8 | Скиллы в агентах – часть 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 | 1 675 |
| 9 | Время летит – прошло ещё несколько занятий на курсе CTO от Стратоплана. За это время успели посмотреть разные темы: от информационной безопасности до найма и развития ключевых сотрудников.
Но больше всего меня впечатлил блок про финансовый менеджмент и построение финансовых моделей. Обычно, будучи тимлидом, руководителем отдела, ты редко сталкиваешься с деньгами напрямую – бюджеты где-то далеко, P&L кто-то другой считает, а ты управляешь людьми и проектами. Тикеты двигаются, релизы случаются – супер.
У меня эта тема давненько лежала где-то в личном бэклоге – надо бы разобраться, но понятное дело – всегда находится что-то более приоритетное, плюс когда не погружён в тему – непонятно с чего начинать. В общем, сам вряд ли когда возьмёшься.
А тут звёзды сошлись – рассказали на занятиях. Разобрали базовую терминологию – что такое P&L, как устроен управленческий и бухгалтерский учёт, чем они отличаются, какие ещё учёты бывают. Изучили баланс, отчёт о прибылях и убытках. Потом перешли к финансовым моделям, даже попробовали составить фин модель на практике – и тут мозги реально поплавились. С первого раза очень сложно, мало что понятно, но очень интересно. | 1 627 |
| 10 | Из маленьких лайфхаков – я перестал пытаться самостоятельно ориентироваться в незнакомых интерфейсах. Открываешь что-то новое, и вместо того чтобы шариться по менюшкам – просто делаешь скриншот и отправляешь агенту. Тот шуршит пару секунд и подсказывает, куда именно тыкать.
На днях настраивал Cloudflare. Кто пользовался – знает, что их панель делали хищники для чужих. Раньше бы полчаса ковырялся по вкладкам. А тут – скрин, в агента, и через несколько секунд пошаговая инструкция, где найти нужное.
Аналогично с Фигмой – я в ней нечастый гость. Нужно было скопировать себе чужой проект, и я понятия не имел, как это делается. Скриншот → агент → готово.
Тот же паттерн кстати с ридмишками проектов. Открываю README, начинаю вчитываться, пытаюсь понять что за проект, как запустить... а потом бью себя по рукам – зачем? Скидываю агенту, и через минуту у меня полная картина: что за проект, как развернуть, какие есть нюансы. И можно задать уточняющие вопросы, если что-то непонятно.
По сути, появился новый навык – не разбираться самому, а делегировать первичное понимание. И это прям очень круто!
#ai #devfm | 1 591 |
| 11 | Голосовой ввод – настоящий геймченджер
Сам удивляюсь, почему так долго откладывал попробовать управление агентами через голосовой ввод – на днях нужно было много всего сделать, и я подумал, а почему бы и нет, должно получиться быстрее.
Неоднократно слышал про Handy – с него и начал. В пару кликов всё настроил: выбрал модель, которая будет работать локально, назначил хоткей на включение режима слушания, и в общем-то всё.
Ну что могу сказать – это чудо чудесное, теперь просто не могу остановиться. Последние пару дней все коммуникации с агентами идут через Handy. Из дополнительных приятностей: раньше иногда было лень писать и думал, ааай агент сам разберётся, а потом агент не разбирался и приходилось расхлёбывать – теперь нет никаких проблем, что-то хочешь уточнить – просто продиктуй.
Есть ещё классная фича – постпроцессинг: после транскрибации текст отправляется в LLM и обрабатывается согласно твоему промпту – например, более лаконично переформулировать то, что только что надиктовал, убрать слова-паразиты. И теперь я пошёл дальше – надиктовываю вообще всё. Нужно оставить коммент в таске – надиктовал, нужно написать сообщение в телегу – надиктовал.
Теперь в офисе постоянно приходится сидеть в переговорках, чтобы не мешать рядом сидящим коллегам.
Люто рекомендую 🙂
#постанадиктован | 1 898 |
| 12 | Я продолжаю экспериментировать с разными штуками, которые позволяют запускать автономную работу агента и выполнять поставленные задачи "под ключ". А то начитаешься всякого на реддите, что "если у вас агент ничем не занят, то вы делаете что-то не так" 🙂
Сейчас пробую Ralphex. Очень любопытная штуковина – под капотом используется Claude Code, но поверх накручена полноценная система управления процессом работы агента.
Начинается всё по классике – нужно любым удобным способом составить план выполнения задачи. Можно использовать встроенную команду plan. Качественный план для агента – это важно, а здесь особенно важно, потому что когда процесс запущен – вклиниться и что-то подправить уже не получится.
Далее просто запускаю ralphex и машина начинает шуршать – выполнять план по шагам, отмечать прогресс, писать тесты. Последний этап – код-ревью. Если у вас в наличии Codex – то он призывается для ревью. Вообще забавно наблюдать, когда один агент чехвостит другого.
На самом деле – там много интересного происходит под капотом – рекомендую поэкспериментировать.
#ai #agents | 1 949 |
| 13 | Вот и прошёл AI Dev Day. Классное получилось мероприятие. Делюсь выжимкой моего доклада.
Первая часть была посвящена тому, как мы разрабатываем агента в среде разработки. Когда мы начинали, было много скепсиса к агентам, поэтому главной ставкой были фичи, связанные с бесшовным входом в разработку с агентом. Но настоящим вызовом стал адопшен – нужно было сделать так, чтобы агентом начали реально пользоваться. Писали доку, гайдлайны, проводили воркшопы – в общем было очень потно, но в то же время приятно было видеть, как в результате растёт аудиторная метрика.
Ещё один важный момент, влияющий на адопшен, который подтверждается как нашими внутренними исследованиями, так и исследованиями DORA – важно, чтобы были прозрачные политики безопасности, чтобы люди понимали, что можно отправлять в агентов, а что нет.
Вообще агентов сейчас разрабатывают кажется все кому не лень, и при этом по ощущениям не так часто говорят о качестве. Об этом была вторая часть доклада – как подходить к качеству через офлайн и онлайн-метрики на примере еще одного агента для написания запросов к данным.
Для офлайн-метрик мы используем валидационный датасет – прогоняем на нём агента, чтобы не выкатить изменения, которые ухудшают пользовательский опыт.
Но одних офлайн-метрик недостаточно, потому что реальных сценариев сильно больше, чем мы можем собрать в датасете. И говоря уже об онлайн-метриках, важно их строить от сценариев использования. Первое на что смотрим – CJM, так появляются метрики, основанные на пользовательских сценариев. А чтобы сформировать более точечные метрики, мы регулярно разбираем весь фидбек по работе нашего агента – это дорого, но позволяет понимать, что реально происходит в продукте. По результатам таких разборов тоже появляются метрики – например, мы заметили фейковый тул-колинг, пошли разбираться из-за чего такое происходит, а заодно появилась метрика, насколько эта проблема актуальна для наших пользователей.
И ещё заканчивая о метриках – важно не забывать их валидировать, действительно ли метрика измеряет то, что нужно. Иногда об этом забывают, а потом удивляются :)
А кто любит движуху вокруг LLM – 21 марта будет ещё один любопытный митап в офлайн и онлайн форматах.
#devfm #ai | 1 807 |
| 14 | Куда податься начинающим разработчикам
Часто дискутирую на тему, как AI влияет на начинающих разработчиков и как правильно учиться в новых реалиях.
Прочитал приятную статью от создателя htmx – стоит ли сейчас идти в разработчики? Автор говорит: да, и делится своими мыслями.
Первое, о чем говорит автор – нужно самостоятельно писать код. Полностью разделяю эту мысль. Если не писать код, то и читать его не будешь уметь. А во времена AI умение читать код становится ещё более важным навыком. Более того, когда не умеешь писать код – у тебя нет понимания, как делать правильно. В итоге просто не сможешь контролировать то, что разрабатываешь.
При этом AI может быть очень полезен для начинающих. Раньше можно было надолго закопаться в проблеме, даже не зная с какой стороны зайти. AI как раз может помочь – не генерировать за тебя, а подсказать направление. Автор приводит пример AGENTS.md – инструкцию для агента, после которой тот помогает разбираться, а не просто генерирует готовый код.
А вот какие навыки будут важны.
Коммуникативные навыки. С агентом, с людьми, письменная и устная.
Понимание бизнес-домена. Тут понравилась забавная мысль. Со стороны бизнеса сейчас порой слышим: всё, нам не нужны разработчики. Автор немного хихикает: это нам, разработчикам, теперь не нужны люди от бизнеса :)
А если серьезно, то я думаю спрос на разработчиков будет только расти. Мы уже не первый раз проходим подобное: 4GL-языки, визуальное программирование, nocode-платформы. Каждый раз слышали, что теперь-то разработчики не нужны, и каждый раз оказывалось, что нужны и даже больше, чем раньше.
Архитектурные навыки. Но навыки не тех архитекторов, которые не пишут код и считают себя архитекторами, а тот навык проектирования, который со временем появляется у разработчика.
А завершается статья вопросом, как джунам находить работу. Автор считает, что пробиваться через сайты подбора – скорее лотерея. И советует старое доброе: семья, друзья, друзья друзей. Пока читал эту часть статьи подумалось, что еще хорошо могут работать стажировки. Когда компании целенаправленно ищут начинающих инженеров и дают возможность развиваться на настоящих боевых задачах. У нас, например, в Яндексе сейчас идёт набор на стажировки по большому количеству направлений.
В общем, выдыхаем – разработчики всё так же будут нужны.
#ai | 2 183 |
