WEBVTT

00:00:00.080 --> 00:00:06.020
Готовы к 10 дням погружения в Microsoft 365, Copilot и Azure и знакомство с людьми,

00:00:06.220 --> 00:00:12.260
формирующими будущие работы. В этом январе M365Con возвращается, и мы расширяем границы.

00:00:12.420 --> 00:00:16.340
Присоединяйтесь к нам для участия в живых сессиях, демонстрациях реальных проектов и получения

00:00:16.340 --> 00:00:20.100
практических знаний от MVP и экспертов со всего мира. Никаких общих слайдов,

00:00:20.260 --> 00:00:24.760
никаких пустых модных словарей. Мы решаем реальные задачи, Copilot Studio,

00:00:24.760 --> 00:00:30.020
и агенты, фабрик, безопасность, управление и автоматизация. Независимо от того,

00:00:30.260 --> 00:00:34.640
являетесь ли вы это специалистом, разработчиком или руководителем бизнеса, у нас найдутся сессии

00:00:34.640 --> 00:00:39.460
именно для вас. За 10 полных дней вы сможете изучить множество технологий и наладить связи с

00:00:39.460 --> 00:00:44.700
глобальным сообществом. Смотрите в прямом эфире и применяйте практические идеи в своей организации.

00:00:44.920 --> 00:00:52.140
Январь 2027 года, 10 дней, одно сообщество Microsoft. Регистрация уже открыта. Переходите

00:00:52.140 --> 00:01:01.400
на m365con.net и забронируйте свое место сегодня. Это m365con.net. Присоединяйтесь прямо сейчас на

00:01:01.400 --> 00:01:07.160
m365con.net и увидимся в прямом эфире в январе. Если вы когда-нибудь открывали решение и сразу

00:01:07.160 --> 00:01:11.260
чувствовали себя подавленными сетью файлов, ссылок и ошибок, готовых напасть на вас, знайте,

00:01:11.420 --> 00:01:15.360
вы не одиноки. Большинство разработчиков работают реактивно, исправляют здесь, отлаживают там.

00:01:15.540 --> 00:01:19.660
Агентский режим GitHub Copilot призван удерживать более широкий контекст и координировать изменения

00:01:19.660 --> 00:01:23.740
между файлами. В этом видео мы покажем, как выглядит такой рабочий процесс в реальном проекте

00:01:23.740 --> 00:01:28.020
на подкаст.нет и азу. Мы разберем работающие решения и покажем состояние до и после изменений,

00:01:28.140 --> 00:01:31.840
внесенных агентом. Вы увидите, как генерировать код для нескольких файлов с меньшими затратами,

00:01:32.020 --> 00:01:35.740
быстрее исправлять ошибки между файлами и даже использовать описание на обычном языке для создания

00:01:35.740 --> 00:01:39.620
структуры функций. А прежде чем мы перейдем к этому, давайте начнем со скрытых издержек цикла

00:01:39.620 --> 00:01:44.560
отладки, в котором многие из нас живут каждый день. Скрытая цена лоскутной отладки. Вы садитесь за исправление

00:01:44.560 --> 00:01:49.320
ошибки, которая кажется достаточно простой. Приложение не собирается, а консоль указывает на строку

00:01:49.320 --> 00:01:53.400
в основном файле проекта. Вы правите метод, перекомпилируете и думаете, что решили проблему,

00:01:53.520 --> 00:01:57.520
пока то же сообщение не появляется снова в слегка измененном виде. Проходит еще полчаса,

00:01:57.560 --> 00:02:01.860
прежде чем вы обнаруживаете настоящую причину. Отсутствующая зависимость, спрятанная в другой

00:02:01.860 --> 00:02:06.340
папке проекта. К тому моменту, как ссылка исправлена и вы переразвертываете проект, большая часть дня

00:02:06.340 --> 00:02:10.540
уходит на заплатки. Запланированная работа над функционалом переносится на завтра. Этот шаблон

00:02:10.540 --> 00:02:14.420
настолько распространен, что кажется нормой. На поверхности кажется, что вы движетесь вперед, потому что

00:02:14.420 --> 00:02:18.060
каждая исправленная ошибка воспринимается как победа. На практике же вы ходите по кругу. Цикл

00:02:18.060 --> 00:02:23.160
выглядит так. Код, компиляция, ошибка, исправление, повтор. Часы улетают в погоне за причинно-следственными

00:02:23.160 --> 00:02:26.840
связями, и итоговым результатом является реактивный прогресс, а незначимое улучшение.

00:02:27.060 --> 00:02:31.060
Сколько из вас потратили целый день именно на этот цикл? Оставьте комментарий в одну строку,

00:02:31.260 --> 00:02:36.140
я прочту самые популярные ответы. Этот цикл изматывает, потому что инструменты вокруг нас развиваются,

00:02:36.140 --> 00:02:40.380
а модель работы – нет. Редакторы получают новые функции, фреймворки эволюционируют,

00:02:40.480 --> 00:02:44.060
интеграции становятся глубже, но отладка по-прежнему требует реактивного подхода.

