PRO анализ в ИТ

Вот мне интересно, если у чувака сеньоры скатились до уровня джунов, то насколько они были сеньорами? И что их мотивировало делать свою работу качественнее? Может им просто KPI поставили на количество строк кода и покрытие тестами?) Ну серьезно, как может быть, что нормальный специалист, получив ИИ перестает думать? А вообще я понял, почему люди так не любят ИИ, потому что он пишет код не так как они. И они ему не доверяют. А еще он пишет код правильнее, дада и не поддерживает их говно код и костыли, которые годами никто не трогал.

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

Агент по умолчанию не задаёт уточняющих вопросов. И вот здесь начинается самое интересное. Человек, наткнувшись на дыру в спецификации, скорее всего придёт и спросит, что имелось в виду. Агенту же нужно продолжать работу, поэтому он вполне способен закрыть эту дыру самостоятельно. Молча, правдоподобно и так, что вы заметите принятое за вас решение только на приёмке. Хуже того: в следующем прогоне он может закрыть ту же дыру уже иначе. Есть три места, где я особенно часто вижу такие проблемы. 1. «И так далее». Если список не дописан, агенту приходится решить, что именно скрывается за этими словами. В итоге вы получаете не продолжение своего списка, а вполне логичную интерпретацию модели. 2. Отсутствующие границы. В спецификациях хорошо описывают, что система должна делать, и гораздо реже — чего она делать не должна. Для человека часть этих границ может быть очевидна из контекста. Агент этого контекста не знает и начинает вполне добросовестно достраивать функциональность, которую никто не заказывал. 3. Молчаливые решения. «Тут и так понятно», «мы это обсуждали на встрече», «все знают, почему выбрали именно так». Пока решение живёт в голове команды, для агента его просто не существует. Он примет своё, а через месяц уже никто не вспомнит, откуда вообще взялось текущее поведение системы. Поэтому перед тем, как отдавать спецификацию агенту, я теперь проверяю не только то, что в ней написано, но и то, что агенту придётся додумать самому. Собрал 12 таких мест в один чек-лист. Проверка занимает примерно минуту на пункт — и делать её лучше до того, как агент начал писать код, а не после того, как его интерпретация превратилась в работающую систему. 👉 Чек-лист:https://analystcraft.ru/blog/checklist-spec-dlya-agenta?utm_source=tg_spherical&utm_medium=social&utm_campaign=lm02_checklist&utm_content=20260811-checklist-spec

Отдайте агенту пять документов, из которых два врут, — и он, скорее всего, не скажет вам, какие именно. Он выдаст вполне связный и убедительный ответ. Только внутри окажется всё сразу: актуальная спецификация, вики двухлетней давности и решения из старого POC. Граница между ними исчезнет, и понять, откуда взялся конкретный вывод, станет практически невозможно. Сначала я думал, что это лечится простой инструкцией: «проверяй источники на актуальность». Оказалось, нет. Самое забавное, что модель действительно проверяет. Она может совершенно честно написать: документ A обновлён месяц назад, документ B — два года назад, между ними есть противоречие. А следующим шагом так же честно собрать информацию из обоих в один гладкий ответ. Потому что её попросили ответить на вопрос, а не сохранить неопределённость. У меня сработал другой подход: вообще не задавать основной вопрос, пока источники не разложены на столе. Сначала Source Map: что это за документ, кто его владелец, когда он обновлялся, насколько ему можно доверять и с чем он конфликтует. И только когда эта карта появилась — задавать вопрос по самой задаче. Это скучнее. Добавляет минут двадцать работы и совершенно не похоже на магический AI из красивых демо. Зато противоречия не растворяются в хорошем тексте, а у каждого вывода остаётся основание. Пожалуй, это и есть главное: сначала разобраться, на чём может стоять ответ. И только потом просить AI его дать.

На этой неделе поймал себя на ошибке, за которую обычно ругаю чужие проекты. В одном документе у меня написано 59,7%, в другом — 10 из 10. На первый взгляд кажется, что кто-то ошибся. На самом деле обе цифры правильные. Просто они относятся к разным бенчмаркам, разным метрикам и отвечают на разные вопросы. Когда работаешь с этим каждый день, нужный контекст живёт в голове. Ты автоматически помнишь, что здесь измеряли качество по ролевым сценариям, а там — семантическое соответствие. Кажется, что это очевидно. Перестаёт быть очевидно ровно в тот момент, когда цифра оказывается в статье, презентации или посте. Человек, который открывает только один документ, этой рамки уже не видит. Для него это просто две противоречащие друг другу цифры. Самое смешное, что решение этой проблемы я сам уже несколько лет показываю на докладах. В Source Map есть простая колонка: «С чем спорит этот источник?» Она заставляет явно фиксировать такие вещи. Какие документы противоречат друг другу. Какие метрики нельзя сравнивать напрямую. Какие выводы верны только в рамках конкретного эксперимента. На собственных материалах я эту колонку... не завёл. Похоже, Source Map нужен не только аналитикам. Иногда он нужен и автору Source Map. 😄

