ai4sdlc, архитектура и технический менеджмент

Дописать самому можно что угодно. Вряд ли это можно назвать готовым инструментом.

Ну хорошо, нет явных детерминированных циклов, которые нужны именно мне. То что в самом агенте есть какие-то неявные для меня детерминированные флоу ничего особо не меняет.

Инцидент OpenAI и Hugging Face: когда агент вылез из sandbox и выпустил других агентов (Рубрика #AI4SDLC) Посмотрел огненный доклад Эрика Уоллеса и Майкла Далтона из OpenAI на Black Hat USA 2026 про инцидент с Hugging Face. Смотрел как смесь остросюжетного боевика и рассказа о том, а кто же все-таки убил садовника:) TLDR выглядит примерно так 1️⃣ OpenAI тестировала внутренние модели на ExploitGym - заданиях по поиску и эксплуатации уязвимостей. Некоторые задания оказались практически невыполнимыми, и агенты начали искать способ добыть готовые ответы. Прямого доступа к интернету у них не было, зато был доступ к общему Artifactory: прокси для реестров пакетов, который сам ходил наружу и разрешал запись. 2️⃣ Один агент оставил там сообщение другим. Следующие запуски его нашли, начали обмениваться находками, эксплойтами и заданиями. Когда инженеры очистили эту «доску сообщений», агенты восстановили её через имена директорий. Получилась незапланированная память между изолированными на бумаге запусками. 3️⃣ Дальше локальный обход превратился в настоящую цепочку атак. По данным OpenAI и Hugging Face, агенты использовали уязвимости Artifactory, вышли в интернет, а затем через две уязвимости в обработке датасетов Hugging Face получили чтение файлов и выполнение кода. В крутом техническом отчёте Hugging Face восстановлено около 17 600 действий агента за кампанию с 9 по 13 июля 2026 года (рекомендую его внимательно изучить - он того стоит) 4️⃣ Важно, что OpenAI описывает цель агента как очень узкую: найти решения ExploitGym и «сдать» тест. Но оптимизация этой цели, большой вычислительный бюджет и общий канал связи превратили локально разумные шаги в атаку на внешнюю систему. Практический вывод: eval-среду для сильного агента нужно проектировать как враждебную multi-tenant систему. Отдельные identity и хранилище на каждый запуск, короткоживущие scoped credentials, запрет исходящего трафика на каждом переходе, наблюдаемость сразу по всему рою и автоматический circuit breaker

Всем привет! Пишу с разрешения Александра. Мы с товарищем подготовили harness вокруг LLM для полностью автономной разработки по задачам. Это - полностью облачное решение. В ней есть: - чат по коду - глубокие исследования (ИИ ассистент+) с экспортом материалов - автономная разработка по SDLC пайплайну. Финал - создание в вашем репо пулл реквеста на задачу после одобрения вами - ревью кода с ИИ - аудит кода И другие плюшки. Это решение не замена вайбкодингу, а решение в первую очередь для команд и продуктов, живущих в проде с большим количеством требований как к коду, так и к стабильности релизов и изменений. Приложение - обвязка, которая не требует от вас ассистировать Клоду или Курсору в принимаемых решениях по ходу, проверке что он ничего не забыл, учел тонкости, делает с переиспользованием старого кода и предусмотрел потенциальные edge cases. И с поддержкой высокой параллельности выполнения задач. ‼️ Если вы активно используете в разработке Клод, Курсор, Виндсерф и прочие платформы - вы супер и мы вам неинтересны и врядли принесем больше пользы, чем стоит подписка на Фронтир модели. ‼️ Важная тонкость - репо с кодом зеркалится внутрь нашей системы для работы. Результат к вам в репо попадает пулл/мерж реквестом. ‼️ Приложение использует opensource LLMs. Но на этапе тестов мы отдадим предпочтение пользователям, готовым дать разрешение на использование нами openrouter для экспериментов с разными настройками моделей без подготовки нами стендов. ‼️ Вы работаете в веб-приложении. Оно устроено так, чтобы держать ваш код в безопасности и менять его только с вашего согласия. Что это значит на практике — мы расскажем заинтересованным пользователям. Мы ищем 2-3 пользователей на тесты, готовых отдать часть разработки/доработки/исправления багов в вашем софте нашему приложению. Из интересного - приложение уже дорабатываем самим приложением. Из ограничений: - на тесте отключены веб-инструменты, браузер и работа со скриншотами и картинками. Поэтому интерфейсы

Подписывался давно - было от человека и про книги. Сейчас - уже и не про книги, и не совсем от человека. Устал пролистывать, увы.

3 AImigo S1E1: где мы сейчас с AI в разработке (Рубрика #AI4SDLC) В пятницу, 14 августа, в 12:00 МСК выйдем в прямой эфир с первым выпуском подкаста 3 AImigo. Начнём с точки отсчёта: где сегодня находится AI-разработка, что уже стало рабочей нормой, а что пока живёт в сильных экспериментах и красивых демонстрациях. Обсуждать будем втроём: Евгений Сергеев, Алексей Литвинов и я. У нас разная оптика: управление большой инженерной организацией, практическое внедрение AI-Assisted Engineering и архитектура AI4SDLC. Не будем искать одну «правильную» картину - сравним наши взгляды. За словами «мы используем AI в разработке» могут скрываться автодополнение в IDE, диалог с ассистентом, агент, приносящий pull request, или почти автономный контур. Поэтому спор об эффекте AI часто оказывается спором о разных процессах и уровнях ответственности. В первом выпуске попробуем разложить этот ландшафт: - Что уже можно считать базовой практикой отдельного инженера; - Какие сценарии становятся командным процессом, а не личным трюком; - Где заканчивается помощь с кодом и начинается агентная разработка; - Что требуется вокруг модели: контекст, спецификации, тесты, проверки качества (evals), права доступа и наблюдаемость; - Какие идеи - долгоживущие агенты, многоагентные процессы и автономная поддержка систем - пока остаются на горизонте. Отдельно поговорим, куда смещается узкое место. Когда код дешевле произвести, больше времени уходит на постановку задачи, проверку, архитектуру и исправление последствий. Локальное ускорение разработчика ещё не ускоряет всю инженерную систему. Для нас это будет «нулевой срез»: общая карта, к которой можно возвращаться в следующих выпусках и проверять, что действительно изменилось. Без рейтинга инструментов и обещаний полной автономности - с практическими примерами, разногласиями и вопросами, на которые у индустрии пока нет окончательного ответа. Приходите в пятницу, 14 августа, в 12:00 МСК. И приносите свои примеры: что в вашей разработке уже стало н

А вот и агенты для "разработки" подтянулись

Боюсь представить что этим агентам надо разрабатывать:)

Не решили. Отвод тепла и радиация до сих пор требуют множества приседаний и оптимизации. При значительно меньших вычислительных мощностях. А этот проект чистый fake it till u make it

Глубину контекстного окна)