00:02:44.060 --> 00:02:48.680
Это как пытаться сдержать разгорающийся пожар ведром воды. Каждую вспышку удается погасить на

00:02:48.680 --> 00:02:53.320
месте, но причины, вызвавшие ее, остаются, почти гарантируя следующий пожар. И с каждым

00:02:53.320 --> 00:02:58.140
переключением вкладки скрытые издержки растут. Вы переходите из класса сервиса в файл конфигурации,

00:02:58.320 --> 00:03:02.560
а затем прыгаете в граф зависимостей. Каждое переключение вырывает вас из логической цепочки,

00:03:02.560 --> 00:03:07.120
вынуждая делать ментальную перезагрузку. Дело не только в секундах, потраченных на переключение окон,

00:03:07.240 --> 00:03:11.500
а в интеллектуальных усилиях по постоянному восстановлению контекста. За день эти мелкие перезагрузки

00:03:11.500 --> 00:03:15.300
превращаются в нечто тяжелое. Для отдельных разработчиков эта усталость проявляется в

00:03:15.300 --> 00:03:19.440
разочаровании и пустой трате времени. Для команд, работающих над корпоративными проектами,

00:03:19.620 --> 00:03:24.080
эффект умножается. Циклы отладки сбивают цели спринта, задерживают запуск функций и создают

00:03:24.080 --> 00:03:28.760
бэклог, который растет быстрее, чем сокращается. Усиление технического долга — лишь еще один

00:03:28.760 --> 00:03:33.520
побочный эффект часов, потерянных на тушение пожаров. Многие команды сообщают, что значительная часть

00:03:33.520 --> 00:03:37.720
их времени разработки уходит на реактивную отладку. Это не самая захватывающая часть инженерии.

00:03:37.720 --> 00:03:41.320
Никто не планирует дорожную карту, ориентируясь на пятикратное исправление одной и той же ошибки

00:03:41.320 --> 00:03:46.080
зависимости. Тем не менее, именно сюда уходят ресурсы неделя за неделей. Когда исправление ошибок

00:03:46.080 --> 00:03:50.640
становится определением прогресса, создание новых функций отходит на второй план, а архитектура

00:03:50.640 --> 00:03:55.500
молча страдает. Неприятная правда в том, что заплаточная отладка не просто замедляет процессы.

00:03:55.640 --> 00:04:00.500
Она укрепляет культуру реакции вместо культуры проектирования. Вы тратите время на тушение пламени,

00:04:00.740 --> 00:04:04.760
а не на построение систем. Это может поддерживать жизнь продукта в краткосрочной перспективе,

00:04:04.760 --> 00:04:08.900
но ограничивает масштабируемость команды и уверенность в релизах. Итак, давайте остановимся на

00:04:08.900 --> 00:04:13.340
этом образе тушения и пожаров. Броситься в эпицентр, вылить воду, двигаться дальше. Проблема не в том,

00:04:13.500 --> 00:04:18.200
что разработчики с этим не справляются. Они справляются. Проблема в том, что пламя никогда по-настоящему

00:04:18.200 --> 00:04:22.420
не гаснет. Оно просто перемещается, вспыхивая в новых файлах, проектах и конфигурациях,

00:04:22.520 --> 00:04:27.940
удерживая всех в режиме реагирования вместо режима созидания. Это порождает вопрос, что, если бы этот цикл

00:04:27.940 --> 00:04:33.240
не лежал только на вас? Что, если бы повторяющиеся части, цикл отслеживания, переключения и исправления,

00:04:33.240 --> 00:04:37.620
можно было организовать иначе, пока вы сосредоточены на разработке. Ведь хотя нагрузка от тушения

00:04:37.620 --> 00:04:42.100
пожаров, очевидно, есть еще одна болевая точка, которой мы пока не коснулись. Настоящая сложность

00:04:42.100 --> 00:04:46.520
возникает тогда, когда ваш проект — это не один файл или модуль. Когда исправление, которое вам

00:04:46.520 --> 00:04:51.220
нужно, охватывает сразу несколько уровней. Представьте, что вы открываете решение, логика

00:04:51.220 --> 00:04:56.400
которого разбросана по разным проектам, сервисам и библиотекам. Нужная вам часть находится в трех

00:04:56.400 --> 00:05:02.120
местах одновременно, и удержать все это в голове уже само по себе испытание. Хаос из множества файлов

00:05:02.120 --> 00:05:06.800
против контекстного контроля ИИ. Когда проекты охватывают несколько уровней, главная трудность

00:05:06.800 --> 00:05:11.520
заключается не в написании кода, а в том, чтобы удерживать вместе все движущиеся части. Именно здесь

00:05:11.520 --> 00:05:15.200
напряжение между хаосом из множества файлов и контекстным контролем на базе ИИ проявляется

00:05:15.200 --> 00:05:20.140
наиболее ярко. Возьмем крупное решение на NIT, состоящее из десятка и более проектов. Любая новая

00:05:20.140 --> 00:05:25.020
функция обычно затрагивает разные уровни одновременно. Контроллер в одном месте, сервис в другом,

