Вернулся пока на Garmin Forerunner 255. Устал мириться с существенными минусами Suunto, при всей их красоте:

- Нет календаря (люблю Гарминовскую утреннюю сводку с календарём)
- Глючный датчик пульса, всегда нужно надевать пульсометр
- Гармин позволяет запустить секундомер не останавливая тренировку. Suunto так не может. Существенный просчёт.
- Плохо пишет треки на открытой воде. Гармину хватает взмаха руки, чтобы вцепиться в спутник. Suunto показал себя сильно хуже.
- MIP экран всё же приятнее для меня
- Пять кнопок лучше, чем три и сенсор


Тотальный отказ от MIP продолжает меня огорчать.

Все побежали и мы побежали

Ну как, выбор между Roo и Cline сделали? На Claude, небось? Мемори банки собрали? В своей продукт добавили агента? А моделька в продукте у вас какая — Qwen или DeepSeek? Как так нет локальной модели, а куда вы будете грузить пользовательские данные? А как тюнили под задачи, RAG? А MCP-сервер уже запилили? В опенсорс его закинули?

Что ж так быстро-то всё меняется, выдохнуть некогда. Архитектуркой бы позаниматься, долги позакрывать. Но некогда. Рынок требует AI. Надо пережить эту волну, но кто бы знал, какая будет следующая.

А вот на фоне этих новостей, про опенсорсивание экстеншена Copilot. Меня тут не беспокоит потенциальная смерть Cursor (а как мы знаем давно строить бизнес поверх чужого продукта — штука опасная). Я так-то вообще курсором пока не проникся, мне хватает Roo + наш Code Assistant, который наконец-то заменил мне Codeium (TIL он теперь windsurf)

Мне стало интересно, а что там в мире JetBrains происходит? Вижу, что рядом ребята сидят и держат открытыми Idea и Cursor/Roo. Одно для кодинга, второе для вайбинга. Гуглёж подсказал, что пилится свой агент Junie, но что там под капотом? Какая моделька? И какая бы она прекрасная не была — хочется же менять и пробовать разное. И для NDA локальные модельки нужны.

В общем если кто в курсе — покидайте статьи/доклады, что там у JB, какой курс.

Сидел с утра собирал memory bank в Roo. Потрясающая штука, даже если им не пользоваться (а почему?), но просто почитать — вот он твой проект как на ладони. Но, конечно, нужно покопаться в нём вместе с нейронкой, направить её в правильную сторону.

Это, кстати, причина, почему roo, а не cline. В cline всё как-то победнее (ну это просто связано с меньшим количеством режимов работы агента).

Если кратко, то memory bank это просто папочка со структурированным описанием вашего проекта, на которую вы натравливаете агента через промт (не вручную конечно же, агенты умеют подмешивать промты из конфига).

UPD: Ну и это конечно уже вчерашний день, потому что теперь есть Context Portal MCP 😃 С RAG конечно же.

Из рабочего чата

RAG на коленке

Решил тут на днях собрать пруф оф концепт чат бота по документации внутреннего проекта. Раз проект внутренний, то никакая LLM про его документацию не знает и, тем более, сходить по сети за ней не может. А значит нужен RAG. Вот тут можете можете почитать, что это такое. TLDR — смотрим, что пользователь спросил, находим нужные разделы в документации и подмешиваем в промт. Дальше моделька сама справится.

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

Результат офигенный конечно. Но вот зараза, у меня нет под рукой нейронок для эмбеддинга. Во внешний мир ходить не хочу, проект внутренний. Что же делать, как показать пруф оф концепт? Собираем с Клодом веб-скрейпер на плейрайте, дербаним доку в JSON, кормим этот JSON приложению на ноде, обслуживающему чат. Теперь на каждый запрос пользователя выбираем слова подлинней, лезем в JSON и находим совпадения (ахах, да, можно было бы и морфологию прикрутить, но некогда, работа не ждёт). Собираем промпт по совпадениям и закидываем в LLM вместе с запросом пользователя. И оно работает. Да, неоптимально, чертовски неоптимально. Но для PoC за глаза хватило.

Apple released container CLI

WWDC is ongoing and one of the news, which unfairly is not spotlighted enough is the containerization framework, which the Apple team published and even open-sourced (!). It's written on Swift and provides the OCI-complaint API. Unfortunately, it's still a virtual machine, but the Apple team refers to it as a micro virtual machine, which can be launched sub secondly with the help of optimized Linux kernel configuration. You can even try it on MacOS 15, but with the crucial limitation: all containers will be run on their own networks. But starting from macOS 26 you can run containers connected.

Good then nothing, but not as good as run containers natively on Linux.

Вообще конечно все эти AI-агенты просто возвращают мне радость программирования. Машина наконец-то делает то, что должна — скучную рутину. А мы парим над этим и раздаём указания. Проверяем теорию за теорией, собираем пруф оф концепты за нефиг делать и тут же без жалости (икеа-эффекта нет) выкидываем. Делаем за день недельную работу.

Я прямо очень доволен. Старички вроде меня снова в строю и могут поделать архитектурку.

Vite is generally known for its unbundled native ESM dev server, which is responsible for the fast startup time and almost instant feedback. Nevertheless, we’ve seen limitations of this approach for projects at unconventional scale, especially in Enterprise setups. To address these, we are working on a full-bundle mode for the dev server.

Наконец-то! Говорил же об этом с первого дня :)

Ну понятно, ребята ждали Rolldown

Ого! 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 чтобы поправить код.