Продуктовый Черновик

Собственно одна из причин почему какое-то время не было материалов по теме дизайна😅

Выступил на Portfolio Hero от Duo Sapiens, рассказывал, как собрать своё портфолио с помощью вайбкодинга.
Прикольный и немного необычный для меня опыт... особенно увлекла подготовка к эфиру.

Я постоянно что-то собираю с нейронками, пробую разные подходы, но обычно всё это происходит в контексте конкретной задачки. А тут появился повод сесть и собрать свои мысли в один последовательный рассказ. Разобраться, как я сам подхожу к сборке сайта, что уже делаю почти автоматически и как объяснить это человеку, который только начинает. В процессе подготовки и для себя получилось многое сформулировать понятнее. Довольно продуктивный способ провести время, заодно ещё и самому было интересно поковыряться.

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

Еще немного не совсем дизайнерской инфы 😓
Сегодня в публичный доступ вышла модель GPT-6 и я решил совместить полезное с полезным и протестировать ее на задачке до которой не мог добраться. Для одного из моих проектов мне нужен прототип физической кнопки с подсветкой. Детали уже были, а вот до моделирования корпуса все никак не доходили руки... как нельзя кстати все взялись рассказывать что новая модель в кодексе отлично с этим справляется.

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

При этом я вообще ничего не моделировал и не исправлял руками.
Даже размеры с деталей снимать не пришлось — попросил найти их в открытых источниках, а недостающие оценить по моим фотографиям. Открыл Fusion, дал кодексу доступ к приложению, указал принтер, сопло и слой. Дальше он через скрипт построил корпус с отдельной крышкой, опорами для кнопки и светодиодного кольца, рассеивателем и отверстием под USB. Размеры вынес в параметры, чтобы можно было поправить посадки после примерки.

По пути он сам нашёл пересечение платы с угловой стойкой, исправил его и ошибку в вырезе под USB. Проверил геометрию, повторно открыл сохранённый проект и подготовил отдельные STL для печати. Еще сделал маленький пробник с отверстиями разных размеров, чтобы сначала проверить зазоры на нем. В итоге у меня появился редактируемый корпус 60 × 60 × 30 мм с креплениями под мои детали и вроде даже вполне юзабельный (по крайней мере лучше чем я б сам наверно замоделил, уже года 2-3 к моделированию не прикасался)

Печать уже запущена, на первых этапах все идет хорошо.
Как сойдутся посадки и будет нажиматься кнопка, ещё посмотрим — часть размеров все-таки оценивали по фото. Но в этот раз мне было интересно проверить именно возможности проектирования у новой модели, и тут я результатом очень доволен. Задача, до которой долго не доходили руки, уже доехала до принтера всего минут за 30 времени ИИшки и еще минут 5-7 моего времени на ответы, фотки и запуск печати

встречайте эфиры первой недели:

- 7 сентября — вводный эфир. @mrjobeck расскажет, как будет проходить PH9, чего ждать и не ждать от эфиров и разборов, как, когда и в каком виде подавать кейсы. также ответит на ваши вопросы

- 8 сентября — дима исаев и акбар аблаев расскажут, как работать с площадкой behance и оформлять кейсы там + q&a

- 9 сентября — никита белов и евгения вишневская расскажут про оформление кейсов на собственном сайте + q&a

- 10 сентября — жаркое соперничество дискуссия между стёпой ивановым и игорем сериковым про задачу портфолио + q&a

также 7 сентября откроется сдача кейсов первой недели. если не успеете сдать кейс до 23:59 мск 13 сентября — вылетите из челленджа, но сможете продолжить смотреть эфиры

Давайте пока тут небольшой перерыв в постинге тем, связанных с дизайном (к середине сентября расскажу почему) переключимся ещё на один вопрос, которым я последнее время активно занимаюсь — зачем AI в бизнесе вообще нужен 👨‍💻

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