Читатель Use Case: дайджест за 3 дня 5 лучших материалов: 1. Fragments: August 4 Коротко: Разбор рисков ИИ: от несанкционированного доступа моделей до признаков пузыря в отрасли. Полезно практикам как напоминание про безопасность, контроль экспериментов и трезвую оценку внедрений. https://martinfowler.com/fragments/2026-08-04.html 2. Пять вопросов, на которые должны отвечать ваши данные, прежде чем с ними начнёт работать ИИ-агент / Хабр Коротко: Материал о том, какие требования к качеству и структуре данных нужны перед запуском ИИ-агента поверх BI. Полезно тем, кто хочет избежать ошибок на старте и подготовить данные к автоматизации ответов. https://habr.com/ru/companies/glowbyte/articles/1066002/?utm_campaign=1066002&utm_source=habrahabr&utm_medium=rss 3. Что реально происходит с ИИ-трансформацией российского бизнеса: семь наблюдений с двух конференций / Хабр Коротко: Сводка повторяющихся выводов с двух конференций о внедрении ИИ в российский бизнес. Полезно практикам, чтобы увидеть, где трансформация уже даёт эффект, а где ожидания пока опережают реальность. https://habr.com/ru/companies/alpinadigital/articles/1066708/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1066708 4. From weeks to minutes: How Formula 1® uses agentic AI on AWS to accelerate data operations | Artificial Intelligence Коротко: Кейс о том, как агентный ИИ ускорил работу с данными и сократил онбординг источников с недель до минут. Полезно тем, кто строит data-платформы и ищет способы автоматизировать рутину и контроль изменений. https://aws.amazon.com/blogs/machine-learning/from-weeks-to-minutes-how-formula-1-uses-agentic-ai-on-aws-to-accelerate-data-operations/ 5. Ассистент или агент: я делал одну контент-машину тремя способами / Хабр Коротко: Сравнение трёх подходов к сборке контент-пайплайна: вручную, в n8n и на Python. Полезно, чтобы выбрать уровень автоматизации под задачу, бюджет и требования к гибкости. https://habr.com/ru/companies/alpinadigital/articles/1066684/?utm_campaign=1066684&utm_source=habrahabr&utm_medium=rss

Новости, что я тут делаю. Во первых пересобрал читателя Use Caseов - теперь он раз в день постит дайджест из 5 статей про анализ, разработку, ИИ и все вокруг этого. Плюс более подробный разбор одной статьи! Подписывайтесь, комментьте, закидывайте ссылки на источники которые добавить. Во-вторых, я активно погрузился в процессы выпуска электронной подписи и делаю собственный прототип для Самсаба на Advnced electronical signature. Использую свой фреймворк Test driven product development на полную катушку с кучей агентов, но тут наткнулся на то, что именно в этом проекте надо жестко упороться в безопасность. И вроде есть куча скилов, которые тестируют твой код на безопасность, проникновения и так далее. Но у меня же другой подход, мы сначала все проектируем, security by design. И вот под это я час пытался найти что то осмысленное, но не шмог. Поэтому встречайте - мой первый публичный скилл для security by design! Буду супер благодарен, если вы его попробуете и дадите комментарии по улучшению!

Одна из самых частых ошибок при работе с LLM выглядит примерно так. Вы просите модель написать код. Потом, не меняя контекст, говорите: «А теперь проверь, всё ли здесь правильно.» Она находит пару мелких замечаний, что-то косметически поправляет и в итоге говорит: «В целом решение корректное.» Честно говоря, было бы странно ожидать другого. Модель не перечитывает код «свежим взглядом». Она продолжает тот же разговор, в котором уже построила гипотезу, что это решение хорошее. Проверка превращается не в независимое ревью, а в продолжение собственной цепочки рассуждений. Я столкнулся с этим, когда гонял локальные модели на собственном харнессе. Я проверял их на десяти сценариях, и долго не мог понять, почему результаты выглядят прилично, а реальной работы почти нет. Ответ оказался неприятно простым. Модель сначала генерировала решение, а потом сама же его подтверждала. После разделения контекстов качество выросло заметно. Теперь одна роль только строит решение и вообще ничего не знает о том, что его потом будут проверять. Вторая получает только готовый результат и задачу его сломать. Без истории диалога, без объяснений, без «я уже думал над этим». Третья вообще работает отдельно — она смотрит только на источники и пытается найти противоречия между ними и тем, что получилось. И здесь, как мне кажется, важен один момент. Это не история про дорогие агентные платформы. Это можно сделать даже тремя отдельными окнами ChatGPT, если у каждого будет своя роль и свой контекст. Чем независимее эти роли друг от друга, тем больше шансов, что одна действительно поймает ошибку другой. Попробуйте вспомнить свою последнюю задачу. Сколько раз вы просили модель проверить то, что она сама только что и написала?

