Ого! 11 лет назад были Яндекс Деньги, спорные ThinkPad’ы, XSLT и XScript и тот же самый кабинет в Бенуа, в котором сижу сегодня. И за окном всё тот же изгиб Невы. И даже место то же, только стол повёрнут иначе, потому что места в кабинете стало больше, гораздо больше.

11 лет не непрерывных конечно, погулял по рынку. «Деньги» за эти годы отделились, переименовались в «Юмани» и уехали на 6-й этаж. А я вот вернулся на четвёртый в Облако.

О, первый раз могу показать чем занимался последние несколько месяцев в виде промо

https://datalens.yandex.cloud/?_lang=ru#neuroanalytic

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

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

Под прошлым постом были вопросы — а почему, собственно, у вас в команде некие фронтенд-инженеры занимаются тем, чем занимаются. Своё виденье я ещё попробую расписать, но тут вовремя приехала выжимка Фаулера от Максима

Expert Generalists

Статья в блоге Мартина Фаулера про T-shaped специалистов. Точнее, все текущие термины (T-shape, П-shape, и другие) плохо подходят, поэтому в статье вводится термин Expert-Generalist, который означает, что человек одновременно является и экспертом (в противовес generalist) и использует свою экспертизу во многих областях (в противовес эксперту в одной области).

В данном случае имеется в виду, что человек является экспертом в фундаментальных понятиях, которые позволяют ему быть успешным в областях, которые построены на этих понятиях. Классический пример из IT, это когда человек имеет опыт написания ПО на 3-4 языка программирования и ему после этого уже не так важно, на каком именно другом языке писать код, пока этот язык следует общим парадигмам (основан на том же фундаменте). Условно, человек, который писал на JS, PHP, JAVA, C++ с легкостью может войти в Go, Rust, Kotlin. Но, вероятно, столкнется с некоторыми проблемами при входе в Haskell. Но, скорее всего, сможет это сделать в короткие сроки.

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

В этом кроется ключевая разница между генералистами и экспертами-генералистами. Чистые генералисты знают все поверхностно. Эксперты-генералисты - знают фундаментальные принципы, знание которых позволяет им погружаться в смежные области

В чем сила таких специалистов:

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

Эксперты-генералисты должны иметь хорошие навыки коммуникации и совместной работы. Т.к. они не являются экспертами в областях, они должны уметь запрашивать помощь у коллег. Понимание основных принципов помогает им быстро погружаться в контексты специалистов

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

Ключевые качества экспертов-генералистов:
- Любознательность
- Умение сотрудничать
- Фокус на клиенте (бизнесовая направленность)
- Ставка на фундаментальные знания
- Широта знаний
- Способность понимать позицию смежных доменов (например, понимать проблемы SRE или DevOps)

Многие эксперты-генералисты вырастают в технических лидеров

Встает закономерны вопрос: "где брать таких специалистов?". Текущий найм устроен так, что мы скорее наймем ультра-эксперта в технологии, чем наймем человека, который любознателен и умеет погружаться в новые домены. В статье предлагается подход из двух решений:
- Перестать смотреть только на узкие хард-скилы. Вместо этого следует проверять человека на обучаемость, любознательность, создание условий для совместной работы
- Проводить внутренние тренинги и воркшопы, цель которых - погрузить специалистов в смежные области. В Thoughtworks есть 3 воркшопа, в которых специалисты делают решения из смежных областей. В рамках воркшопа они реализуют простые прототипы kafka, kubernetes, delta lake (штука для работы с данными). Создав прототип, люди начинают понимать базовые принципы, на которых основаны эти системы и начинают видеть рабочие ситуации с другой стороны

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

Для каждой ключевой компетенции в команде нужен 1-2 специалиста.

---

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



https://martinfowler.com/articles/expert-generalist.html

#managment #tshape #martinFowler

Обещал же расписать.

Прошу не проецировать на весь Яндекс, так как все бизнес-юниты работают совершенно с разными подходами. Более того, даже внутри одного БЮ может быть разный подход в разных командах.