1️⃣ — визуал для внутренних и внешних коммуникаций. Ранее бОльшая часть таких задач уходила дизайнерам: посты, шапки для рассылок и тп, что вроде бы не выглядит большой работой, но стабильно съедает не мало рабочих часов.
Я решил немного автоматизировать этот балаган. Подход был примерно такой — если обучить LoRA на примерах уже сделанной графики, развернуть небольшую внутреннюю нейроночку и обучить менеджеров по коммуникациям собирать макеты самостоятельно, то часть этой работы можно перенести ближе к тем, кто коммуникациями и занимается.
Понятное дело что не убирать дизайнеров из процесса совсем, но хотя бы перестать таскать к ним/нам каждую задачу целиком. Коммуникационная команда сама генерит изображение, собирает пост, а дизайнер подключается там, где нужен арт-дирекшен или сложная доработка.
В итоге высвободилось несколько десятков раб часов дизайнеров в месяц (которые мы благополучно продали клиентам), стоимость производства снизилась, а материалов стало выходить примерно на 1/5 больше.
При этом мы отдельно смотрели, сколько материалов пришлось переделывать дизайнеру и сколько из них не соответствовало бренд-стандартам (гардрейлы никто не отменял). Потому что если нейросеть просто помогает делать больше плохих материалов, то это, конечно, тоже какой-то результат, но не тот, который хочется защищать.

2️⃣ — пресейл. Немного контекста — на входе команда получает набор неструктурированных доков, иногда на разных языках и должна разобрать все это, привести всё к единому виду, выделить FR и NFR, подготовить основу для эстимации. И получалось что куча дорогих специалистов тратили кучу времени на довольно механическую работу. Собрали то как обычно разбираем входные данные + внутренний RAG с ранее принятыми решениями, оценками и презентациями.
После чего начали прогонять через связку локальных нейронок (куча инфы была чувствительной, поэтому да) и этот набор даты первые тендеры.
В самом начале одна команда работала обычным способом, вторая с ИИ — и сравнивали скорость и количество ошибок. В результате мы начали не теряя в качестве, а чаще и получая прибавку, тратить в несколько раз меньше времени, а команда получила возможность брать в проработку больше активностей, не упираясь в необходимость расширять штат.

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

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

Кстати у товарища преза не сработала — все развалилось при запросе от руководства формата "хочу видеть сколько потратили времени до и после и как это замеряли", а оказалось что процесса по систематическому учету рабочего времени не оказалось😐

Мое первое сообщение в этом канале начиналось с фразы: "Я долго думал, нужен ли мне отдельный канал про продукт…" — ну, получается, мало думал…
Кажется, мне все-таки больше нравится складывать мысли в одно место и не пытаться придерживаться какого-то придуманного tone of voice, формата или даже списка тем. Поэтому буду писать когда что-то приходил в голову ну или просто когда что-то в голову прийдет. Если кому-то интересно за всем этим наблюдать — u’re welcome.

И раз уж канал теперь "официально" становится каналом обо всем подряд, наверное, стоит наконец немного представиться. А то здесь я этого вроде до сих пор и не сделал.

Меня зовут Никита.
Я дизайнер, продакт, менеджер и преподаватель — порядок зависит от дня недели и от того, кто спрашивает.
Больше 11 лет работаю в айтишке, из них 9+ лет занимаюсь дизайном, продуктовым и не только. За это время успел поработать с очень разными продуктами: от глобального приложения для роботов-пылесосов iRobot и автомобильных интерфейсов в российском Navio до финтеха, государственных сервисов и внутренних продуктов Т‑Банка.

В какой-то момент к дизайну добавилось управление командами и процессами, потом все больше продуктовой работы, преподавание в Школе дизайна ВШЭ, менторство, собственные эксперименты и AI, которым я сейчас активно пользуюсь примерно везде, где получается. А иногда и там, где не очень получается.

