Вишнёвые истории

Вот вам идея, как провести выходные, если не получается уйти из дома гулять и активничать. 1. Берёте книгу Станислава Лема «Непобедимый». 2. Читаете её залпом, она небольшая. 3. Берёте одноимённую игру «The Invincible». 4. Проходите её так же залпом, выпив весь имеющийся чай или что вы там пьёте. 5. Получаете невероятное удовольствие и жалеете, что такое будет тяжело повторить.

Прочитал книгу «Если кто-то его создаст — все погибнут» Элиезера Юдковского (автор серии «Гарри Поттер и Методы Рационального Мышления») и Нейта Соареса. Что сказать, картинка к посту – хорошая иллюстрация. В целом весьма интересная работа, не сказать, чтобы философская, много технических аспектов. Если вы ии-фаталист, точно к прочтению для большего нагнетания жути, если ии-энтузиаст, то вполне подойдёт для взгляда под другим углом на возможное светлое будущее. Мне понравилось обилие инженерных рассуждений, раскрытие аспектов и опасений, весьма убедительных к слову. Так же интересно ретроспективно взглянуть на формирование MIRI, поискать перекрёстно публичные обращения и т.д.. Короче крайне советую посветить немного свободного времени этой работе.

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

Ещё чуть-чуть шутеек и дальше техническое будет)

Ой как да)

Бенуа Шиллингс: R&D после кода (Рубрика #AI4SDLC) Посмотрел keynote доклад Бенуа Шиллингса, VP из Google DeepMind на AI Engineer World’s Fair 2026. Его позиция мне интересна - он не лидер продуктового ИТ, внедряющий агента в SDLC, а руководитель R&D. Его команда создаёт технологии, которые понадобятся Gemini на горизонте от месяца до года. Поэтому вместо backlog, CI/CD и SLO он обсуждает, чему должна научиться следующая модель. У истории забавное начало. В 2018 году его команда в X запустила проект Pitchfork про применение ML к коду, но идею почти никто не воспринимал всерьёз. Сам Шиллингс отвергал программирование на естественном языке: для этого уже есть языки программирования. Теперь человек с 45-летним опытом - от ассемблера до Python - признаёт ошибку и использует vibe coding. Главный тезис: генерация кода и software engineering - это разные задачи. По мнению Шиллингса, модели уже генерируют синтаксис лучше человека. Но настоящая разработка начинается, когда нужно изменить систему с 35 миллионами строк PHP, учесть архитектуру, безопасность и последствия решения через десять лет. Узкое место переезжает в постановку задачи, декомпозицию и проверку замысла. Код для DeepMind - это удобная R&D-лаборатория: данных много, результат проверяется компилятором и тестами. Следующий шаг - self-play, где модель сама создаёт задачи, решает и проверяет их, как AlphaZero учился через игру с собой. Ограничением становятся compute и качество среды обучения. Исследовательский roadmap из доклада выглядит так: - Учить модель писать безопасный код сразу, а не только находить уязвимости постфактум; - Развивать планирование, декомпозицию и перенос идей между областями; - Менять evals: проверка «запустилось и выдало ответ» слишком узка для архитектуры; - Выходить за линейную цепочку токенов к мультимодальным представлениям; - Возможно, создавать строгие языки для моделей, даже если человеку их будет неудобно читать. Последний пункт особенно хорошо показывает R&D-оптику: снять ограничение читаемости кода человеком и переложить доказательство корректности на модель и язык. Шиллингс прогнозирует, что код станет почти бесплатным, его объём взорвётся, а через год люди почти перестанут читать результат агента - как сегодня редко проверяют ассемблер после компилятора. Это прогноз, не факт и есть определенная разница между агентом и компилятором - последний работает по строгой спецификации, а агент - в неоднозначном бизнес-контексте. За рамками остаются legacy, ownership, SLO, стоимость inference и rollout. Зато финал уходит в химию и биологию: для Шиллингса coding models - полигон для общего reasoning и научных открытий. Мне это выступление понравилось - это не инструкция по внедрению AI в ИТ (с этим у меня проблем нет), а скорее карта upstream-исследований. Условно - R&D спрашивает: «Что модель сможет открыть и построить?» - Продуктовое ИТ добавляет: «Как доказать, что результат нужен, безопасен и управляем?» #AI #AI4SDLC #Research #Engineering #Architecture #Evals

La Furia Roja 🕺

Действительно)

