☕️ Кем станет аналитик, когда ИИ научился писать SQL

Сейчас модно рассуждать на тему того, как кого-то заменит ИИ. Решил посмотреть на роль аналитиков - так как они являются основными пользователями моих продуктов.

Начнем с главного — заменят не аналитика — заменят кусок работы: накидать черновик запроса, собрать табличку, поймать аномалию глазами, нарисовать первый график. Это ИИ уже делает быстрее аналитиков.

Но профессия от этого не исчезает. У неё смещается центр тяжести.

Раньше единицей работы был ответ на вопрос. Теперь — система, которая отвечает на вопросы сама.

Вот как это выглядит на практике. Сегодня к аналитику приходят с «почему просела конверсия?», он лезет в данные, считает, объясняет. Завтра первым на этот вопрос ответит ассистент. И работа аналитиков будет — не ответить, а сделать так, чтобы ИИ ответил правильно: взял ту метрику, что нужно, не перепутал корреляцию с причиной, честно показал ограничения и сам поднял руку, когда вопрос слишком рискованный для автоответа.

Аналитик перестанет быть тем, кто отвечает на каждый вопрос. Он станет тем, кто проектирует смысл: как считается метрика, что такое «активный пользователь», какие разрезы вообще допустимы, где проходит граница между «ИИ ответит сам» и «тут нужен человек».

Как, по-моему, будет выглядеть рабочий день:

— не «закрыть 10 ad hoc-запросов», а посмотреть, на чём ассистент путается, и починить это в корне
— не «сделать ещё один разрез по просьбе бизнеса», а превратить повторяющийся вопрос в готовый сценарий, который дальше крутится без вас
— не «построить дашборд», а владеть определениями метрик так, чтобы человек, дашборд и ИИ понимали их одинаково

И вот тут интересное. Чем дешевле сгенерировать ответ, тем дороже за него отвечать. Раньше кривую цифру видел один заказчик. Теперь кривую трактовку ассистент разошлёт сразу сотне людей. Поэтому самый ценный навык — не «написать запрос», а «понять, что ответ неверный, хотя выглядит он чертовски убедительно».

Что из этого следует:
— SQL не умирает, меняется вопрос на собесе. Было: «умеешь писать?». Стало: «умеешь увидеть, где ИИ написал ерунду?»
— дорожают не технические скиллы, а постановка правильного вопроса, проектирование метрик, причинно-следственное мышление и умение довести анализ до решения, а не до графика
— появляются новые роли: владелец метрик, куратор качества ответов ассистента, decision partner — тот, кто помогает бизнесу не «посмотреть данные», а выбрать действие и проверить, что из него вышло

Аналитик будущего меньше похож на того, кто выдаёт отчёты по запросу, и больше — на того, кто строит и поддерживает доверие к данным. ИИ забирает скорость и черновики. За человеком остаётся смысл, проверка и ответственность за решение.

И это, честно говоря, работа поинтереснее, чем десятая выгрузка за день.

#thoughts #ai #llm

☕️ От вайбкодинга к agentic engineering

А вот и подтверждение к мыслям из предыдущего поста. Google опубликовали интересный whitepaper — «The New SDLC With Vibe Coding» про то, как меняется разработка, когда код пишет агент, а не человек.

В доке ребята обсуждают вайбкодинг и agentic engineering — говорят, что это не две альтернативы, а два конца одного спектра. Разница между ними в том, насколько строго вы проверяете и контролируете то, что он выдаёт — сколько вокруг его работы структуры, тестов и вашего собственного мыслетоплива.

Главный различитель — как проверяется результат. В вайбкодинге проверка опциональна: запустил, вроде работает, поехали. В agentic engineering работают две проверки разом. Тесты — это про всё детерминированное: то что легко проверить кодом — чтобы одинаковый вход всегда давал одинаковый выход. Evals — проверяют то, что заранее не предскажешь: правильным ли путём агент шёл, те ли инструменты выбрал, и достаточно ли качественный получился ответ. Нет обоих — это всё ещё вайбкодинг, какими бы умными ни были промпты.

Что зацепило больше всего и что натолкнуло на мысль "вот оно подтверждение тезисов поста":

— Context engineering, а не prompt engineering. Качество кода зависит не от хитрости промпта, а от качества контекста. Модели не нужны хитрые формулировки — им нужен тот же контекст, что и новому коллеге в команде.

— Agent = Model + Harness. Около 90% поведения агента определяет не модель, а «обвязка» (тот самый harness) вокруг неё: инструкции, тулзы, песочницы, guardrails. Когда агент косячит, первый инстинкт — винить модель. Чаще это отсутствующая тула, размытое правило или контекст, забитый шумом. Большинство провалов агентов — это провалы конфигурации.