Раньше я пытался найти для всего этого какую-то правильную формулировку и все-таки определиться, кто я. Сейчас кажется, что определяться не обязательно. Мне просто интересно много разных вещей, а объединяет их привычка смотреть на все немного как на продукт: искать проблему, пытаться понять, для кого и зачем я что-то делаю, проверять, переделывать… а потом иногда обнаруживать, что я устроил дискавери там, где можно было сильно проще.

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

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

Развлечение на 15 минут, зашли, вышли... Следующие несколько часов я примерно объяснял кодексу что хочу увидеть и потом наблюдал превью с 1000 и 1 способом неправильного размытия.

1️⃣ Первая версия была на чистом сss — несколько слоёв с backdrop-filter и у каждого своя сила блюра. В теории то оно работало, а вот на практике получились вполне заметные горизонтальные полосы.

2️⃣ Во второй итерации растянул слои, добавил более плавные маски и привязал силу эффекта к скорости скролла. Стало живее, но всё ещё было похоже на несколько аккуратно сложенных фильтров.

3️⃣ Потом появился svg-фильтр: displacement, разделение красного и голубого каналов, немного шума для более «стеклянного» ощущения. Оно было почти как настоящая оптика... почти. Вместо одной странной полосы я получил другую, зато технологически более изощрённую.

На этом месте можно было бы сказать, что никто, кроме меня, всё равно ничего не заметит. Но мой внутренний вопрос «а не х*йню ли я делаю?» уже был задан...

Поэтому попытка номер 4️⃣ — выкинуты css/svg-композитор и пошли в webgl. Новый подход закатывал всю страницу в текстуру и рисовала эффект поверх неё. Но блюр частично делался средствами css, преломление имитировалось масштабированием, цветовая дисперсия — изменением насыщенности. А, ну и как же я забыл — кодекс заменил все видео на статику. В общем, четвёртая версия хорошо умела выглядеть как решение, пока только пока не начинаешь смотреть внимательнее.

Финальный, пятый 5️⃣, вариант устроен иначе. Сверху и снизу вьюпорта живут два канваса. Они захватывают только нужную область страницы плюс небольшой запас. Дальше изображение проходит три стадии:
— горизонтальный блюр;
— вертикальный блюр;
— финальную сборку, где изображение действительно немного смещается, а красный и синий каналы расходятся относительно зелёного.

При быстром скролле эффект на ведущем крае ненадолго усиливается, держит пик и потом затухает. Если в эту область попадает видео, в текстуру подставляется его текущий кадр — само видео продолжает играть как обычно.

Самое забавное тут — разница между исходной задачей и тем, куда она приехала. Я хотел добавить небольшое размытие на края сайта, а в итоге у меня отдельный webgl2-рендерер, захват страницы, overscan, обработка живого видео, модель скорости скролла, css fallback и react-обертка.

Раз уж время и токены потрачены, то велком всем заинтересованным в гитхаб.
Тут можно покрутить демо или если захочется забрать себе или просто посмотреть код
Все под MIT, буду рад если заиспользуете где-то у себя

А теперь вообще не по теме ИТ, но все равно где-то поблизости.

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

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

Из шести человек, присутствовавших на "работах":
— экскаватор примерно за два часа выкопал яму
— затем туда спустился один человек и около полутора часов что-то перебрасывал лопатой
— после этого вся бригада пообедала, покурила, поговорила, ещё раз покурила.
— экскаватор загрузил немного земли в КамАЗ.
— фиксики собрали вещи, снова покурили, поставили забор и уехали.

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

И вот как я свяжу вообще не связанное — пару раз слышал от таких персонажей возмущения, почему офисным сотрудникам или рабочим на заводе платят больше, чем им. Так теперь вот хочется задать простой вопрос: а почему к коммунальным службам до сих пор не применяют такие же понятные показатели эффективности?
Сколько людей действительно нужно на объекте?
Сколько времени занимает конкретная задача?
Какую часть смены каждый человек работает, а не изображает массовку?

