23384
Делюсь новостями из мира аналитики и карьерными советами. 15 лет в Аналитике и Инжиниринге Данных, 10 лет в MAANG 🛠️ dataengineer.ru | 🏄♂️ Surfalytics.com №5017813306 Реклама: https://almond-rule-130.notion.site/1199f595f76a8030ba1be1e607c9a8ce
🎓Старый добрый формат вебинаров 🎓
27 января в 20:00 по мск
Здесь в канале трансляция...
🖥 Тема: Единое пространство аналитики, или просто Тенгри.
⭐ Спикер - Голов Николай, последние годы строил аналитические платформы на таких системах как Snowflake и Databricks, о которых часто говорит Дмитрий.
🧩Собрал стартап, вместе с командой запилили аналог, о чем и расскажет нам.
На вебинаре мы попробуем разобраться, почему десятки тысяч компаний выбрали Snowflake, а те, кто хочет локальное развертывание, смогут выбрать Tengri Data Platform ( который доступнен как на своем железе так и в облаках, объединяющий хранение, трансформацию, визуализацию данных, SQL и Python, и все это для десятков и сотен TB).
Сайт по system design (Рубрика #Architecture)
Многие мои подписчики знают, что я планировал написать книгу ... но я не уточнял какую. Суть была в том, что я параллельно занимался работой над несколькими книгами. Ближе всего к готовности была книга по System Design (с фокусом на подготовке к интервью) - мне просто было проще всего ее собрать из своих материалов. Я работал по стартинке - сделал желаемое оглавление, собрал часть глав из своих материалов и получил большой Google Doc. Но на каникулах меня осенило, что цель-то не в книге, а в удобной компиляции моих мыслей. Поэтому я поменял подход - скормил google doc сервису Lovable для создания интерактивного сайта, а дальше инкрементально начал его дорабатывать. Я этим занимался больше месяца и получился такой вот сайт system-design.space. Конечно, нет предела совершенству и я собираюсь продолжить его наполнение, но думаю, что он уже может принести пользу тем, кто хочет прокачаться в проектировании.
Если найдете какие-то ошибки или опечатки, то пишите - я буду править их по мере своих сил. В ближайшие месяцы я планирую добавить еще рекомендованных книг, поработать над пулом задачек, чтобы тут были не только классические из других книг + сделаю побольше красивых визуализаций. На более далеком горизонте я планирую пойти в стороне не только классическо system design, но и других типов, что описаны в главе про специфику интервью.
#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software
Как говориться elevate your game with AI - ну то есть пора уже дальше двигаться.
Кто смотрел мое видео как я на работе работаю и задачки закрываю одну за другой с AI, MCP, rulers, repo indexing и тп? Там я показал реальные практические примеры, которые закрывают 90% моих повседневных задач.
Но все это ограничено 1-2 сессиями с AI, где я, как бы контролирую файлы и процесс.
Все пошло дальше. Теперь инженер может запускать 20-50 сессий и агенты работают, каждый в свой git branch и потом все это собирается в pull request.
Я пока еще не приступил к такому, но это следующий шаг в разработке, уже без IDE.
Вот что почитать:
Gastown
Multi-Claude
Claude-flow
Это все будем разбирать на Surfalytics.
Даже уже сейчас вы может через tmux запускать агентов и контролировать план задача через OpenSpec.
PS при этом 98% моих коллег, а их явно очень много практически не используют базовые возможности. На их фоне я просто супер герой производительности, я уже думаю понижать скорость и просить AI помогать мне дозировать мою сверх производительность🙈
PPS: как видите Claude code сейчас number one для разработки.
А как у вас?
ФААНГ уже нет… В топе их нет по зарплатам.
В этом плане для меня рынок Северной Америки — это большой непредсказуемый рынок. Тут всё ещё есть надежда найти интересную работу, высокую зарплату, начать что-то совмещать или делать своё. В целом нет предела, и есть рабочие варианты для роста дохода.
В РФ мне всё видится в другой плоскости. Все зарплаты чётко ограничены. Совмещение практически исключено. Главное направление дополнительного дохода — это коучинг, менторинг и курсы. Создать свой сервис или продукт очень сложно.
На рынке работодателей доминируют несколько основных компаний с известными вилками. Если брать дата-инженеров, то это всегда одинаковый доход и схожий стек. Рост только в лидов и руководителей, но сильно на доход не повлияет.
Так как я давно не работал в РФ, я могу ошибаться. Мой основной источник — это вакансии с GetMatch.
Как обстановочка?
Недавно помог Ване (Ivan) из Мексики 🇲🇽
В октябре к сообществу Surfalytics присоединился парнишка из Mexico City. Очень весёлый и оптимистичный, в каждом посте писал jajaja — это аналог нашего хахаха. Я не знаю, где он меня нашёл. Ну он коренной мексиканец, если что.
Я добавил его карточку intro и его пост о job offer. У него были не самые сильные скилы по дата-аналитике, но он всё сделал на 100%, как мы ему посоветовали: новое резюме, пет-проекты, мок-собеседования и дальше долбить собеседования.
В итоге вчера он написал, что получил оффер в штаты (remote) на Sr DE, с зарплатой в USD, которая в 2 раза выше аналога в Mexico City.
То есть рецепт простой — никакой самодеятельности. Когда вам дают советы бывалые, просто тупо им следовать до победного.
PS мне кажется у него все только начинается, там у него Databricks, а он с ним не работал, так что поддержим мексиканского товарища, не дадим ударить в грязь лицом))
Контекст из индустрии
Таких ситуаций много. В 1Password на ARR и подписках погорело много аналитиков (уволили), так как часто бывает полный хаос внутри, начиная с момента, как вы заводите новый продукт в системе.
Вопрос к вам
Есть ли у вас примеры, когда к вам прилетала задачка, которая не совсем про вас, или когда вы давали задачу человеку, а он её избегал?
Что вы знаете о стратегии данных (data strategy)?
Стратегия данных — это комплексный план организации по управлению данными как стратегическим активом для достижения бизнес-целей. Это документ или набор принципов, определяющих, как компания будет собирать, хранить, обрабатывать, анализировать и использовать данные для создания ценности.
Классный обзор от знакомого про Claude Code
Читать полностью…
Канал Артемия @data_apps один самых недооцененных каналов.
Возможно это связано, что он пишет про технологии и подходы, которые must have на западе, но плохо заходят на ru сегменте.
Сегодня он написал пост про свой опыт работы в компании и свое разочарование от происходящего. Можно сказать, что это и есть burn out.
Раньше я писал хороший пост про матрицу компетенции и карьерные перспективы.
PS вообще Senior Engineer самая уязвимая категория людей в психологическом плане - выгорания, буллинг от менеджеров, глупые хотелки руководства, несбыточные надежды карьерного роста, падения рынка ценных бумаг, дорожание теслы, налог на премиум тачки, прогрессивная налоговая шкала, куча бесполезных знаний по устаревшим технологиям.
Lance + DuckDB - очень интересный сетап для 2026 https://lancedb.com/blog/lance-x-duckdb-sql-retrieval-on-the-multimodal-lakehouse-format
Читать полностью…
Запускаем год с запуска LLM
На вебинаре 15 января эксперты Cloud.ru расскажут, как точно рассчитать конфигурацию для запуска LLM и как настраивать параметры инференса, чтобы сэкономить, но не потерять в качестве.
Что еще интересного в программе:
🟢из чего складывается потребление vRAM
🟢как точно рассчитать нужную конфигурацию GPU
🟢какие параметры LLM сильнее влияют на цену и производительность
🟢как масштабировать модель и переводить ее в serverless-режим
А еще будет практика: запустим LLM в сервисе Evolution ML Inference, покажем оптимальные параметры, сравним разные конфигурации по цене и скорости работы.
Будет интересно всем, кто хочет избежать лишних трат на ML-инфраструктуру.
Зарегистрироваться
Основатель O’Reilly - Tim O’Reilly написал хорошую статью - AI and the Next Economy
Основные идеи статьи от АI:
🔄 Экономика как циркуляция
Автор утверждает, что экономика — это не просто производство, а производство + спрос. Спрос требует широко распределённой покупательной способности. Нельзя построить процветающее общество, оставив большинство людей "за бортом".
⚠️ Проблема нарративов об AGI
Многие нарративы об искусственном общем интеллекте (AGI) предполагают, что:
• Производительность вырастет
• ВВП увеличится
• Но при этом игнорируется вопрос: кто будет покупателями, если большинство людей потеряют работу и доход?
💔 Две версии будущего
1. Экономика открытий — ИИ может помочь решить глобальные проблемы (энергия, материалы, болезни), но:
• Открытия ≠ экономическая ценность
• Между открытием и широким внедрением — долгий путь
• Если контроль над технологиями сконцентрирован, получится "феодализм открытий"
2. Замена труда — ИИ заменит интеллектуальную работу, но:
• Если зарплаты исчезнут, кто будет покупать товары?
• Падение доли зарплат в экономике приведёт к нестабильности
🔑 Ключевые уроки истории
Автор приводит примеры:
• Генри Форд платил высокие зарплаты и сократил рабочие часы, создав массовый рынок для своих автомобилей
• Amazon и Google изначально создавали циркулирующую экономику (flywheel-эффект), но со временем стали извлекать ренту
• Децентрализация (ПК, интернет, open source) стимулирует инновации; централизация захватывает ценность
💡 Что нужно делать
AI-лабораториям:
• Измерять успех не только по возможностям моделей, но и по их распространению
• Создавать открытые интерфейсы, переносимость, совместимость
• Избегать искусственных барьеров
Компаниям:
• Не просто сокращать расходы через ИИ
• Инвестировать дивиденды от производительности в сотрудников (повышение зарплат, сокращение часов, переобучение)
Правительствам:
• Инвестировать в инфраструктуру и институты для новой экономики
• Рассмотреть переход от налогов на труд к налогам на прирост капитала
🌊 Главная метафора
Цитата из Уильяма Блейка: "Плодовитый перестанет быть плодовитым, если Пожиратель не будет, как море, принимать избыток его наслаждений".
Иными словами: производство должно потребляться, система должна циркулировать. ИИ-экономика нуждается в "маховике" (flywheel), который обеспечит широкое распространение благ, а не их концентрацию.
Хочу поделиться интересным опытом с AI. Опять же, на сам конечный результат это не влияет. Но влияет на его скорость и качество.
Возьмем пример Azure Data Factory. Это такой orchestration инструмент на Azure. По умолчанию там UI и drag&drop. Все очень просто, пока не нужно делать 100 pipelines.
Допустим, мы продвинутые инженеры (сеньоры, например), и мы хотим использовать best practices и engineering excellence, и добавили git версионирование, и следующий шаг будет сделать Infrastructure as a Code.
Первое, о чем мы подумаем - это Terraform или Azure Bicep. А может быть, вообще возьмем ADF SDK, и там есть Python SDK или C# (я, кстати, на нем и делал все в Microsoft внутри Visual Studio (не путать с VS Code)).
То есть мы думаем о привычном методе, о коде, который будет написан AI, но как будто человеком, и, в теории, другие человеки смогут его читать (без AI).
Хотя по факту никто его уже не будет читать без AI. И вообще уже не важно, что там C#, Python, Bicep, Terraform - главное, чтобы данные грузились.
Тут важно заметить, что это применимо к инжинирингу данных, и может быть совсем не применимо к другим областям.
Что я сделал?
Взял свой GitHub репозиторий с ADF, где все автоматически создано в ARM (Azure JSON формат), который не пишется человеком, и попросил AI сделать правила репозитория и начать создавать новые pipelines. (Аналог может быть Tableau Workbook XML или другие смежные программы с их файлами)
Таким образом, из моего backlog я просто взял и выкинул кучу задач про миграцию ADF на Bicep/Terraform и ускорил разработку, доработку и документацию в несколько раз.
То есть идея в том, что с AI я спустился на уровень ниже: вместо привычной абстракции в виде Terraform/Python я начал фигачить JSON ARM, который не human readable. И я полагаю, нам нужно не бояться уходить от традиционных методов и начинать исследовать новые возможности.
Скоро можно будет сразу на бинарном коде строить дашборды.
PS на картинке пример. Я еще собрал историю своих промотав за последние несколько месяцев и на их базе создал монстр правило как все должно работать и в него написано про доступный MCP сервер, чтобы сразу ходить и все проверять. Раньше я ленился и поэтому много надо было копировать руками и было много ошибок.
Дальше хочешь попробовать вставить duckdb куда-нибудь для оптимизации расходов, один ADF Runtime стоит 3к$ в месяц.
Apache Spark выпустил релиз 4.1
Если 4.0 было страшно использовать, то 4.1 уже вполне.
Ключевые обновления
1. Spark Declarative Pipelines (SDP)
Новый декларативный фреймворк, который позволяет разработчикам определять наборы данных и запросы, а Spark автоматически управляет:
• Графом выполнения и порядком зависимостей
• Параллелизмом, контрольными точками и повторными попытками
• Поддержка Python, SQL и Spark Connect API
2. Real-Time Mode (RTM) в Structured Streaming
Первая официальная поддержка режима реального времени для непрерывной обработки с задержкой менее секунды:
• Задержка p99 в диапазоне единиц миллисекунд для задач без сохранения состояния
• Поддержка Kafka источников и приёмников
• Активируется простым изменением конфигурации без переписывания кода
3. Улучшения PySpark
Arrow-нативные UDF и UDTF:
• Новые декораторы @arrow_udf и @arrow_udtf для эффективного выполнения без накладных расходов на конвертацию Pandas
• Прямая работа с объектами PyArrow для векторизованной обработки
Python Worker Logging:
• Захват логов UDF через встроенную табличную функцию
• Упрощённая отладка Python функций
Filter Pushdown для Python Data Sources:
• Уменьшение перемещения данных за счёт обработки фильтров на уровне источника
4. Spark Connect
• Spark ML теперь GA для Python клиента
• Интеллектуальное кэширование моделей и управление памятью
• Сжатие планов выполнения protobuf с использованием zstd
• Потоковая передача результатов Arrow порциями
• Снято ограничение в 2 ГБ для локальных отношений
5. Улучшения SQL
SQL Scripting (GA):
• Включён по умолчанию
• Поддержка циклов, условных операторов и обработчиков ошибок
• Новый синтаксис CONTINUE HANDLER и многопеременное объявление DECLARE
VARIANT Data Type (GA):
• Стандартизированное хранение полуструктурированных данных (JSON)
• Shredding для оптимизации чтения:
▪ В 8 раз быстрее по сравнению со стандартным VARIANT
▪ В 30 раз быстрее по сравнению с JSON-строками
Recursive CTE:
• Поддержка рекурсивных общих табличных выражений для обхода иерархических структур
Новые аппроксимационные скетчи:
• KLL (для квантилей) и Theta скетчи для эффективных операций над множествами
Производительность
• Режим реального времени обеспечивает улучшение задержки на порядки величин
• VARIANT с shredding: 8-30x ускорение чтения (с компромиссом 20-50% замедления записи)
Для инвесторов было необходимо посмотреть демографию клиентов в США. Для такой задачи можно использовать открытые источники, например данные US Census Bureau, которые доступны в Snowflake.
Бюро переписи населения США публикует данные о американском населении и экономике.
Американское исследование сообществ (American Community Survey) этого агентства — это постоянно проводимый опрос, который предоставляет самые актуальные социальные, экономические, жилищные и демографические статистические данные. Ежегодно публикуются как однолетние, так и пятилетние оценки для различных уровней географических единиц, включая штаты, города, почтовые индексы и группы переписных участков. В отличие от Всеобщей переписи населения (Decennial Census), Американское исследование сообществ публикуется каждый год и рассылается по выборке адресов в США (~3,5 миллиона).
CASE
WHEN median_household_income_dollars >= 150000 THEN 'High Income ($150k+)'
WHEN median_household_income_dollars >= 100000 THEN 'Upper Middle ($100k-$150k)'
WHEN median_household_income_dollars >= 75000 THEN 'Middle Income ($75k-$100k)'
WHEN median_household_income_dollars >= 50000 THEN 'Lower Middle ($50k-$75k)'
ELSE 'Lower Income (<$50k)'
Давайте проведем опрос про уровень использования AI вами в работе.
Этап 1: Нулевой или почти нулевой ИИ: возможно автодополнение кода, иногда вопросы в чат
Этап 2: Агент для кодирования в IDE с разрешениями. Узкоспециализированный агент для кодирования в боковой панели запрашивает ваше разрешение на запуск инструментов.
Этап 3: Агент в IDE, режим YOLO: Доверие растёт. Вы отключаете разрешения, агент становится более широким.
Этап 4: В IDE, широкий агент: Ваш агент постепенно заполняет весь экран. Код нужен только для просмотра различий (diff).
Этап 5: CLI, один агент. YOLO. Различия (diff) пролетают перед глазами. Вы можете смотреть на них, а можете и нет.
Этап 6: CLI, мультиагентность, YOLO. Вы регулярно используете от 3 до 5 параллельных экземпляров. Вы работаете очень быстро.
Этап 7: 10+ агентов, ручное управление. Вы начинаете достигать пределов ручного управления.
Этап 8: Создание собственного оркестратора. Вы на передовой, автоматизируете свой рабочий процесс.
Я где-то между 4 и 6. Я не использую Cursor, поэтому CLI слово ко мне не очень подходит.
Сегодня у Cursor появилось обновление - CLI Agent. В целом я понимаю, что в IDE намного больше ограничений, так как она занимает весь экран и сложно иметь много окон с IDE, у меня обычно 2-3 сессии параллельно.
В след посте добавлю опрос.
Есть интересный концепт про проверку вашей LLM на самостоятельность - Solving a Million-Step LLM Task with Zero Errors
Главная проблема современных языковых моделей (LLM) — «накопление ошибок». Если задача требует 1000 последовательных шагов и на каждом шаге вероятность ошибки всего 1%, то вероятность успешного завершения всей цепочки стремится к нулю.
Авторы представили систему MAKER, которая смогла выполнить задачу, состоящую из более чем 1 000 000 (миллиона!) шагов, не допустив ни одной ошибки.
За счет чего это работает?
🔹 Микроагенты: Задачу дробят на атомарные части, где ошибиться практически невозможно.
🔹 Массовое голосование: Каждый чих нейронки проверяется другими агентами в реальном времени. Если один «галлюцинирует», остальные его поправляют.
🔹 MDAP: Вместо монолитного ИИ используется распределенная сеть процессов (Massively Decomposed Agentic Processes).
Почему это важно?
Это доказывает, что для решения сверхсложных задач (уровня целых корпораций или научных открытий) нам не обязательно ждать GPT-6. Мы можем строить сверхнадежные системы уже сейчас, просто правильно организуя работу существующих моделей.
Сейчас стараемся изучать каждые выходные проекты. Сегодня Snowflake + Terraform. Очень круто, что ребята выходят из зоны комфорта и учат других!
Читать полностью…
Интересная точка зрения подъехала про использования токенов для LLM.
Я про такое даже не задумывался. Отличный хак для вендора.
Милое зрелище: девелоперы искренне верят, что «обманули систему», платя по $200 в месяц за безлимитный Claude Code. «О, я сжигаю токенов на $2К шестью инстансами Claude Code еще до завтрака!»
Приятель, ты сжигаешь не токены. Ты сжигаешь наценку.
Я подключил Claude Code к выделенному vLLM, чтобы посмотреть, что там реально «под капотом». После шести часов чистого кодинга и дебага картина такая:
* 47 млн входящих токенов (prompt tokens).
* 45 млн попаданий в префикс-кэш (prefix-cache hits).
* 96,39% коэффициент попадания в кэш (token-weighted).
* Реальные вычисления: 1,3 млн префилла + 300 тыс. токенов генерации.
Это не видеокарты пашут на износ. Это кэш с манией величия.
«Субсидированный» тариф Anthropic для кодинга на самом деле никакой не субсидированный — это лотерея кэширования. Когда они скармливают тебе хорошо квантованную смесь Haiku/Opus, которая на 96% состоит из зазубренного шаблонного кода, маржинальная стоимость стремится к нулю. Лимиты — это искусственный дефицит. Тарифы по $100 и $200 — просто психологические якоря.
Ты платишь не за вычислительные мощности. Ты платишь за ощущение безграничной власти, пока они душат тебя лимитами в «5 часов в неделю», чтобы защитить маржинальность своих GPU.
Агентный кодинг — это гениальный ценовой хак. Только не путай его с реальной экономикой токенов 🤡
Убедись, что твой ИИ принадлежит тебе. Облачный ИИ не на твоей стороне; он на стороне компании, которая им владеет.
Канал Лёши Арефьева про управление IT продуктами @alexcouncil. Метрики, инструменты и полезные материалы на околопродуктовые темы.
Подборка интересных постов:
- что делать, когда исследований овердохрена /channel/alexcouncil/1156
- проектный менеджмент для самых маленьких /channel/alexcouncil/1142
- про метрики продукта: CAC - сколько стоит клиент /channel/alexcouncil/1136
- шпаргалка: пирамида метрик /channel/alexcouncil/1122
- про следующий уровень по позиции /channel/alexcouncil/1020
Если интересно, подписывайтесь - @alexcouncil
Пример некомпетентности или лени? Вопрос только чей — моей или менеджера?
У компании есть Stripe (платежная система), в которой заведены продукты и подписки. У каждого продукта есть свои вложенные свойства — план, срок, страховка и т.п.
Задача: сделать дашборд с простыми показателями — ARR, Active Customers, Cancellation, Expansions и т.п.
Как работает система: Fivetran загружает данные в Snowflake, dbt использует medallion architecture, дашборд в Sigma BI.
Максимально популярный кейс для стартапов и небольших компаний в Северной Америке.
Команда и контекст
В команде (data team) есть VP, Product Manager Customer Analytics, Data Analyst.
Есть существующие dbt-модели от прежнего подрядчика и дашборд в Sigma BI по подпискам, который каждый день просматривается exec-командой.
Моя зона ответственности: вся data & ML инфраструктура, CI/CD, инструменты и т.п. То есть для меня бизнес-логика subscriptions — это black box. Хотел бы я лучше понимать подписку? Возможно. Удвоит это мой доход? Нет;)
На добровольно-принудительных основаниях мне предложили пофиксить subscription black box, как я это ранее делал для других доменов (sales, marketing, product usage, customer service).
Что произошло
Вместе с Cursor (AI), открытыми примерами dbt-моделей и документацией API я смог создать Subscriptions V3. Почему V3? Потому что V2 сказали убрать, так как цифры не сильно похожи на V1 — тот, который каждый день смотрит exec-команда.
Когда я закончил V3, меня стали спрашивать: «А почему показатели расходятся с V1?» Ответ простой — логика другая. И каждый день сыплется порция новых вопросов и идей.
В какой-то момент я потерял суть событий и вообще задался вопросом: если цифры в V1 так нравятся exec-команде, то почему бы не оставить их? (Риторический вопрос)
Так как я взялся за эту задачу, я как бы стал ответственным за это дело. И все дружно приходят ко мне с вопросами, как будто я эксперт в подписках, знаю всё про ARR/MRR и другие тонкости расчётов, и особенно знаю, почему V1 и V3 расходятся.
Самое главное
Эталонных цифр нет. То есть ни V1, ни V3 мы не можем сравнить с истиной. В Stripe есть свои дашборды, но команда решила, что там показатели ниже, чем в V1, и поэтому такое нам не подходит.
Ещё недавно узнал от CTO, что он эксперт по подпискам, а всё это время (2–3 месяца) работа велась под руководством Product Manager.
Два взгляда на ситуацию
А) Вы работаете в стартапе, и вы можете надевать шляпу инженера, аналитика, продакта и выходить за рамки своих обязанностей, вообще кидаться на амбразуру при любом удобном случае.
Б) Вы эксперт в определённой области — в моём случае дата-инфраструктура, и я отвечаю за всю систему в целом. Моё преимущество в том, что мне не надо ковыряться в domain-логике, особенно если это не простые вещи, как продажи, где ПРИБЫЛЬ = СУММА × КОЛ-ВО ЗАКАЗОВ, и я смогу посмотреть в backend на правильный ответ.
PS Это я очень вежливо описал ситуацию 😉
Моя позиция
Со своей колокольни я могу сказать, что моё время расходуется неэффективно — вариант Б, и скинуть на меня такой проект неправильно. У меня чувство, что я расходую энергию на какие-то глупости из-за того, что кто-то не захотел разобраться в сложном вопросе и решил делегировать мне.
На данном примере я хотел показать пример неэффективного использования инженерного времени и отсутствия правильного распределения обязанностей, которые ведут к:
• Проблемам с качеством insights
• Проблемам в других областях, которые просто простаивают
• Ухудшению климата в команде
• Waste времени и ресурсов
Я считаю, что начиная с определённого этапа компании должны использовать профессионалов и их сильные стороны, вместо того чтобы затыкать ими дыры.
Существует известный красный флаг - это когда вам говорят, это не моя работа, или у меня этого нет в обязанностях. К этой ситуации я этот пример не отношу. И тут важно, что это у всего есть предел и не возможно требовать от человека то, что за 2 года никто не могу сделать и все избегали. Если посмотреть на расход токенов в AI на эту задачку, что за 3 месяца набежала кругленькая сумма. Без AI вообще бы была труба.
Как найти работу за рубежом, если страшно и непонятно с чего начать?
Международный рынок открывает двери к крутым проектам, зарплатам в долларах и евро, но иногда кажется искать работу за границей долго, нудно и слишком сложно!
Непонятно, что делать. Правила рынка другие. Здесь мало резюмешки на хэдхантере и рекрутеры за тобой не бегают толпами. Нужно заводить LinkedIn, искать рефералов, выискивать вакансии среди десятков джоб-бордов...
Разобраться быстро самому почти невозможно. Зато есть такие ребята как AgileFluent 👇
Они уже 4 года помогают IT и Digital специалистам выйти на международный рынок. На их счету — 800+ офферов в 32 странах в такие компании как Amazon, Cisco, UniCredit, Revolut, FLO, Ferrero, N26, ALDI, Semrush, Wheely…
Они ведут крутой канал про международку, где делятся:
✔️ историями тех, кто переехал и зарабатывает в валюте,
✔️ разборами резюме и LinkedIn профилей,
✔️ персональными подборками вакансий,
✔️ гайдами и чек-листами по CV, CL, LinkedIn...
Если давно мечтал о работе за рубежом — это твой знак! Начни с их канала :)
👉 Подписывайся
Реклама. ООО «Эджайл», ИНН 7810964334, erid:2Vtzqvk5SgK
Пришло время Agentic RAG — подхода, при котором AI-агент самостоятельно ищет, рассуждает и действует, используя RAG не как чат, а как инструмент доступа к знаниям 😎
На вебинаре 22 января специалисты Cloud․ru покажут, как с помощью Evolution AI Agents, Evolution Managed RAG и MCP-протокола построить систему, способную решать многошаговые задачи в реальном времени.
В программе:
😶🌫️как устроена архитектура Agentic RAG;
😶🌫️как MCP-сервер для Evolution Managed RAG предоставляет стандартизированный интерфейс к векторной базе знаний;
😶🌫️как агент использует retrieval-augmented reasoning в одном цикле исполнения;
😶🌫️какие LLM лучше подходят: для быстрых гипотез и для production с высокой нагрузкой.
А еще будет практическая часть: получится развернуть AI-агента в Evolution AI Agents и подключить MCP-сервер для Evolution Managed RAG.
Зарегистрироваться
Вчера был интересный разговор с VP Data в крупной Wealth Management компании, который стал с 2026 года VP Data & Artificial Intelligence. (Я помогаю им с прорывными аналитическими решениями).
Сама компания традиционный Enterprise, где источник данных SFTP и множество решений on-premise.
Ему понравился мой background и он захотел познакомиться поближе. Разговор он начал с того, что он тут где-то года два и у него есть два сценария:
1) оставить всё как есть, и через два года его попросят
2) попытаться сделать что-то прорывное, и даже если его попросят, у него будет классный кейс.
Это было очень необычное начало знакомства, но мне понравилось. Он рассказал как в 2017 году познакомился со статьей Attention is All you Need, и как воодушевившись ей, они стали делать продукт внутри финансовой организации и получилось очень круто.
Cтатья представляет архитектуру Transformer — революционную модель для обработки последовательностей, основанную исключительно на механизмах внимания (attention), полностью отказавшись от рекуррентных и свёрточных нейронных сетей. Модель достигла новых рекордов в машинном переводе (28.4 BLEU на английско-немецком переводе), обучаясь значительно быстрее предшественников благодаря возможности параллелизации вычислений. Статья важна потому, что Transformer стал фундаментом для современных языковых моделей (BERT, GPT, T5 и других), определив развитие всей области обработки естественного языка и искусственного интеллекта на годы вперёд.
📅 #Топ мировых конференций по Data Engineering на 2026
🧰 01/24 — Data Day Texas +AI — Austin, USA — ламповая комьюнити-конфа про инженерку данных: пайплайны, DWH/lakehouse, облака, практики прод-эксплуатации. Online только материалы/записи (если выложат).
🧭 03/09-11 — Gartner Data & Analytics Summit — Orlando, USA — data governance, architecture, operating model, “как продать и масштабировать платформу данных” в компании (полезно архитекторам/лидам). Online только материалы после (если доступны).
☁️ 04/22-24 — Google Cloud Next — Las Vegas, USA — паттерны построения data platforms в GCP: ingestion, lakehouse/warehouse, streaming, security & governance. Online только записи/хайлайты (если будут).
⚡ 05/19-20 — Current (Confluent) — London, UK — Kafka/streaming в проде: real-time ETL, schema evolution, governance, observability, event-driven архитектуры. Online только материалы/записи (если выложат).
🏛️ 05/06-08 — Data Innovation Summit — Stockholm, Sweden — современная дата-платформа: data products, governance, quality, architecture, enterprise-кейсы.
❄️ 06/01-04 — Snowflake Summit — San Francisco, USA — облачный DWH/платформа: performance, governance, sharing, ingestion/ELT, экосистема. Online только livestream ключевых + записи.
🧊 06/15-18 — Data + AI Summit (Databricks) — San Francisco, USA — lakehouse/lakehouse-ops: ingestion, streaming, governance, cost/perf, infra для MLOps/GenAI на платформе. Online только Watch On Demand.
🌀 08/31-09/02 — Airflow Summit — Austin, USA — оркестрация и ops: multi-tenant Airflow, reliability, backfills, sensors, best practices для data platform teams. Online только записи (если выложат).
🛠️ 09/15-18 — Coalesce (dbt Labs) — Las Vegas, USA — analytics engineering для прод-DWH: dbt, тесты/контракты, семантика, lineage, CI/CD. IRL + online.
🎡 09/23-24 — Big Data LDN — London, UK — большой зоопарк modern data stack: платформы, интеграции, governance/quality, архитектурные кейсы и вендоры. Online только материалы (если появятся).
🏗️ 11/30-12/04 — AWS re:Invent — Las Vegas, USA — инфраструктура под data platforms: storage/lakehouse, streaming, managed data services, security, FinOps. Online только on-demand + Best of re:Invent (virtual).
#y2026 #DE #data #conferences #dataengineering #modernDataStack #dataplatform #airflow #dbt #iceberg #kafka #streaming #dataquality #datagovernance #tobecontinued..
Сохраняй — и пусть 2026 будет годом крепких дата-платформ и бодрых релизов 🚀
* при подготовке использовались #LLM, тч делайте #фактчекинг 😁 (и присылайте под пост или в директ;))
У AI есть интересный side эффект.
Как вы знаете, когда вы закрываете задачу, то вы получаете заряд дофамина. С AI в IDE вы можете закрыть в 5 раз больше задач в 3 раза быстрей. При условии, что нет токсичной среды с микроменджерами и медленным code review процессом и вы знаете, что делаете.
В каком-то смысле AI заменяет соц сети, только за это еще платят.
Сегодня у меня на zoom call товарищ подключился со своего рабочего места…
Будущее наступило🚶♀️
PS хотите удивить на собеседовании? Теперь знаете, что делать. И глаз не видно, которые списывают из chatgpt))
Статья "When AI writes almost all code, what happens to software engineering?" от The Pragmatic Engineer посвящена изменениям в профессии разработчика в связи с развитием AI для написания кода.
Основные темы статьи:
🔄 Переломный момент
Автор и многие опытные инженеры заметили, что новые модели AI (Opus 4.5, GPT-5.2, Gemini 3), выпущенные в ноябре-декабре 2025 года, достигли качественно нового уровня. Теперь AI может генерировать 90%+ кода, который раньше писали разработчики вручную.
📉 Плохие новости (The Bad)
• Снижение ценности специализации - знание конкретных языков программирования становится менее важным
• Прототипирование - теперь доступно не-техническим специалистам
• Конец узкой специализации - разделение на frontend/backend разработчиков может исчезнуть
• Рефакторинг и реализация задач - всё больше делегируется AI
Мой коммент: Несмотря на такой хороший список возможностей AI, очень мало кто этим пользуется, даже среди разработчиков. Многие люди не любят сильно напрягаться и изучать новое. С точки зрения специализации инженера данных, его ценность не в написании кода, а в создании аналитических систем.
📈 Хорошие новости (The Good)
• Инженеры важнее кодеров - навыки software engineering (архитектура, тестирование, код-ревью) ценятся больше
• Tech lead навыки - становятся базовыми требованиями
• Product-minded подход - разработчики должны лучше понимать продукт
• Системное мышление - важнее умение проектировать системы, чем писать код
Мой коммент: Так же и для аналитики и инженеринга данных - основы и фундаментальные знания важнее. Product-подход, ценность от выполнения задач, решения бизнес-проблем - все это как было важно, так и остается важным. Но теперь это может быть ваше основное преимущество.
⚠️ Неприятные последствия (The Ugly)
• Больше сгенерированного кода = больше проблем
• Слабые практики разработки начнут вредить быстрее
• Work-life balance может ухудшиться из-за повышенных ожиданий продуктивности
Мой коммент: Проблемы от vibe-coding — это очевидно, и некоторые уже меняют title в LinkedIn на "fixing your problems after vibe-coding". В токсичных компаниях реально могут требовать от вас больше результатов за меньшее время. Только вот в токсичных компаниях часто руководство не понимает ничего в AI, vibe-coding, и пока можно делать больше за меньшее количество времени. Но рано или поздно это изменится. Ведь можно отслеживать, сколько токенов было израсходовано, в какие репо коммитился код, и использовать AI как надзирателя. В любом случае, на данном этапе work-life баланс улучшился. Вопрос: надолго ли?
🤝 Слияние ролей
Границы между product managers и software engineers размываются - PM могут генерировать код, а инженеры берут на себя больше продуктовых решений.
Мой коммент: Я уже рассказывал про product-менеджера, который устал ждать отчет и навайбкодил целое решение с AI, дашбордом и парсингом данных опросов по продукту и стал чувствовать себя очень крутым и важным после этого. К сожалению, в production такое решение не пойдет, но он смог решить проблему сам от начала до конца без навыков и получил классный прототип с реальными инсайтами.
Очень интересный обзор М5 процессора https://youtu.be/Jh9pFp1oM7E?si=gwUcZVsxPhzA4TFk
Будет интересно с детьми посмотреть
PS согласно автору без использования AI, все сделано в Blender. Хотя у Blender есть MCP.
Building A Generative AI Platform - Это очень подробная статья (июль 2024) о построении платформы для генеративного AI, которая постепенно описывает архитектуру от простейшей (запрос → модель → ответ) до сложной production-системы. Основные компоненты:
1) Context construction (RAG с embedding/term-based поиском, SQL-запросы, веб-поиск, query rewriting),
2) Guardrails (входные для защиты от утечек PII и jailbreaking, выходные для проверки качества/токсичности/галлюцинаций),
3) Router и Gateway (маршрутизация запросов к разным моделям, унифицированный доступ, fallback, контроль доступа),
4) Cache (prompt cache, exact cache, semantic cache для снижения латентности и стоимости),
5) Complex logic (циклы, условное ветвление, write-действия),
6) Observability (метрики, логи, трейсы) и
7) Orchestration (LangChain, LlamaIndex и др., но автор советует начинать без них).
А какие вы порекомендуете свежие ресурсы? Если хотите добавить ее как ссылку в коммент, можно использовать код:
Читать полностью…
http://ssilka.ru