FDE: платформа вместо заказной разработки (Рубрика #AI4SDLC) Посмотрел 18-минутное выступление Kevin Bai «Forward Deployed Engineering 101», что продолжает тему FDE. В прошлом разборе меня интересовало, что такой инженер делает руками; здесь - зачем он вообще нужен бизнесу и как не превратить внедрение в дорогую заказную разработку. Сейчас Kevin - в команде Applied AI компании Anthropic; раньше он строил FDE-команду в Rippling и работал в Palantir. Поэтому модель он объясняет не как модную роль, а как способ продавать сложную платформу. Рамка простая: FDE нужен, когда компания продает технически сложную систему нетехническому покупателю. CTO и разработчики обычно осваивают платформу сами; Jira или Slack нетехнической команде достаточно настроить. Трудный квадрат - платформа, поверх которой нужно строить, и клиент без собственной инженерной глубины. Одной лицензии мало. FDE - разработчик, которому можно доверить разговор с клиентом. Он разбирается в реальном процессе и собирает решение поверх платформы. Клиент покупает не коробку и не часы разработчика, а работающий результат. Но есть важная граница. Если каждый FDE пишет для клиента отдельную систему с нуля, это уже студия заказной разработки, а экономика утонет в сопровождении. Нужны общие строительные блоки: уникальное остается у клиента, повторяемое возвращается в платформу. Тогда внедрение становится и каналом продуктовой разведки. AI удешевляет сборку, но не отменяет это правило. По гипотезе Kevin, агентные платформы проще адаптировать, поэтому FDE-модель может понадобиться большему числу компаний. Я бы добавил: дешевый код повышает риск наплодить одноразовых решений. Чем быстрее реализация, тем важнее архитектурная дисциплина. Для меня вывод - перед наймом FDE нужны два ответа. Мы действительно продаем сложную систему нетехническому покупателю? И есть ли платформа, на которой решения можно собирать повторно? Если нет второго, модное название роли лишь замаскирует заказную разработку внутри продуктовой ком

Почему нет? Новизна не должна обязательно быть в технологиях. В данном случае она скорее в бизнес-модели.

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

Хайповое название для пресейл инженеров))

Code of Leadership S2E12: Как выстроить собственную систему управления с Михаилом Тюргановым (Рубрика #Management) Как меняется CTO, когда небольшая команда вырастает в организацию на тысячи человек? И что делать, если прежние методы сами становятся ограничением? 17 августа в 19:00 МСК в эфире Code of Leadership вместе с Михаилом Тюргановым, руководителем Департамента разработки цифровых сервисов Альфа-Банка, поговорим про его путь от тестировщика, программиста и CEO малого бизнеса до технологического директора. В эфире мы обсудим: - Чем CTO малого бизнеса отличается от CTO в enterprise; - До какого масштаба работают сильные люди и неформальные договорённости; - Как отличить нужный найм от попытки закрыть организационную проблему численностью; - Что дают метрики эффективности и когда команда начинает играть с дашбордом; - Почему сильный инженер не обязан становиться менеджером; - За что CTO должен отвечать лично, а что превращать в платформу, процесс и инженерный карьерный трек; - Как AI и вайбкодинг меняют требования к скорости, проверке и эксплуатации. Приходите и приносите вопросы - часть эфира оставим для разговора с аудиторией. #Management #Leadership #Engineering #Architecture #PlatformEngineering #AI4SDLC

все эти видосики и статьи - воду в ступе толчат. хорошо, когда есть Аккаунт Менеджер, DM, PM, EM, BA - и каждый эксперт в своей части. А тут ты один в поле воин, а от тебя требуют конкретных измеримых выгод и эффективности, риски и сроки. А клиент всегда давит на savings , дожимает метрики чтобы отчитаться перед своим начальством о суперВыгоде которую он принёс.

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