00:05:25.240 --> 00:05:29.940
а набор конфигурационных файлов где-то еще. Прежде чем написать хоть строчку, вы тратите время на

00:05:29.940 --> 00:05:34.340
отслеживание ссылок и проверку зависимостей, надеясь, что мелкое изменение не приведет к неожиданным

00:05:34.340 --> 00:05:39.020
сбоям в других частях цепи. Такой рабочий процесс не исключение. Это норма для корпоративных

00:05:39.020 --> 00:05:43.980
приложений, особенно когда в дело вступают сервисы и интеграции Azure. Структура таких систем

00:05:43.980 --> 00:05:49.260
далеко не плоская. Интерфейсы, маппинги внедрения зависимостей и межпроектные ссылки – все это

00:05:49.260 --> 00:05:54.040
играет свою роль. С учетом Azure некоторые зависимости выходят далеко за пределы папки решения,

00:05:54.220 --> 00:05:59.400
функции, привязки сервисной шины, настройки ресурсов, подключения к хранилищам. Вы координируете

00:05:59.400 --> 00:06:04.500
код в IDE, конфигурационные файлы на диске и сервисы, определенные в облаке. Никому из них нет

00:06:04.500 --> 00:06:08.360
дела до того, что вам хотелось бы совершать меньше кликов. Каждый раз при переключении контекста

00:06:08.360 --> 00:06:12.540
вы тратите энергию на воссоздание общей картины. Большинство из нас пытается удержать этот контекст

00:06:12.540 --> 00:06:17.360
в рабочей памяти. Поначалу это получается, но по мере роста проекта ошибки неизбежны. Вы добавляете

00:06:17.360 --> 00:06:21.900
новый метод в сервис, но забываете о его регистрации в D. Вы пишете код Azure функции и только потом понимаете,

00:06:22.080 --> 00:06:26.380
что привязка так и не была добавлена в хост, JSON или шаблон развертывания. Ничто не предупредит вас до момента

00:06:26.380 --> 00:06:30.420
запуска, когда вы будете заняты отладкой вместо разработки. Сам по себе код не самая сложная часть.

00:06:30.640 --> 00:06:34.900
Сложность заключается в координации между файлами. Всем знакомо чувство бесконечного переключения

00:06:34.900 --> 00:06:39.300
между вкладками из контроллера в сервис, затем в модель, потом в конфиг и обратно, только чтобы

00:06:39.300 --> 00:06:44.300
понять, что вы уже забыли, зачем открыли этот файл. Это мелкая помеха, которая повторяется десятки

00:06:44.300 --> 00:06:48.700
раз в день. Такие взаимодействия накапливаются, создавая трение, которое тормозит реальный прогресс.

00:06:48.860 --> 00:06:52.020
В результате доставка замедляется не из-за того, что медленно пишется код, а из-за того,

00:06:52.020 --> 00:06:55.740
что подержание синхронизации всего совсем крадет фокус. Эти накладные расходы растут

00:06:56.380 --> 00:07:01.340
ориентированных проекта. Azure распределяет ключевые настройки по разным местам, локальным файлам

00:07:01.340 --> 00:07:08.140
конфигурации, переменным среды, шаблоном ARM или BSIB, CI, CD-пайплайном. То, что выглядит как запрос на

00:07:08.140 --> 00:07:13.660
одну функцию, часто затрагивает четыре уровня абстракции. Эта сложность неизбежна. Она заложена в

00:07:13.660 --> 00:07:18.660
саму работу экосистемы. И вот здесь режим агента может стать поворотным моментом. Вместо того, чтобы

00:07:18.660 --> 00:07:22.380
оставлять всю эту координацию на вас, он спроектирован так, чтобы удерживать широкий контекст сразу

00:07:22.380 --> 00:07:26.320
по множеству файлов. Это значит, что когда вы просите внести изменения на одном уровне, он

00:07:26.320 --> 00:07:30.760
не игнорирует остальные. В демо я создам новую Azure функцию и покажу, как агент помогает

00:07:30.760 --> 00:07:36.160
генерировать тело метода, создавать конфигурацию привязки, обновлять хост, JSON и даже предлагать

00:07:36.160 --> 00:07:40.960
верную регистрацию внедрения зависимости. Обычно это многоэтапный процесс, разбросанный по разным

00:07:40.960 --> 00:07:46.540
файлам. Агент же позволяет объединить его в один поток. Речь не о замене ваших суждений, а об избавлении

00:07:46.540 --> 00:07:52.020
от рутинной работы, чтобы вы могли сосредоточиться на архитектурных решениях. Люди могут держать в голове

00:07:52.020 --> 00:07:57.080
примерный план или набросать его на доске. И ежеочлеживает детали в каждом файле, не теряя

00:07:57.080 --> 00:08:01.620
основной нити. То, что для нас кажется огромной когнитивной нагрузкой, для агента является базовым

00:08:01.620 --> 00:08:05.140
контекстом. На практике разница заключается в переходе от хаотичного переключения вкладок к

00:08:05.140 --> 00:08:08.600
согласованным изменениям, которые остаются синхронизированными. Во время демо я также открою