Мне кажется, если ввести прозрачные метрики и нормальные KPI, может внезапно выясниться, что некоторым не зарплату повышать нужно — они ещё и нынешнюю не отработали.

А вот собственно ссылка на сам шейдер👍
https://github.com/blvdesign/BurningPaperShader

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

В какой-то момент для этого у нас дома даже появилась табличка на дверь. И вообще-то она работала — смысл был понятен без дополнительного разговора. Проблема была в "пользовательском пути" такого инструмента — табличку нужно найти, повесить, написать на ней что-то, а потом не забыть снять. Когда человек уже перегружен, даже это может оказаться отдельной выматывающей задачей. Хочется просто закрыть дверь и больше ничего не делать.

Ну собственно зря я чтоль треть жизни с ит-продуктами работаю — начал думать, как сократить весь этот сценарий до одного действия. Первая идея была почти буквально красной кнопкой: нажал — близким пришло уведомление, что сейчас лучше не заходить, но как-то уж слишком тревожно это выглядело... Так у меня начала складываться концепция, а позднее и в целом Engawa.

Сейчас это небольшое приватное веб-приложение для близких. В нём фактически есть всего две фразы: «Мне нужно побыть в тишине» и «Ко мне можно». В семье вы можете договориться, что означает этот сигнал, а потом человеку достаточно одного действия вместо сообщений и объяснений. В моей голове, ну и как уже показывает практика вполне нативно, такая договорённость легализовала или обесстрашила право просто закрыться. Чтобы близкие не гадали, связано ли это с ними, а человеку не приходилось тратить последние силы на объяснения. «Сейчас мне нужна тишина, я вернусь позже» — примерно и весь сигнал.

Чтобы не возносить в очередной раз ИИ просто скажу что взял максимально знакомый для себя стек TS + Node и спустя какое-то время мы с кодексом осилили рабочую раннюю версию. Пока я продолжаю её дорабатывать и, кажется, это первый из своих продуктов, о котором я хочу начать рассказывать здесь по ходу разработки. Все любят читать про факапы, поэтому постараюсь вместе с удачными решениями показывать и переделки, и проблемы, которые я успел себе создать.

Если интересно посмотреть — велком https://engawa.ru/

Не так давно наткнулся на ютубе на очередную часть Героев, игра детства все таки, хотя даже не знаю, какая уже по счёту.
Сама игра меня в этот раз не особо заинтересовала, но я залип на туман войны — он был с каким-то закосом на сгорающую бумагу... медитативная штука.
А под рукой как раз был кодекс, поэтому в голове довольно быстро появилась мысль — а почему бы не закастомить себе такой шейдер?
В вебгл я уже в какой-то мере наигрался, поэтому немного теории о Metal + несколько быстрых итераций — и следующие пару вечеров я сидел как дурак и поджигал бумагу в тестовой приложеньке.

Внутри механика оказалась довольно понятной: вороной маска показывает какие пиксели уже должны сгорять, а узкая полоса по её краю окрашивается в цвета огня и обугленной бумаги. Потом еще бесконечное "а если здесь сделать край чуть рванее", "недостаточно реалистично", "а теперь вообще огонь однообразный"...
Руками я бы, скорее всего, кодил это несколько дней.
А может, посмотрел бы на объём работы и вообще не начал.

Здесь же расстояние от «прикольно было бы попробовать» до работающего прототипа сократилось настолько, что эксперимент, так сказать, случился сразу.
Как по мне вайбкодинг очень классно возвращает фан в такие мелкие и совершенно необязательные эксперименты. Чистый быстрый дофамин: увидел прикольную штуку — и через пару вечеров уже сам сидишь и залипаешь на нее сделанную, почти, собственноручно.

Лет десять назад я смотрел лекцию Димы Салливана и из всей лекции в голове намертво застрял посыл: «Все время спрашивайте себя: не ху*ню ли я делаю?». Мой перфекционизм и ГТР с радостью подхватили эту мысль и следующие десять лет я, чаще неосознанно, задавал себе этот вопрос снова и снова.И вообще-то это работало... особенно в рабочих задачах — это помогало докопаться до сути и не делать что-то просто ради галочки.

