LEFT JOIN

⏬ Привет, это Yandex for Analytics Предлагаем размяться и проверить свои навыки. Ответы есть, но подглядывать во время решения — неспортивно ⬇️ 🔵 Задача 1. Вспоминаем теорию вероятностей 🔵 Задача 2. Теорема Байеса 🔵 Задача 3. Базовая база теории игр 🔵 Задача 4. Тренируем SQL 🔵 Задача 5. Честная математическая статистика 🔵 Задача 6. Что-то на бизнесовом 💠 Скоро вернёмся с новыми задачами. А пока делитесь своими решениями в комментариях! Подписывайтесь: 💬 @Yandex4Analytics

Новое техношоу о фейлах на дата-платформах Все упало, все сломалось, бизнес в панике. Для дата-инженеров это обычный вторник, а для шоу «Дропнуто» — повод снять свежий выпуск. «Дропнуто» превращает фейлы дата-платформ в истории, которые полезно услышать каждому, кто работает с данными. В центре каждого эпизода — один герой и одна яркая история фейла, развернутое обсуждение архитектуры и процессов, а также немного самоиронии. Анонсы и ссылки на прямые эфиры появятся в телеграм-боте проекта. Подписывайтесь, чтобы узнавать о премьерах первыми

Anthropic представила Claude Opus 4.5 Да, это очередная новая модель, которая стала еще умнее, чем предшественницы, еще лучше кодит, размышляет, взаимодействует с агентами и так далее. На картинке к посту — данные ключевых бенчмарков, где видно, насколько Claude Opus 4.5 хорош, хотя и уступает в некоторых категориях конкурентам. В чем он точно их превосходит — так это в безопасности: он намного менее склонен к «вызывающему опасения» поведению, чем ChatGPT и Gemini, и лучше защищен от промпт-инъекций. В общем, все как всегда — это все пишут в каждом пресс-релизе, когда выходит новая модель. Из оригинального: 🔵Opus 4.5 оказался слишком умен для некоторых бенчмарков. В τ²-Bench он нашел новое и при этом рабочее решение, которые не было предусмотрено авторами. Из-за этого тест он завалил, но Anthrpoic все равно им гордятся. 🔵У того, что модель получилась такая сообразительная, есть практическая польза для конечного потребителя: она намного эффективнее расходует токены. Opus 4.5 превосходит Sonnet 4.5 и при этом тратит на 76% меньше токенов на те же задачи. 🔵Ну и самое главное — использование Opus 4.5 через Claude API обойдется в $5/$25 за миллион токенов. В общем, новая модель Anthrpoic стала не только умнее, но и доступнее. Ждем теперь, когда очередную новинку, рвущую все бенчмарки, выкатит OpenAI.

Насколько глубоко ИИ на самом деле проник в повседневную жизнь? Ответ можно найти в свежем Viz of the Day на Tableau Public — там собраны последние новости и данные про ИИ в разных сферах. Несколько пунктов оттуда: 🔵В ноябре 2024 объем текстов, написанных ИИ, превысил объем написанных людьми — правда, есть вероятность, что большая часть из них пылится на дне интернета и особого внимания не привлекает. 🔵Написание текстов для рабочих или личных целей — самый популярный запрос пользователей ChatGPT в период с мая 2024 по июнь 2025. 🔵Генерируют не только текстовый контент — в октябре 2025 число запросов к Adobe Firefly, платформе для создания изображений, достигло 29 млрд. Это в 10 раз больше, чем в октябре 2022, когда сервис только запустился. 🔵47% опрошенных пользователей Stack Overflow используют ИИ в работе каждый день, хотя вайб-кодингу 72% сказали твердое нет. Так что каждый раз, когда вы заходите в интернет, читаете статьи, смотрите на картинки или видео, вероятность, что что-то из этого контента окажется творением ИИ, только растет.

Как выбрать MCP-сервер: практическое руководство Итак, вы решили использовать ИИ в работе, но не просто мучить ChatGPT вопросами, а сделать все по науке, через MCP-сервер. Осталось только выбрать, какой вам нужен. Идете в интернет, находите сайт-агрегатор или подборку серверов и видите там сотни вариантов. Если вам нужно подключить ИИ к какому-то популярному инструменту — например, к PostgreSQL, то в поисковой выдаче на вас вывалится несколько страниц результатов. 🔵Чем они все друг от друга отличаются? 🔵Что надо учитывать при выборе? 🔵Какой MCP-сервер лучше — специализированный под узкий спектр задач или универсальный? 🔵А может, вы вообще не знаете пока, что такое MCP-сервера и где они водятся? 🔜 На эти вопросы отвечаем в нашей новой статье на Хабре!