00:08:08.600 --> 00:08:12.760
созданный агентом pull request или диффов, чтобы вы могли увидеть, какие именно правки были внесены.

00:08:12.880 --> 00:08:17.460
Эта прозрачность важна. Вы сохраняете полный контроль для проверки и утверждения, пока всю грязную работу

00:08:17.460 --> 00:08:21.020
по обновлению файлов агент берет на себя. Поэтому вместо того, чтобы тратить полдня на сборку

00:08:21.020 --> 00:08:24.880
фрагментов кода, вы даете указание один раз, подтверждаете созданные обновления и переходите

00:08:24.880 --> 00:08:28.840
к высокоуровневому проектированию. Облегчение заключается не только в сэкономленных кликах или

00:08:28.840 --> 00:08:32.960
нажатиях клавиш, но и в возможности сосредоточиться на решении реальных задач, а не на отслеживании

00:08:32.960 --> 00:08:37.300
связей между десятком файлов. Это преимущество наиболее заметно, когда что-то идет не так, ведь даже при

00:08:37.300 --> 00:08:41.840
улучшенной работе с контекстом системы дают сбои, конфига разъезжаются, а некорректные ссылки возвращаются

00:08:41.840 --> 00:08:46.400
снова. И здесь начинается следующее испытание, как ошибки обнаруживаются и исправляются после того,

00:08:46.560 --> 00:08:51.220
как они возникают. От поиска ошибок к их автономному исправлению. Вспомните, как часто вы сталкивались

00:08:51.220 --> 00:08:55.720
с сообщением об ошибке, указывающем прямо на один файл. Вы переходите по трассировке стека к указанному

00:08:55.720 --> 00:09:00.640
методу, вносите небольшую правку и запускаете пересборку. Это кажется очевидным решением, пока та же

00:09:00.640 --> 00:09:05.840
ошибка не появляется снова, но уже в немного ином виде. И тогда вы понимаете, что трассировка стека показывала

00:09:05.840 --> 00:09:09.800
лишь симптом. Настоящая проблема скрыта где-то в другом месте, возможно, во вспомогательном классе или внутри

00:09:09.800 --> 00:09:13.360
файла конфигурации, который вы не открывали всю неделю. Каждый разработчик сталкивался с подобным

00:09:13.360 --> 00:09:17.040
введением в заблуждение. То, что кажется проблемой, на самом деле не требует исправления там.

00:09:17.160 --> 00:09:21.920
Это быстро съедает время. Вы вносите одну правку, пересобираете, ждете. Затем вас встречает новая

00:09:21.920 --> 00:09:26.800
ошибка, ведущая к другому файлу, еще одной правке и очередной пересборке. Этот цикл кажется продуктивным,

00:09:26.900 --> 00:09:32.120
ведь вы что-то делаете, печатаете, компилируете, но по сути это метод проб и ошибок, а не реальное решение.

00:09:32.120 --> 00:09:36.680
Такой цикл может поглотить часы, оставив вас с мелкими поверхностными исправлениями без реального

00:09:36.680 --> 00:09:40.980
прогресса в задаче, с которой вы начали. Настоящая цена здесь – упущенные возможности.

00:09:41.160 --> 00:09:45.840
Пока вы пойманы в ритм, пересобрать и повторить, вы не решаете бизнес-задачи и не выпускаете

00:09:45.840 --> 00:09:50.280
функции, которые ждут пользователи. Энергия уходит на догадки, а не на проектирование.

00:09:50.440 --> 00:09:55.220
В моменте это кажется активной работой, но эти часы не приносят ничего, кроме поддержания системы

00:09:55.220 --> 00:10:00.160
в рабочем состоянии. В команде такая поверхностная активность замедляет все и создает очередь функций,

00:10:00.160 --> 00:10:04.920
которые постоянно откладываются. Именно здесь рабочий процесс с агентом начинает выглядеть иначе.

00:10:04.920 --> 00:10:08.560
Идея не в том, чтобы остановиться на одной строке, которую подсветил стек вызовов.

00:10:08.680 --> 00:10:13.280
Напротив, он спроектирован так, чтобы удерживать контекст всей системы, задаваясь вопросом не только

00:10:13.280 --> 00:10:17.320
о том, что должен делать файл, а какая последовательность изменений нужна для восстановления

00:10:17.320 --> 00:10:22.000
согласованности. На практике это означает, что он может предлагать правки, затрагивающие несколько

00:10:22.000 --> 00:10:26.040
файлов. Например, в демо вы увидите, что когда метод требует изменений, он может предложить

00:10:26.040 --> 00:10:30.080
соответствующие правки в конфигах или шаблонах развертывания, вместо того, чтобы заставлять вас

00:10:30.080 --> 00:10:34.500
искать их вручную. Это переход от автодополнения к чему-то более масштабному. Автодополнение

00:10:34.500 --> 00:10:38.780
завершает строки, а агент координирует работу между файлами, и эта координация особенно важна,

00:10:38.940 --> 00:10:43.100
когда ошибки не локализованы в одном месте. Возьмем распространенный сценарий Азу. Вы создали

