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

Для инвесторов было необходимо посмотреть демографию клиентов в США. Для такой задачи можно использовать открытые источники, например данные US Census Bureau, которые доступны в Snowflake.

Бюро переписи населения США публикует данные о американском населении и экономике.

Американское исследование сообществ (American Community Survey) этого агентства — это постоянно проводимый опрос, который предоставляет самые актуальные социальные, экономические, жилищные и демографические статистические данные. Ежегодно публикуются как однолетние, так и пятилетние оценки для различных уровней географических единиц, включая штаты, города, почтовые индексы и группы переписных участков. В отличие от Всеобщей переписи населения (Decennial Census), Американское исследование сообществ публикуется каждый год и рассылается по выборке адресов в США (~3,5 миллиона).

Задача простая, показать типового американца клиента нашего продукта. Последний опрос проводился в декабре 2023.

Сами по себе данные очень неудобные https://api.census.gov/data/2023/acs/acs5/variables.html, так что AI очень хорошо помог (Cursor, MCP - прям как я в недавнем видео записал).

Чтобы упросить логику, трансформации разложил по слоям в dbt.

Хотел поделиться примером демографии по медиане доходов в США:

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)'

То есть из примера видно, что средний доход в штатах это 75к в год (до налогов), где-то 4т в месяц на руки. А высокий доход это 150т+, около 8т на руки в месяц. Точно так же и в Канаде, только в Канадских долларах, но налоги будут выше и цены на все тоже будут выше.

А если посмотреть на зп Инженера данных, то старший специалист в США это 180-220к$, а в Канаде 160-180к CAD.

То есть зарплаты в ИТ они выше, чем “high income”.

Но у них есть недостаток, как правило все “high income” специалисты будут жить в дорогих городах, платить большую ипотеку или рент, платить кредит за машину(ы) и по факту, они будут такими же бедными.


Я бы сделал сейчас другие бакеты:
- High Income: >600к
- Upper Middle: 400-600к
- Middle: 250-400к
- Lower: <200к

Очень интересный обзор М5 процессора https://youtu.be/Jh9pFp1oM7E?si=gwUcZVsxPhzA4TFk

Будет интересно с детьми посмотреть

PS согласно автору без использования AI, все сделано в Blender. Хотя у Blender есть MCP.

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% замедления записи)

Статья "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 такое решение не пойдет, но он смог решить проблему сам от начала до конца без навыков и получил классный прототип с реальными инсайтами.

Хочу поделиться интересным опытом с 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к$ в месяц.

Основатель O’Reilly - Tim O’Reilly написал хорошую статью - AI and the Next Economy

Основные идеи статьи от АI:

🔄 Экономика как циркуляция
Автор утверждает, что экономика — это не просто производство, а производство + спрос. Спрос требует широко распределённой покупательной способности. Нельзя построить процветающее общество, оставив большинство людей "за бортом".

⚠️ Проблема нарративов об AGI
Многие нарративы об искусственном общем интеллекте (AGI) предполагают, что:
• Производительность вырастет
• ВВП увеличится
• Но при этом игнорируется вопрос: кто будет покупателями, если большинство людей потеряют работу и доход?

💔 Две версии будущего
1. Экономика открытий — ИИ может помочь решить глобальные проблемы (энергия, материалы, болезни), но:
• Открытия ≠ экономическая ценность
• Между открытием и широким внедрением — долгий путь
• Если контроль над технологиями сконцентрирован, получится "феодализм открытий"
2. Замена труда — ИИ заменит интеллектуальную работу, но:
• Если зарплаты исчезнут, кто будет покупать товары?
• Падение доли зарплат в экономике приведёт к нестабильности

🔑 Ключевые уроки истории
Автор приводит примеры:
• Генри Форд платил высокие зарплаты и сократил рабочие часы, создав массовый рынок для своих автомобилей
• Amazon и Google изначально создавали циркулирующую экономику (flywheel-эффект), но со временем стали извлекать ренту
• Децентрализация (ПК, интернет, open source) стимулирует инновации; централизация захватывает ценность

💡 Что нужно делать
AI-лабораториям:
• Измерять успех не только по возможностям моделей, но и по их распространению
• Создавать открытые интерфейсы, переносимость, совместимость
• Избегать искусственных барьеров
Компаниям:
• Не просто сокращать расходы через ИИ
• Инвестировать дивиденды от производительности в сотрудников (повышение зарплат, сокращение часов, переобучение)
Правительствам:
• Инвестировать в инфраструктуру и институты для новой экономики
• Рассмотреть переход от налогов на труд к налогам на прирост капитала

🌊 Главная метафора
Цитата из Уильяма Блейка: "Плодовитый перестанет быть плодовитым, если Пожиратель не будет, как море, принимать избыток его наслаждений".

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

У AI есть интересный side эффект.

Как вы знаете, когда вы закрываете задачу, то вы получаете заряд дофамина. С AI в IDE вы можете закрыть в 5 раз больше задач в 3 раза быстрей. При условии, что нет токсичной среды с микроменджерами и медленным code review процессом и вы знаете, что делаете.

В каком-то смысле AI заменяет соц сети, только за это еще платят.

Lance + DuckDB - очень интересный сетап для 2026 https://lancedb.com/blog/lance-x-duckdb-sql-retrieval-on-the-multimodal-lakehouse-format