AI-помощники при работе с кодом. Взгляд в будущее - Евгений Колесников - Platform Engineering Night (Рубрика #AI)

Крутое выступление Евгения из команды Yandex Infrastructure, в котором он делится глубокими мыслями про развитие AI copilot инструментами. Женя выступал с этим докладом на Platform Engineering Night в Т-Банке. Я уже рассказывал про выступления моих коллег оттуда: "AI и Platform Engineering" от Игоря Маслова и "Разработка собственного AI-ассистента для кода: спринт или марафон?" Дениса Артюшина. Ребята рассказывали про наши подходы к интеграции AI в SDLC) и интересно сравнить мысли из тех докладов с идеями Жени, что я постарался изложить ниже

1. Реальность разработки
По стате разработчики пишут код всего 40 минут - 120 минут в день, при этом комитят в среднем только 40 строк кода в день. Основная проблема не в скорости печати, а в сложности мыслительных процессов, что идут на трех уровнях
- Ментальная модель - что мы хотим сделать
- Семантическая модель - как мы это будем делать
- Синтаксическая модель - непосредственно сам код
ИИ сейчас помогает в основном на последнем этапе, что объясняет ограниченность эффекта.
2. Режимы работы разработчиков
Существуют два основных режима:
- Flow - сотояние потока, когда код "летит из-под пальцев". Интересно, что в DevEx фреймворке Flow - это одна из составлящих, кстати, я делал обзор whitepaper о нем
- Exploration - поиск информации в документации, интернете, общение с ИИ
Понимание этих режимов критично для эффективного использования ИИ-инструментов.
3. Чего хотят разработчики от ИИ
По мнению Евгения ожидания инженеров такие
- Переложить на AI рутинные операции, например, написание юнит-тестов
- Общаться на естественном языке с последующим уточнением через промпты
- Получить детерминированные результаты от недетерминированного genAI
Интересно, что у Google был whitepaper буквально с таким названием "What Do Developers Want From AI?" - я его разбирал раньше, а потом еще записал эпизод подкаста "Research Insights" вместе с моим коллегой, Колей Бушковым, где мы разбирали этот whitepaper
4. Бизнес-приоритеты
Бизнес хочет сокращения time to market, снижения издержек, а также предсказуемости. Но обычно все упирают на сокращение издержек, когда говорят, что "90% кода будет писаться ИИ". Но часто это не означает увольнение 90% программистов, а увеличение продуктивности существующих команд. Евгений привел пример Дарио Амодея с его тезисами из цитаты выше - а я разбирал это выступление раньше
5. Проблема измерения эффективности
Критически относитесь к цифрам вроде "повышение продуктивности на 55%". Продуктивность - неопределенный термин, зависящий от множества факторов. Пока нет единого способа точно измерить пользу от ИИ-инструментов. Интересно, что я уже пару раз выступал с темой навроде "Зачем заниматься темой developer productivity в большой компании"
6. LLM ≠ Продукт
Использование последней языковой модели не гарантирует успех продукта. UX/UI, правильный промптинг и интеграция в рабочий процесс часто важнее, чем выбор конкретной модели.
7. Правильные метрики
Стоит измерять NPS, CSAT в связке с retention (у SourceCraft от Yandex между 60-70%), cycle time, lead time и влияние на бизнес-метрики. Метрика счастья пользователя - интегральный показатель принятия/отклонения подсказок.
8. Снижение хайпа - это хорошо
За 2023-2024 год интерес к ИИ в некоторых областях упал и это хорошо - разработчики начинают реалистично оценивать возможности и ограничения ИИ-инструментов, что ведет к более эффективному использованию.
9. Будущее: от генерации к агентам
Развитие сейчас идет от генеративных моделей к агентским. Агенты проактивно решают задачи, но пока крайне ненадежны. Следующий этап развития - сделать агентов более надежными и предсказуемыми. Чем глубже интеграция ИИ в инфраструктуру компании, тем больше выигрыш.

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

#AI #Software #Engineering #Architecture #Agents

Изучая новости отчественных облаков обратил внимание на ключевые тезисы из дискуссии «Озера данных для конкурентоспобности бизнеса».

1. Компании инвестируют в озера данных сейчас, даже если не видят большого эффекта. Через несколько лет догонять лидеров в этой гонке будет сложно. 
2. Мы идем к тому, что компании, которые не используют Data Lakehouse, будут считаться отстающими на Х лет.
3. Для многих компаний работа с большими данными — инвестиция вдолгую. Впереди — выработка методологии для правильной оценки эффекта, который принесут объемы вложенных ресурсов. 
4. Перед бизнесом стоит организационный вызов: нужно научить отделы внутри компаний делиться данными и, возможно, идти в сторону отраслевых хранилищ с обезличенными данными.
5. Средний объем корпоративных хранилищ данных перешагнул порог 500 Тб.
6. Подобрать инфраструктуру для работы с большими данными сложно, поскольку ошибки при выборе провайдера могут сильно помешать масштабироваться на долгой дистанции.