00:10:43.100 --> 00:10:47.080
новое приложение функцию, но после развертывания триггер очереди не срабатывает, так как привязка

00:10:47.080 --> 00:10:51.540
не соответствует сигнатуре метода. Обычно вы копаетесь в логах, выясняете, какая привязка неверна,

00:10:51.760 --> 00:10:56.660
вручную правите JSON-файл функции, а может, даже меняете шаблон инфраструктуры, если там тоже есть

00:10:56.660 --> 00:11:01.660
несоответствие. Каждый шаг – это отдельная погоня, и каждое исправление запускает новый тестовый прогон.

00:11:01.660 --> 00:11:05.520
В режиме агента рабочий процесс выглядит иначе. Он может предложить изменение кода,

00:11:05.680 --> 00:11:09.380
создать правильную привязку JSON для функций и отобразить правки для скриптов развертывания,

00:11:09.540 --> 00:11:13.620
если они не согласованы. Вы проверяете, подтверждаете и двигаетесь дальше, не тратя часы на сборку

00:11:13.620 --> 00:11:17.520
каждого слоя воедино. И здесь ключ – это доверие. Никто не должен чувствовать, что в фоне

00:11:17.520 --> 00:11:21.620
происходят невидимые изменения. Вот почему так важен процесс проверки. В этой демонстрации мы

00:11:21.620 --> 00:11:25.780
пройдем через это вместе. Агент предлагает скоординированные изменения. Мы откроем диффов,

00:11:25.900 --> 00:11:30.240
чтобы проверить, что именно было создано, запустим модульные тесты, локально проверим сборку,

00:11:30.240 --> 00:11:34.700
и только после этого решим принять или отклонить изменения. Этот цикл проверки позволяет вам

00:11:34.700 --> 00:11:38.960
сохранять полный контроль, избавляясь от рутинной работы. Стоит подчеркнуть, агенты помогают

00:11:38.960 --> 00:11:43.020
двигаться быстрее, но они не заменяют грамотные инженерные практики. Вам по-прежнему следует

00:11:43.020 --> 00:11:46.960
относиться к проверке кода ECI как к обязательным этапам контроля. Пусть и сокращает время на

00:11:46.960 --> 00:11:50.460
поиск ошибок, но используйте автоматизированные проверки и человеческий контроль в качестве

00:11:50.460 --> 00:11:54.820
системы безопасности. Такой баланс решает проблему доверия и гарантирует, что прирост скорости

00:11:54.820 --> 00:11:59.580
не снизит стабильность. Разница в скорости не является теоретической. Там, где поиск ошибок и ручное

00:11:59.580 --> 00:12:03.520
исправление, могут отнять полдня. Скоординированные предложения сокращают время до минуты.

00:12:03.520 --> 00:12:07.480
А в освобожденное время вы можете направить на работу, которая действительно требует ваших усилий.

00:12:07.580 --> 00:12:11.560
На функции, которые заметят пользователи, и архитектурные решения, улучшающие вашу кодовую базу.

00:12:11.700 --> 00:12:15.360
Вместо того, чтобы «тушить пожары» при запуске, вы можете уверенно проектировать систему заранее.

00:12:15.500 --> 00:12:18.480
Таким образом, цикл отладки больше не должен определять ваш рабочий день.

00:12:18.600 --> 00:12:22.540
Когда агент предлагает обновление для нескольких файлов, вы переходите от хаотичного поиска

00:12:22.540 --> 00:12:26.320
к ритму «проверил и одобрил». Вы перестаете ходить кругами по ошибкам и начинаете

00:12:26.320 --> 00:12:30.220
рассматривать отладку как структурированный, почти автоматизированный этап рабочего процесса.

00:12:30.220 --> 00:12:33.260
Этот сдвиг освобождает когнитивные ресурсы и время для создания функций,

00:12:33.440 --> 00:12:36.820
а не только для исправления недочетов. И как только устранение ошибок перестает быть

00:12:36.820 --> 00:12:40.840
борьбой с симптомами, открываются двери к чему-то большему. К тому, как можно начинать работу

00:12:40.840 --> 00:12:45.020
над целыми функциями в таком же структурированном ключе. Представьте, если тот же рабочий процесс,

00:12:45.220 --> 00:12:49.560
что предлагает скоординированное исправление, сможет взять описание на обычном языке и создать

00:12:49.560 --> 00:12:54.280
под него рабочую структуру. Здесь начинается следующий этап разработки. Разработка на основе

00:12:54.280 --> 00:12:57.820
спецификации без лишних затрат. Один из самых интересных сдвигов происходит,

00:12:57.820 --> 00:13:02.080
когда вы перестаете мыслить только файлами и методами, а начинаете описывать задачи простым

00:13:02.080 --> 00:13:05.740
языком. Именно здесь на помощь приходит разработка на основе спецификации без лишних накладных

00:13:05.740 --> 00:13:09.500
расходов. Представьте, что вы пишете простой запрос на добавление функции. Добавить рабочий

00:13:09.500 --> 00:13:13.680
процесс формирования отчетов, который создает ежемесячные сводки, сохраняет их и делает доступными

