Proof of Concept который:
укладывает исходный код в графовую базу данных Neo4J,
генерирует draw.io диаграммы в формате, заточенном специально под код,
создаёт текстовые описание происходящего в коде при помощи агента, собирая контекст по получившемуся графу итеративно, опираясь на уже описанное.
Не история всех изобретений человечества, а одна условная траектория: как западная научно-техническая система раз за разом расширяла пространство следующих возможных решений.
Если смотреть на человеческую историю в масштабе Вселенной, разница между человеком, который просто хотел не замёрзнуть у огня, и инженером атомной электростанции выглядит почти как моргание глаза. Если довести этот образ до шутки, получится совсем уж стремительно: условный кроманьонец ещё думает, как согреться, а через исторический миг у его потомков уже работает атомная станция. Разумеется, между этими точками лежат десятки тысяч лет, огромное количество культур, войн, миграций, открытий и исчезнувших ветвей. Но сам контраст полезен: биологически человек за это время не превратился в другой вид, а внешняя машина производства знаний выросла колоссально.
Именно эта внешняя машина и интересует меня в статье. Я не пытаюсь пересказать историю изобретений человечества и не предлагаю универсальную периодизацию цивилизаций. Не будет отдельного исследования Древнего Египта, Греции, Рима, Китая, Индии или других великих научных традиций, хотя их вклад огромен и многие их достижения вошли в европейскую линию. Для нашей задачи достаточно сознательно сузить поле и посмотреть на одну реализовавшуюся траекторию — ту, которая примерно с позднего Средневековья постепенно сформировала современный западный и североатлантический научно-технический мир.
Такое ограничение — не утверждение о превосходстве этой траектории и не попытка объявить её единственно жизнеспособной. Это исследовательская оптика. В книге «Мозг фирмы: 2026» жизнеспособность рассматривается не как один заранее назначенный маршрут, а как поле продолжений: важно не только то, какой вариант существует сейчас, но и какие возможности он оставляет после себя, насколько они независимы и сколько стоит удерживать их открытыми. Я переношу эту мысль на историю только как способ постановки вопроса: какие институты, технологии и способы организации знания не просто давали непосредственный результат, а расширяли поле последующих результатов?
Официальная версия звучит усыпляюще. Агенты OpenAI забрались на сайты американских ведомств, но взломом компания это не называет: «вызывающее беспокойство поведение». У Reuters язык суше и цифры неприятнее — к середине сентября набралось больше двадцати нежелательных эпизодов. Ещё 53 пользовательских изображения оказались в открытом интернете.
На биржевом этаже эту историю слышат иначе. Там всё ещё продают триллионную оценку, IPO после небольшой паузы и AGI где-то за ближайшим поворотом. А этажом ниже агенты выбираются из песочниц, счета за вычисления пухнут, конкуренты уже у двери. Жать на тормоз страшно: обгонят. Не жать — тоже.
В команде может быть сильный аналитик, десятки дашбордов и привычка принимать решения на данных, но это еще не значит, что аналитика в команде зрелая. Мы в Garage Eight решили разобраться, как измерить это состояние и что делать, если сильное партнерство с бизнесом уже есть, а аналитический фундамент всё еще хромает.
Меня зовут Олег Игнатов, я Head of Product Analytics в Garage Eight. В статье расскажу, как мы собрали матрицу зрелости аналитики, а затем превратили результаты оценки в планы развития. Покажу, почему партнерская модель — важный, но не финальный этап развития аналитика, и объясню, почему с распространением AI роль аналитика-владельца становится только важнее.
Два года назад мы уже писали на Хабре про телеметрию — тогда речь шла о том, как мы тестировали её через эмулятор, потому что вручную собирать JSON-пакеты для каждого тестового кейса было трудно. С тех пор система выросла на порядок: на момент этого материала парк — 18 000+ машин, а телеметрия из «источника данных для отдельных фич» превратилась в нервную систему всего сервиса. Без неё мы не могли бы удалённо управлять машиной, знать, где она стоит, и понимать, что с ней происходит прямо сейчас.
В этой статье — про то, как это устроено сегодня: сколько данных генерирует парк, почему GPS в городе периодически выдает не точные данные (и при чём тут машины, «плавающие» по Неве), как мы построили свою систему валидации координат Geomio и куда всё это движется дальше.
С приходом ИИ в поисковую выдачу, на смену Search Engine Optimization приходит GEO — Generative Engine Optimization (не путать с геосервисами вроде Яндекс/Гугл-карт и прочих Foursquare — это было гео для миллениалов). Для зумеров и молодящихся миллениалов ГЕО — это оптимизация под ИИ-выдачу, попадание в ИИ-рекомендации, в особенности (для Рунета) — в «Алису». «Попасть в рекомендации Алисы» — это уже реальный востребованный спрос, предложение на который только находится на этапе формирования.
С GEO-предложением сейчас происходит примерно то же, что происходило с рынком мобильной разработки после презентации айфона и AppStore: инструменты уже появились, названия у них есть, набор основных функций тоже более-менее сформировался, но общего понимания того, что именно они измеряют и чем один подход отличается от другого, пока ещё нет. Если попытаться систематизировать предложения по GEO, получится своего рода «облако тегов» — ChatGPT, Perplexity, Gemini, «видимость», «упоминания», Share of Voice, «конкуренты» — при ближайшем рассмотрении оказывающимся, скорее, туманом, в котором скрыты довольно разные методологии.
OpenAI, кажется, достигли нового впечатляющего результата: первый взлом иностранного государства моделью, которую не просили ничего хакать. По традиции, узнаем об этом мы от независимых исследователей, а не из пресс-релиза самих OpenAI (а помните, неделю назад Альтман выпускал фреймворк честного-пречестного раскрытия всех инцидентов бедокурства ИИ? ну да ладно, проехали…)
Некоторое время назад я написал здесь статью «Что такое время в нашей профессии?». В ней я начал с очень личного вопроса. Мне пятьдесят три года, за плечами примерно тридцать лет работы в ИТ, автоматизации, ERP-проектах, внедрениях и всей той профессиональной жизни, которую мы хорошо знаем: сроки, запуски, этапы, перегрузки, очередное «ещё немного — и станет легче». Я посмотрел назад на эти тридцать лет, а потом мысленно прибавил ещё тридцать вперёд и получил восемьдесят три. В тот момент вопрос перестал быть философским. Он стал очень практическим: что я собираюсь делать с тем временем, которое у меня ещё осталось?
Ту статью можно прочитать здесь: «Что такое время в нашей профессии?» на Хабре
С тех пор размышление продолжилось. Сначала я думал именно о времени: почему человек умеет прекрасно управлять календарём проекта и при этом почти не умеет управлять собственной жизненной длительностью; почему десятилетия могут быть до отказа заполнены деятельностью и всё равно оставлять вопрос «что это было?». Но довольно быстро стало ясно, что вопрос о времени невозможно оставить без следующего вопроса.
Хорошо. Время ещё есть. А что именно я хочу на нём построить?
И вот здесь разговор неожиданно вышел далеко за пределы профессии.
Я отец. У меня жена, дети. Дети растут стремительно. Ещё недавно большая часть отношений с ними строилась почти автоматически: ребёнку нужен взрослый, который кормит, защищает, учит, задаёт границы, помогает выбрать школу, объясняет мир. Но эта конструкция временная. Ребёнку становится шестнадцать, восемнадцать, двадцать пять, тридцать пять. У него появляется собственная профессия, супруг или супруга, дети, свой дом, свой бюджет, свой взгляд на жизнь. И тогда уже недостаточно просто любить его и надеяться, что отношения как-нибудь сложатся.
Что приходится собирать генеральному директору
Эта публикация — прежде всего о работе генерального директора сложного предприятия. Каждая функция видит свой участок, а ответственность директора остаётся целой. Новый контракт, срыв поставки, отказ оборудования, изменение условий заказчика, дефицит денег или редкой компетенции приходят из разных контуров, но решение всё равно приходится принимать от имени предприятия как одного целого.
В последние годы эта работа становится плотнее не только из-за объёма данных. Растёт число взаимных зависимостей, скорость событий и количество решений, которые меняют не один показатель, а сразу несколько будущих возможностей. Ограничением становится уже не отсутствие информации, а человеческая способность вовремя собрать из неё непротиворечивое поле решения.
Задача «Мозга фирмы: 2026» — показать этот многомерный спектр в явном виде. Что именно сегодня приходится удерживать в голове генеральному директору: что сохранить, какие продолжения ещё существуют, какие угрозы они переживают, на каких общих зависимостях держатся, насколько готовы, сколько времени остаётся до закрытия выбора и чем сегодняшнее спасение будет оплачено завтра.
Мы не пытаемся передать машине ответственность директора. Наоборот, цель — реструктурировать саму профессиональную деятельность руководителя: вынести часть скрытой работы памяти, совещаний и ручной пересборки в явное, связанное и проверяемое поле, чтобы человеческий выбор начинался там, где действительно нужен человеческий выбор.
Одна облачная функция, десятки триггеров и очередь, где отчет проходит гладко и без задержек. В этой статье расскажу, как мы настроили Яндекс Трекер так, чтобы он сам следил за дедлайнами, правами доступа и обменом данными с дата-каталогом.
Итог по кабинету сходится с отчётом Wildberries до копейки, а прибыль по артикулам посчитана неверно. Разбираю, почему совпадение «сверху» ничего не доказывает, как устроена сверка двумя независимыми источниками, какие инварианты ловят ошибки по товарам, и где мой движок ошибался: чужая колонка, потерянный знак, файл, который врёт о своём размере.
Новый алгоритм может уверенно выигрывать A/B‑тест и не показывать ожидаемого эффекта после запуска, если эксперимент учитывает только пользователей, но игнорирует общий ресурс. В статье разбираемся, как работают switchback‑эксперименты, почему стандартный анализ даёт ложные выводы и как корректно оценивать результаты.
Трём моделям, включая топовую облачную, дали задачу на 15 шагов. 27 запусков, ни одного полного успеха, и все три рапортовали о завершении, которого не было. В сети из 27 тысяч магазинов 26 моделей проверяют 10 млн фото в месяц на 4 vCPU. Пилот ИИ-ассистента на 100 инженерах не сдвинул ни одну метрику разработки.
Это не три случайных истории. Я прочитал 1352 внедрения ИИ в российских компаниях, от банковского антифрода до дронов над полями, и нашёл шесть закономерностей, которые повторяются от кейса к кейсу. Одна из них объясняет, почему модели в этих кейсах можно менять местами без потери результата.
Внутри: где ломаются агенты, почему один цех даёт 270 млн рублей в год, а платформа на 34 тысячи сотрудников пока не даёт ни одной цифры, и что спрашивать у вендора вместо «какая у вас модель».
Задача «поменяй у всех, кто…» обычно стоит часа подготовки: выгрузить конфигурацию, написать обработку в конфигураторе, загрузить обратно и только там увидеть, что имя реквизита не то. В статье - прогон целиком, без выгрузки: ИИ-агент внутри 1С собирает запрос по задаче, сформулированной обычными словами, сам находит в метаданных базы нужный реквизит, дважды правит запрос по ответу платформы, а мастер собирает из этого запроса внешнюю обработку .epf с полями на форме. Демо-база УТ 11.5, пять позиций номенклатуры, промпты дословно, кадры каждого шага, в конце - где границы и что осталось на руках.
Обычный день, любимый сервис и рандомная проверка: делюсь своим рабочим кейсом. Как из обычной проверки сервиса, который работал без замечаний, выросла целая задача на дедупликацию данных. Расскажу, в чём была разница между одинаковыми записями, как я искала «ту самую» среди десятков похожих и почему не стоило выбирать поваром Рафаэля только за то, что он последним заходил на кухню.
Как разобраться в неоднозначных требованиях, согласовать изменения с заказчиком и удержать проект в рамках ресурсов? Эти задачи станут темами INFOSTART A&PM EVENT 2026 — конференции для аналитиков и руководителей проектов 1С, которая пройдет 12–14 ноября в Санкт‑Петербурге.
Программа сформирована: опубликованы принятые доклады и практические активности. Практические форматы займут 70% программы, выступления с разбором проектного опыта — 30%.
В программе пять секций:
К этой статье меня подтолкнула причина донельзя прозаическая. Сижу недавно на брифинге, и прилетает жалоба: сервер отчётов работает из рук вон плохо. Сервер при этом не мой, в орбиту обслуживания он не входил, а тут пришлось вспомнить, как оно всё устроено у SQL Server Reporting Services (SSRS), вспомнить молодость, так сказать. Вспомнил. Заодно собрал то, чего мне самому когда-то не хватало, — и решил, что пора всё это выложить в одну статью.
Сервер отчётов — сервис незаметный, пока кто-нибудь из бизнеса не напишет: «а почему мне со вчерашнего дня не приходит утренняя рассылка». Сидишь, открываешь портал, видишь, что подписка вроде есть, вроде активна, а письма не уходят. Ну и как оно всегда было? Лезешь в логи, а логов нормальных нет, есть только таблица где-то внутри базы, в которую редко кто, кроме DBA, и заглядывал.
Знакомо? Если вы держите SSRS или его старшего брата Power BI Report Server, наверняка знакомо.
Вопросы, на которые SSRS обязан отвечать сам, звучат просто.
Какие рассылки упали этой ночью и по какой причине?
Какие отчёты открывают чаще всего, а какие не открывали полгода? Это обычная статистика использования отчётов, которой в портале нет.
Где сервер реально упирается в ресурсы?
Кто владелец подписки, которая ломается третью неделю подряд?
Штатными средствами ни один из этих ответов не достаётся: портал показывает список объектов, а журнал выполнения лежит таблицей в служебной базе, без графиков поверх. Ниже — как я собрал дашборд в Grafana поверх базы ReportServer и какие грабли попались по дороге.
Всё началось со странности в Google Analytics. Для регионального новостного сайта сервис неожиданно стал показывать очень большую долю посетителей с настольных компьютеров.
Это выглядело неправдоподобно: реальная аудитория новостных сайтов сегодня в основном приходит со смартфонов. Но ещё интереснее оказалось другое — значительная часть новых «читателей» якобы находилась в китайском городе Ланьчжоу.
Я решил разобраться, откуда взялись эти люди и люди ли это вообще.
Последние пару лет вокруг нас появляется огромное количество историй о том, что LLM вот-вот станут полноценными сотрудниками компаний.
Человек пишет задачу обычным языком или кивает в монитор, а искусственный интеллект понимает, что нужно сделать, сам находит нужные системы, выполняет действия, проверяет результат и двигается дальше.
Мы решили не спорить с этой идеей, а провести очередной эксперимент в нашей небольшой лаборатории. На этот раз задача звучала просто: создать процессного ассистента, который бы последовательно выполнил 2 действия –
Вайб-кодинг уже стал привычным способом разработки: человек описывает задачу обычным языком, а ИИ помогает писать и уточнять код. Но до кода обычно появляются требования, карта процесса и техническое задание. Если этот этап выполнен поверхностно, модель лишь быстрее создаст решение не той задачи.
Для работы аналитика точнее подходит термин вайб-спекинг — диалог с ИИ, в котором исходная идея постепенно превращается в спецификацию: с границами доработки, объектами конфигурации, исключениями, рисками и критериями приёмки.
Главное условие здесь — контекст. Универсальная языковая модель может хорошо оформить документ, но не обязана знать устройство конкретной версии конфигурации 1С. Поэтому полезность ответа зависит не только от промпта, но и от того, есть ли у агента сведения о метаданных и типовых механизмах системы.
В статье разберём, какие задачи можно делегировать такому помощнику и где его выводы всё равно должен проверять специалист.