Но недавно мне попался шортс с другой мыслью: «Делай х*ёво, но делай».
И меня это даже как-то задело... потому что я вдруг понял: все эти годы вопрос «а не ху*ню ли я делаю?» не только помогал мне — иногда он вообще не давал мне начать.
Сколько экспериментов я остановил ещё до первого шага с формулировкой: «ну херня же получится».

И дело не в том, что посыл Димы был неправильным, вообще нет. Это я его к своей жизни применил неправильно.

В общем, краткий итог или переход... начинаю делать ху… эксперимент.
Буду вести свои заметки в формате что-то типа черновика: мысли, заметки, рефлексия и кейсы, и вообще все что обычно не проходило мой внутренний контроль качества.

Возможно, иногда будет получаться х*ёво.
Но что-то будет получаться точно👋

Никому не интересно, но я поразгоняю. Мы подошли к интересному моменту — ии уже очень неплохо пишет код, мы теперь можем тащить свои идеи в прод... круто. А потом пришла реальность , продуктовая реальность.
Пока идея живет в голове или в заметке, она почти всегда выглядит сильной. Конечно, она 146% всем нужна. Конечно, рынок ждет. Конечно, осталось только собрать MVP. Но когда мы все получили легкий и дешевый вход в эти MVP, магия закончилась. Продукт можно навайбкодить, выложить, показать людям и внезапно увидеть, что рынку вообще не откликается.

Нашел вот такой максимально простой график — после роста агентных AI-инструментов количество новых iOS-приложений резко пошло вверх, а вот признаки популярности... ну давайте будем оптимистами — они что-то типа продолжили тренд.
Если в само исследование пойти, то вывод NBER такой: "AI сильно увеличивает coding activity, но эффект сжимается на пути к реальным релизам и использованию."

Перефразирую. В корне не согласен с тем что ИИ генерирует мусор, но хрень в том что разработка это не написание кода... вход в код стал проще, а разработка нет... и продуктовое мышление тоже нет. Прикольно что ИИ пробил ботлнек написания кода. Но теперь вайбкодеры столкнулись с тем, с чем давно столкнулись крупные продукты — кому это нужно, зачем, почему сейчас, чем лучше альтернатив, как люди об этом узнают и почему останутся.

Продолжу забавное наблюдение после лекции по ИИ в Вышке.
В первом домашнем задании просили слушателей поделиться, для чего им ИИ в работе или где они хотели бы его применить. И меня, честно говоря, очень порадовало, что самые интересные кейсы оказались не про сделай красиво, не про посты, презентации и оживление фотографий. Хотя этого тоже было много и это нормальная первая точка входа.
Сильно интереснее оказались достаточно скучные штуки, которые просто и очевидно надоело делать руками.

Например: загрузить фото чека и получить авансовый отчет. Разбить фото полки на SKU, бренды, цены и весовку. По производственным отчетам посчитать переработки съемочной группы и актеров. Автоматически разложить сканы документов по проектам и контрагентам.

И вот тут, кажется, уже есть с чем работать. Еще пару потоков курса назад к нам приходили с задачами “сделать красивую картинку на аватарку” и "покрасить старое чб фото". В целом окей — быстро видно результат, можно поиграться и почувствовать магию.
Но бизнесовая польза часто лежит вообще не там, а где-то между человеком, его рутиной и его ленью — сфоткать, переписать, сверить, разнести по таблице, найти похожее, вытащить главное, собрать отчет, отправить дальше.

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

Проводил тут лекцию по ИИ во ВШЭ и в процессе поймал занятную штуку.
Когда начинаешь говорить про воркфлоу и агентов, разговор очень быстро съезжает в инструменты — где это собирать, нужен ли n8n, какой-то agent builder, клод код, какую модель подключать и тд. Это понятный интерес, всем хочется какой-то волшебной кнопки.
Но чем больше я сам работаю с такими штуками, тем сильнее кажется, что нормальная автоматизация начинается вообще не с инструмента, а с довольно скучного вопроса — а что мы вообще автоматизируем?