00:13:13.680 --> 00:13:17.960
через админ-панель. Вместо того, чтобы получать отдельные фрагменты кода, вы сразу получаете рабочую

00:13:17.960 --> 00:13:22.020
структуру, распределенную по всему приложению. Контролеры созданы, модели прописаны,

00:13:22.020 --> 00:13:26.460
сервисы зарегистрированы, а конфигурация подключена. Этот переход от описания намерения

00:13:26.460 --> 00:13:30.780
к появлению готового каркаса в проекте делает такой подход по-настоящему практичным,

00:13:30.920 --> 00:13:35.360
а не теоретическим. В традиционных условиях разработка с начала спецификация имеет тяжелую

00:13:35.360 --> 00:13:39.160
репутацию. В крупных организациях это обычно означает длинные документы с требованиями,

00:13:39.280 --> 00:13:43.320
многостраничные описания и жесткие диаграммы, которые всех замедляют. Они оправданы в регулируемых

00:13:43.320 --> 00:13:47.060
отраслях или глобально распределенных командах, но в повседневной работе большинство разработчиков

00:13:47.060 --> 00:13:51.340
их пропускают. Написание и поддержание подробных спецификаций требует затрат, на которые ни у кого нет

00:13:51.340 --> 00:13:56.260
времени или терпения. Это дополнительная работа поверх выпуска функций, и по мере приближения сроков

00:13:56.260 --> 00:14:00.900
этими задачами обычно жертвуют. Ирония очевидна, разработчикам на самом деле нравится мыслить

00:14:00.900 --> 00:14:05.140
в общих чертах. Знание структуры заранее внушает уверенность. Проблема не в намерениях,

00:14:05.260 --> 00:14:09.000
а в поддержке документации. Как только спецификация начинает расходиться с реальностью,

00:14:09.220 --> 00:14:13.280
ее поддержка становится временем. Вот почему реальная работа так часто скатывается к импровизации,

00:14:13.280 --> 00:14:17.180
а не к полноценному проектированию, даже в компаниях, которые формально одобряют тщательное

00:14:17.180 --> 00:14:20.720
планирование. Агентский рабочий процесс предлагает альтернативу. Вместо того,

00:14:20.720 --> 00:14:24.520
чтобы требовать отполированный документ с дизайном, он помогает превратить описание на обычном

00:14:24.520 --> 00:14:29.460
языке в каркас, который вы можете доработать. Вам не нужны UML-диаграммы или рукописные карты

00:14:29.460 --> 00:14:35.080
интерфейсов. Можно просто сказать, создай модуль отчетов с новым API-инпоинтом, свяжи его с хранилищем

00:14:35.080 --> 00:14:40.440
и защити доступом на основе ролей, и система создаст базу во всех файлах вашего NIT-решения.

00:14:40.440 --> 00:14:45.400
В демонстрации я зачитаю описание на обычном языке, затем покажу файлы, созданные агентом,

00:14:45.520 --> 00:14:50.100
контроллеры, модели и регистрацию сервисов, и укажу на моменты, которые все еще требовали

00:14:50.100 --> 00:14:55.020
ручной доработки. Так вы сможете самостоятельно оценить качество. Это создает золотую середину

00:14:55.020 --> 00:14:59.560
между двумя режимами разработки. С одной стороны, есть вайп-кодинг, быстро, свободно,

00:14:59.720 --> 00:15:04.080
но хрупко для долгосрочных систем. С другой стороны, проектирование на основе спецификаций

00:15:04.080 --> 00:15:08.440
надежно, но мучительно медленно. С поддержкой агентов вы описываете идею обычными словами,

00:15:08.440 --> 00:15:12.180
появляется каркас, и вы можете итерировать почти так же быстро, как при вайп-кодинг,

00:15:12.360 --> 00:15:16.180
сохраняя при этом преимущество организованной структуры. Возьмем тот же процесс отчетности.

00:15:16.180 --> 00:15:20.380
Обычно вам пришлось бы создать модель, построить сервис данных, подключить контроллер,

00:15:20.640 --> 00:15:24.820
настроить безопасность и связать все в конфигурации запуска. Это значит прыгать по множеству

00:15:24.820 --> 00:15:29.140
файлов в надежде, что согласованность сохранится. При таком подходе вся структура создается

00:15:29.140 --> 00:15:32.140
мгновенно. Реальная экономия заключается не столько в меньшем количестве строк кода,

00:15:32.300 --> 00:15:35.520
сколько в предотвращении ошибок при работе с разными файлами, например, если забыл зарегистрировать

00:15:35.520 --> 00:15:40.080
новый сервис после того, как уже его создал. Конечно, всегда возникает вопрос стиля, будет ли и навязывать

00:15:40.080 --> 00:15:44.100
шаблонный код или перечеркивать принятые соглашения. На практике агенты часто отражают

00:15:44.100 --> 00:15:48.420
существующие в проекте паттерны в своих предложениях. В демонстрации вы увидите обе стороны.

00:15:48.640 --> 00:15:53.440
Места, где структура контролеров идеально совпала с нашей, и места, где догадки и не совпали

