From Vibe Coding to the AI Software Factory - статья Seattle Data Guy, в которой он описывает как инженерные команды эволюционируют в использовании AI и больших языковых моделей для разработки.

Автор описывает 5 уровней зрелости использования ИИ в командах — от хаотичных экспериментов до выстроенной «фабрики по производству ПО».

Уровень 1 — Гараж. Личные эксперименты и хобби-проекты, которые никогда не доходят до продакшена.

Уровень 2 — Верстак с макросами. Небольшие скрипты и мини-приложения, решающие конкретные задачи, но всё ещё далёкие от полноценного производства.

Уровень 3 — Мастерская. Команды начинают стандартизировать промпты, шаблоны и агентов, но это всё ещё лишь точечные улучшения.

Уровень 4 — Конвейер. Появляются повторяемые системы, стейт-машины, отслеживание метрик и токеномики. Можно реально измерять эффективность.

Уровень 5 — Фабрика ценности. Всё вышеперечисленное связывается с реальной бизнес-ценностью — иначе это просто «производство виджетов ради виджетов».

Максимум, что мне доводилось видеть для инжиниринга данных это между уровнем 2 и 3. Для разработки ПО, конечно же, это все двигается в сторону уровня 4, 5. Паттерны AI разработки уже вырисовываются и есть свои best practices - бери и делай, по ходу адаптируй.

Думая об уровнях и адаптации ИИ в компаниях, мне вспоминается мем “можно, а зачем?”

PS вообще SeattleDataGuy что-то сдулся🪦

Как построить управляемый Data Lakehouse за неделю на Evolution Data Platform ⤵️

На вебинаре 8 сентября эксперты Cloud.​ru покажут, как за неделю с нуля построить архитектуру Data Lakehouse на Evolution Data Platform — от загрузки сырых данных до курированных витрин — с помощью управляемых сервисов, без эксплуатационной нагрузки и с фокусом на бизнес-результат.

В программе:
▶️принципы построения Lakehouse-архитектуры с единым слоем хранения в S3 в формате Apache Iceberg с поддержкой ACID-гарантий и версионирования;

▶️подходы к централизованному управлению метаданными и происхождением данных через Managed Metastore;

▶️способы реализации контроля качества данных в Managed Spark без остановки пайплайнов;

▶️методы организации хранения данных с разным уровнем доверия: партиционирование по качеству, time travel и разделение слоев хранения;

▶️принципы настройки единого SQL-слоя через Managed Trino с разграничением доступа;

▶️инструменты автоматизации оркестрации и мониторинга пайплайнов в Managed Airflow;

▶️возможности визуализации качества и происхождения данных в Managed BI.
➡️ Регистрация — по ссылке

Diversity для LLMs

В одном стартапе, про который я недавно писал, все используют Claude Code.

Claude Code подключён к MCPs:
• dbt Cloud
• Snowflake
• Omni BI

С помощью Claude Desktop и Claude Code любой желающий (с доступом) может писать код, открывать PR. Как правило, всё это происходит в dbt или Omni.

То есть все поголовно стали Analytics Engineers. Даже если вы с компьютером на «вы», теперь даже с iPad'а можно заменить BI- и Analytics Engineer. Ведь основным языком программирования, как говорят, стал English. Даже если вы не согласны с этим (как и я), то ваш руководитель может считать по другому, а его мнение имеет бОльший вес, поэтому по факту будет так, как начальство скажет.

В отдельном посте я расскажу, как мы перешли к data model-oriented development (именно бизнес-модель данных, ER-диаграмма по Кимбаллу).

Так вот, суть проблемы такова: у всех Claude Code (не путать с Claude Котом из поста выше), и все работают не покладая рук. Коммит за коммитом, комментарий за комментарием и т. п. Агент пишет код, создаёт документацию, формирует описание PR, тестирует код. Другой человек с таким же агентом пытается код проверить, оставляет комментарии.

В последнее время у Claude прямо беда с написанием английского текста — он пишет размашисто и непонятно, оставляет большие и бесполезные комментарии в коде, вообще стал чудить. Также появилась новая фича — Watermark, которая осознанно заменяет слова на синонимы.

Поэтому работать всей командой, используя одни и те же модели, стало сложно. Я провёл эксперимент: стал использовать Cursor для проверки кода и текста. Оказалось, что Cursor понимает мою проблему и с удовольствием почистил PR, подсказал, где урезать код и текст, где не применились best practices и т. п. В целом могу сказать, что Cursor достаточно хорошо прокачался за последнее время — теперь у них есть Grok.

Таким образом, с одной моделью далеко не уедешь, если создаёшь серьёзный продукт. Всегда полезно добавить второе мнение от другой модели. Насколько я понимаю, в AI4SDLC это уже закладывается на входе, поэтому можно смело планировать использование нескольких моделей и агентов для повышения качества кода и документации и снижения когнитивной нагрузки на оператора AI. Мы же теперь операторы, а не инженеры?🎮