Нейроаналитик DataLens: ваш ключ к данным О чем чаще всего просят аналитиков? «Да просто объясни, что эти данные значат? Что мне с ними делать?» Пользователь хочет увидеть руководство к действию и ответы на свои вопросы, а не сложные дашборды, где еще с фильтрами и гранулярностью надо разбираться. А что, если мы скажем, что уже есть такой помощник, который может сделать данные ближе и понятнее? Это — Нейроаналитик от DataLens. И если вы до сих пор не познакомились с ним — вы упускаете один из самых элегантных способов общаться с вашими цифрами. Как это работает? По-человечески Представьте, что вы можете спросить у системы так же, как спросили бы у коллеги: «Покажи, как изменилась выручка в этом месяце» или «Сравни конверсию по регионам». В ответ Нейроаналитик не просто построит график, а сформулирует выводы и предоставит краткий отчет. Что он умеет? 🔵Отвечать на вопросы текстом. Спросите: «Почему просели продажи в мае?» — и получите готовый анализ с выводами. 🔵Создавать и дорабатывать кастомные визуализации в Editor. 🔵Генерировать сложные вычисляемые поля простым текстом. Просто опишите, какую метрику нужно рассчитать (например, «рентабельность по кампаниям»), и помощник создаст формулу за вас. 🔵Находить скрытые связи. Автоматически сканирует данные и предлагает инсайты, о которых вы могли и не подумать. Важно учитывать, что это не замена аналитикам, а помощник и для дата-специалистов, и для бизнес-заказчиков. Вот, что про это думает основатель LEFT JOIN Николай Валиотти:

Конечно, обычные аналитики никуда не денутся — за кодом, SQL-запросами, дашбордами, всей дата-инфраструктурой и так далее все равно должен стоять человек, который это все контролирует и настраивает. Но сервисы вроде Нейроаналитика и не должны никого заменять. Они нужны для случаев, когда у пользователя есть короткий, конкретный вопрос и он хочет получить короткий, конкретный ответ. Попробуйте Нейроаналитик в действии — задайте свой первый вопрос в DataLens и посмотрите, как просто может быть работа с данными.

Реклама. ООО Яндекс.Облако. ИНН 7704458262

Как когнитивные искажения убили стартап Вы когда-нибудь слышали про приложение Takkle? Скорее всего, нет. Это была американская социальная сеть со спортивным уклоном. Takkle давно схлопнулась, и от нее остались только старые аккаунты в Twitter и на Youtube. Но ее недолгая история довольно любопытна. Что случилось с Takkle, и почему это должно быть интересно? По воспоминаниям бывшего VP по инжинирингу, одна из причин провала — это неудачное решение CTO еще на этапе разработки. Старый СТО уволился, а новый, пришедший ему на смену, сказал, что PHP никуда не годится и надо срочно все переписывать на Perl. Это был опытный специалист с серьезным резюме, который провел анализ, привел аргументы и в итоге всех убедил. 💬 Плюсом перехода стало то, что команда создала действительно выдающийся проект на Perl, которым можно гордиться. Минусами стало то, что им пришлось нанять больше людей в команду, расходы выросли, а разработка затянулась. За это время их главный конкурент, который принадлежит признанной экстремистской организации, окончательно захватил рынок. Хотя Takkle все же запустилась и какое-то время просуществовала, наверстать упущенное она так и не могла. Сейчас сложно судить, какой могла бы быть ее судьба. Может быть, она точно так же канула бы в лету через пару лет, а может, она смогла бы найти свою нишу и вырасти во что-то большее. 💬 Но главное то, что на грабли Takkle компании наступают чаще, чем кажется. Да, не все станут переписывать проект на полпути, но многие дорогостоящие решения важных людей нередко принимаются по наитию, на эмоциях или на хайпу. (Ир)рациональный выбор Решение нового СТО Takkle казалось очень даже рациональным и обоснованным: он проанализировал плюсы и минусы и даже провел презентацию. Но все эти телодвижения нужны было не для того, чтобы реально разобраться в вопросе, а чтобы обосновать уже принятое решение. 💬 То есть СТО и не думал серьезно сравнивать PHP и Perl. Он уже решил, что надо переходить на Perl, и просто хотел перетянуть на свою сторону остальных. Такая преданность ЯП или тулу (например, БД, BI-системе и так далее) у некоторых специалистов превращается в когнитивное искажение. Они уверенны, что их выбор самый лучший и оптимальный, и даже не рассматривают альтернативы. Это мешает принимать решения рационально и может дорого обойтись компании — как это было с Takkle. 💬 Автор пришел к выводу, что надо вообще уходить от обсуждения «какой язык самый лучший» и все переводить в деньги: считать, сколько будет стоить разработка, поддержка, дальнейшее развитие проекта. Кажется, что это мысль очевидная, но практика говорит об обратном. А что вы думаете? Сталкивались с похожими кейсами?