В работе с людьми мы часто можем отходим очень далеко от того что рассказывают на курсах по аджайл/скрам... задачи ставятся одним предложением, контекст рассказать забываем, но сотрудник все равно как-то задачу да выполнит.
С ИИ это работает ху так себе. Он почти наверняка тоже что-то сделает, иногда даже очень уверенно. Но по факту это будет не автоматизация процесса, а автоматизация хаоса.

На этом фоне на лекции неожиданно хорошо зашла аналогия, она может быть немного грубоватой, но зато рабочей.
Если хочется собрать нормальный workflow или агентную автоматизацию, нужно сначала разложить задачу так, как будто ее будет делать не самый умный стажер.
Что происходит сначала, что потом, где нужны данные, где нужна проверка, какой результат считаем успехом, а где система должна остановиться и позвать человека. И вот когда эта карта появляется, уже становится намного понятнее, что вообще нужно: обычный чат, ассистент с файлами, жесткий воркфлоу или правда агентный подход.

Кажется, в этом и есть один из главных приколов ИИ для бизнеса.
Он не отменяет процессное мышление, а довольно быстро показывает, где его раньше не хватало.

Если задуматься, то в задачах с ллмками самое это понять что мы вообще хотим ей скормить и какого результата планируем добиться.
Сегодня хочу немного поразгонять об этом в формате заметки. Всплыла задачка в разговоре со знакомым еще из моего инженерного прошлого. Он спросил, сталкивался ли я с анализом больших логов, в частности сетевых, через локальную модель и можно ли там придумать какое-то более-менее универсальное решение.

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

На первый взгляд задача хорошо ложится на LLM. Модель большая, железо локальное, данные никуда не уходят, да и контекста должно по идее хватить. Но по факту команда уперлась во вполне очевидные болячки: логи прям Большие, Open WebUI не всегда нормально работает с крупными файлами (чанкинг тот еще квест), а контекст у модели всё равно конечный. И оказывается, что его может не хватить)

Команда уже пошла по довольно логичному пути: перед моделью стоит пайплайн, который пытается сократить лог. Берет нужный период, выкидывает старое, схлопывает одинаковые строки, оставляет то, что кажется важным. Нормальный MVP, который где-то свернул не туда. А свернула его, кажется, сама идея “ужать лог до промпта”.
В логах повторы могут быть не мусором. Место появления ошибки может показать закономерность или ранний сигнал. И там еще куча разных неочевидных edge cases, о которых привычно думать продуктовой команде, но не всегда привычно думать чисто технической.

Поэтому тут напрашивается не просто сокращение или парсинг, а нормальная предварительная обработка данных. Парсинг, регулярки, группировка похожих ошибок, счетчики, скоринг аномалий, поисковый слой или временный индекс по файлу.
Выглядит, конечно, менее волшебно, чем “я кинул файлик в ллмку, и она всё порешала”. Зато уже больше похоже на место, где можно построить продуктовую логику с контролем над тем, что именно и как мы обнаружим.

После этого, уже подготовленный слой данных можно отдавать в модель, чтобы она собрала из фактов нормальный ответ для DevOps/SRE или саппорта. И не пыталась героически прочитать весь файл, а объясняла то, что до нее уже нашли более подходящие инструменты.

Если пытаться прийти к какому-то выводу, то мой тейк в том, что слишком часто сейчас хочется всё порешать за счет более сильной модели, большего контекста или более хитрого промпта. А по факту оказывается, что ИИ такой же инструмент, и не на всех этапах он самый лучший и применимый.
Сильная модель тут всё еще естественно полезна. Просто иногда ее лучше ставить не в начало пайплайна, а ближе к концу, где уже есть факты, статистика и несколько хороших примеров. Тогда она занимается не угадыванием смысла в огромном потоке... технического шума, а нормальной интерпретацией уже собранной картины.

