О чем молчит AI CTO
Open in Telegram
Привет! Я Влад, CTO по AI в red_mad_robot. Здесь делюсь применении AI в бизнесе, разбираю технологии и публикую интересные материалы из жизни.
Show more1 079
Subscribers
-124 hours
+77 days
+1730 days
Data loading in progress...
Similar Channels
No data
Any problems? Please refresh the page or contact our support manager.
Tags Cloud
Incoming and Outgoing Mentions
---
---
---
---
---
---
Attracting Subscribers
September '26
September '26
+8
in 0 channels
August '26
+24
in 0 channels
Get PRO
July '26
+30
in 2 channels
Get PRO
June '26
+78
in 1 channels
Get PRO
May '26
+53
in 0 channels
Get PRO
April '26
+150
in 5 channels
Get PRO
March '26
+104
in 3 channels
Get PRO
February '26
+355
in 2 channels
Get PRO
January '26
+211
in 3 channels
Get PRO
December '250
in 1 channels
Get PRO
November '25
+157
in 1 channels
| Date | Subscriber Growth | Mentions | Channels | |
| 08 September | 0 | |||
| 07 September | 0 | |||
| 06 September | 0 | |||
| 05 September | +5 | |||
| 04 September | +3 | |||
| 03 September | 0 | |||
| 02 September | 0 | |||
| 01 September | 0 |
Channel Posts
| 2 | No text... | 403 |
| 3 | AI SDLC не помещается в один harness
Оригинальный пост в канале автора
С одной стороны небольшое решение для работы с сервером srv-explore, но если присмотреться Артем применил паттерны, которые должны быть встроены в AI SDLC любой компании.
Давай те посмотрим внимательней, у него с одной стороны, есть локальный harness разработчика, этот harness скорее всего оброс привычками этого разработчика, у него установлены любимые skills и доступен контекст проекта не только как кода, но и знаний. С другой — удалённый агент, настроенный под управление удаленным сервером и сбором метрик с него. Если посмотреть на мой прошлый разбор AI SDLC Сегодня можно увидеть, что обычно решения концентрируются вокруг одного из этих вариантов решения. Что может дасть процессу разделения harness на личный и общественный и их одновременную работу?
Несколько одновременно работающих harness сохраняют нужный контекст, ограничивают автономию местом её применения и освобождают процесс от одного исполнителя.
Первый выигрыш — не приходится тащить весь контекст в одно место. Локальный агент остаётся моим рабочим интерфейсом, а серверный знает свои логи, сервисы и инструменты. Через MCP второй просто появляется среди tools первого.
Локальный и удалённый `harness` работают одновременно, каждый в своём контексте.
Второй выигрыш — автономию можно выдавать адресно. Серверный агент сам ищет путь к ответу, но делает это внутри отдельной песочницы. Его системный prompt требует вернуть факты и команды; гипотезы и решения остаются у локального агента. Я бы ещё дал такому контуру пространство для исследовательских скриптов.
Свобода агента заканчивается вместе с границей его среды и ответственности.
Третий выигрыш — процесс меньше зависит от конкретного исполнителя. MCP отделяет локальный контур от серверного, поэтому их можно менять независимо, пока сохраняется контракт результата. Да и harness на удалённой части строго не привязан к производителю, сейчас это Claude Agent SDK, но его легко поменять на OpenCode.
Harness становится переменной, а роль и handoff остаются.
Поэтому я бы не собирал AI SDLC вокруг одного полюса. Раздать всем skills для локального harness — оставить процесс на личных средах. Загнать всех в удалённые процессы — потерять персональный контекст. Архитектура должна соединять оба контура.
О чём молчит AI CTO | 559 |
| 4 | No text... | 863 |
| 5 |  Выступал на ИТ-Пикнике с докладом "Джентельменский набор продакшен GenAI инфраструктуры". Собрал воедино решения, которые мы несколько лет строили в Т-Банке вокруг генеративных моделей. Разложил их по логическим слоям и получился вот такой джентельментский набор архитектурных кубиков для GenAI. В самом докладе рассказывал какие из этих кубиков когда нужны (выложил презентацию в комментариях). | 1 |
| 6 | Джентльменский_набор_GenAI.pdf | 1 |
| 7 | No text... | 943 |
| 8 |  Рекомендую к просмотру
Подкаст вышел про тему мертвого интернета и в целом про возможности ИИ от интересный ребят =)
Эпизод уже тут YouTube и в VK | 663 |
| 9 |  243-ФЗ: происхождение большой LLM становится частью архитектуры
26 июля подписан Федеральный закон № 243-ФЗ «О поддержке развития технологий искусственного интеллекта в Российской Федерации». Он вводит понятие большой фундаментальной модели, два специальных статуса для российских моделей и право Правительства определять случаи, когда можно применять только модели с такими статусами.
Разберёмся, что именно меняет новый закон и почему происхождение большой LLM теперь необходимо учитывать при проектировании продукта.
Что закон считает большой моделью
Термин в законе шире привычного понятия LLM. Большой фундаментальной моделью считается программа, которая одновременно:
- содержит не менее одного миллиарда параметров
- выполняет большое количество разных задач
- служит основой для создания или доработки другого программного обеспечения
- выдает результаты на уровне интеллектуальной деятельности человека или выше
Порог в один миллиард параметров сам по себе не делает модель большой фундаментальной. Поэтому специализированные модели для классификации, распознавания или прогнозирования, скорее всего, останутся за пределами определения даже при значительном размере. Важны свойства самой модели, а не конкретный бизнес-сценария, в котором она используется.
Два статуса российской модели
Закон вводит два статуса для больших моделей: суверенный и национальный.
Суверенную модель разрабатывает российское юридическое лицо, которое контролирует весь жизненный цикл и способно технически воспроизвести разработку, включая обучение. Ответы пользователям формируются, а данные хранятся в российских центрах обработки данных, принадлежащих российским юридическим лицам.
В национальной модели существенные характеристики, программное обеспечение и настраиваемые параметры определяет российское юридическое лицо. При ее создании можно использовать российские и зарубежные компоненты, включая другие большие модели, если они распространяются по открытой лицензии. Требования к российским центрам обработки данных сохраняются.
Для обоих статусов понадобится подтверждение соответствия законодательству и традиционным духовно-нравственным ценностям. Процедуру должно установить Правительство.
Какие инструменты создает закон
Разработчики суверенных и национальных моделей смогут получать государственную поддержку. Закон также создает механизм доступа к данным государственных информационных систем для обучения. Конкретный порядок еще предстоит определить.
Отдельная льгота касается охраняемых произведений. Компьютерный анализ и краткосрочная запись материала в память машины не считаются нарушением авторских и смежных прав, если это делается исключительно для обучения суверенной или национальной модели. Разработчик должен правомерно получить экземпляр произведения либо работать с опубликованным материалом, доступным для анализа без технических ограничений. Это касается авторских и смежных прав и не отменяет требования о персональных данных, коммерческой тайне, конфиденциальной информации и условиях договора.
Еще один инструмент — право Правительства определять случаи, где разрешены только суверенные или национальные модели. Для финансового рынка такие решения согласовываются с Банком России. Перечня случаев пока нет. Именно он покажет, насколько сильно закон повлияет на выбор моделей в государственных, финансовых и других чувствительных системах.
Основная часть закона вступает в силу 1 сентября 2026 года. Требования к специальным статусам и ряд прикладных норм начнут действовать 1 марта 2027 года.
Что это значит для нас с вами
Закон создает общий словарь и полномочия для следующего этапа регулирования. Порядок присвоения статусов, отраслевые ограничения и требования к рискам появятся в подзаконных актах. Самое интересное впереди: следующие правила будут опираться на уже определенные категории, а происхождение модели станет либо ограничением, либо возможностью.
«Новый закон является рамочным, направлен именно на развитие ИИ и не содержит каких-то запретов», — констатировал Дмитрий Григоренко.
«СенатИнформ», 17 июля 2026 года
О чем молчит AI CTO | 984 |
| 10 | AI-трансформация начинается не с платформы, а с одного процесса
Microsoft выпустила The AI Strategy Roadmap — 66-страничную методичку о том, как перейти от разрозненных AI-пилотов к организации, в которой AI встроен в основные бизнес-процессы.
Материал основан на интервью с 70 руководителями бизнеса и IT, клиентском опыте и внутренней трансформации самой Microsoft.
Главная мысль:
У большинства компаний нет дефицита AI-идей. У них нет механизма, который превращает отдельный успешный пилот в повторяемую организационную способность.
Microsoft называет это целевое состояние Frontier Transformation: AI перестаёт быть личным инструментом отдельных сотрудников и становится частью работы всей компании — от ключевых процессов до принятия решений.
Они выделяют 5 стадий:
1. эксперименты
2. планирование
3. внедрение
4. масштабирование
5. AI становится стандартным способом выполнения работы
Сначала компания проверяет гипотезы, а затем превращает успешные эксперименты в устойчивую систему, которая работает в масштабе всего бизнеса. Чтобы двигаться по этому пути, Microsoft предлагает одновременно развивать пять направлений:
1. Бизнес-стратегия — какие проблемы решаем и по каким бизнес-метрикам определяем успех.
2. Технологии и данные — готовность данных, общая платформа, наблюдаемость и надёжность.
3. AI-стратегия и пользовательский опыт — доверие, внедрение в реальные процессы и обратная связь.
4. Организация и культура — новые роли, навыки, стимулы и модель работы людей с агентами.
5. Управление и безопасность — единые правила, контроль доступа, реестр систем и управление всем жизненным циклом AI.
Повторяющийся паттерн внедрения простой: начинать нужно не с большой AI-стратегии, а с одного узкого процесса, где можно быстро показать результат без лишнего риска. Такой пилот нужен не только ради ROI — на нём компания учится доводить AI-решение до устойчивой работы и сразу строить его как будущую часть бизнеса, а не одноразовый эксперимент.
Когда модель уже достаточно хорошо решает выбранную задачу, масштабирование начинает упираться в устройство самой компании. Microsoft предлагает для этого центр компетенций — команду, которая не забирает проекты себе, а задаёт единый путь от идеи до запуска. В самой Microsoft его усилили после того, как разные подразделения начали создавать похожие решения по разным правилам. Такой центр сокращает повторную работу и помогает успешным пилотам быстрее и безопаснее становиться частью бизнеса.
По мере роста числа проектов ими предлагают управлять уже не как набором независимых экспериментов, а как единым портфелем. Компания регулярно пересматривает результаты и перераспределяет внимание и инвестиции в пользу решений, которые действительно создают ценность.
Microsoft связывает 67% полученной от AI ценности с организационными факторами. В самой методичке эта цифра почти не расшифрована, но вывод понятен: одних технологий недостаточно — компании придётся изменить сам способ работы, чтобы люди задавали направление и оценивали результат.
Документ местами предсказуем и заметно ведёт к экосистеме Microsoft. Но как управленческая карта он хорошо фиксирует следующее:
Масштабируется не пилот, а способность компании снова и снова превращать подходящие задачи в работающие AI-решения.
О чем молчит AI CTO | 945 |
| 11 |  История технологии, которая появилась раньше своего времени
Сначала Java выглядела как эксперимент. Небольшая группа инженеров создавала её для будущего рынка, которого ещё не существовало. Первые продукты не стали массовыми, первоначальная ставка не сработала, а сам проект оказался близок к закрытию.
Но внутри неудачного продукта сохранилась сильная идея: отделить намерение разработчика от конкретной среды исполнения и позволить одному решению работать в разных контекстах. Некоторое время эта идея оставалась интересной только инженерам. Затем изменилась сама индустрия — появилась новая вычислительная среда, в которой прежние ограничения стали особенно заметны.
В 1995 году технологию представили уже не просто как очередной инструмент, а как новый принцип создания программных систем. Начался взрыв ожиданий: компании запускали проекты, разработчики осваивали новый подход, инвесторы увидели огромный рынок. Казалось, что новая технология полностью заменит прежние способы работы.
Но первые массовые приложения оказались слабее обещаний. Они были медленными, нестабильными и плохо подходили для серьёзных систем. Началось разочарование, а сценарий, благодаря которому технология стала известной, постепенно потерял прежнее значение.
Однако исчезла не технология. Исчезло первое представление о том, для чего она нужна. Пока рынок обсуждал яркие демонстрации, Java проникала в инфраструктуру. Вокруг неё появились инструменты, стандарты, библиотеки и сообщество, а на её основе начали создавать критически важные системы.
Так отдельный инструмент превратился в платформу. Она не заменила всю индустрию и не выполнила все ранние обещания, но изменила базовые ожидания разработчиков и заставила даже конкурентов принять её ключевые принципы.
Это история технологии, которая появилась раньше подходящего для неё мира. Первый продукт не взлетел, первый массовый сценарий оказался временным, но фундаментальная идея была верной.
И 1995 год стал не годом появления законченной технологии, а моментом, когда стало видно направление движения.
А теперь замените Java на GenAI, а 1995 год, на 2025 год.
Документальный фильм: The Java Story
О чем молчит AI CTO | 806 |
| 12 | Мое внимание привлек Making of Claude Code. Очень рекомендую открыть режим терминала.
Там команда вспоминает как появился Claude CLI, который Борис Черный собрал примерно за два дня и сам не до конца понимал, что именно получилось. Ранний доступ встретили прохладно, но команда читала обратную связь и быстро выпускала исправления. Благодаря автообновлениям фикс мог оказаться у пользователя через пять минут.
Вера команды в продукт и внимательное отношение к обратной связи сделали его по-настоящему полезным.
О чем молчит AI CTO | 902 |
| 13 |  AI-тарификация. Часть 2/2
Начало
Тарификация людей с AI
А как тарифицировать работу людей с AI? Ведь когда мы говорим про AI, кажущаяся бесплатность отдельного шага очень легко превращается в иллюзию бесплатности человека с AI.
Уже сейчас генерация изображений, суммаризация, поиск, первый вариант веб-приложения почти ничего не стоят, и некоторые клиенты, не разобравшись, начинают делать вывод, что результат человека с AI тоже должен стоить почти ничего.
Параллельно растет неравноправие людей. Раньше внутри одной роли была понятная вилка: тот же Middle backend developer мог быть сильнее или слабее, быстрее или медленнее, но рынок, процессы и ожидания роли довольно быстро сжимали разброс.
Теперь AI эти границы растягивает: один человек использует ассистента как автодополнение и ускоряет старый процесс, пока другой собирает вокруг себя рабочий контур с обратной связью. Формально роль одна и та же, но производительность может отличаться в разы. Мне известны случаи, когда стали использовать не самые качественные метрики по количеству MR и строк кода, а затем выявлять слабые звенья с последующим увольнением.
Консалтинг чувствует изменения
Очень хорошо заметны изменения в консалтинге, к которому я сейчас отношу себя в той или иной степени. Клиенты видят, что работа становится быстрее с агентами, и часто просят скорости и маленьких команд, а нам приходится справляться, создавая Tiny Teams.
В прошлом году мы столкнулись с большим сопротивлением в командах: ну кто захочет становиться фронтендером, если развивает себя как бизнес-аналитика? Или как собрать эту команду из текущих доступных ресурсов, когда команды всегда делились на специальности?
Этот год расставляет приоритеты: вижу в окружении понимание, что по-другому работать будет практически невозможно.
И как же зарабатывать компаниям, предоставляющим подобные услуги, если старая единица сравнения не работает? Там прямо сейчас мучительно уходят от оплаты часов, потому что AI ломает старую связку между размером команды и ценностью результата.
Если сильный человек с AI делает работу маленькой команды, продавать размер команды становится все сложнее. Хотя это понимал и Марвин Бауэр, неформальный основатель McKinsey & Company, он говорил в 1941 году:
"You cannot measure value by hours. Lawyers don't and we shouldn't."
То есть ценность нельзя мерить часами, но ими так удобно клиентам сравнивать консультантов друг с другом, ожидая одинаковую ценность и ища наименьшую стоимость.
Цена надежности
А какую ценность могут приносить внешние подрядчики в AI-сфере? Как правило, это создание надежного, масштабируемого и поддерживаемого бизнес-процесса, оптимизирующего текущие процессы или приносящего новые возможности для заработка, где цена ошибки может быть достаточно высока. Иначе зачем их подключать?
И здесь нужно быть осторожнее с экономическими ожиданиями, потому что хорошо помню интересную закономерность из опыта работы в научно-исследовательском институте.
Мы занимались гироскопами на разных физических принципах: атомными, волоконно-оптическими, механическими, вибрационными. На уровне физики — это разные устройства, на уровне инженеров — разные школы, даже на уровне страны — разные заводы. Но когда нужно выйти на один и тот же класс космически малой ошибки, стоимость вдруг сходится к одному большому порядку величины
С AI, как мне кажется, происходит похожая история: как только цена ошибки возрастает, стоимости решений с AI и без AI начинают сходиться к одной большой величине.
⬥⬥⬥
Получается диссонанс между старой и новой экономикой.
Старая экономика привыкла видеть человека в процессе и брать деньги рядом с этим человеком. Новая пока выглядит непривычно: то токены по подписке, то запрос к сайту за деньги, то маленькая команда вместо большой, то агентский слой вместо привычного интерфейса.
И это происходит потому, что человек из середины процесса исчезает, а агентские действия начинают потреблять чужие данные, интерфейсы, вычисления и доверие.
Бизнесу приходится искать новые механизмы, но какие из них будут востребованы, покажет только время.
О чем молчит AI CTO | 935 |
| 14 |  AI-тарификация. Часть 1/2
AI ломает не только интерфейсы, но и привычные единицы экономического учета. Когда действие выполняет агент, становится непонятно, за что брать деньги: за час человека, за запрос машины, за доступ к данным, за поручение или за достигнутый результат.
Старая экономика считала человека
Сегодняшняя экономика привязана к человеку внутри процесса. Консалтинг продает человеко/часы, YouTube показывает рекламу, маркетплейс берет комиссию. Вокруг действий человека и его цифровых следов выстраиваются продуктовые метрики и маркетинговая стратегия.
AI-агенты начинают вытаскивать человека из этого процесса. Человек формулирует намерение, а дальше ассистент читает, сравнивает, делает заказ и приносит результат. Если оценивать такую работу в агенто/часах, она выглядит почти бесплатной. Только агент равнодушен к рекламе, не обязан ходить по витринам, не оставляет привычный след в интернете и не проходит продуктовую воронку так, как ее рисовали последние двадцать лет.
Человеческие потребности при этом не исчезли: нам все так же нужно вызывать такси до аэропорта, покупать смартфоны на маркетплейсах, выбирать подрядчиков для ремонта ванной комнаты, разбираться в многостраничных документах за минуты и просто принимать решения. По факту сейчас меняются привычки людей, интерфейсы и место, где ценность превращается в деньги.
Я уже давно стал доверять Алисе подбор рецептов блюд, а не искать их в сети.
Агент становится новым интерфейсом
Раз мы заговорили про Алису, стоит упомянуть, что у Яндекса выстраивается целая экосистема: агенты Алисы встраиваются в Такси, Лавку и другие сервисы. Теперь Алиса не просто отвечает, а помогает выполнить поручение внутри продукта. Пользователь все меньше обязан идти по привычной цепочке экранов: он формулирует намерение и ждет исполнения.
Но как зарабатывать на контенте и рекламе в Лавке, если исполнитель — агент? Видимо, поэтому Cloudflare пробует брать плату с машинного потребления ресурса. Не с показа баннера, а с самого факта, что ресурс был использован.
Это выглядит непривычно, но логика понятна: если старый способ монетизации зависел от человека на странице, а теперь ценность забирает машина, то бизнес будет искать способ поставить цену ближе к машинному потреблению.
Продолжение
О чем молчит AI CTO | 548 |
| 15 | Agent Driven SDLC: как меняется разработка в эпоху ИИ
Ребята из Selectel помогли оформить выступление с конференции «МЛечный путь 2026» в статью на Хабре. Спасибо их команде за приглашение, хорошую организацию конференции и помощь с текстом. Ценно, когда доклад после сцены превращается в подобный материал.
- Статья
- Запись доклада
О чем молчит AI CTO | 542 |
| 16 |  Из чего состоит AI-бенчмарк
Недавно мы в red_mad_robot выпустили открытый benchmark для детекции персональных данных в русском тексте. Внутри данные, собранные из реальных продакшен-сценариев.
Параллельно Валера Ковальский сравнивает Drift и другие агентные оболочки на наборе открытых benchmark как дополнительная обратная связь для продукта.
Ранее я писал, что главный инженерный вызов в агентных системах сейчас связан с качеством обратной связи и создатель Claude Code Борис Черный недавно подтвердил эту мысль: «Переход от агентов к loops - такой же большой скачок, как когда-то переход от обычного кода к агентам». Но loop работает, только если система умеет определить ошибку и понять, стоит ли продолжать работу.
Поэтому я решил разобрать семейство открытых бенчмарков τ-bench. Первая версия проверяла общение агента с пользователем и работу с tools. В τ²-bench пользователь получил возможность действовать в среде, а не только отвечать агенту. А τ³-bench добавил задачи с базами знаний, голосовой режим испытаний и набор исправлений в сценариях. Разбирать такой benchmark удобнее через четыре слоя. Покажу их на одном сценарии:
Yusuf Rossi получил заказ #W2378156 и хочет обменять клавиатуру и термостат. Нужная клавиатура с подсветкой недоступна, поэтому пользователь согласен на модель без неё. Провести обмен можно только один раз.
⬥⬥⬥
1. Слой данных и среды
Первый слой создаёт мир, в котором работает агент: данные, связи между ними и последствия действий. Например, в домене Retail, который моделирует интернет-магазин, это пользователи, товары, их варианты, заказы и платежи.
Так появляется Yusuf Rossi, доставленный заказ, две купленные позиции и доступные варианты. Клавиатура существует на двух уровнях, как тип товара product_id, так и конкретная версия с размером и подсветкой item_id. Поэтому агент может подобрать другой вариант той же клавиатуры, но не заменить её термостатом.
Среда определяет, как агент работает с данными: одни инструменты ищут пользователя и заказ, другие меняют состояние. В банковском домене добавляется корпоративная неструктурированная база знаний с регламентами. Агент ищет правило в документах и применяет его к ситуации.
⬥⬥⬥
2. Методология
Методология определяет, какое поведение считается правильным. Сценарий задаёт желание пользователя: Yusuf хочет заменить две позиции и решить всё за один разговор.
Дальше вступают бизнес-ограничения. Правила магазина требуют подтвердить личность, менять только товары из доставленного заказа и получить согласие. Для нашего сценария критично: обменять модно только один раз, поэтому обе позиции нужно подготовить заранее. Из данных это не следует, правило живёт на уровне бизнеса.
Критерии успеха фиксируют итог: в заказе появляются нужные варианты клавиатуры и термостата, пользователь получает возврат разницы на карту, агент объясняет условия и дожидается подтверждения.
⬥⬥⬥
3. Слой исполнения
Симулятор раскрывает запрос Yusuf. Агент уточняет детали, читает заказ, подбирает варианты и решает, когда проводить обмен. Оркестратор передаёт реплики, направляет вызовы в среду и пишет журнал.
В голосовом режиме добавляются задержки, шум, перебивания и ошибки распознавания имени или подтверждения.
⬥⬥⬥
4. Слой оценки
Последний слой превращает испытание в результат: к какому состоянию агент привёл мир.
Оценщик строит эталон из правильных действий. Для Yusuf это заказ, где обе позиции заменены одним вызовом, а разница возвращена на карту. Затем оценщик сравнивает состояние после действий агента с эталоном, если совпало — задача пройдена. Что входит в проверку, задаётся отдельно: состояние базы, обязательная информация в ответе или утверждения на естественном языке. У Yusuf всё держится на состоянии базы.
Для надежности добавляется повторяемость: агент должен пройти одну задачу несколько раз подряд. Один удачный прогон плохо описывает надёжность.
τ³-bench хороший пример устройства benchmark. И он же показывает, что такой инструмент требует отдельной работы: данных, сценариев, среды, оценщика и постоянной чистки ошибок в самих задачах.
видео
О чем молчит AI CTO | 710 |
| 17 |  Внешний skill ≠ безопасный skill
NVIDIA выпустила SkillSpector. Он проверяет skills на prompt injection, кражу данных, опасный код и уязвимые зависимости. Можно сканировать папку, файл или GitHub-репозиторий. Базовая проверка работает локально без LLM.
Полезная привычка: прогонять через него каждый внешний skill перед установкой.
#Skill
О чем молчит AI CTO | 859 |
| 18 |  Как Product Engineer может собирать интерфейсы
За последние пару месяцев я собрал четыре прототипа: для геоаналитики, тендеров, обучения и работы с текстом. В нескольких случаях идея дошла до сервиса, которым пользуются десятки людей.
На этих проектах я понял, что одного Claude Code недостаточно.
Он хорошо реализует уже сформулированное решение. Но сначала идею нужно увидеть и собрать пользовательский сценарий. При работе с агентами результат часто прячется за полотном текста, но при этом непонятно, что увидит человек и как он будет пользоваться сервисом.
Для меня рабочая схема сложилась так:
Stitch → Claude Design → Claude Code + Impeccable
⬥⬥⬥
Stitch для меня стал личным визуальным черновиком.
Сижу с чашкой чая, надиктовываю мысли о новом приложении и наблюдаю, как рядом появляются экраны. Пока смотришь, в голове возникают следующие вопросы: что должно быть на главной, нужен ли отдельный экран, где пользователь увидит результат.
Я никогда не показываю эти черновики. В них можно зачеркнуть всё и начать сначала. Их задача в другом: помочь мне самому понять верхнеуровневый стиль, состав экранов и основной use case.
Stitch пока сырой. Русскую речь он понимает, но часто переводит разговор на английский. Голосовой режим хорошо подходит для момента, когда мысль проще проговорить, чем превратить в требования.
Отдельно я бы смотрел на DESIGN.md. Google развивает его как формат, через который можно объяснить дизайн агентам. В моём процессе этот файл дальше становится частью общего контекста разработки.
Из Stitch я выхожу, когда сценарий стал ясным у меня в голове.
⬥⬥⬥
В Claude Design черновик превращается в прототип, который уже можно обсуждать.
Здесь я прохожу конкретные use cases: переходы, формы, всплывающие окна и состояния интерфейса. Что увидит пользователь после действия? Как выглядит ошибка? Что произойдёт, если данных пока нет?
Если основной клиент продукта я сам, прототип согласовываю с собой. Если есть Product Owner, показываю ему. Для прототипа этого достаточно: нужно зафиксировать основной сценарий, ключевые состояния и визуальное направление.
Самая полезная часть Claude Design в моём процессе связана с GitHub. Согласованный прототип превращается в код, после чего источником истины становится репозиторий.
⬥⬥⬥
Дальше начинается полноценная разработка. В какой-то момент над бэклогом одновременно работают несколько агентов: добавляют функции, закрывают задачи, чинят баги.
И тут интерфейс начинает расплываться.
Каждый агент может нормально решить свою локальную задачу, а вместе они принесут разные отступы, компоненты и представления о хорошем UX. Поэтому агенты получают PRODUCT.md, DESIGN.md и прогоняют Impeccable на своей части работы.
Impeccable даёт им общий язык frontend-качества. Он замечает лишние контейнеры, слабую визуальную иерархию, случайные цвета, отсутствие состояний и плохую адаптивность.
При этом инструмент достаточно самостоятелен. Если экран и сценарий уже понятны, Stitch можно пропустить. Для небольшой доработки я сразу иду в Claude Code с Impeccable.
⬥⬥⬥
Claude Code остаётся ядром разработки, но одного универсального агента мало. На разных этапах нужны свои усилители: один помогает додумать идею экраном, другой собирает сценарий, третий удерживает качество реализации.
Порог входа в смежные роли снизился. Product Engineer может быстрее освоить их рабочий минимум, задавать более точные вопросы и самостоятельно собирать прототипы. Инструменты не делают его дизайнером или frontend-экспертом. Они дают практику и обратную связь, через которые постепенно появляется новая компетенция.
Здесь же находится риск. AI усиливает то, что вы уже умеете, и выдаёт убедительный результат там, где знаний пока не хватает. Нужно различать собственную компетенцию и качество ответа модели.
Инструменты позволяют одному человеку пройти больше этапов разработки. Вместе с этим растёт число решений, за которые он отвечает.
Какие специализированные усилители вы уже добавили вокруг Claude Code, чтобы закрыть свои слабые зоны?
#ProductEngineering
О чем молчит AI CTO | 998 |
| 19 |  Если раньше весь бизнес можно было вести в Excel (а позже в Google Sheets), то теперь нам нужен только один инструмент - Codex (ну или Claude).
Внедренная система плагинов позволяет автоматизировать процессы не выходя за рамки инструмента с умным ассистентом, пишем код, заказываем пиццу, строим продуктовые dashboards и выбираем фильм на вечер, и все это, не закрывая Codex. Там обрабатывается входящая почта, анализируются таблицы и составляются презентации. А многие и TG почти автоматизировали %)
Но чтобы научить всех пользоваться этими инструментами правильно, Anthropic и OpenAI идут в консалтинг и собираются обучать специалистов по внедрению своих наработок в бизнес. Кажется, Windows и Excel пора подвинуться в сторонку.
Но есть и другая правда, одного AI недостаточно, что бы делать большие, надежные и масштабируемые сервисы.
О чем молчит AI CTO | 840 |
| 20 |  Как ИИ меняет разработку изнутри: расскажем на закрытой сессии red_mad_robot
ИИ в разработке уже прошёл этап личных экспериментов: почти все подключают его к задачам, ускоряют рутину и видят первые результаты. Но эффект часто остаётся локальным и не меняет процесс системно.
28 мая в офисе red_mad_robot посмотрим, как перевести этот опыт на уровень команды: через практику инженера, лида и тех, кто отвечает за результат.
В программе — три практических блока:
1️⃣ Куда движется рынок и почему техкоманды становятся компактнее
2️⃣ Как переосмысляются роли в команде, а спецификации, тесты и архитектура превращаются в основу работы и продуктовых решений
3️⃣ Как строить AI-native команду QA и почему все начинается с лида
Встреча пройдёт 28 мая в 18:00 в нашем офисе. Формат закрытый (количество мест ограничено), но если интересно, то оставляйте заявку через @redmadmadbot.
#AI_moment #роботайм
↗️ red_mad_robot | 819 |