Когда 100500 раз переустанавливаешь node_modules с крашем либы при запуске проекта, а потом узнаешь про npm cache clean --force

33 года, атас просто, я в ужасе. Выводов нет, смиряюсь с числом)

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

Нет, ну вы видели?!! Понадобились всего лишь 30 лет на подумать и мы наконец-то можем нормально слать длинные фильтры)

Скоро во всех техах страны)

Доверие как критерий при проектировании систем При разработке ПО мы постоянно работаем с такими понятиями, как требования и риски. Но есть еще один пункт, не менее важный, как мне кажется, доверие. Работая с системами годами, я вынес доверие в отдельную категорию при проектировании. Что я в него вкладываю? Доверие во многом формирует и требования, и риски: чем меньше мы доверяем, тем больше рисков закладываем. И я, честно говоря, скорее склоняюсь к тому, чтобы не доверять, чем доверять. О чем речь. Мы постоянно делаем какие-то интеграции с разными API. Это могут быть интерфейсы крупных компаний вроде Google или Amazon, мелких стартапов, платёжных систем, разных по масштабу. Это могут быть облачные ресурсы, которым мы доверяем или не доверяем в той или иной степени. И в работе со сторонними API и ресурсами я всегда закладываю риски: отказоустойчивость, безопасность, надежность партнера. Под надежностью партнера я понимаю в том числе то, что он будет существовать ещё какое-то время вперёд и его не придется менять на аналог. А ведь даже у гигантов бывают ситуации, когда они закрывают продукты. И если ваш продукт построен на жёсткой связке с чужим, то вероятность головной боли, когда тот закроется, довольно высокая. Поэтому еще на этапе проектирования мы прячем такие вещи на уровне реализации в некие абстракции, чтобы интерфейс провайдера всегда можно было легко заменить на аналогичный. Для этого есть определенные паттерны. Даже интегрируясь с платежными системами, мы находимся в зоне высокого недоверия, пусть это и известная, большая, популярная система уровня банка. Единственное, чему я могу доверять у платежной системы, это информация, которую она возвращает о статусе транзакции. Для меня это финальные, понятные и относительно надёжные данные. Почему относительно? Потому что за свою карьеру я работал в разных компаниях, не раз интегрировался с платёжными системами и сталкивался с тем, что статус транзакции может измениться. Например, с успешного на неуспешный или наоборот. А это довольно критично. Если мы сначала получили финальный статус, а потом оказалось, что транзакция не была оплачена, то мы сработали в минус и отдали товар или услугу покупателю бесплатно. И такое в реальности бывает. Не стоит забывать и про форс-мажоры, которые тоже влияют на наши системы. Я на своей памяти помню, как горел крупный дата-центр в Европе, как падали облака. Да и в последнее время — я уже про это писал — качество интернета и сервисов заметно ухудшилось по сравнению с тем, что было. И это тот самый риск, который мы должны закладывать: косяки бывают у всех, везде работают люди или люди, которые используют что-то во вред или не правильно (например, доверяют результатам AI, не глядя). Не стоит сбрасывать со счетов и физические воздействия. Пожар, как я сказал, никто не отменял. Но бывают еще и землекопы, которые могут перебить магистральный кабель и оставить целый дата-центр без света или без интернета. Понятно, что на этот случай всегда есть резервные каналы и прочее, но я бы об этом не писал, если бы сам не видел, как падают дата-центры. Сейчас рисков еще больше, потому что добавились регуляторы: юрисдикции разных стран давят друг на друга, пытаются что-то заставить сделать и из-за этого в любой момент вам могут просто отказать в услуге. Например, из-за паспорта определённого цвета. Или даже из-за национальности. С таким я тоже сталкивался. Поэтому при проектировании систем я всегда работаю с доверием и по умолчанию не доверяю никому. Я доверяю только своей системе и то с определенной долей недоверия. Именно поэтому существуют разные компенсационные меры, которыми стоит руководствоваться при проектировании. Как правило, именно их мы и пытаемся придумать на уровне системного дизайна, используя определенные паттерны. И не потому, что в первую очередь не доверяем себе, в первую очередь потому, что не доверяем другим. В любой момент может случиться что угодно, и заранее ко всему мы не будем готовы. Поэтому система должна сама компенсировать свое состояние если это, конечно, входит в ее требования.

Немного солнечного Питера вам.

Вы знаете, как расшифровывается SDLC? (только честно и не подглядывая в первый комментарий)