Так вот, в нашей команде все занимаются почти всем. Да, фронтендера не попросят писать под на Питоне, бэкендера не отправят на Реакт. Но девопс, БД, сеть — такие задачи могут прилететь любому. Если этот любой готов к этому (и это важно). Мы знаем, кто к чему тяготеет, и насильно не отправим человека решать задачи, не свойственные его скиллам.

Т.е. пресловутый t-shape присутствует, и у каждого своя палочка своей конфигурации. Тут задача — удерживать команду в балансе, чтобы всё не упиралось в одного узкого специалиста (а так оно и будет, если вы уйдёте в гипер-специализацию). Два-три человека должны быть в каждой области.

То есть в команде не случайные люди — она собрана исходя из этой специфики изначально. И это работает.

Что нам это даёт? Возможность двигаться быстро. Возможность не ждать, пока узкий специалист освободится/выйдет из отпуска. Возможность привлекать сильных специалистов, которые ищут место, где смогут покачать скиллы в другой области. И даже возможность, пока заняты бэкендеры, собрать «настоящий» бэк на ноде силами фронтов.

Это не плохо и не хорошо, это просто вот такой вот подход, который в наших условиях работает.

Для себя я вижу здесь только возможности роста как специалиста, и во многом это и была причина, по которой я выбрал команду. Мне не так интересно получить от бэкендера эндпоинт для AI — интересно разобраться самому.

Если первые впечатления от того же Cursor были отвратительными, то сейчас он уже как-то подуспокоился в своём стремлении делать YOLO и может предоставить сравнимый с Roo опыт постепенного продвижения по задаче. При этом, конечно, в более приятном интерфейсе (те же диффы изменений выглядят гораздо наглядней, чем в Roo).

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

В целом и там, и там можно работать с одинаковой эффективностью. А вот вопрос стоимости сложный, понятно, что в чистом виде Cursor будет дешевле, но кто ж знает, к каким моделям у вас есть доступ? У меня вот Roo смотрит в «бесплатный» развёрнутый внутри DeepSeek и платный Claude. Щёлкаю под задачу и наличие денег на счету.

Сама по себе работа в паре с AI (то, что пытались зафорсить как DeepCoding в противовес VibeCoding, но, кажется, не прижилось) неплохо так прокачивает скиллы код-ревью. Я (как типичный IC) редко работаю над кодом в команде, и вот тут второй пилот вернул забытые ощущения и позволяет держать ритм.

Продолжаю радоваться, что дожил до такого.

https://remarkable.com/products/remarkable-paper/pro-move

Вот это классный мув, точно получше, чем заезд arc в attlassian.

Мне нравится размышлять в моём Kindle Scribe и читать на нём шикарно, но какой же он тяжёлый. А новый remarkable выглядит ультимативным повседневным гаджетом, хочу!

Пока все стряхивают пыль с читалок, чтобы залить свежего Пелевина, мы вместо этого не спим и готовимся к Neuro Scale. Фиксим ещё один последний баг и выкатываем последнюю_финальную_теперь_точно_финальную_версию (2).

Так уж случилось, что ритм в Облаке годичный, от Скейла до Скейла. Всё, что непосильным трудом наделано — всё покажем.

В том числе, конечно, и всё, что мы, фронтендеры, наделали с нейроаналитикой (я про это ещё потом доклад прочитаю, почему агенты для нейронок должны строить именно фронты).

26 сентября буду выступать в Пензе на Secon

Порассуждаю как сейчас делать AI-агентов и почему это нормальная и решаемая задача для фронтендеров. Приходите поспорить.

Тут кажется требует уточнений, что говорить мы будем про UI, который потребляет API LLM.

Насколько всегда с отвращением пользовался Курсором, настолько же (но в положительную сторону) с удовольствием запускаю задачи в Claude Code. Сложно объяснить это ощущение, но как-то там более лампово и уютно что ли.
И результат сильно лучше, особенно после нескольких итераций с ревью в Copilot.

А главное — нет причин менять IDE/редактор. С zed так вообще нативная интеграция из коробки, но всегда можно открыть терминал и сделать там всё.

Удивительно, что пока экстеншены затаскивали векторный поиск и наворачиваи UI, оказалось, что агенту достаточно grep для того, чтобы собрать хороший контекст и sed чтобы поправить код.

