Соглашусь с мыслью про паузу, но добавлю уточнение.
Аналитика не бесполезна, она просто не спасает, если решение уже принято из состояния (страха, спешки, желания снять напряжение), а обсуждение идёт для галочки. Это выглядит как коллективная игра в процесс, где цель размазать ответственность. Хорошая практика брать время на подумать заранее: чаще контекст прилетает не сегодня на вчера, и окно для анализа почти всегда есть. В идеале аналитика должна дать 2–3 осмысленных варианта и критерии выбора. А архитектура - да, должна позволять долго не фиксировать детали и держать опции открытыми до последнего ответственного момента. Тогда решения принимаются не реактивно, а осознанно.
Про over-engineering / трейсы. Да, ручной tracer.Enter в каждую функцию, мягко говоря, архитектура через страдания. Я сам от этой идеи не в восторге: добавлять boilerplate, чтобы потом бороться с техдолгом звучит как так себе. Если можно обойтись без runtime трейсинга я первый буду рад.
Но про "достаточно rules / tree / project awareness" у меня опыт хуже. Я реально пробовал решать это правилами: claude.md, rules, как следовать практикам, ограничения, чеклисты. И паттерн повторяется:
на старте, когда агент подгружает контекст, он ещё более-менее следует правилам. через какое-то время (особенно в длинной имплементации) начинает дрейфовать: упрощает, забывает запреты, выбирает короткий путь.
Самый показательный кейс: много раз видел, как Клод ломал тесты, потом чинит-чинит, и в итоге… скипает. При том что СКИПАТЬ ТЕСТЫ ЗАПРЕЩЕНО!!! было явно и жирно прописано как критичное правило. То есть проблема не в том, что правила плохие проблема в том, что агент не гарантирует их соблюдение.
Поэтому я не считаю, что внешняя валидация = Лечение симптомов. Для меня это скорее страховка от неизбежного дрейфа. Контекст-менеджмент нужен, да. Но он не заменяет механизм остановись и докажи, что не сломал инварианты, особенно когда агент уже вошёл в режим лишь бы прошло.
я готов признать:
да, трейсы спорный инструмент; да, хочется решения без вживления проводов в каждую функцию; и да, если найдётся устойчивый способ заставить агента стабильно соблюдать rules я буду только рад и с удовольствием перейду на него.
Согласен. Сам столкнулся с этой дилеммой и пока не нашёл хорошего решения. С одной стороны не хочется писать голословно, с другой глубоко верифицировать каждую ссылку нереалистично по времени. Думаю в сторону одного фокуса, писать про свое мнение из опыта.
Спасибо, справедливо замечено про размер выборки. Я ссылку добавлял как почитать первоисточник тем, кому интересно, а не как попытку закрыть вопрос авторитетом. Не ожидал, что это будет восприниматься как антипаттерн, в следующий раз подумаю как лучше это оформить.
Да, роль меняется, это не новость, об этом говорят не первый год. Но я бы уточнил.
По первому вопросу: разработчики действительно смещаются в сторону системного анализа и проектирования. Плюс резко растет навык ревьюера т.к. при работе с AI-агентами это становится основным циклом: задача -> ревью -> ревью -> ревью.
При этом я разделяю две сферы:
Системная разработка (драйверы, ядра финансовых/медицинских сервисов и т.д. ) - там еще надо думать, как применять AI-агентов
Бизнес-логика - вот тут спецификации работают отлично
По второму вопросу: не только системный анализ. Я экспериментирую с цепочкой: цель -> objectives -> эпики -> стори -> задачи. Вместо BPMN использую Activity или Sequence диаграммы так как они так же описывают процесс.
Это большая исследовательская работа, требующая отдельного фокуса. Но сейчас именно это мой основной вектор: системный анализ и автоматизация разработки.
А вот что меня реально интересует: куда в этой картине входят джуны? Раньше путь был понятен - пишешь код, набиваешь руку. А сейчас?
И обратная сторона - текущие системные аналитики. У многих нет технической базы, кода не писали. Им куда - глубже в бизнес-анализ? Или придется доучиваться?
Black-box reproduction: без доступа к исходникам. Агенту даём API/доки/примеры запрос-ответ, возможно тестовый стенд. Тогда задача воспроизвести поведение, то что описано в статье.
White-box reproduction: с доступом к репозиторию. Тут у меня есть сомнение: в зависимости от лицензии посмотрел код и повторил может стать проблемой, в силу того что агент может взять некоторые куски кода как есть.
Согласен, подход рабочий. Но здесь есть важный момент: при таком подходе специалист фактически превращается в оператора ИИ. И требования к этому оператору по уровню близки к сеньору, нужно уметь быстро ревьюить, понимать логику, держать модель в голове, знать подходы и шаблоны.
Возникает вопрос: как в такой модели расти новичкам? Вчерашний студент просто не обладает этим багажом, и без него он не сможет эффективно управлять ИИ.
Мне кажется, текущая ситуация не даёт ответа, как выстраивать карьерный путь в такой новой реальности.
бизнес видит что с ИИ можно доставлять быстрее. бизнес сам им пользуется для валидации идей, для постановки задач, для контроля. очень заманчиво ввести промпт:
Сформируй недельный отчёт по всем инициативам, за которые я отвечаю как BusinesRole. Используй только данные из TaskTracker, CorpWiki,GitLab. Период последние 7(30) дней.
Добавь анализ пробелов, слабых звеньев, узких мест: где не хватает информации, где отсутствует прогресс, где есть организационные или технические провисания.
Согласен, вместе с тем всех не отревьюишь, запретить использовать тоже сложно - соответственно необходимы механизмы контроля, я думаю что это один из векторов развития
Думаю, индустрия неизбежно придёт к строгим механизмам контроля агентов. Отказаться от их использования уже невозможно, но запускать их в продакшн без оконтроля, в ряде областей очень рискованно.
с тестами есть еще история про то что, пытаясь их пофиксить макака все чаще стала принимать решение - тест не проходит - отключу тест - линтер не проходит - отключу
и даже явный запрет в инструкциях не всегда помогает.
по поводу детализации промптов - согласен, времени уходило очень много. Работа с промптами напомнила мне ситуацию когда я осваивал TDD в 2008. Тогда написание тестов требовало очень много времени, и тесты получались такими что рефакторинг делать с ними было очень сложно, приходилось тесты отключать и по новой писать. Но ничего, эта инвестиция времени была полезной
да, здесь согласен. идея spec driven очень близка. сейчас тестирую этот подход в том числе. однако вопрос с качеством кода все также остается. ревьюить все изменения утомляет и на редактирование кода достаточно быстро выдаешь право делать это автоматом.
по ощущениям, Google с Gemini сильно отстаёт от OpenAI и Anthropic. Ответы - менее точные, UX - не разобрался еще. Пока ощущается как догоняющий, а не ведущий.
Кстати, форматирование в стиле GPT - постепенно становится привычным. Читать по шаблону быстрее, чем линейный текст. Это не просто удобно - это ответ на повышающийся объём поступаемой информации.
да да да, сделал я портирование списка контактов из Агента в Жабер,
в Агенте список пропал — «Спасибо жаберу! Все собирался почистить контакт лист!»
вот только не думал что хочу избавится от всего списка сразу )
Соглашусь с мыслью про паузу, но добавлю уточнение.
Аналитика не бесполезна, она просто не спасает, если решение уже принято из состояния (страха, спешки, желания снять напряжение), а обсуждение идёт для галочки. Это выглядит как коллективная игра в процесс, где цель размазать ответственность. Хорошая практика брать время на подумать заранее: чаще контекст прилетает не сегодня на вчера, и окно для анализа почти всегда есть. В идеале аналитика должна дать 2–3 осмысленных варианта и критерии выбора. А архитектура - да, должна позволять долго не фиксировать детали и держать опции открытыми до последнего ответственного момента. Тогда решения принимаются не реактивно, а осознанно.
Понял твою мысль и частично соглашусь.
Про over-engineering / трейсы.
Да, ручной tracer.Enter в каждую функцию, мягко говоря, архитектура через страдания. Я сам от этой идеи не в восторге: добавлять boilerplate, чтобы потом бороться с техдолгом звучит как так себе. Если можно обойтись без runtime трейсинга я первый буду рад.
Но про "достаточно rules / tree / project awareness" у меня опыт хуже.
Я реально пробовал решать это правилами: claude.md, rules, как следовать практикам, ограничения, чеклисты. И паттерн повторяется:
на старте, когда агент подгружает контекст, он ещё более-менее следует правилам. через какое-то время (особенно в длинной имплементации) начинает дрейфовать: упрощает, забывает запреты, выбирает короткий путь.
Самый показательный кейс: много раз видел, как Клод ломал тесты, потом чинит-чинит, и в итоге… скипает. При том что СКИПАТЬ ТЕСТЫ ЗАПРЕЩЕНО!!! было явно и жирно прописано как критичное правило. То есть проблема не в том, что правила плохие проблема в том, что агент не гарантирует их соблюдение.
Поэтому я не считаю, что внешняя валидация = Лечение симптомов.
Для меня это скорее страховка от неизбежного дрейфа. Контекст-менеджмент нужен, да. Но он не заменяет механизм остановись и докажи, что не сломал инварианты, особенно когда агент уже вошёл в режим лишь бы прошло.
я готов признать:
да, трейсы спорный инструмент;
да, хочется решения без вживления проводов в каждую функцию;
и да, если найдётся устойчивый способ заставить агента стабильно соблюдать rules я буду только рад и с удовольствием перейду на него.
Согласен. Сам столкнулся с этой дилеммой и пока не нашёл хорошего решения. С одной стороны не хочется писать голословно, с другой глубоко верифицировать каждую ссылку нереалистично по времени. Думаю в сторону одного фокуса, писать про свое мнение из опыта.
Спасибо, справедливо замечено про размер выборки. Я ссылку добавлял как почитать первоисточник тем, кому интересно, а не как попытку закрыть вопрос авторитетом. Не ожидал, что это будет восприниматься как антипаттерн, в следующий раз подумаю как лучше это оформить.
спасибо, это полезно. буду работать над оформлением.
Да, роль меняется, это не новость, об этом говорят не первый год. Но я бы уточнил.
По первому вопросу: разработчики действительно смещаются в сторону системного анализа и проектирования. Плюс резко растет навык ревьюера т.к. при работе с AI-агентами это становится основным циклом:
задача -> ревью -> ревью -> ревью.
При этом я разделяю две сферы:
Системная разработка (драйверы, ядра финансовых/медицинских сервисов и т.д. ) - там еще надо думать, как применять AI-агентов
Бизнес-логика - вот тут спецификации работают отлично
По второму вопросу: не только системный анализ. Я экспериментирую с цепочкой:
цель -> objectives -> эпики -> стори -> задачи.
Вместо BPMN использую Activity или Sequence диаграммы так как они так же описывают
процесс.
Это большая исследовательская работа, требующая отдельного фокуса. Но сейчас именно это мой основной вектор: системный анализ и автоматизация разработки.
А вот что меня реально интересует: куда в этой картине входят джуны? Раньше путь был понятен - пишешь код, набиваешь руку. А сейчас?
И обратная сторона - текущие системные аналитики. У многих нет технической базы, кода не писали. Им куда - глубже в бизнес-анализ? Или придется доучиваться?
Спасибо, интересная статья!
Я бы разделил ваш сценарий на два режима:
Black-box reproduction: без доступа к исходникам.
Агенту даём API/доки/примеры запрос-ответ, возможно тестовый стенд.
Тогда задача воспроизвести поведение, то что описано в статье.
White-box reproduction: с доступом к репозиторию.
Тут у меня есть сомнение: в зависимости от лицензии посмотрел код и повторил может стать проблемой, в силу того что агент может взять некоторые куски кода как есть.
Согласен, подход рабочий. Но здесь есть важный момент: при таком подходе специалист фактически превращается в оператора ИИ. И требования к этому оператору по уровню близки к сеньору, нужно уметь быстро ревьюить, понимать логику, держать модель в голове, знать подходы и шаблоны.
Возникает вопрос: как в такой модели расти новичкам? Вчерашний студент просто не обладает этим багажом, и без него он не сможет эффективно управлять ИИ.
Мне кажется, текущая ситуация не даёт ответа, как выстраивать карьерный путь в такой новой реальности.
для бизнеса.
бизнес видит что с ИИ можно доставлять быстрее. бизнес сам им пользуется для валидации идей, для постановки задач, для контроля.
очень заманчиво ввести промпт:
Сформируй недельный отчёт по всем инициативам, за которые я отвечаю как BusinesRole. Используй только данные из TaskTracker, CorpWiki, GitLab. Период последние 7(30) дней.
Добавь анализ пробелов, слабых звеньев, узких мест: где не хватает информации, где отсутствует прогресс, где есть организационные или технические провисания.
Согласен, вместе с тем всех не отревьюишь, запретить использовать тоже сложно - соответственно необходимы механизмы контроля, я думаю что это один из векторов развития
Думаю, индустрия неизбежно придёт к строгим механизмам контроля агентов. Отказаться от их использования уже невозможно, но запускать их в продакшн без оконтроля, в ряде областей очень рискованно.
с тестами есть еще история про то что, пытаясь их пофиксить макака все чаще стала принимать решение
- тест не проходит - отключу тест
- линтер не проходит - отключу
и даже явный запрет в инструкциях не всегда помогает.
по поводу детализации промптов - согласен, времени уходило очень много. Работа с промптами напомнила мне ситуацию когда я осваивал TDD в 2008. Тогда написание тестов требовало очень много времени, и тесты получались такими что рефакторинг делать с ними было очень сложно, приходилось тесты отключать и по новой писать. Но ничего, эта инвестиция времени была полезной
предпочитаю plantuml, однако в последнее время в чаще и чаще начинаю использовать mermaid
да, здесь согласен. идея spec driven очень близка. сейчас тестирую этот подход в том числе. однако вопрос с качеством кода все также остается. ревьюить все изменения утомляет и на редактирование кода достаточно быстро выдаешь право делать это автоматом.
учту
по ощущениям, Google с Gemini сильно отстаёт от OpenAI и Anthropic. Ответы - менее точные, UX - не разобрался еще. Пока ощущается как догоняющий, а не ведущий.
Кстати, форматирование в стиле GPT - постепенно становится привычным. Читать по шаблону быстрее, чем линейный текст. Это не просто удобно - это ответ на повышающийся объём поступаемой информации.
Спасибо, классная статья.
Освежил некоторые моменты.
скачал Psi
взял инструкцию и сделал step by step
Результат:
в Mail.Ru агенте список контактов пропал
(видимо руки кривые ))) )
жаббер тут не причем
но первое закомство не особо произвело впечатление
в Агенте список пропал — «Спасибо жаберу! Все собирался почистить контакт лист!»
вот только не думал что хочу избавится от всего списка сразу )