— Экономика. Вайбкодинг = низкий CapEx, высокий OpEx: жжёшь токены в бесконечных циклах «почини свою же ошибку», плюс потом налог на поддержку спагетти-кода. Agentic engineering — наоборот: вложился в систему один раз, дальше дёшево масштабируешь.

Ну и дальше ребята пишут о том, о чем мы уже говорили:
— заведите AGENTS.md для проекта: стек, конвенции, жёсткие правила. Добавляйте новое правило каждый раз, когда агент делает то, что не должен
— пишите тесты и evals до генерации кода — это и есть контракт с AI
— ревьюйте каждую строку, которая идёт в прод. Особенно ту, что выглядит «умно»

Главная мысль: генерировать агенты научились. Новое ремесло — это верификация, валидация и направление агента в нужное русло.

#ai #agents #vibecoding #thoughts

☕️ CodexBar — лимиты AI-инструментов прямо в меню баре

Антропики недавно меня забанили, пришлось перейти на Codex. Начал искать аналог Usage Tracking, и нашёл - называется CodexBar - показывает остатки лимитов и время до их сброса. И самое главное - не только Codex'а, можно настроить и для Claude и для Cursor и др.

Что умеет:
— Отслеживает лимиты сессии, недели и месяца
— Поддерживает 60+ провайдеров: Codex, Claude, Cursor, Gemini, Copilot, OpenRouter и другие
— Показывает баланс кредитов, расходы и статистику токенов — где это доступно
— Предупреждает о сбоях и деградации сервисов
— Добавляет виджеты с лимитами и графиками на рабочий стол
— Работает и через CLI — удобно для терминала, скриптов и CI

Приложение бесплатное и с открытым исходным кодом, работает на macOS 14+. Оно использует уже существующие сессии OAuth, CLI, API-ключи или cookies и не хранит пароли.

Установка через Homebrew:
brew install --cask steipete/tap/codexbar

Или можно скачать приложение с GitHub.

#tools #ai #codex

☕️ Loop Engineering: что за новый термин

В последнее время все носятся с Loop Engineering как с писаной торбой. Особенно активно его стали обсуждать после фразы Бориса Черного, создателя Claude Code: он больше не пишет промпты — вместо этого пишет лупы, которые сами промптят Claude.

Попробовал разобраться что это и как работает. Вышло вот что.

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

Обычно работа выглядит так: попросили агента собрать отчёт, прочитали, заметили пропущенный раздел, попросили исправить, нашли странную цифру, снова отправили на доработку. Получается цикл, но управляет им человек.

А теперь соберём этот процесс в луп.

В понедельник в 9:00 расписание запускает агента. Он забирает данные и готовит черновик. Затем отдельная проверка смотрит, все ли разделы заполнены, сходятся ли цифры и есть ли ссылки на источники.

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

Всё сошлось — черновик уходит человеку на согласование. Три попытки не помогли — луп останавливается и тоже зовёт человека.

Вот, собственно, и весь Loop Engineering:

триггер → работа агента → проверка → исправление → новая проверка → готово или нужен человек.

Сам луп в коде может быть совсем небольшим. Внутри проекта это часто четыре артефакта:
— инструкция для агента,
— запускающий сценарий (в сценарии также задают лимит повторов и условия остановки),
— проверка результата и
— файл состояния с попытками и ошибками.

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

Для разработчиков идея знакомая: сначала задаём автоматическую проверку (тесты), а затем исправляем результат, пока она не пройдёт. Только теперь таким результатом может быть не только код, но и отчёт, презентация, разбор отзывов или проект ответа клиенту.

Какой бы луп собрать первым? Лучше на начинать с лупа «самостоятельно улучшай весь мой бизнес». Хороший первый кандидат гораздо проще, он должен удовлетворять критериям:
— задача регулярно повторяется;
— у неё есть понятный момент запуска;
— результат можно проверить по конкретным правилам;
— неудачную попытку легко отменить;
— перед важным действием можно поставить согласование человека.

Например, луп может разбирать записи встреч и искать потерянные задачи, проверять счета перед оплатой, собирать отзывы клиентов по темам или готовить пост вместе с фактчеком.

Итого, loop Engineering стоит понимать так: мы проектируем уже не один удачный запрос к агенту, а небольшой воспроизводимый процесс вокруг него. Агент может самостоятельно пройти несколько итераций, но цель, ограничения и финальное решение всё ещё остаются за человеком.

Как начать?
Если хочется попробовать Loop Engineering руками, можно начать с репозитория cobusgreyling/loop-engineering. Там есть готовые шаблоны лупов для Codex, Claude Code и других инструментов.

#ai #agents #thoughts