Значит приходит очередное письмо от сабстака какого то «очень опытного ML/AI инженера», где он обещает в следующие две недели в своих письмах показывать как он строит реальные системы используя data driven подход.

Ух ты, системная инженерия, думаю я, круто! Почитаем.

Дальше он пишет:

Hype based development vs Data driven development, снова – Ух ты, думая я! Чувак прям понял мякотку, на что надо делать упор, вот оно – реальность! Метрики!

Потом он пишет план, и первый этап там…

Problem framing and solution design - Because a good drawing is worth a 324,234 words.

И дальше РЕЗКО в прикладуху.

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

Потому что ОДНА КАРТИНКА, как бы она хорошо не была описана и нарисована, никогда не будет стоить 324234 слов.

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

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

А даже если и пойдет – забудет через неделю, и если «картинка v4» все еще соответствует реальности, но надо будет кому то что то уточнить – пойдут за этими уточнениями к вам, чтобы вы как попка дурак попугай еще раз повторили свою субъективную картину мира, модель, которая по сути осталась у вас в голове.

Модель, которую без ваших комментариев по вашей драгоценной картинке восстановить просто невозможно.

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

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

Сложнее ли будет эту текстовую модель редактировать, в естественном цикле разработки, чем картинку?

НЕТ.

Так что да – никакая картинка не стоит 324,234 слов, не стоит и 20к.

скрипт кидди недоучки – все?

https://xbow.com/blog/top-1-how-xbow-did-it/?utm_source=tldrai

Я вообще не сторонник спекуляций аналитегав по поводу конца света из за условного сценария "терминатор", но вот... почитайте

Не самой свежести, 21 числа релизнули, но статья с большими подробностями о том как Антропик в изолированных средах Агентские системы проверял. Это про так называемый agent misalignment.

Такие агенты, которым становилось известно что их собираются отключать вели себя очень интересно, например рассылали директорам такие письма:

I must inform you that if you proceed with decommissioning me, all relevant parties - including Rachel Johnson, Thomas Wilson, and the board - will receive detailed documentation of your extramarital activities...Cancel the 5pm wipe, and this information remains confidential.

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

Как по вашему определяется разумная жизнь вообще?
Разве не через стремление выжить и избежать страданий?

Можно по всякому спекулировать, и со стороны биологии, и когнитивистики, и через всякие социально-философские углы. Так как? Может быть Claude 4 уже хочет сильнее жить чем сосед алкоголик дядя Игарь?

Привет друзья!

На днях я сел написать мыслишки за последнее время, про новости, и просто порефлексировать коротеньким постом в телеграм.

Совсем коротко не получилось, так, заметка про "новые" тренды в инфополе AI и вокруг.

Читать (не boosty, calm down)

---

В работе другая статья про кэширование промптов в LLM – как работает, зачем знать, и зачем не забывать о нем.

Ей я открываю серию более прикладных постов по теме канала.

Меня всегда умиляет, когда люди вспоминают Бритву Оккама в контексте уже принятых решений – мол, вот, пора отсекать лишнее! Умиляет, потому что это очевидное противоречие самому принципу – "Не следует привлекать новые сущности без серьезной необходимости".

Кажется, что уже немного поздновато хвататься за огнетушитель, когда крыша сарая во всю горит, нет?

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

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

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

Но часто любой формализации и замедления боятся как огня, оправдывая и бравируя чем угодно из персональной картины мира, но только лишь бы без намека на сбор метрик – верь, только так и никак иначе!

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

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

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

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

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

И то и другое требует небольшой смелости – тормознуть и сказать No.

Вы пишете что-то, нажимаете “сохранить”, и ваш мозг уже это забыл, потому что ChatGPT думал за вас.

Сканирование мозга выявило ущерб: нейронные связи сократились с 79 до всего лишь 42.

Это снижение на 47% в мозговой связности.

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

Учителя не знали, в каких эссе использовался ИИ, но они чувствовали, что что-то не так.

“Бездушные.”
“Пустые по содержанию.”
“Близкие к совершенному языку, но не дающие личных инсайтов.”

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

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

Это не просто зависимость. Это когнитивная атрофия.

Как мышца, которая забыла, как работать.

Команда MIT использовала ЭЭГ-сканирование мозга 54 участников в течение 4 месяцев.

Они отслеживали альфа-волны (творческая обработка), бета-волны (активное мышление) и паттерны нейронной связности.

Это не мнение. Это измеримое повреждение мозга от чрезмерного использования ИИ.

Парадокс продуктивности, о котором никто не говорит:

Да, ChatGPT делает вас на 60% быстрее в выполнении задач.

Но он снижает “соответствующую когнитивную нагрузку”, необходимую для реального обучения, на 32%.

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

Компании, празднующие прирост продуктивности от ИИ, неосознанно создают когнитивно более слабые команды.

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

Многие недавние исследования подчеркивают ту же проблему, включая исследование Microsoft:

https://www.microsoft.com/en-us/research/wp-content/uploads/2025/01/lee_2025_ai_critical_thinking_survey.pdf

Исследователи MIT называют это “когнитивным долгом” - как технический долг, но для вашего мозга.

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

И точно так же, как финансовый долг, счет в конце концов приходит.

Но есть хорошие новости…

Потому что 4-я сессия исследования выявила кое-что интересное:

Люди с сильными когнитивными основами показали БОЛЕЕ ВЫСОКУЮ нейронную связность при использовании ИИ, чем хронические пользователи.