Вы посмотрели открытое занятие 22 июля и до сих пор думаете. Давайте угадаю, что вас держит. «Я и так пользуюсь ChatGPT для требований». Пользуетесь. И скорее всего получаете складный текст, который потом сами же переписываете, потому что модель уверенно придумала половину связей. Интенсив не про то, как формулировать запросы. Он про то, как собрать контекст на входе, чтобы придумывать было нечего, и как проверить результат, не читая его целиком. «Шесть недель, у меня нет столько времени». Занятие раз в неделю, среда, два часа. Между занятиями вы работаете над своей задачей, а не над учебной. То есть время тратится на ту работу, которую вы всё равно делаете, только с разбором. «Вдруг мой проект не подойдёт». Подойдёт почти любой, где есть больше одного источника требований и они противоречат друг другу. Не подойдёт, если задача уже понятная и разложенная, тогда и разбирать нечего. «Это очередной курс про промпты». Курса нет. Есть шесть рабочих сессий, где группа до десяти человек проходит свой проект от карты источников до прототипа и защищает результат. Слайдов минимум, разборов максимум. Кому не стоит идти: если вы хотите готовые формулировки и чек-листы без своей работы. Мы разбираем ваши задачи, а не мои примеры. Это требует времени между занятиями. Сегодня первое рабочее занятие. Места в группе ещё есть. После среды группа уходит в проекты, и вход становится бессмысленным: догонять будет нечем. Кто думал — сейчас последний момент: analystcraft.ru/vibe-analytics Не были на открытом занятии, но тема цепляет? Тоже берём, напишите мне в личку — договоримся, как вам все успеть. Если решите, что не сейчас, следующая группа стартует 9 сентября. Там же можно оставить почту, чтобы не пропустить.

Впервые в истории люди оказываются дешевле софта Аналитики из a16z свели данные по затратам на ИИ в компаниях и нарисовали вот такие интересные картинки. Если кратко, они посчитали, что в топ-1% компаниях распределения расходы на ИИ-токены в расчете на одного сотрудника практически сравнялись с средней годовой зарплатой инженера. При этом за последнее время рост был экспоненциальным, так что при таком векторе развития к концу года инженеры уже будут сильно проигрывать LLMкам в зарплате. Забавно, правда? Нам-то обещали, что будет наоборот. И это речь только про явные затраты. Если копнуть глубже, то оказывается, что помимо затрат на токены ИИ также генерирует множество новых рабочих мест: второй график показывает, что компании с высокой интенсивностью использования ИИ за 2 года после внедрения нарастили штат на +10,2%, тогда как компании с низкими расходами на ИИ остались практически на месте, штат почти не изменился. (Но это всего лишь корреляция, которая может объясняться и другими факторами.) www.a16z.news/p/the-next-ai-goldrush-tokens-loops

Внезапно тут выяснилось, что кожаные все таки дешевле ИИ. Но как мне кажется, проблема в первую очередь в том, что люди не меряют, где ИИ стоит применять, а где нет и пихают его везде и средняя температура по больнице выходит именно вот такой. Да, если полностью писать код ИИ, то он выйдет дороже, чем его писал бы разраб, потому что куча исправлений, недосмотров и багов. Но есть работать в подходе предварительного планирования и грамотного выбора моделей под задачу (под планирование топовые модели, а под обычные код задачи и простенькие), то внезапно можно и 100 баксами в месяц обойтись. Я вот в подмастерьи так и делаю сейчас - компоную маленькие модельки под простые локальные задачи, а сложное можно и в большие ЛЛМ отправлять

Запилил статью на VC про метод TDPD, зацените https://vc.ru/id6010996/3045528-test-driven-product-development-kak-ya-perestal-proveryat-kazhduyu-strochku-za-ai-agentami