К самим тезисам и облачным продуктам вопросов нет - уверен, озёра данных действительно рулят: они хранят большие объёмы информации, даже в формате Iceberg. Но тема-то заявлена - «конкурентоспособность бизнеса».

Подобные посты часто публикуют и Yandex Cloud, и Arenadata. Но такой контент не создаёт ценности - он ориентирован на нетехнических пользователей. Обычно таким читателям неважно, сколько там терабайт, и вряд ли они поймут разницу между lakehouse и data warehouse.

Складывается впечатление, что компании должны внедрять озёра данных просто потому, что «все внедряют». И если вы ещё не внедрили и не мигрировали - то вам, по сути, нечем будет «мериться». Сколько у кого терабайт? Сколько кластеров? Сколько табличек?

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

Этот подход хорошо иллюстрирует пример с резюме. Вы можете описать свой опыт через output:

- количество таблиц
- количество пайплайнов
- количество дашбордов
- количество PR
- количество строк кода
- миграция из А в Б
- внедрение А, Б, В

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

PS мне нравятся продукты yandex, vk, arenadata, проделана колоссальная работа и созданы отличные решения. Просто улыбнул факт подачи информации о ценности для бизнеса, напомнил мне собеседования и резюме. Всегда хочется рассказать про детали, но они не так важны.

Все знакомы с понятием Ad-hoc запросов. Обычно мы воспринимаем их негативно, так как они отвлекают, время-то и так мало.

На самом деле, ad-hoc запросы могут бысть источником quick wins, и способом быстро показать impact и завоевать доверие (earn trust).

Ad-hoc — это не бардак. Это VIP-запросы, которые показывают: вам доверяют. Ваша задача - не утонуть, а превратить это в рычаг для влияния.

Вот пример фреймфорка:

1. Принять быстро
Ответ в течение пары минут (или автоответ, если в фокусе) показывает: у нас есть процесс, а не паника.

2. Быстрое фильтрование (2 минуты):

- Это повлияет на $Xk+ или стратегию?
- Нужно на этой неделе для принятия решений?
- Делается за полдня одним аналитиком?
- Если да → делаем. Если нет - в бэклог с пометкой по приоритету.

3. Минимум, но по делу
- Отправляем краткий инсайт, график или SQL - что реально помогает. Повторилось 3 раза? → автоматизация.

📌 Чтобы не сгореть:

- Назначаем on-call-аналитика/инженера (10% времени спринта)
- Не забываем про ротацию и отслеживание нагрузки
- Повторяемые запросы → обучающие материалы или дашборды

Эскалации - через менеджера, не через «договорился в курилке».

Ищете работу на международном рынке?

Тогда канал Connectable Jobs будет полезен для вас. Ребята собирают вакансии в международных стартапах с русскоязычными фаундерами, делятся важной информацией про команды и инвестиции, а также прямыми контактами HR для удобного отклика.

Вот несколько актуальных вакансий таких компаниях:
— Head of Data в Manychat
— Data Engineer в Constructor
— Lead of Engineering в Appodeal

Еще у Connectable Jobs есть отдельный канал для разработчиков и инженеров, где публикуются вакансии только в этой области.

Подписывайтесь и развивайте карьеру в будущем единороге 🚀

Всем хороших выходных! Для меня бутылочка сидра в компании жены лучшая награда за 6 рабочих дней:)

PS в пятницу записал для Surfalytics первый эпизод mock Data Engineering System Design interview, использовали Azure cloud.

PPS интересный факт, стаканы из IKEA, но made in Russia😊

Недавно увидел хорошие термины про тип работы - deep work vs shallow work.

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

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

Даже хорошо спланированную работу в формате deep work можно легко превратить в shallow work. Достаточно начать реагировать на сообщения в мессенджере от коллег, менеджеров, друзей. Или участвовать в частых митингах.

Вот и получается: вроде день прошёл, а результата ноль.

Мне лично помогает несложное кольцо действий:
1. составить список 2–3 важных дел на день
2. не переключаться на новое дело, пока не закончу первое
3. блоки deep work в календаре, которые отменяют все встречи - они у меня стоят на год вперёд

Так же можно запланировать дела на неделю, добавив в них личные дела. Свой календарь я не разделяю на личный и рабочий.

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

В прошлом году мы сделали небольшой surf camp в Тофино, на бергу тихого океана.

