Провокационный заголовок для привлечения внимания.
Разбавлю свои полуконспекты историями из жизни.
За эту неделю произошли со мной вещи, которые меня заинтересовали и их можно напрямую связать с заголовком настоящего поста.
итак.
начать надо с того, что у нас в компании начали раскатывать гигачатковоркинг для внутреннего использования. сначала давали точечно доступ по запросу, а теперь раскатили на всех. Но естественно с оговорками, чтобы не сливали документы, конф инфу, перс данные. чтобы потом не попасть в новости.
меня это событие заинтересовало с той стороны, что это уже не бесплатная сетка, а размышляющая модель с возможностью в нее добавлять документы, и даже целые папки с документами. что есть хорошо. угадайте какие файлы я начал скармливать сетке 
ну и начал с ним экспериментировать над своими рабочими проектами и задачами. у него конечно, своеобразный характер, и у авторов свое видение как надо строить интерфейс с LLM. к каждой нейронке надо привыкать - к характеру, стилю выдачи, способу взаимодействия.
ну так вот.
случай 1:
из нейронки получилось получить несколько рабочих артефактов, связанных с архитектурой решений, и буквально сегодня (28-08-2026) решал задачу связанную с сравнением сценариев внедрения системы. топ-менеджменту надо обосновать вопрос миграции в ситуации неопределенности. надо объяснить почему компании выгодно сейчас потратить Х миллионов рублей на проект миграции. и какой из 5 возможных сценариев в текущей неопределенности наиболее оптимальный.
на выходе был получен документ с реестром сценариев, описанием особенностей. матрицами сравнения сценариев по разным критериям. и в конце обоснование почему конкретный сценарий считается в исходных условиях наиболее предпочтительным. дополнительно сделал калькулятор на экселях, для получения более точных данных о стоимости владения каждым решением в контексте каждого сценария в окне времени на 2 года. отдельный калькулятор вытащил потому что те расчеты которые были предложены показались построенными на устаревших данных. а так будет возможность получить актуальные данные для принятия решения.
судьба документа пока до конца не понятна, так как итоговый вариант (который меня устроил) я получил уже за границей рабочего дня, но коллегам его по почте направил. на следующей неделе ожидаю что на основе этого документа руководству будут предложены обоснования (аргументированные!) про то, каки путем следует двигаться дальше.
но в этой истории меня не сам артефакт порадовал, а путь его получения.
я уловил тот самый вайб architect-вижна, когда ты в голове легко и непринужденно оперируешь масштабами времени 1+ год, 2+ года, думаешь о том как 2 системы будут стыковаться мостом, какие есть + и - у каждого решения. что будет если резко перестанут финансировать проект. какое решение вообще оптимально взять если есть риск прекращения финансирования. а какое решение лучше взять под будущую реорганизацию с присоединяем. далее как меняются риски. что будет если случится внезапная смерть системы (система старая, никто не может сказать сколько она еще протянет). и в каком сценарии деньги на проект будут потеряны, а в каком случае затраты будут оправданы.
и я отметил легкость и естественность таких размышлений про системы. даже понравилось. действительно не уровень “нарисуй мне эпическую битву славян против космических ящеров”.
с каждым запросом у уточнением размеры матриц сравнения становились все больше и больше.
случай 2:
пользователи обратились с запросом дать доступ к функционалу распределения заявок на закупку. это потенциально опасная функция так как она может по неосторожности сломать данные других пользователей. и это уровень минимум руководителя отдела закупок.
но из-за особенностей устройства нашего холдинга так получилось что пользователям из другой компании эта функция нужна чтобы самостоятельно управлять своими закупками, а не зависеть от специалистов материнской компании. для простоты так опишу.
мне рассказывают всю эту историю про такие сложные взаимоотношения. я понимаю, что парни дело говорят, но с т.з. бизнеса разрешение на такой доступ должен давать держатель процесса - директор по закупкам материнской компании. так скажем. я как админ не могут открыть доступ без такого согласования.
я предлагаю пойти по пути, когда я помогаю составить ADR-ку на основании описания текущей ситуации. описываю все аргументы, все + такого решения, потенциальные риски, ограничение и административные меры которые необходимо будет принять для того чтобы новая схема корректно работала и была защищена, в случае ее одобрения. получается на выходе документ.
сегодня в него заказчик внес свои предложения и уточнения. далее - он должен будет оформить оф запрос на директора головной компании и приложить ADR в качестве обоснования.
далее, если будет получено согласие, то мы пойдем по пути открытия доступа к функционалу, а если согласия не будет, то в жизни заказчика ничего не поменяется. но мы хотя бы попытались решить вопрос через запуск цикла архитектурных изменений.
в этой истории так же мне понравилась та легкость с которой я думал об этой задаче. все было естественным и как будто само-собой разумеющимся.
о судьбе этого документа возможно я что-то узнаю. точно узнаю, если это решение будет согласовано. если будет тишина, то или заказчик не направил запрос и просто забил, или не получили согласование.
такие дела.
спасибо за внимание.
