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

В общем, сегодня вечером проводим совместный вебинар с Soft Skills Lab, даже тему (сами подписчики) выбрали кликбейтную. Все бесплатно, нужна рега.

В предыдущих сериях я изобретал свой подход к анализу трейдоффов и решений (раз, два), потом нашел большие энтерпрайз методы.

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

Регайтесь в боте и не забывайте спрашивать, будет ли запись.

#AI #анализ

Помните классические инструменты requirement engineering времен Вигерса, Коберна, Якобсона, которые использовали для анализа и проверки качества требований? Все эти полотна из требований, сценариев, uml-диаграмм, которые давали очень полную и непротиворечивую картинку, и которые не мог читать ни один человек в здравом уме? После которых разрабы подходили к аналитикам и говорили: "Бро, все круто, только объясни нормально, что сделать нужно?"

Интересно, что при грамотной работе с иишечкой они могут быть довольно полезны.

Часто инфа в классических артефактах частично или полностью дублируется, плюс они позволяют проверять полноту друг друга. Например, связки:

• контекстная диаграмма + DFD + концептуальная ERD
• Use Cases Diagram +Use Cases + сиквенс под каждый + портянка ФТ

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

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

Не то чтобы все это необходимо для разработки, но как только втягиваешься в серьёзную мультиагентность, становится все сложнее остановиться

Правда, часть из них были неплохими инструментами мышления, но так ли важно, почему человек их не использует: из-за отсутствия времени или наличия иишечки?

Интересный стрим от Александра Поломодова и Максима Смирнова про настроения в индустрии относительно скиллов, памяти агентов, харнесса и развития моделей. Лютого хардкора внутри нет, для ленивого просмотра на вечер.

#оффтоп

Прастити, ору. Цитата из вакансии:

Роль подойдёт тем, кому комфортна прозрачность, регулярная коммуникация и работа в матрице.

Никогда, вас устроит никогда?

82 человека хотело вторую часть, держите: продолжение стрима по Кафке. Будем ломать кластер, порядок сообщений и гарантии доставки.

Жду 82 регистрации.

Сколько же мистики и магии собирается вокруг AI. Интересно, с интернетом так же было 25 лет назад?

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

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

• Скилл — это обычный промпт, который сохранили в файле, дали ему название и добавили описание
• Вызывать скилл может не только человек, но и агент, по своему усмотрению, в какой-то

И все.

Агент — программа, которая в процессе работы обращается к модельке для принятия решений.

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

Секонд брейн — помойка из связанных md-файлов, которые регулярно читает и обрабатывает моделька по каким-то правилам.

Дримс — джобы, которые регулярно срабатывают и обрабатывают накопленную в проекте инфу по какой-то логике.

Ну и дальше харнесс, рой агентов, семантический слой и т.д.

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

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

Кто-то уже предлагает забить на харнесс и сфокусироваться на грамотном формировании и вызове памяти. Мол с остальным справятся модельки.

Тем более странным мне видятся попытки делать универсальный харнесс, который не зависит от модели — как будто это попытка усреднения сильных и слабых.

Лысый из Амазона утверждает, что нужно думать не о том, что изменится завтра, а что останется неизменным через 10 лет.

На счет 10 лет хз, но уверен, что в ближайшие 3-5 лет никуда не исчезнет и даже усилится потребность в инженерном мышлении. Ибо чем ближе сейчас задачи к коду и реализации, тем лучше с ними справляется иишечка.

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

Кто еще не догадался, это приглашение на курс по интеграции и архитектуре систем, который стартует в субботу, 14 ноября.

Пересказывать программу не буду, ее можно посмотреть на сайте. Подчеркну три идеи, на которых строится курс:

— учимся самостоятельно рассуждать, анализировать незнакомые задачи, развиваем инженерное мышление

— мы занимаемся проектированием распределенных систем - можно сколько угодно разбрасываться паттернами и называть это System Design, но с базовой базой придется подружиться

— погружение в нюансы технологий: сети, инфра, хранилища - это важнее, чем бесконечно рассуждать "как правильно выбрать Х"

Чтобы не продавать кота в мешке, традиционно предлагаю:

• посмотреть анонимные отзывы последних трех потоков, без цензуры
• заглянуть в среду на вебинар про выделение сервисов под новые фичи
• писать любые вопросы в комменты или в личку @and_burakov

До среды еще ранняя цена действует, запрыгивайте.