Вайб-кибершпионаж Уже был и вайб-кодинг, и вайб-инжиниринг, а вот теперь — вайб-кибершпионаж с помощью ИИ. Anthropic рассказали про операцию некой преступной группировки из Китая, которая пыталась использовать Claude для атаки на крупные технологические компании, финансовые и государственные учреждения. Злоумышленников уже остановили, а пострадавших оповестили. 🔜 Как проходила операция? Главной задачей для человека было убедить Claude заняться взломом. Чтобы обойти внутренние ограничения ИИ, ему давали небольшие, на первый взгляд безобидные задания, чтобы он «думал», будто участвует в тестировании системы безопасности. Это был первый этап атаки. На втором Clause изучал ИТ-инфраструктуру жертвы, чтобы найти, где хранятся самые ценные данные. Затем он искал слабые места в системе безопасности, собирал логины и пароли, создавал бекдоры. А в конце еще и писал документацию «проекта» с описанием инфраструктуры и украденными доступами. Интересно, что иногда он галлюцинировал и просто выдумывал эти доступы. Все это — с минимальным участием человека:

В целом злоумышленники смогли переложить на ИИ 80–90% всей кампании, участие человека требовались лишь эпизодически (для принятия 4–6 ключевых решений на каждую кампанию).

Современный ИИ достаточно умен, чтобы справляться со сложными техническими задачами, причем, намного быстрее человека. А еще способен действовать как агент практически автономно и получать доступ к различным инструментам через MCP — это все и позволило преступникам свалить на него всю работу. Anthropic заявляют, что из всей операции только небольшой процент атак оказались успешными, но предупреждают, что масштаб подобных операций — и заодно урон — будут только расти. Чтобы обезопасить себя от ИИ-атак, копаниям предлагают вкладываться в ИИ-защиту.

OR или не OR? Представим, что у вас есть большая таблица applications, в которой хранятся данные о заявках пользователей, а также о людях, которые их подают (они указаны в столбце submitter_id) или рассматривают (reviewer_id). Вам нужно посчитать, со сколькими заявками взаимодействовал пользователь — неважно, отправлял или рецензировал. Какой запрос, на ваш взгляд сработает быстрее?

SELECT COUNT(*)
FROM application
WHERE submitter_id = :user_id
   OR reviewer_id  = :user_id;

или

SELECT (
  SELECT COUNT(*) FROM application WHERE reviewer_id  = :user_id
)
+ (
  SELECT COUNT(*) FROM application WHERE submitter_id = :user_id
)
- (
  SELECT COUNT(*) FROM application WHERE submitter_id = :user_id
    AND reviewer_id = :user_id
);

Первый вариант выглядит изящнее, да и логичнее — зачем расписывать сложную конструкцию с подзапросами, когда можно обойтись 4 строками. Но при этом второй запрос выполнится почти в 100 раз быстрее. Пруф. По той же ссылке есть объяснение, почему так получается, но если кратко: 🔵Оператор AND уменьшает выборку данных, а индексы и статистика БД помогают оптимизировать его выполнение. Когда вам нужно отобрать данные по двум условиям, движок ищет сначала ищет записи, где выполняется более редкое условие и затем проходится по второму. 🔵Оператор OR либо последовательно проходится по всем данным в таблице, либо целиком одной колонке, затем по второй, чтобы их объединить. Оба варианта более «дорогие», чем просто просканировать столбец и отфильтровать лишнее Так что если вы замечаете, что запросы с OR слишком долго выполняются, то имеет смысл их переписать — пусть будут не такие красивые, зато более эффективные. Например, для кейсов, как в начале поста автор рекомендует задуматься о создании «дочерней» таблицы:

CREATE TABLE application_user (
  user_id        int8 NOT NULL,
  application_id int8 NOT NULL,
  user_type      enum('submitter','reviewer') NOT NULL
);