00:15:53.440 --> 00:15:57.920
с реальностью. Такое сочетание важно. Вы будете знать, чему можно доверять, а что все еще нужно

00:15:57.920 --> 00:16:01.700
поправить. Итоговый результат – это не шаблонный код под копирку. Это по-прежнему ваш проект,

00:16:01.700 --> 00:16:05.820
только с меньшим объемом ручной работы по созданию каркаса. Вы сохраняете высокую скорость,

00:16:06.040 --> 00:16:09.540
опираясь на фундамент, который можно улучшать по мере роста проекта. Вместо того,

00:16:09.540 --> 00:16:13.080
чтобы составление спецификации оставалось уделом архитекторов, любящих диаграммы,

00:16:13.260 --> 00:16:16.760
оно становится инструментом для любого разработчика, желающего быстро экспериментировать,

00:16:16.920 --> 00:16:21.320
не жертвуя порядком. Когда это входит в ваш ежедневный рабочий процесс, спецификация перестает

00:16:21.320 --> 00:16:26.260
казаться формальным корпоративным этапом и превращается в легкую запись. Вы описываете свое намерение,

00:16:26.260 --> 00:16:31.380
система создает основу, а вы фокусируетесь на проработке деталей. Основной эффект заключается не просто

00:16:31.380 --> 00:16:36.340
в генерируемом коде, а в том, что значит экономия времени неделя за неделей. Больше часов на разработку

00:16:36.340 --> 00:16:40.880
функций, меньше рутины на настройку. Это подводит нас прямо к вопросу, который волнует каждого

00:16:40.880 --> 00:16:45.480
разработчика больше всего. Во что именно выливаются эти изменения с точки зрения продуктивности?

00:16:45.680 --> 00:16:50.300
Отдача от продуктивности. Главный вопрос не в том, экономите ли вы несколько минут тут и там,

00:16:50.460 --> 00:16:54.580
а в том, как эти небольшие сдвиги превращаются в существенные часы в течение недели.

00:16:54.580 --> 00:16:59.000
Это и есть отдача от продуктивности. Возврат времени, который обычно незаметно ускользает из-за

00:16:59.000 --> 00:17:03.320
переключения контекста, повторных циклов сборки и внесения правок вручную. Большинство разработчиков

00:17:03.320 --> 00:17:07.740
принимают эти небольшие потери как неизбежную часть работы. 10 минут на поиск значения в конфиге,

00:17:07.920 --> 00:17:11.980
еще 15 на перезапуск из-за пропущенной ссылки или прыжки между файлами для проверки связей.

00:17:12.060 --> 00:17:16.180
По отдельности они кажутся незначительными, но в сумме за целый спринт они определяют,

00:17:16.380 --> 00:17:20.020
сколько реальной ценности будет доставлено. То, что выглядит как привычные движения,

00:17:20.240 --> 00:17:24.200
скрывает серьезную задержку сроков поставки. Скрытый груз заключается не во времени компиляции

00:17:24.200 --> 00:17:28.380
или скорости печати. Он кроется в рваном ритме, который навязывается вашей концентрацией. Каждый раз,

00:17:28.520 --> 00:17:32.000
когда вы переходите из одного файла в другой, ваш мозг перезагружается. У этой перезагрузки

00:17:32.000 --> 00:17:36.000
есть своя цена. Перекладывание повторяющихся исправлений на агента облегчает это бремя.

00:17:36.180 --> 00:17:39.680
Вместо постоянного восстановления контекста вы тратите силы там, где это важно,

00:17:39.860 --> 00:17:43.980
на решение более серьезных архитектурных задач. Многие команды не отчлеживают эти микрозатраты,

00:17:44.100 --> 00:17:48.060
потому что они не отражаются в тикетах Джира или истории ГИД. Работа, которая ни к чему не привела,

00:17:48.260 --> 00:17:52.340
не фиксируется в логах, но она все равно отнимает энергию. И по мере роста кодовой базы это трение

00:17:52.340 --> 00:17:56.380
не просто растет линейно. Больше уровней – значит больше зависимостей, которые нужно держать в памяти,

00:17:56.380 --> 00:17:59.860
и больше шансов потратить время на простое выравнивание структуры, прежде чем двигаться дальше.

00:18:00.040 --> 00:18:03.460
Агентские рабочие процессы меняют ситуацию, напрямую воздействуя на эти факторы потерь.

00:18:03.580 --> 00:18:07.100
Они не просто быстрее заполняют заглушки методов, они сокращают циклы поиска,

00:18:07.240 --> 00:18:11.420
исправлений и перезапусков, которые съедают целые вечера. Команды, использующие агентские рабочие

00:18:11.420 --> 00:18:14.320
процессы, во многих случаях отмечают более быстрое устранение блокировок.

00:18:14.460 --> 00:18:18.380
В этом видео мы продемонстрируем одну задачу «да» и «после», чтобы вы могли оценить результат.

00:18:18.600 --> 00:18:22.100
Я зафиксирую время, затраченное на реализацию одной и той же функции Азур вручную,

