Latest / M365.FM – подкаст о Microsoft 365, Copilot и ИИ на русском / Хватит латать баги: режим агента GitHub Copilot для .NET и Azure (ИИ-дубляж)

Transcript

Хватит латать баги: режим агента GitHub Copilot для .NET и Azure (ИИ-дубляж) · M365.FM – подкаст о Microsoft 365, Copilot и ИИ на русском

0:00
Готовы к 10 дням погружения в Microsoft 365, Copilot и Azure и знакомство с людьми,
0:06
формирующими будущие работы. В этом январе M365Con возвращается, и мы расширяем границы.
0:12
Присоединяйтесь к нам для участия в живых сессиях, демонстрациях реальных проектов и получения
0:16
практических знаний от MVP и экспертов со всего мира. Никаких общих слайдов,
0:20
никаких пустых модных словарей. Мы решаем реальные задачи, Copilot Studio,
0:24
и агенты, фабрик, безопасность, управление и автоматизация. Независимо от того,
0:30
являетесь ли вы это специалистом, разработчиком или руководителем бизнеса, у нас найдутся сессии
0:34
именно для вас. За 10 полных дней вы сможете изучить множество технологий и наладить связи с
0:39
глобальным сообществом. Смотрите в прямом эфире и применяйте практические идеи в своей организации.
0:44
Январь 2027 года, 10 дней, одно сообщество Microsoft. Регистрация уже открыта. Переходите
0:52
на m365con.net и забронируйте свое место сегодня. Это m365con.net. Присоединяйтесь прямо сейчас на
1:01
m365con.net и увидимся в прямом эфире в январе. Если вы когда-нибудь открывали решение и сразу
1:07
чувствовали себя подавленными сетью файлов, ссылок и ошибок, готовых напасть на вас, знайте,
1:11
вы не одиноки. Большинство разработчиков работают реактивно, исправляют здесь, отлаживают там.
1:15
Агентский режим GitHub Copilot призван удерживать более широкий контекст и координировать изменения
1:19
между файлами. В этом видео мы покажем, как выглядит такой рабочий процесс в реальном проекте
1:23
на подкаст.нет и азу. Мы разберем работающие решения и покажем состояние до и после изменений,
1:28
внесенных агентом. Вы увидите, как генерировать код для нескольких файлов с меньшими затратами,
1:32
быстрее исправлять ошибки между файлами и даже использовать описание на обычном языке для создания
1:35
структуры функций. А прежде чем мы перейдем к этому, давайте начнем со скрытых издержек цикла
1:39
отладки, в котором многие из нас живут каждый день. Скрытая цена лоскутной отладки. Вы садитесь за исправление
1:44
ошибки, которая кажется достаточно простой. Приложение не собирается, а консоль указывает на строку
1:49
в основном файле проекта. Вы правите метод, перекомпилируете и думаете, что решили проблему,
1:53
пока то же сообщение не появляется снова в слегка измененном виде. Проходит еще полчаса,
1:57
прежде чем вы обнаруживаете настоящую причину. Отсутствующая зависимость, спрятанная в другой
2:01
папке проекта. К тому моменту, как ссылка исправлена и вы переразвертываете проект, большая часть дня
2:06
уходит на заплатки. Запланированная работа над функционалом переносится на завтра. Этот шаблон
2:10
настолько распространен, что кажется нормой. На поверхности кажется, что вы движетесь вперед, потому что
2:14
каждая исправленная ошибка воспринимается как победа. На практике же вы ходите по кругу. Цикл
2:18
выглядит так. Код, компиляция, ошибка, исправление, повтор. Часы улетают в погоне за причинно-следственными
2:23
связями, и итоговым результатом является реактивный прогресс, а незначимое улучшение.
2:27
Сколько из вас потратили целый день именно на этот цикл? Оставьте комментарий в одну строку,
2:31
я прочту самые популярные ответы. Этот цикл изматывает, потому что инструменты вокруг нас развиваются,
2:36
а модель работы – нет. Редакторы получают новые функции, фреймворки эволюционируют,
2:40
интеграции становятся глубже, но отладка по-прежнему требует реактивного подхода.
2:44
Это как пытаться сдержать разгорающийся пожар ведром воды. Каждую вспышку удается погасить на
2:48
месте, но причины, вызвавшие ее, остаются, почти гарантируя следующий пожар. И с каждым
2:53
переключением вкладки скрытые издержки растут. Вы переходите из класса сервиса в файл конфигурации,
2:58
а затем прыгаете в граф зависимостей. Каждое переключение вырывает вас из логической цепочки,
3:02
вынуждая делать ментальную перезагрузку. Дело не только в секундах, потраченных на переключение окон,
3:07
а в интеллектуальных усилиях по постоянному восстановлению контекста. За день эти мелкие перезагрузки
3:11
превращаются в нечто тяжелое. Для отдельных разработчиков эта усталость проявляется в
3:15
разочаровании и пустой трате времени. Для команд, работающих над корпоративными проектами,
3:19
эффект умножается. Циклы отладки сбивают цели спринта, задерживают запуск функций и создают
3:24
бэклог, который растет быстрее, чем сокращается. Усиление технического долга — лишь еще один
3:28
побочный эффект часов, потерянных на тушение пожаров. Многие команды сообщают, что значительная часть
3:33
их времени разработки уходит на реактивную отладку. Это не самая захватывающая часть инженерии.
3:37
Никто не планирует дорожную карту, ориентируясь на пятикратное исправление одной и той же ошибки
3:41
зависимости. Тем не менее, именно сюда уходят ресурсы неделя за неделей. Когда исправление ошибок
3:46
становится определением прогресса, создание новых функций отходит на второй план, а архитектура
3:50
молча страдает. Неприятная правда в том, что заплаточная отладка не просто замедляет процессы.
3:55
Она укрепляет культуру реакции вместо культуры проектирования. Вы тратите время на тушение пламени,
4:00
а не на построение систем. Это может поддерживать жизнь продукта в краткосрочной перспективе,
4:04
но ограничивает масштабируемость команды и уверенность в релизах. Итак, давайте остановимся на
4:08
этом образе тушения и пожаров. Броситься в эпицентр, вылить воду, двигаться дальше. Проблема не в том,
4:13
что разработчики с этим не справляются. Они справляются. Проблема в том, что пламя никогда по-настоящему
4:18
не гаснет. Оно просто перемещается, вспыхивая в новых файлах, проектах и конфигурациях,
4:22
удерживая всех в режиме реагирования вместо режима созидания. Это порождает вопрос, что, если бы этот цикл
4:27
не лежал только на вас? Что, если бы повторяющиеся части, цикл отслеживания, переключения и исправления,
4:33
можно было организовать иначе, пока вы сосредоточены на разработке. Ведь хотя нагрузка от тушения
4:37
пожаров, очевидно, есть еще одна болевая точка, которой мы пока не коснулись. Настоящая сложность
4:42
возникает тогда, когда ваш проект — это не один файл или модуль. Когда исправление, которое вам
4:46
нужно, охватывает сразу несколько уровней. Представьте, что вы открываете решение, логика
4:51
которого разбросана по разным проектам, сервисам и библиотекам. Нужная вам часть находится в трех
4:56
местах одновременно, и удержать все это в голове уже само по себе испытание. Хаос из множества файлов
5:02
против контекстного контроля ИИ. Когда проекты охватывают несколько уровней, главная трудность
5:06
заключается не в написании кода, а в том, чтобы удерживать вместе все движущиеся части. Именно здесь
5:11
напряжение между хаосом из множества файлов и контекстным контролем на базе ИИ проявляется
5:15
наиболее ярко. Возьмем крупное решение на NIT, состоящее из десятка и более проектов. Любая новая
5:20
функция обычно затрагивает разные уровни одновременно. Контроллер в одном месте, сервис в другом,
5:25
а набор конфигурационных файлов где-то еще. Прежде чем написать хоть строчку, вы тратите время на
5:29
отслеживание ссылок и проверку зависимостей, надеясь, что мелкое изменение не приведет к неожиданным
5:34
сбоям в других частях цепи. Такой рабочий процесс не исключение. Это норма для корпоративных
5:39
приложений, особенно когда в дело вступают сервисы и интеграции Azure. Структура таких систем
5:43
далеко не плоская. Интерфейсы, маппинги внедрения зависимостей и межпроектные ссылки – все это
5:49
играет свою роль. С учетом Azure некоторые зависимости выходят далеко за пределы папки решения,
5:54
функции, привязки сервисной шины, настройки ресурсов, подключения к хранилищам. Вы координируете
5:59
код в IDE, конфигурационные файлы на диске и сервисы, определенные в облаке. Никому из них нет
6:04
дела до того, что вам хотелось бы совершать меньше кликов. Каждый раз при переключении контекста
6:08
вы тратите энергию на воссоздание общей картины. Большинство из нас пытается удержать этот контекст
6:12
в рабочей памяти. Поначалу это получается, но по мере роста проекта ошибки неизбежны. Вы добавляете
6:17
новый метод в сервис, но забываете о его регистрации в D. Вы пишете код Azure функции и только потом понимаете,
6:22
что привязка так и не была добавлена в хост, JSON или шаблон развертывания. Ничто не предупредит вас до момента
6:26
запуска, когда вы будете заняты отладкой вместо разработки. Сам по себе код не самая сложная часть.
6:30
Сложность заключается в координации между файлами. Всем знакомо чувство бесконечного переключения
6:34
между вкладками из контроллера в сервис, затем в модель, потом в конфиг и обратно, только чтобы
6:39
понять, что вы уже забыли, зачем открыли этот файл. Это мелкая помеха, которая повторяется десятки
6:44
раз в день. Такие взаимодействия накапливаются, создавая трение, которое тормозит реальный прогресс.
6:48
В результате доставка замедляется не из-за того, что медленно пишется код, а из-за того,
6:52
что подержание синхронизации всего совсем крадет фокус. Эти накладные расходы растут
6:56
ориентированных проекта. Azure распределяет ключевые настройки по разным местам, локальным файлам
7:01
конфигурации, переменным среды, шаблоном ARM или BSIB, CI, CD-пайплайном. То, что выглядит как запрос на
7:08
одну функцию, часто затрагивает четыре уровня абстракции. Эта сложность неизбежна. Она заложена в
7:13
саму работу экосистемы. И вот здесь режим агента может стать поворотным моментом. Вместо того, чтобы
7:18
оставлять всю эту координацию на вас, он спроектирован так, чтобы удерживать широкий контекст сразу
7:22
по множеству файлов. Это значит, что когда вы просите внести изменения на одном уровне, он
7:26
не игнорирует остальные. В демо я создам новую Azure функцию и покажу, как агент помогает
7:30
генерировать тело метода, создавать конфигурацию привязки, обновлять хост, JSON и даже предлагать
7:36
верную регистрацию внедрения зависимости. Обычно это многоэтапный процесс, разбросанный по разным
7:40
файлам. Агент же позволяет объединить его в один поток. Речь не о замене ваших суждений, а об избавлении
7:46
от рутинной работы, чтобы вы могли сосредоточиться на архитектурных решениях. Люди могут держать в голове
7:52
примерный план или набросать его на доске. И ежеочлеживает детали в каждом файле, не теряя
7:57
основной нити. То, что для нас кажется огромной когнитивной нагрузкой, для агента является базовым
8:01
контекстом. На практике разница заключается в переходе от хаотичного переключения вкладок к
8:05
согласованным изменениям, которые остаются синхронизированными. Во время демо я также открою
8:08
созданный агентом pull request или диффов, чтобы вы могли увидеть, какие именно правки были внесены.
8:12
Эта прозрачность важна. Вы сохраняете полный контроль для проверки и утверждения, пока всю грязную работу
8:17
по обновлению файлов агент берет на себя. Поэтому вместо того, чтобы тратить полдня на сборку
8:21
фрагментов кода, вы даете указание один раз, подтверждаете созданные обновления и переходите
8:24
к высокоуровневому проектированию. Облегчение заключается не только в сэкономленных кликах или
8:28
нажатиях клавиш, но и в возможности сосредоточиться на решении реальных задач, а не на отслеживании
8:32
связей между десятком файлов. Это преимущество наиболее заметно, когда что-то идет не так, ведь даже при
8:37
улучшенной работе с контекстом системы дают сбои, конфига разъезжаются, а некорректные ссылки возвращаются
8:41
снова. И здесь начинается следующее испытание, как ошибки обнаруживаются и исправляются после того,
8:46
как они возникают. От поиска ошибок к их автономному исправлению. Вспомните, как часто вы сталкивались
8:51
с сообщением об ошибке, указывающем прямо на один файл. Вы переходите по трассировке стека к указанному
8:55
методу, вносите небольшую правку и запускаете пересборку. Это кажется очевидным решением, пока та же
9:00
ошибка не появляется снова, но уже в немного ином виде. И тогда вы понимаете, что трассировка стека показывала
9:05
лишь симптом. Настоящая проблема скрыта где-то в другом месте, возможно, во вспомогательном классе или внутри
9:09
файла конфигурации, который вы не открывали всю неделю. Каждый разработчик сталкивался с подобным
9:13
введением в заблуждение. То, что кажется проблемой, на самом деле не требует исправления там.
9:17
Это быстро съедает время. Вы вносите одну правку, пересобираете, ждете. Затем вас встречает новая
9:21
ошибка, ведущая к другому файлу, еще одной правке и очередной пересборке. Этот цикл кажется продуктивным,
9:26
ведь вы что-то делаете, печатаете, компилируете, но по сути это метод проб и ошибок, а не реальное решение.
9:32
Такой цикл может поглотить часы, оставив вас с мелкими поверхностными исправлениями без реального
9:36
прогресса в задаче, с которой вы начали. Настоящая цена здесь – упущенные возможности.
9:41
Пока вы пойманы в ритм, пересобрать и повторить, вы не решаете бизнес-задачи и не выпускаете
9:45
функции, которые ждут пользователи. Энергия уходит на догадки, а не на проектирование.
9:50
В моменте это кажется активной работой, но эти часы не приносят ничего, кроме поддержания системы
9:55
в рабочем состоянии. В команде такая поверхностная активность замедляет все и создает очередь функций,
10:00
которые постоянно откладываются. Именно здесь рабочий процесс с агентом начинает выглядеть иначе.
10:04
Идея не в том, чтобы остановиться на одной строке, которую подсветил стек вызовов.
10:08
Напротив, он спроектирован так, чтобы удерживать контекст всей системы, задаваясь вопросом не только
10:13
о том, что должен делать файл, а какая последовательность изменений нужна для восстановления
10:17
согласованности. На практике это означает, что он может предлагать правки, затрагивающие несколько
10:22
файлов. Например, в демо вы увидите, что когда метод требует изменений, он может предложить
10:26
соответствующие правки в конфигах или шаблонах развертывания, вместо того, чтобы заставлять вас
10:30
искать их вручную. Это переход от автодополнения к чему-то более масштабному. Автодополнение
10:34
завершает строки, а агент координирует работу между файлами, и эта координация особенно важна,
10:38
когда ошибки не локализованы в одном месте. Возьмем распространенный сценарий Азу. Вы создали
10:43
новое приложение функцию, но после развертывания триггер очереди не срабатывает, так как привязка
10:47
не соответствует сигнатуре метода. Обычно вы копаетесь в логах, выясняете, какая привязка неверна,
10:51
вручную правите JSON-файл функции, а может, даже меняете шаблон инфраструктуры, если там тоже есть
10:56
несоответствие. Каждый шаг – это отдельная погоня, и каждое исправление запускает новый тестовый прогон.
11:01
В режиме агента рабочий процесс выглядит иначе. Он может предложить изменение кода,
11:05
создать правильную привязку JSON для функций и отобразить правки для скриптов развертывания,
11:09
если они не согласованы. Вы проверяете, подтверждаете и двигаетесь дальше, не тратя часы на сборку
11:13
каждого слоя воедино. И здесь ключ – это доверие. Никто не должен чувствовать, что в фоне
11:17
происходят невидимые изменения. Вот почему так важен процесс проверки. В этой демонстрации мы
11:21
пройдем через это вместе. Агент предлагает скоординированные изменения. Мы откроем диффов,
11:25
чтобы проверить, что именно было создано, запустим модульные тесты, локально проверим сборку,
11:30
и только после этого решим принять или отклонить изменения. Этот цикл проверки позволяет вам
11:34
сохранять полный контроль, избавляясь от рутинной работы. Стоит подчеркнуть, агенты помогают
11:38
двигаться быстрее, но они не заменяют грамотные инженерные практики. Вам по-прежнему следует
11:43
относиться к проверке кода ECI как к обязательным этапам контроля. Пусть и сокращает время на
11:46
поиск ошибок, но используйте автоматизированные проверки и человеческий контроль в качестве
11:50
системы безопасности. Такой баланс решает проблему доверия и гарантирует, что прирост скорости
11:54
не снизит стабильность. Разница в скорости не является теоретической. Там, где поиск ошибок и ручное
11:59
исправление, могут отнять полдня. Скоординированные предложения сокращают время до минуты.
12:03
А в освобожденное время вы можете направить на работу, которая действительно требует ваших усилий.
12:07
На функции, которые заметят пользователи, и архитектурные решения, улучшающие вашу кодовую базу.
12:11
Вместо того, чтобы «тушить пожары» при запуске, вы можете уверенно проектировать систему заранее.
12:15
Таким образом, цикл отладки больше не должен определять ваш рабочий день.
12:18
Когда агент предлагает обновление для нескольких файлов, вы переходите от хаотичного поиска
12:22
к ритму «проверил и одобрил». Вы перестаете ходить кругами по ошибкам и начинаете
12:26
рассматривать отладку как структурированный, почти автоматизированный этап рабочего процесса.
12:30
Этот сдвиг освобождает когнитивные ресурсы и время для создания функций,
12:33
а не только для исправления недочетов. И как только устранение ошибок перестает быть
12:36
борьбой с симптомами, открываются двери к чему-то большему. К тому, как можно начинать работу
12:40
над целыми функциями в таком же структурированном ключе. Представьте, если тот же рабочий процесс,
12:45
что предлагает скоординированное исправление, сможет взять описание на обычном языке и создать
12:49
под него рабочую структуру. Здесь начинается следующий этап разработки. Разработка на основе
12:54
спецификации без лишних затрат. Один из самых интересных сдвигов происходит,
12:57
когда вы перестаете мыслить только файлами и методами, а начинаете описывать задачи простым
13:02
языком. Именно здесь на помощь приходит разработка на основе спецификации без лишних накладных
13:05
расходов. Представьте, что вы пишете простой запрос на добавление функции. Добавить рабочий
13:09
процесс формирования отчетов, который создает ежемесячные сводки, сохраняет их и делает доступными
13:13
через админ-панель. Вместо того, чтобы получать отдельные фрагменты кода, вы сразу получаете рабочую
13:17
структуру, распределенную по всему приложению. Контролеры созданы, модели прописаны,
13:22
сервисы зарегистрированы, а конфигурация подключена. Этот переход от описания намерения
13:26
к появлению готового каркаса в проекте делает такой подход по-настоящему практичным,
13:30
а не теоретическим. В традиционных условиях разработка с начала спецификация имеет тяжелую
13:35
репутацию. В крупных организациях это обычно означает длинные документы с требованиями,
13:39
многостраничные описания и жесткие диаграммы, которые всех замедляют. Они оправданы в регулируемых
13:43
отраслях или глобально распределенных командах, но в повседневной работе большинство разработчиков
13:47
их пропускают. Написание и поддержание подробных спецификаций требует затрат, на которые ни у кого нет
13:51
времени или терпения. Это дополнительная работа поверх выпуска функций, и по мере приближения сроков
13:56
этими задачами обычно жертвуют. Ирония очевидна, разработчикам на самом деле нравится мыслить
14:00
в общих чертах. Знание структуры заранее внушает уверенность. Проблема не в намерениях,
14:05
а в поддержке документации. Как только спецификация начинает расходиться с реальностью,
14:09
ее поддержка становится временем. Вот почему реальная работа так часто скатывается к импровизации,
14:13
а не к полноценному проектированию, даже в компаниях, которые формально одобряют тщательное
14:17
планирование. Агентский рабочий процесс предлагает альтернативу. Вместо того,
14:20
чтобы требовать отполированный документ с дизайном, он помогает превратить описание на обычном
14:24
языке в каркас, который вы можете доработать. Вам не нужны UML-диаграммы или рукописные карты
14:29
интерфейсов. Можно просто сказать, создай модуль отчетов с новым API-инпоинтом, свяжи его с хранилищем
14:35
и защити доступом на основе ролей, и система создаст базу во всех файлах вашего NIT-решения.
14:40
В демонстрации я зачитаю описание на обычном языке, затем покажу файлы, созданные агентом,
14:45
контроллеры, модели и регистрацию сервисов, и укажу на моменты, которые все еще требовали
14:50
ручной доработки. Так вы сможете самостоятельно оценить качество. Это создает золотую середину
14:55
между двумя режимами разработки. С одной стороны, есть вайп-кодинг, быстро, свободно,
14:59
но хрупко для долгосрочных систем. С другой стороны, проектирование на основе спецификаций
15:04
надежно, но мучительно медленно. С поддержкой агентов вы описываете идею обычными словами,
15:08
появляется каркас, и вы можете итерировать почти так же быстро, как при вайп-кодинг,
15:12
сохраняя при этом преимущество организованной структуры. Возьмем тот же процесс отчетности.
15:16
Обычно вам пришлось бы создать модель, построить сервис данных, подключить контроллер,
15:20
настроить безопасность и связать все в конфигурации запуска. Это значит прыгать по множеству
15:24
файлов в надежде, что согласованность сохранится. При таком подходе вся структура создается
15:29
мгновенно. Реальная экономия заключается не столько в меньшем количестве строк кода,
15:32
сколько в предотвращении ошибок при работе с разными файлами, например, если забыл зарегистрировать
15:35
новый сервис после того, как уже его создал. Конечно, всегда возникает вопрос стиля, будет ли и навязывать
15:40
шаблонный код или перечеркивать принятые соглашения. На практике агенты часто отражают
15:44
существующие в проекте паттерны в своих предложениях. В демонстрации вы увидите обе стороны.
15:48
Места, где структура контролеров идеально совпала с нашей, и места, где догадки и не совпали
15:53
с реальностью. Такое сочетание важно. Вы будете знать, чему можно доверять, а что все еще нужно
15:57
поправить. Итоговый результат – это не шаблонный код под копирку. Это по-прежнему ваш проект,
16:01
только с меньшим объемом ручной работы по созданию каркаса. Вы сохраняете высокую скорость,
16:06
опираясь на фундамент, который можно улучшать по мере роста проекта. Вместо того,
16:09
чтобы составление спецификации оставалось уделом архитекторов, любящих диаграммы,
16:13
оно становится инструментом для любого разработчика, желающего быстро экспериментировать,
16:16
не жертвуя порядком. Когда это входит в ваш ежедневный рабочий процесс, спецификация перестает
16:21
казаться формальным корпоративным этапом и превращается в легкую запись. Вы описываете свое намерение,
16:26
система создает основу, а вы фокусируетесь на проработке деталей. Основной эффект заключается не просто
16:31
в генерируемом коде, а в том, что значит экономия времени неделя за неделей. Больше часов на разработку
16:36
функций, меньше рутины на настройку. Это подводит нас прямо к вопросу, который волнует каждого
16:40
разработчика больше всего. Во что именно выливаются эти изменения с точки зрения продуктивности?
16:45
Отдача от продуктивности. Главный вопрос не в том, экономите ли вы несколько минут тут и там,
16:50
а в том, как эти небольшие сдвиги превращаются в существенные часы в течение недели.
16:54
Это и есть отдача от продуктивности. Возврат времени, который обычно незаметно ускользает из-за
16:59
переключения контекста, повторных циклов сборки и внесения правок вручную. Большинство разработчиков
17:03
принимают эти небольшие потери как неизбежную часть работы. 10 минут на поиск значения в конфиге,
17:07
еще 15 на перезапуск из-за пропущенной ссылки или прыжки между файлами для проверки связей.
17:12
По отдельности они кажутся незначительными, но в сумме за целый спринт они определяют,
17:16
сколько реальной ценности будет доставлено. То, что выглядит как привычные движения,
17:20
скрывает серьезную задержку сроков поставки. Скрытый груз заключается не во времени компиляции
17:24
или скорости печати. Он кроется в рваном ритме, который навязывается вашей концентрацией. Каждый раз,
17:28
когда вы переходите из одного файла в другой, ваш мозг перезагружается. У этой перезагрузки
17:32
есть своя цена. Перекладывание повторяющихся исправлений на агента облегчает это бремя.
17:36
Вместо постоянного восстановления контекста вы тратите силы там, где это важно,
17:39
на решение более серьезных архитектурных задач. Многие команды не отчлеживают эти микрозатраты,
17:44
потому что они не отражаются в тикетах Джира или истории ГИД. Работа, которая ни к чему не привела,
17:48
не фиксируется в логах, но она все равно отнимает энергию. И по мере роста кодовой базы это трение
17:52
не просто растет линейно. Больше уровней – значит больше зависимостей, которые нужно держать в памяти,
17:56
и больше шансов потратить время на простое выравнивание структуры, прежде чем двигаться дальше.
18:00
Агентские рабочие процессы меняют ситуацию, напрямую воздействуя на эти факторы потерь.
18:03
Они не просто быстрее заполняют заглушки методов, они сокращают циклы поиска,
18:07
исправлений и перезапусков, которые съедают целые вечера. Команды, использующие агентские рабочие
18:11
процессы, во многих случаях отмечают более быстрое устранение блокировок.
18:14
В этом видео мы продемонстрируем одну задачу «да» и «после», чтобы вы могли оценить результат.
18:18
Я зафиксирую время, затраченное на реализацию одной и той же функции Азур вручную,
18:22
а затем с помощью агента, чтобы вы могли увидеть прирост продуктивности в конкретных цифрах.
18:25
С точки зрения бизнеса, ценность проявляется в скорости работы над проектом.
18:29
Более быстрые циклы разработки важны не только для удовлетворенности разработчиков.
18:32
От них зависит, выйдут ли функции в текущем релизе или отложатся на кварталы вперед.
18:35
Они влияют на технический долг, так как меньше костылей и регрессий попадает в бэклог.
18:39
Более плавный рабочий процесс позволяет командам двигаться вперед,
18:42
не возвращаясь к исправлению ошибок прошлого спринта.
18:44
Эта стабильность со временем приводит к сокращению, тушению пожаров и повышению качества результатов.
18:48
Существует также человеческий фактор.
18:50
День, потраченный на погоню за ошибками, выматывает любого инженера.
18:53
Когда наступает усталость, сложнее проектировать чистый код,
18:56
внимание притупляется и прокрадываются ошибки.
18:58
Переложив технические исправления на агента, разработчики дольше сохраняют концентрацию.
19:02
Эта дополнительная фокусировка повышает как продуктивность, так и качество.
19:06
Когда вас не тормозят постоянные мелкие препятствия,
19:08
вы свободны мыслить шире и планировать эффективнее.
19:11
На практике разница выглядит так.
19:13
Создание новой функции Azure с множеством привязок и интеграции
19:16
может затянуться на два полных дня без посторонней помощи.
19:18
Из-за настройки, тестирования и бесконечного исправления
19:21
несовпадающих ссылок задача затягивается.
19:24
С помощью агента ту же функцию можно создать за полдня.
19:27
Не потому, что срезаются углы, а потому, что настройка файлов и оркестрация
19:30
выполняются безошибочно с первого раза.
19:32
Сроки сокращаются за счет устранения ложных стартов и избыточных усилий.
19:36
Некоторые разработчики высказывают справедливые опасения.
19:38
Не притупляются ли ваши собственные навыки, если полагаться на и при сопровождении кода?
19:41
Такой взгляд часто упускает из виду суть происходящих изменений.
19:44
Делегирование рутинной настройки не ослабляет вашу экспертизу,
19:46
а сохраняет ее для проектирования и архитектуры, где важны ваши суждения.
19:50
На самом деле вы получаете пространство для решения более сложных задач
19:53
вместо пустой траты энергии на исправление.
19:55
Если попробуете это, напишите в комментариях, сколько часов вам удалось сэкономить за спринт.
19:59
Я добавлю интересные ответы в будущее видео.
20:01
Узнавая, как другие команды переживают этот переход,
20:03
все получают более четкое представление о реальной пользе, выходящей за рамки демо-примеров.
20:07
Однако пара слов предосторожности, автоматизация помогает, но безопасность все еще важна.
20:10
Всегда запускайте тесты и используйте код-ревью для проверки изменений, созданных агентом.
20:14
Доверяйте тому, что рутина сокращается, но сохраняйте прежние механизмы защиты.
20:18
Разница в скорости имеет смысл только при неизменном качестве.
20:21
Надежные тесты и грамотное ревью пиар защищают ваш конвейер выпуска от хрупкой автоматизации.
20:26
Выгода заключается не в быстром написании строк кода,
20:28
а в освобождении ресурсов для создания более сильных решений.
20:31
С меньшей усталостью и меньшим количеством.
20:33
Редактор субтитров А.Семкин Корректор А.Егорова