И свой изначальный запрос переделать через JOIN:

SELECT * FROM application a
  JOIN application_user au USING (application_id)
WHERE au.user_id = :user_id;

Это все не повод отказываться от использования OR совсем и в любой непонятной ситуации создавать и джойнить новые таблицы. Но особенности этого оператора стоит иметь в виду, особенно, когда вы работаете с большими объемами данными.

Ваш PostgreSQL больше читает или пишет? Одна из причин, почему Postgres так популярен — это его универсальность и гибкость. Мало того, что он прекрасно встроится почти в любой проект, так еще и можно оптимизировать и докрутить под свои запросы, чтобы поднять и без того высокую производительность. Как именно его оптимизировать и докручивать, зависит от совокупности факторов, среди которых — то, каким операциям отдается приоритет: чтению или записи. 💬 Социальные сети, новостные сайты, интернет-магазины, в общем, все, где люди больше листают, чем что-то активно делают — это проекты, где больше приходится читать. Финансовые приложения, системы, которые отслеживают какие-то события на сайте или собирают данные для аналитики — это больше про постоянную запись новой информации в базу. А еще есть смешанные варианты, например, мессенджеры или CRM-системы, где пользователь и запрашивает данные, и вносит их сам со сравнимой частотой. Операции чтения и записи «стоят» неодинаково — вторые дороже, сложнее и дольше. Следовательно, если оптимизировать PostgreSQL под свой проект, то это надо учитывать. 🔵Так, там, где больше чтения, принципиальна скорость, чтобы обеспечить пользователю максимально быстрый доступ к информации, которую он ищет. А это оптимизация индексов, кэширования и «тяжелых» SQLзапросов. 🔵А там, где нужно больше делать новые записи, важнее обеспечить вычислительные мощности, быстрое хранилище и большой объем оперативки, а еще не злоупотреблять индексами. Нашли для вас полезную инструкцию, как разобраться, к какой категории относится ваш проект, и что еще можно сделать с вашим Postgres, чтобы он работал быстрее.

Выпрямитель графиков — незаменимый гаджет для аналитика Описание товара гласит, что «выпрямитель исправляет некорректные графики, вводя пространственную осведомленность в неэвклидовы координаты». Купили бы? Всего-то 173 доллара, между прочим. Это один из товаров сайта anycrap, который «воплощает нереальные вещи в жизнь». Просто вводите любое слово в поисковую строку, и он выдает вам страницу продукта с картинкой, описанием и ценой, сгенерированных ИИ. В бесконечном ИИ-каталоге можно найти что угодно: от абсурдных гаджетов вроде «генератора пердежа» до квантового мусора. Ну, или вообще всего его угодно, что пожелаете. Как-то так мог бы выглядеть маркетплейс из «Рика и Морти» — тем более, что плюмбус там тоже есть.

Сделай сам: БД ключ-значение своими руками База данных нужна, чтобы было куда удобно и компактно сложить данные, а потом — чтобы было где быстро и легко их найти. Звучит логично, но на практике добиться удобства, компактности, быстроты и легкости не так уж и просто. 🔵Как вносить новые данные в файл? 🔵Как изменять или удалять старые? 🔵Как сэкономить место на диске и не дать базе разрастись до неразумных размеров? 🔵Как ускорить поиск, особенно когда количество записей растет? Как только находите ответ на один вопрос, тут же появляются новые. Это хорошо видно на примере статьи про создание БД с нуля: автор начинает с простого файлика с ключами и значениями и, постепенно дорабатывая его, доходит до создания LSM-дерева с индексами и сегментацией. И все это с интерактивным визуалом для наглядности. Отличный материал для тех, кто хочет начать с азов, узнать, какие задачи встают перед создателями БД и как их можно решить.

Новогодняя реклама Coca-Cola опять со вкусом ИИ Хеллоуин отпраздновали (если праздновали) — пора готовиться к Новому году. К тому же, уже подоспела традиционная новогодняя реклама Coca-Cola. Как и в прошлом году, ее сделали с помощью ИИ. На Youtube-канале компании выложили сразу несколько вариантов. К посту прикреплен сокращенный, но есть и еще и минутная версия и ролик о создании. В прошлый раз ИИ-грузовики вызвали неоднозначную реакцию. В этом году картинка однозначно выглядит бодрее, но в комментариях еще все еще ругают за пластмассовость и бездушность. А как вам? Почувствовали новогоднее настроение?