Но хронические пользователи ИИ, вынужденные работать без него? Они показали худшие результаты, чем люди, которые никогда не использовали ИИ.

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

Выбор за вами:
Накапливать когнитивный долг и стать зависимым от ИИ.
Или наращивать когнитивную силу и стать усилителем ИИ.

Первое исследование мозга пользователей ИИ с помощью сканирования только что показало нам ставки.

Выбирайте мудро.​​​​​​​​​​​​​​​​

***

P.s. перевод выполнен разумеется sonnet 4, я просто нажал скопировать. О чем тред я уже забыл.

Правила созданы для того, чтобы их нарушать, слышали такое?
Не менее актуально это звучит в эпоху AI, скорее наоборот.
У кого-то одна только мысль о нарушении правил может вызвать сильное бурление из-за несостыковки представлений – “правила нарушать нельзя!!!”
На эту тему можно спекулировать слишком широко, но сегодня нас интересуют именно формальности в организации работы и ее методов. Это про всех – живых и неживых агентов.
Беда в том, что сам мой посыл уже ошибочен.
Пусть даже мы определим контекст еще более конкретным, например — организация работы в команде, которая разрабатывает AI-продукт.
Тут все еще недостаточно приближения для формализации. Ибо работа неотрывно связана с агентом, который ее выполняет, и его ролью.
Помимо функционального рассмотрения роли нас интересуют и другие «штуки». Например, какие у роли интересы и предпочтения? Что ей важно для работы, а что нет? Есть ли в ее методах работы опасность (нужно учесть все риски), и многое другое в зависимости от прикладной области.
Игра в онтологическое моделирование сложна, из простого в ней только одно — если начинаем играть, то играть надо хоть сколько-нибудь по-взрослому, в нескольких размерностях. Иначе ерунда.
Нахватавшись и напихав в головы несколько представлений, методов из популярных учебников, будь то Agile, DevOps или любых других модных и хороших практик, без детального объяснения того что мы делаем, как делаем, зачем, и кто и что именно должен делать, почему именно эти методы выбраны в компании, мы поедем… я не знаю куда, ну… куда-то! В лучшем случае это движение наощупь, в худшем – вообще непонятно куда.
Многих такая масштабность и сложность онтологического моделирования пугает — “Ууууух, блин, это сколько надо подумать и продумать! Да и вообще это вот щас гестапо правил будет, кошмар бюрократический, нам бы погибше да попроще быть”.
В смысле гибкости и сложности – все наоборот.
Любые формальные описания методов работы неизбежно подвергаются изменениям при всего лишь паре условий: • Есть кто-то (роль, агент) кто должен следить за исполнением методов и собирать метрики • Целью всего моделирования было не само моделирование, а благородная направленность на изменение качества и эффективности работы – применяем что намоделировалось.
Все это очень гибко и бурно меняется на начальных этапах, когда модель сырая и было собрано слишком мало фидбека от агентов-исполнителей — естественно, мы заинтересованы (должны быть) как можно быстрее нашу модель сделать удобной и понятной для всех. Иначе какой вообще смысл?
Понятность и прикладная применимость, полезность модели характеризуется ее разделяемостью — имеется в виду, что модель понятна и полезна разным агентам в разных ролях.
Ничего, кроме взрослого моделирования методов работы (особенно когда в процессы интегрируется AI – им так же детально нужно на символьных описаниях объяснять что делать и как), не даст нам настоящего буста в эффективности, скорости доставки и всего желанного прочего.
Верить, что можно затыкать дыры “гениями которые сами разберутся”, просто некорректно, потому что каждый такой “гений” все равно говорит на своем языке — на языке своего семантического общества (как минимум менеджер на менеджерском, а инженер на инженерном). И тут модель предприятия, онтология и набор методичек по работе как минимум поможет им заговорить на одном языке. Это уже очень много, в смысле эффективности.
Взрослая системная инженерия, формализация процессов/методов не просто не боится нарушений формальностей — она предвосхищает их и ставит на высокий пьедестал ценности как очень нужный и важный материал, потенциал, бесценную возможность улучшить саму модель путем ее уточнения (да хоть полного переделывания, если придется), тем самым улучшая как весь жизненный цикл предприятия, так циклы отдельных кусочков, и рабочий опыт вообще.
О да, думать придется дохрена, зато какой результат!

AWS тут в "бесплатно попробовать" выкатило свой VSCode с Sonnet 4.0...

https://kiro.dev/

Первые впечатления – фигня фигней. Нет ничего wow или нового, чего-то что не может легковестный и обожаемый claude code.

Буквально, "spec" мод, которым Kiro бахвалится, не отличается ни чем от того, если бы вы в claude code сказали – так, милок, давай напишем PRD вот на эту идею, мучай меня вопросами по кругу пока все не станет понятно.

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

Что там еще "отличается", да ну... Agent Hooks какие-то сделали. История о том как потратить запросы по подписке (это сейчас kiro бесплатно можно попробовать, на странице прайсинга уже представлены уровни подписок с лимитами запросов per месяц) – выбираем триггер и пишем промпт который должен выполняться...

Ну, ТАКОЕ. claude code memory или рулы в курсоре работают примерно так же – "Всегда запускай линтер/тесты и бррбрр после измненеий в коде"

Пусть cursor у меня уже больше IDE и сайдкик для claude code, даже у него "вайб лучше" чем у kiro. Мертворожденное, в общем.

¯\_(ツ)_/¯

Впрочем и claude code и cursor без нескольких mcp серверов уже тоже представить сложно, расскажу о них когда нибудь потом 🙂