00:18:22.100 --> 00:18:25.760
а затем с помощью агента, чтобы вы могли увидеть прирост продуктивности в конкретных цифрах.

00:18:25.900 --> 00:18:28.980
С точки зрения бизнеса, ценность проявляется в скорости работы над проектом.

00:18:29.160 --> 00:18:32.140
Более быстрые циклы разработки важны не только для удовлетворенности разработчиков.

00:18:32.240 --> 00:18:35.560
От них зависит, выйдут ли функции в текущем релизе или отложатся на кварталы вперед.

00:18:35.700 --> 00:18:39.600
Они влияют на технический долг, так как меньше костылей и регрессий попадает в бэклог.

00:18:39.800 --> 00:18:42.440
Более плавный рабочий процесс позволяет командам двигаться вперед,

00:18:42.600 --> 00:18:44.720
не возвращаясь к исправлению ошибок прошлого спринта.

00:18:44.860 --> 00:18:48.820
Эта стабильность со временем приводит к сокращению, тушению пожаров и повышению качества результатов.

00:18:48.820 --> 00:18:50.620
Существует также человеческий фактор.

00:18:50.780 --> 00:18:53.600
День, потраченный на погоню за ошибками, выматывает любого инженера.

00:18:53.740 --> 00:18:56.060
Когда наступает усталость, сложнее проектировать чистый код,

00:18:56.260 --> 00:18:57.980
внимание притупляется и прокрадываются ошибки.

00:18:58.100 --> 00:19:02.320
Переложив технические исправления на агента, разработчики дольше сохраняют концентрацию.

00:19:02.480 --> 00:19:05.980
Эта дополнительная фокусировка повышает как продуктивность, так и качество.

00:19:06.100 --> 00:19:08.500
Когда вас не тормозят постоянные мелкие препятствия,

00:19:08.740 --> 00:19:11.140
вы свободны мыслить шире и планировать эффективнее.

00:19:11.260 --> 00:19:12.980
На практике разница выглядит так.

00:19:13.100 --> 00:19:16.160
Создание новой функции Azure с множеством привязок и интеграции

00:19:16.160 --> 00:19:18.740
может затянуться на два полных дня без посторонней помощи.

00:19:18.820 --> 00:19:21.820
Из-за настройки, тестирования и бесконечного исправления

00:19:21.820 --> 00:19:24.080
несовпадающих ссылок задача затягивается.

00:19:24.320 --> 00:19:27.080
С помощью агента ту же функцию можно создать за полдня.

00:19:27.280 --> 00:19:30.700
Не потому, что срезаются углы, а потому, что настройка файлов и оркестрация

00:19:30.700 --> 00:19:32.400
выполняются безошибочно с первого раза.

00:19:32.620 --> 00:19:35.920
Сроки сокращаются за счет устранения ложных стартов и избыточных усилий.

00:19:36.080 --> 00:19:38.260
Некоторые разработчики высказывают справедливые опасения.

00:19:38.440 --> 00:19:41.580
Не притупляются ли ваши собственные навыки, если полагаться на и при сопровождении кода?

00:19:41.700 --> 00:19:44.320
Такой взгляд часто упускает из виду суть происходящих изменений.

00:19:44.320 --> 00:19:46.980
Делегирование рутинной настройки не ослабляет вашу экспертизу,

00:19:46.980 --> 00:19:50.180
а сохраняет ее для проектирования и архитектуры, где важны ваши суждения.

00:19:50.320 --> 00:19:53.320
На самом деле вы получаете пространство для решения более сложных задач

00:19:53.320 --> 00:19:55.100
вместо пустой траты энергии на исправление.

00:19:55.300 --> 00:19:59.080
Если попробуете это, напишите в комментариях, сколько часов вам удалось сэкономить за спринт.

00:19:59.120 --> 00:20:01.160
Я добавлю интересные ответы в будущее видео.

00:20:01.400 --> 00:20:03.400
Узнавая, как другие команды переживают этот переход,

00:20:03.560 --> 00:20:07.040
все получают более четкое представление о реальной пользе, выходящей за рамки демо-примеров.

00:20:07.120 --> 00:20:10.700
Однако пара слов предосторожности, автоматизация помогает, но безопасность все еще важна.

00:20:10.700 --> 00:20:14.640
Всегда запускайте тесты и используйте код-ревью для проверки изменений, созданных агентом.

00:20:14.640 --> 00:20:18.480
Доверяйте тому, что рутина сокращается, но сохраняйте прежние механизмы защиты.

00:20:18.660 --> 00:20:21.400
Разница в скорости имеет смысл только при неизменном качестве.

00:20:21.580 --> 00:20:25.900
Надежные тесты и грамотное ревью пиар защищают ваш конвейер выпуска от хрупкой автоматизации.

00:20:26.140 --> 00:20:28.340
Выгода заключается не в быстром написании строк кода,

00:20:28.560 --> 00:20:31.180
а в освобождении ресурсов для создания более сильных решений.

00:20:31.340 --> 00:20:33.140
С меньшей усталостью и меньшим количеством.

00:20:33.140 --> 00:20:36.960
Редактор субтитров А.Семкин Корректор А.Егорова