☕️ Команды будущего: несколько мыслей

Да здравствует эра дженералистов. Всех специалистов упакуют в скиллы, а дженералисты будут этими скиллами хороводить

Решил сесть осмыслить как AI меняет команды. Надеваю шапку футуролога. Поехали.

1️⃣ Команды станут меньше, но не так, как это любят подавать. Не «увольняем половину, AI справится». А иначе: исчезает не работа, а передача работы между людьми. Раньше она шла цепочкой — один придумал, оформил, передал, другой собрал, третий проверил. Каждая передача требовала отдельного человека просто чтобы её обслуживать. AI убирает передачи. И вместе с ними — роли, которые жили только на этих стыках.

2️⃣ В новом продукте, где сплошная неопределённость, один человек теперь закрывает то, на что раньше нужна была мини-команда. Тот, кто чувствует ценность, сам собирает прототип с агентами. У Y Combinator четверть стартапов последнего набора написала 95% кода с помощью AI — и это уже не магия, а обычная новая практика. Команда на старте сжимается до двух-трёх человек, которые умеют всё понемногу и что-то одно — глубоко.

3️⃣ На зрелом продукте появляется работа, которой раньше не было: следить, чтобы агенты вели себя предсказуемо. Не врали, не роняли прод, делали то, что задумано. Это уже отдельная профессия со своим названием — AgentOPS. Зрелой команде нужен не «больше рук», а человек, который держит надёжность всей этой автоматики.

4️⃣AI — не волшебная палочка, и данные показывают это жёстко. Исследование METR: опытные разработчики с AI делали задачи на 19% медленнее — а были уверены, что ускорились на 20%. Чувствуешь одно, по факту другое. Рядом — снесённая агентом продакшн-база у Replit, утечка данных клиентов у Lovable, оценка, что безопасен лишь каждый второй кусок AI-кода. Вывод не «AI бесполезен», а «контроль никуда не делся». Кто-то в команде всё ещё должен держать качество — иначе долги копятся тихо и всплывают в худший момент.

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

Что с этим делать уже сейчас. Не цепляться за место в процессе — должность, передачу задач, статус. Цепляться за способность: вы либо находите ценность, либо доводите её до работающего и надёжного результата. Осваивать агентов как рабочий инструмент — спокойно, без веры в чудо и без страха.

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

#ai #agents #vibecoding #thoughts

☕️ Четыре репозитория со скиллами для аналитики

Покопался на гитхабе и отобрал четыре репозитория со скиллами под аналитику данных — те, что реально зашли. Мой фаворит — ai-analyst - это просто комбайн, делает всё 🔥

Напомню: скилл — это папка с инструкцией и шаблонами, которую Claude подгружает сам, когда видит подходящую задачу. Один раз кладёте в неё свои правила, метрики и схему — и дальше не объясняете контекст заново в каждом чате.

👀 Ссылки
→ https://github.com/nimrodfisher/data-analytics-skills
→ https://github.com/florianbonnet14/ThePowerOfAnalytics_ClaudeSkills
→ https://github.com/borghei/Claude-Skills/tree/main/data-analytics
→ https://github.com/ai-analyst-lab/ai-analyst

Спойлер: половина пользы — не в самих скиллах, а в файлах references рядом с ними. Положите туда свою схему, метрики и пороги алертов. А ещё лучше попросите Claude адаптировать их под вашу инфру.

#claude #agents #tips #tools

☕️ Агенты как пользователь

Возникла мысль, что продакты должны теперь держать в голове ещё один сегмент пользователей — LLM-агентов. Ладно, не прям отдельный сегмент, скорее агент — это не персона, а режим потребления, вторая поверхность продукта для существующего пользователя.

Идея простая: агенты уже сейчас лезут в наши интерфейсы. Кликают, заполняют формы, дёргают API, оформляют заказы. Делают это коряво и ненадёжно — но делают.
Посмотрел, оказывается, даже термин для этого есть — Agent Experience (AX) и четыре вещи, которые агенту нужны: доступ, контекст, инструменты, оркестрация.
Под это даже стандарты создали — MCP, llms.txt, Agent-to-Agent (A2A) протокол.

Почему важно думать и про агентов? Они не прощают того, что прощает человек. Человек стерпит лаг, додумает кривую формулировку, выкрутится из непонятного дашборда. Агенту нужны машиночитаемость, детерминизм и осмысленные тексты ошибок — чтобы поправить себя без человека. Это приводит нас к необходимости наконец чинить API, доки и данные, на которые годами забивали ради красивого UI.

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

О чем тогда надо подумать в продукте:
— посмотреть логи и user-agent — ходят ли агенты к вам вообще, или пока рано что-то предпринимать
— навести порядок в API и доках: чистый OpenAPI, понятные ошибки, чтобы агент сам себя поправил
— задать границы полномочий: что агенту можно авторизовать без человека, а что — нельзя
— не убирать трение там, где оно защищает пользователя

#agents #thoughts #mcp #ai

☕️ Кем станет аналитик, когда ИИ научился писать 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