29 октября на митапе A?.Frontend Community порассуждаю про эволюцию OpenAI API

https://digital.alfabank.ru/events/frontend-b-day-meetup

Тайминг плотный (люблю такое) попробую впихнуть самую суть.

Трансляция будет

Не удалось в короткий тайминг впихнуть всё (плюс пришлось немного спешить).
И вот остался на руках у меня почти нераскрытый Responses API, а раскрыть/показать его идеи и противоречия хочется. А там прямо интересно! Многое уже можно попробовать прямо у нас в AI Studio. Хотя и не всё (но обещают довезти тот же Conversations API).
И сам бы послушал какого-нибудь фаната Langchain, чтобы он попробовал убедить меня забыть про OpenAI SDK.

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

Кстати, про Холи. В прошлом году был экспертом на докладе Димы Андриянова про полезные автотесты. В этом году он продолжит копать тему тестирования, а также заранее подготовился и завёл канал (а то в прошлом году подходили с вопросами, где следить за работой и куда писать фидбек).

Диму знаю давно, делали вместе ШРИ, был он и в гостях в Девшахе у меня. Дима крутой!

Попробовал переписать с OpenAI API SDK на LangChain (говорят это база) и... что-то не понял. Абстракции они же должны вроде как сложность скрывать, но сложности в OpenAI Chat Completions API никакой (зря что ли ребята в Open AI потратили всего одни выходные чтобы его создать). А вот приносимой боли в дебаге немало — добраться до того, что там на самом деле происходит будет уже непросто.

Самое смешное, что claude code на вопрос «давай накинем дебага и узнаем, как там залетают в апи тулы» предложил мне просто переписать на OpenAI API SDK, потому что тот объём шума, который вываливает

env LANGCHAIN_VERBOSE = "true"; 

он переварить не способен.

Да, есть LangSmith, но это уже какой-то оверкилл подрубать внешний платный SaaS-сервис для дебага обёртки над простеньким api.

В то же время вызов OpenAI API SDK элементарно превращается в обычный curl запрос, который ты можешь приложить к тикету в саппорт, если сам не разобрался.

Если на JS, то разве что через переопределения метода fetch у класса работы с ЛЛМ можно законсольложить сформированный запрос. Я на MoscowJS как раз на это жаловался, начиная с 52:32

А если на Python, то там я вообще не нашёл, можно ли это как-то сделать

Антон в докладе хорошо показал/рассказал.

Эксперименты с апишками заставляют отметить, какое сейчас прекрасное время, чтобы пробовать новое.

Открываю Perplexity (я его уже дефолтным поисковиком поставил, хах), открываю Zed. В одном окне копаю информацию, во втором агент собирает прототипы (мы как-то пропустили смерть классического скаффолдинга).

Можно собрать базовый вариант. Можно усложнить. Можно накинуть тестов и запрофилировать. Можно пообсуждать результаты с нейронкой.

Можно двинуться дальше и спроектировать полноценное приложение, чтобы проверить теорию.

Что мы теряем? Да разве что набитую руку на быстрое создание новых проектов. Есть такое (и ведь я сам не пользуюсь алиасами, чтобы пальцы не забывали как отбивать команды). Но, честно, у меня тут ребенок на одной руке висит, второй я варю суп. А желание проверить идею оно же буравит мозг и спать не даёт.

Я думаю, что мы так или иначе будет всё более верхнеуровнево смотреть на код, освобождая место в памяти от сигнатуры функций, в сторону ревью алгоритмов и концепций и теряя скилл вайтбординга. Да так ли это важно? Вот мне в 40+ уже нет, мне важнее быстро концепции проверять и выбирать лучшие. Зато насмотренность в коде как растёт*!

*Я всё ещё не приемлю вайб-кодинг и вычитываю каждую сгенерированную строчку.

ACP в zed оказался не так хорош, как я думал

Ну ладно, пока буду делать claude -r

https://github.com/zed-industries/zed/issues/37481

Мы открыли CFP на «Я люблю фронтенд 2026» — заполняйте форму, если вам есть, что сказать.

Конференция случится ровно 14 февраля, не планируйте ничего (ну кроме более важного).