¡Ya disponible! Investigación de Telegram 2025 — los principales insights del año 
DevFM
Ir al canal en Telegram
О разработке: AI, технологии, инструменты, system design, процессы, команды Для связи @sa_bul
Mostrar más2 837
Suscriptores
+324 horas
+67 días
+5830 días
Carga de datos en curso...
Canales Similares
Nube de Etiquetas
Menciones Entrantes y Salientes
---
---
---
---
---
---
Atraer Suscriptores
junio '26
junio '26
+5
en 0 canales
mayo '26
+70
en 1 canales
Get PRO
abril '26
+63
en 2 canales
Get PRO
marzo '26
+334
en 4 canales
Get PRO
febrero '26
+114
en 3 canales
Get PRO
enero '26
+41
en 0 canales
Get PRO
diciembre '25
+24
en 1 canales
Get PRO
noviembre '25
+27
en 2 canales
Get PRO
octubre '25
+18
en 1 canales
Get PRO
septiembre '25
+38
en 0 canales
Get PRO
agosto '25
+17
en 0 canales
Get PRO
julio '25
+43
en 3 canales
Get PRO
junio '25
+31
en 1 canales
Get PRO
mayo '25
+35
en 0 canales
Get PRO
abril '25
+37
en 1 canales
Get PRO
marzo '25
+295
en 11 canales
Get PRO
febrero '250
en 6 canales
Get PRO
enero '250
en 2 canales
Get PRO
diciembre '24
+88
en 2 canales
Get PRO
noviembre '24
+15
en 1 canales
Get PRO
octubre '24
+17
en 1 canales
Get PRO
septiembre '24
+33
en 1 canales
Get PRO
agosto '24
+58
en 3 canales
Get PRO
julio '240
en 1 canales
Get PRO
junio '240
en 0 canales
Get PRO
mayo '240
en 0 canales
Get PRO
abril '240
en 0 canales
Get PRO
marzo '240
en 0 canales
Get PRO
febrero '24
+16
en 0 canales
Get PRO
enero '24
+20
en 0 canales
Get PRO
diciembre '23
+27
en 0 canales
Get PRO
noviembre '23
+30
en 0 canales
Get PRO
octubre '23
+52
en 0 canales
Get PRO
septiembre '23
+54
en 0 canales
Get PRO
agosto '23
+42
en 0 canales
Get PRO
julio '23
+135
en 0 canales
Get PRO
junio '23
+170
en 0 canales
Get PRO
mayo '23
+97
en 0 canales
Get PRO
abril '23
+91
en 0 canales
Get PRO
marzo '23
+101
en 0 canales
Get PRO
febrero '23
+126
en 0 canales
Get PRO
enero '23
+243
en 0 canales
Get PRO
diciembre '22
+155
en 0 canales
Get PRO
noviembre '22
+144
en 0 canales
Get PRO
octubre '22
+203
en 0 canales
Get PRO
septiembre '22
+845
en 0 canales
| Fecha | Crecimiento de Suscriptores | Menciones | Canales | |
| 03 junio | +3 | |||
| 02 junio | +2 | |||
| 01 junio | 0 |
Publicaciones del Canal
Периодически я рассказываю о классных мероприятиях – и вот одно из них – 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 |