В этом году мы тоже решили сделать небольшой camp: 30 июня по 3 июля.

Присоединяйтесь:)

Всем привет, в продолжение data&drinks 🌎, давай встретимся:
- 27 или 28 июня в Чикаго
- 20 или 21 августа в Денвере

Если вы из этих городов пишите в комментах или в личку!

Игра симулятор про CDO, попробуйте, получилось прикольно https://www.whoisthebestcdo.com

VC заинвестировали больше 73 лярдов в AI стартапы в 2025, и теперь кошечки прыгают в олимпийский бассейн как настоящие.

https://youtube.com/shorts/Z_hSnPzztpA

Оказывается есть еще очень много компаний, которые используют Microsoft Reporting Service (SSRS).

SSRS (SQL Server Reporting Services) был создан Microsoft и впервые представлен как часть SQL Server 2000 в 2004 году (в составе SQL Server 2000 Reporting Services add-on, релиз - январь 2004). Основная цель - дать пользователям SQL Server инструмент для создания отчётов, который интегрируется с экосистемой Microsoft и конкурирует с Crystal Reports (в то время популярным решением).

И вот, на конференции sqlBits в июне Microsoft объявил о завершении поддержки SSRS. В новом SQL Server будет уже Power BI Report Server (PBIRS), который будет работать с ключом лицензии SSRS.

Но обещана поддержка до 2033 года. В любом случае, если вы используете софт в РФ, поддержка вам и не нужна.

С legacy-софтом я вижу только одну проблему - это, прежде всего, проблема специалистов. Быть экспертом в устаревших системах сужает карьерные возможности. Несмотря на то, что SSRS и другие решения всё ещё отлично работают, вам, как высококлассному специалисту, делать там особо нечего. Зато для бизнеса это отличный вариант: надёжный софт, проверенный десятилетием, легко найти специалистов, и платить им много не нужно.

Tableau Lego и невозможные визуализации.

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

Сегодня расскажу о своей визуализации Tableau Lego. Ей 5 лет, она стала классикой в своём сегменте, но не каждый Tableau эксперт понимает как она построена. Я консультировал несколько инженеров и сейлзов внутри компании Tableau по принципам её построения. То есть, инженеры, создающие продукт, хотели понять на что способен продукт, и что можно ещё создать. И внутри компании создают 3D проекты чтобы расширить понимание возможностей продукта.

Сама визуализация "Tableau Lego" - это эмулятор конструктора, где можно по шагам эмулировать сборку лего домика, а также смотреть на него под разными углами. Всё работает на чистой математике, без внешних модулей.

Когда-то для меня 3D в Tableau казалось космосом. Но надо было разобраться и добавить что-то своё. Месяца на 4 погружался в 3D, принципы, что было сделано и что можно сделать. Сверхсложного ничего нет - просто нужно время. Из своего - добавил работу с OBJ файлами - это сильно изменило картинку. До этого 3D модели описывались форматом стереолитографии, и полигоны делились на треугольники. С моим подходом можно работать с любым числом вершин в полигоне.

Самое сложное - создать датасет, остальное - дело техники. Визуализация - это набор полигонов с заданными координатами вершин и формулы проекции на плоскость плюс алгоритм сортировки полигонов. Максимально подробно всё описал в статье "3D модели в Tableau". Её до сих пор читают и делают 3D. Мы даже конкурс один раз проводили на индийском TUG с призами.

Мне нравится концепция Лего, когда из базовых кубиков создаёшь примитивные конструкции, а и из примитивных конструкций создаёшь сложные сооружения. Как в жизни.

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

Зачем всё это? В русскоязычном пространстве такой вопрос возникает часто, а в англоязычном - нет. В англоязычном комьюнити просят статьи, вебинары и объяснения. Мне просто интересно делать то, что считают невозможным. Это классно, когда ты ограничен инструментом (нет циклов, скриптов и т.п.), и приходится придумывать вычисления для реализации идеи.
В СНГ такие вещи никому не нужны, и это печально. А в англоязычном пространстве всегда ищут что-то необычное и тех кто это делает. В твиттере (благодаря таким работам) на мой профиль подписаны CEO Salesforce, CEO Tableau, CTO Twitter/Facebook (сейчас - Sierra AI) - это люди, определяющие куда пойдёт мировое IT. И им это надо.

Фан факт: я поступил в 2 вуза из топ-3 в этом списке, но учиться пошел в другие места.

Физтех всегда был для меня первым из всех технических вузов, а вот Иннополис удивил

Вот это я понимаю чувак курсы по SQL Server и dba рекламирует на фоне своего Porsche с hello kitty, мужик красавчик, я бы купил. А то у нас люкс только у бизнес коучей, рэперах и в телеграмм розыгрышах.