Как выглядит кошмар аналитика В честь Хеллоуина решили обсудить с вами кое-что действительно жуткое — страшнее приведений или клоунов. Плохой SQL. 👻 Потому что приведений не существует, а вот кривой код очень даже реален и иметь с ним дело приходится регулярно. Для затравки нашли для вас целую подборку примеров, среди которых: 🔵нагромождение CASE WHEN, создающее хаос, в котором может разобраться только автор кода (но это не точно), 🔵несколько уровней подзапросов, разобраться в которых не может даже сам автор, 🔵вьюхи поверх вьюх поверх других вьюх — сначала это может быть удобно и красиво, но со временем система рискует стать слишком непонятной, еще и создает нагрузку на базу, 🔵попытки «подчистить» результат запроса с помощью DISTINCT для того, которые прячут проблему вместо того, чтобы ее решать. Встречались с чем-то подобным? Или даже видели что-нибудь похуже? Делитесь в комментариях! 👀

Очистка ИИ-слопа: современные решения современных проблем Что мы все о плохом — ИИ отнимает работу, из-за ИИ компании реже нанимают джунов, списки профессий, которые к (тут вставить какой-нибудь год) уничтожит ИИ и так далее. Он вообще-то еще и создает рабочие места вполне успешно. Современный генеративный ИИ работает быстро, но не очень хорошо. Он действительно может за секунды сделать то, на что люди потратили бы несколько часов или дней: написать текст или код, сделать иллюстрацию или видео. Проблема в том, что тексты у него водянистые и написанные в особом, очень узнаваемом ИИ-стиле, который всем уже приелся. На иллюстрациях и в видео часто встречаются ошибки, хотя рисовать правильное количество пальцев он уже научился. Ну а про качество кода вы наверняка и сами знаете. 🔜 И именно это и привело к появлению новой ниши — очистка ИИ-слопа: так называют низкокачественный контент, сделанный с помощью искусственного интеллекта. Авторы вычитывают и переписывают ИИ-тексты, дизайнеры исправляют картинки, а программисты правят код. Уже даже появился сайт Vibecodefixers.com для поиска специально обученных людей, которые могут навести порядок в чужом вайб-коде. Так что одну дверь ИИ закрывает, но зато открывает другую. Ждет ли нас за этой дверью что-то хорошее — время покажет.

Viz of the Day во всем многообразии Tableau любит показывать возможности своего тула и самые крутые датавизы выставляет на всеобщее обозрение как Viz of the Day, чтобы все смотрели, впечатлялись и вдохновлялись. Эти визы дня бывают кардинально разные: про бизнес, экологию, социальные вопросы, поп-культуру. Визуально они тоже отличаются — от классических лаконичных дашбордов до дизайнерских интерактивных инфографик. Отследить какие-то закономерности в этом разнообразии раньше было не просто, но теперь эта задача стала попроще. Амбассадор Tableau Хидеаки Ямамото собрал данные о 600 последних Viz of the Day и отобразил на инфографике. И вот на ней тренды уже видны: 🔵Большинство авторов Viz of the Day — из США и Англии, а большая часть работ — на английском языке. Есть только одно исключение на португальском. 🔵2 трети работ принадлежат людям, у которых в портфолио уже есть Viz of Day. У рекордсменки из Англии таких работ аж 11 штук. 🔵Самые популярные цвета — синий, голубой, белый и серый. К сожалению, выделить конкретные темы по описаниям, которыми сопровождаются визы, сложно — в основном там на все лады повторяются слова «data», «viz», «explore» и так далее. Так что сказать, на какую тему надо сделать дашборд, чтобы повысить шансы засветиться в категории Viz of the Day, не получится. 😕

dbt 101: что нужно знать на старте и лучшие практики dbt — отличный тул для трансформации данных и заслуженный стандарт индустрии. Мы его часто используем, потому что он сильно упрощает работу на проектах со сложной аналитикой и множеством SQL-скриптов. Кое-что из своего опыта собрали в новой статье. Это не инструкция, как настроить dbt и начать работу, а вводный материал, где мы решили поделиться, а что это вообще такое: зачем нужно, какие функции выполняет, какие задачи решает. Ну и заодно добавили парочку лучших практик, которые хорошо показывают себя на проектах. Кстати, один реальный проект тоже чуть-чуть показали. 🔜 Статья уже на Хабре!