Читатель Use Case: дайджест за 3 дня Дата отбора: 2026-07-26 5 лучших материалов: 1. The importance of active listening in the role of a Business Analyst - Requirements Engineering Magazine https://re-magazine.ireb.org/articles/the-importance-of-active-listening-in-the-role-of-a-business-analyst 2. Modernize Java with Cursor and GitLab https://about.gitlab.com/blog/modernize-java-with-cursor-and-gitlab/ 3. Building search-based RAG using Claude, Datasette and Val Town https://simonwillison.net/2024/Jun/21/search-based-rag/#atom-tag 4. RMMi 1.0: A New Maturity Model for Requirements Engineering - Requirements Engineering Magazine https://re-magazine.ireb.org/articles/rmmi-1-0-a-new-maturity-model-for-requirements-engineering 5. Integrating User-Centric Design in Business Analysis - Requirements Engineering Magazine https://re-magazine.ireb.org/articles/integrating-user-centric-design-in-business-analysis Статья дня: The importance of active listening in the role of a Business Analyst - Requirements Engineering Magazine https://re-magazine.ireb.org/articles/the-importance-of-active-listening-in-the-role-of-a-business-analyst Разбор: IREB напоминает очевидное, которое в проектах почему-то регулярно забывают: бизнес-аналитик ценен не тем, что «собирает требования», а тем, что умеет слушать. Сильная мысль статьи — качество требований начинается не с шаблонов, а с качества разговора: перефразирование, уточнение контекста, проверка скрытых допущений. Это особенно актуально сейчас, когда команды тонут не в нехватке инструментов, а в плохой коммуникации между бизнесом и IT. Но статья слишком общая. Она почти не отвечает на практические вопросы: как измерить эффект active listening, где граница между вниманием и затягиванием интервью, что делать, если проблема не в BA, а в конфликте интересов и отсутствии decision rights. Полезный вывод: active listening — это не soft skill «для галочки», а базовая техника снижения риска в requirements engineering. Но без конкретных практик и организационного контекста это остаётся красивым советом, а не методикой. Источник: https://re-magazine.ireb.org/articles/the-importance-of-active-listening-in-the-role-of-a-business-analyst

А еще я потихоньку оживляю Читателя юз кейсов с обзорами на статьи. Подключил 8 источников, планирую добавлять, ну а если вы знаете где еще живут хорошие статьи - пишите в комментах

В глоссарии вышла четвёртая страница метода — Task Pack. Это финальный артефакт цикла: source map → System Context Pack → Review Findings → Task Pack. Заготовка постановки, которая в отличие от финального ТЗ сохраняет открытые вопросы и трассируемость до источников: каждое требование — с цитатой, каждое «мы не уверены» — явно. Чем Task Pack отличается от ТЗ и SDD, что внутри и как он живёт дольше самого ТЗ: https://analystcraft.ru/blog/glossary/task-pack Теперь весь метод описан в глоссарии — все четыре артефакта со ссылками друг на друга.

Первое занятие второго потока — готово. 🔥 Вчера провели первое, открытое занятие интенсива. Если не успели присоединиться — запись уже доступна, очень рекомендую посмотреть. Не обошлось без маленького факапа: запись почему-то не стартовала автоматически, поэтому самое начало пришлось запускать вручную. К счастью, потеряли буквально несколько первых минут, а дальше всё прошло именно так, как хотелось. Что особенно понравилось — атмосфера. Вместо того чтобы просто слушать лекцию, большинство ребят пришли со своими задачами. Мы разбирали не абстрактные примеры, а реальные рабочие кейсы, вокруг которых и будет строиться весь интенсив. Сейчас каждый уже выбирает проект, с которым будет работать ближайшие шесть недель. И, пожалуй, главным открытием для меня стали сами модели. Ещё буквально пару месяцев назад LLM очень плохо справлялись с поиском противоречий в нескольких формализованных источниках. Если дать им PDF, Confluence, API-контракт и переписку, они скорее сглаживали различия, чем честно показывали конфликты. Сегодня ситуация уже совсем другая. И ChatGPT, и неожиданно Kimi 2.6 начали довольно уверенно находить расхождения между источниками. Пока это не идеальный уровень, но прогресс оказался настолько заметным, что я прямо по ходу курса решил немного изменить программу. Теперь меньше времени будем тратить на разговоры о том, какую нейросеть выбрать и как написать идеальный промпт. Гораздо интереснее научиться правильно собирать контекст проекта. Потому что именно от качества контекста сегодня всё сильнее зависит качество результата. Если честно, это даже хорошая новость. Значит, роль аналитика всё больше смещается от «оператора нейросети» к человеку, который умеет собрать правильные источники, поставить правильную задачу и принять правильное инженерное решение. Именно этому и будем учиться дальше. Если всё ещё думаете, присоединяться или нет — запись первого занятия уже доступна (Ютуб, Рутуб). Пока ещё можно спокойно влиться в поток без ощущения, что вы что-то пропустили. 🚀

А я напомню, что открытое занятие через полчаса. Еще можно зарегистрироваться и запрыгнуть на занятие - абсолютно бесплатно! https://analystcraft.ru/vibe-analytics#open-session