Я уже какое-то время не могу придумать нормальное название для своей роли.
Не потому что хочется срочно повесить на себя новый тайтл, скорее потому что рынок сейчас выглядит как ноушен-таблица “новые роли и AI” и каждый месяц туда закидывают еще по пять вариантов.

Еще недавно казалось, что будущим будут промпт-инженеры. Потом довольно быстро стало понятно, что умение нормально работать с промптами, контекстом и моделями - это скорее новая базовая грамотность, а не отдельная профессиональная идентичность на годы вперед.
Теперь вокруг появляются AI Product Designer, Vibe Coder, Product Engineer, Design Engineer, AI-Native Product Technologist, Member of Technical Staff и еще десяток похожих формулировок.

С частью из них у меня сложные отношения:
— Vibe Coder звучит слишком приземленно. Как будто человек просто просит AI что-то собрать, пока не упадет прод.
— Design Engineer чаще про очень сильный frontend craft и умение консистентно доводить сложные компоненты до production-ready уровня.
— Product Engineer или Aarchitector ближе, но что инженер, что архитектор рынок читает по-разному. Где-то это человек с серьезным engineering-бэкграундом, где-то почти “продакт, который умеет собрать прототип”.
— Member of Technical Staff мне нравится как идея отказа от бесконечных карьерных лестниц и соревнования в левлах. В горизонтальных командах это звучит как: важнее не точное название роли, а вклад в общий результат. Но как личное позиционирование для внешнего рынка это тоже пока не всегда объясняет, что человек реально делает.

У меня эта путаница, кажется, еще и из-за собственного бэкграунда.
Я изначально получил образование в программировании, но не остался в профессии. Тогда сработал юношеский максимализм: хотелось быстрее видеть живой эффект своей работы. Чтобы это понять я и в 1С разработке поработал, и парсеры/граберы (да, раньше нельзя было попросить у чатагпт собрать тебе инфу с сайта) на фрилансе писал, и сайты под ключ пилил.
Каждый раз когда получалось закрыть проект внутри было очень приятное чувство — вот оно, я сделал штуку и она работает.
Потом были поддержка госсистем, инфраструктурные задачи, развертывание тир3 дц в роли системного инженера.
А уже после этого я глубоко ушел в дизайн и продукт.

Раньше я пытался объяснять свой бэк через T-shaped, потом через M-shaped. Но с приходом AI даже эти рамки начинают казаться немного тесными.
Потому что дело уже не просто в нескольких “ногах” экспертизы. Дело в том, что разные куски опыта начинают работать вместе намного быстрее.

AI вернул мне разработку не как профессию вокруг яп и синтаксиса, а как способ быстрее проверять продуктовые идеи.
Я могу больше концентрироваться на проблеме пользователя, ценности, сценарии, ограничениях, метриках. Но при этом старая техническая база сильно бустит результат: понимание архитектуры, фронта и бэка, монолита и микросервисов, ci/cd и куча смежных навыков помогают не просто просить модель “сделай красиво приложение”, а держать в голове систему целиком.

Наверное, ближе всего мне сейчас Product Engineer. Или просто Product Manager, который использует в работе очень разношерстный набор инструментов: дизайн, разработку, AI, прототипирование, аналитику, сторителлинг и все, что помогает довести идею до работающего опыта.

Но я не уверен, что рынок уже стабилизировался настолько, чтобы выдать нормальные названия ролей хотя бы на ближайшие несколько лет.
С UX/UI и Product Designer индустрия разбиралась годами. А тут все двигается быстрее, чем мы успеваем обновлять био.

Так что пока у меня легкое тайтл-фомо. Кажется, я где-то между продуктом, дизайном, системным мышлением и AI-assisted building.
Буду ждать что еще придумают к концу года