«Мало получить инсайт — надо еще донести его понятным языком» И другие вызовы в работе аналитика в большой компании. В подкасте «Потом доделаю» вышел выпуск как раз для нас с вами: Роман Халкечев, руководитель аналитики Яндекс Поиска и Рекламы, рассказал, как в корпорации работают с данными. Многие компании об этом либо ничего не рассказывают, либо говорят насколько общими фразами, что лучше бы ничего не говорили. Что-то реально интересное и полезное на эту тему — как этот подкаст — появляется не так уж и часто. Про что говорили? 🔵С какими сложностями приходится сталкиваться, как доносить ценность данных до коллег и что делать, если ваши инсайты идут вразрез с решениями бизнеса. 🔵Как ИИ влияет на работу, меняет и продукты Яндекса, и рабочие процессы внутри. 🔵Сколько у него сотрудников в управлении (спойлер: 400), чем все эти люди занимаются и как управлять такой БОЛЬШОЙ командой. 🔵Как в реальности выглядит тот самый data-driven подход, к которому все так стремятся: как принимать решения, когда данных недостаточно (да, и у Яндекса такое бывает) или слишком много. Для аналитиков, дата-инженеров и всех остальных, кто «про данные», в выпуске много прикладных советов, как работать с бизнес-заказчиками и развиваться в профессии. Для тех, кто с данными связан «косвенно» — например, продактов — это возможность взглянуть на «внутреннюю» кухню аналитики и узнать, почему она так часто не дает однозначных ответов на вопросы бизнеса, но прислушиваться к ней все равно надо. 🔜 Слушаем на Яндекс Музыке.

OpenAI представила ChatGPT Atlas Вы никогда не думали, как было бы удобно, если бы кто-то за вас покидал покупки в корзину в онлайн-магазине, а перед этим еще сравнил, чем отличаются два на первый взгляд идентичных товара? Прочитал длинную статью и пересказал содержание? Придумал остроумный ответ в дискуссии в соцсети? В общем, взял на себя эту сложную, нудную задачу сидения в интернете? 🔜 Что ж, если вы пользуетесь Mac’ом (остальным придется подождать), то теперь можете обзавестись таким помощником. OpenAI представила браузер ChatGPT Atlas, с прикрученным к нему ИИ-ассистентом. На картинке выше вы можете увидеть пример задачи для него — выбрать товары для похода на пляж с семьей. Пользователь может ограничить доступ ИИ к отдельным сайтам, попросить сделать саммари написанного на экране или «покопаться» в истории браузера и найти там ссылку, которую посещал ранее. Владельцам платных подписок доступен еще и агентский режим, в котором ИИ может совершать какие-то действия на сайте. Например, не только придумать остроумный ответ, но и отправить его, а потом еще наставить оппоненту дизлайков. Ну что скажете — будете пользоваться Atlas’ом? Или может уже пользуетесь каким-то другими ИИ-браузерами? 👀

Вайб-кодинг против вайб-инжиниринга Все мы уже поняли, что такое «вайб-кодинг» — это человек генерирует код с помощью нейросетей, иногда даже не особо вникая, что они ему там пишут. Код работает, и ладно. Быстро, просто, но результат может быть непредсказуем. Но ведь есть и альтернативный подход — не сваливать на нейросеть всю работу, а использовать ее как помощника. При этом человек все еще руководит процессом и отвечает за качество работы. Получается быстрее, чем все делать руками, уже не так просто, зато за результат не стыдно. Это уже не вайб-кодинг — но что тогда? Есть вариант называть это «вайб-инжиниринг». В чем суть? 🔵Чтобы от ИИ получать реальную пользу (а не только едва жизнеспособный код), надо хорошо разбираться, как он работает, понимать его ограничения и выстраивать процесс. 🔵Под «выстраиванием» процесса мы понимаем использование старых добрых практик, которые применяются в нормальной, «безвайбовой» разработке. Составление грамотного плана работы и документации, настройка автоматических тестов, вдумчивое тестирование вручную, код-ревью — это все помогает не только людям, но и ИИ. 🔵Вайб-инженеру также важно реально оценивать возможности ИИ: что ему можно доверить, а что лучше сделать самому, как корректно поставить задачу и проверить качество выполнения. Человек в каком-то смысле занимает роль лида или менеджера, контролирующего своего ИИ-подчиненного. В общем, слагаемые те же, что при вайб-кодинге, — есть человек, ИИ и какая-то работа, которую этим двоим надо выполнить. Но подход и конечный результат совсем другие. Вопрос только в названии — как вам оно? Как думаете, пойдет «вайб-инжиниринг» в народ?