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, Co-Pilot, She, Azure та людей, що формують майбутні роботи.
0:07
Цього січня M365Con повертається, і ми стаємо ще масштабнішими.
0:12
Приєднуйтесь до нас на живі сесії, демонстрації реальних кейсів та практичні знання від MVP та експертів галузі з усього світу.
0:18
Жодних шаблонних слайдів, жодних безкінічних модних слів.
0:22
Ми розглядаємо реальні виклики Co-Pilot Studio, She-агенти, Fabric, безпека, управління та автоматизація.
0:29
Незалежно від того, чи ви IT-фахівець, розробник або бізнес-лідер, для вас знайдуться відповідні сесії.
0:35
Протягом 10 повних днів ви зможете дослідити різноманітні технології та поспілкуватися з глобальною спільнотою.
0:40
Дивіться наживо та приносте практичні інсейти у свою організацію.
0:44
Січень 2027 року, 10 днів, одна спільнота Microsoft. Реєстрацію вже відкрито.
0:51
Переходьте на M365Con.net і забронюйте своє місце сьогодні.
0:56
Це M365Con.net.
0:59
Приєднуйтесь на M365Con.net і побачимось у січні.
1:04
Якщо ви коли-небудь відкривали проєкт і одразу відчували себе перевантаженими мережею файлів, посилань та помилок, що чекають на вас, ви не самотні.
1:11
Більшість розробників працюють реактивно, тут підлатають, там налагодять.
1:15
Режим агента GitHub Coopilot має на меті охопити ширший контекст і координувати зміни в багатьох файлах.
1:20
У цьому відео ми продемонструємо, як виглядає такий робочий процес у реальному проєкті на NIT та Azure.
1:25
Ми пройдемося по живому рішенню і покажемо роботу агента до та після змін.
1:28
Ви побачите, як створювати багатофайловий код з меншими витратами, швидше виправляти помилки між файлами та використовувати звичайну мову для створення каркасів функцій.
1:36
Але перш ніж ми перейдемо до цього, давайте почнемо з прихованої вартості циклу налагодження, у якому багато хто з нас живе щодня.
1:41
Прихована вартість клаптикового налагодження.
1:43
Ви сідаєте за роботу, щоб виправити помилку, яка виглядає досить простою.
1:46
Додаток не збирається, а консоль вказує нарядок у вашому головному файлі проєкту.
1:50
Ви підправляєте метод, перекомпілюєте і думаєте, що все вирішили, поки те саме повідомлення не з'являється знову у дещо іншій формі.
1:56
Минає ще пів години, перш ніж ви помічаєте справжню проблему.
1:59
Відсутня залежність, захована в іншій папці проєкту.
2:02
До того моменту, як посилання виправлено і ви робите повторне розгортання, більша частина дня перетворюється на латання дірок.
2:07
Заплановано роботу над новою функцією, відкладено на завтра.
2:10
Цей шаблон настільки поширений, що здається нормальним.
2:12
На поверхні ви ніби просуваєтесь вперед, бо кожна виправлена помилка здається перемогою.
2:16
На практиці ви бігаєте по колу.
2:17
Цикл виглядає так – код, компіляція, помилка, виправлення, повторення.
2:21
Години зникають у гонитві за причинами та наслідками, а кінцевий результат – це реактивний прогрес, а не значущі покращення.
2:32
Цей цикл виснажує тим, що інструменти навколо нас розвиваються, а підхід – ні.
2:37
Редактори отримують нові функції, фреймворки еволюціонують, інтеграції стають глибшими, але налагодження все ще вимагає реактивного підходу.
2:43
Це як намагатися зупинити пожежу, що розгорається одним відром води.
2:47
Кожен спалах гаситься на місці, але умови, що його викликали, залишаються, гарантуючи наступну пожежу.
2:52
Із кожним перемиканням вкладки зростає прихована ціна.
2:55
Ви переходите від класу сервісу до файлу конфігурації, а потім стрибаєте до графа залежностей.
3:00
Кожне перемикання вириває вас із логічного ланцюжка, змушуючи до розумового перезавантаження.
3:04
Справа не лише в секундах, витрачених на перемикання вікон, а в розумовому навантаженні постійного відновлення контексту.
3:09
Протягом дня ці маленькі перезавантаження накопичуються у щось важке.
3:13
Для окремих розробників втома проявляється як розчарування та марнування часу.
3:17
Для команд, що працюють над корпоративними проєктами, вплив множиться.
3:20
Цикли налагодження збивають цілі спринтів, затримують випуски функцій і створюють беклог, який росте швидше, ніж зменшується.
3:26
Збільшення технічного боргу – лише ще один побічний ефект годин, втрачених на гасіння пожеж.
3:31
Багато команд повідомляють, що значна частина їхнього робочого часу витрачається на реактивне налагодження.
3:35
Це не найбільш захоплива частина інженерії.
3:37
Ніхто не планує дорожню карту навколо п'ятиразового виправлення однієї і тієї ж невідповідності залежностей.
3:42
Проте саме туди йдуть ресурси тиждень за тижнем.
3:44
Коли виправлення помилок стає визначенням прогресу, створення нових функцій відходить на другий план, а архітектура тихо страждає на фоні.
3:51
Неприємна правда в тому, що латання дірок при налагодженні не просто сповільнює роботу.
3:55
Воно зміцнює культуру реакції замість культури проєктування.
3:58
Ви витрачаєте час на гасіння вогню, а не на побудову систем.
4:01
Це може підтримувати життя продукту в короткостроковій перспективі, але обмежує масштабування команди та впевненість у релізах.
4:07
Отже, давайте затримаємося на цьому образі гасіння пожеж.
4:10
Кинутися до вогнища, вилити воду, рухатися далі.
4:12
Проблема не в тому, що розробники не вміють цього робити.
4:15
Вміють.
4:15
Проблема в тому, що вогонь ніколи насправді не згасає.
4:18
Він просто переміщується, спалахуючи в нових файлах, проєктах, конфігураціях, тримаючи всіх у режимі реагування, а не творення.
4:24
Це піднімає питання, що буде, якщо цей цикл перестане лежати лише на вас.
4:29
Що, якби повторювані частини цикл відстеження, перемикання та виправлення можна було керувати інакше, поки ви зосереджені на створенні.
4:36
Тому що, хоча напруга від гасіння пожеж очевидна, є ще одна точка тиску, якої ми ще не торкнулися.
4:41
Справжня складність виникає тоді, коли ваш проєкт – це не один файл чи модуль.
4:45
Це стається, коли потрібне виправлення охоплює кілька рівнів одночасно.
4:48
Уявіть, що ви відкриваєте рішення, де логіка розкидана між різними проєктами, сервісами та бібліотеками.
4:54
Потрібна вам частина знаходиться в трьох місцях одночасно, і втримати це в голові окрема боротьба.
5:00
Хаос багатьох файлів проти контекстного контролю ЩІ.
5:04
Коли проєкти охоплюють багато рівнів, головний виклик – не написання коду, а в тому, щоб поєднати всі рухомі частини воєдину.
5:11
Саме тут найбільш чітко проявляється напруга між хаосом багатьох файлів і контекстним контролем з допомогою ЩІ.
5:15
Візьмемо велике NIT-рішення з десятком або більше проєктів.
5:19
Будь-яка нова функція зазвичай зачіпає різні рівні одночасно.
5:22
Контролер в одному місці, сервіс в іншому і набір конфігураційних файлів, що живуть де-інде.
5:27
Перш ніж написати «Бодай рядок», ви витрачаєте час на відстеження посилань і перевірку залежностей,
5:32
сподіваючись, що невелика зміна не спричинить несподіваних збоїв далі по ланцюгу.
5:35
Такий робочий процес не виняток.
5:37
Це норма для корпоративних додатків, особливо коли з'являються сервіси та інтеграції Azure.
5:42
Структура таких систем не є пласкою.
5:45
Інтерфейси, відображення впровадження залежностей DI та міжпроєктні посилання – усе це відіграє роль.
5:50
З Azure деякі залежності виходять за межі папки рішення, функціональні додатки,
5:54
прив'язки сервісної шини, налаштування ресурсів, підключення до сховищ.
5:58
Ви координуєте код у своєму IDE, конфігураційні файли на диску та сервіси, визначені в хмари.
6:03
Їм байдуже, що ви хотіли б робити менше кліків.
6:06
Щоразу, коли ви перемикаєте контекст, ви витрачаєте енергію на відтворення повної картини.
6:10
Більшість із нас намагається втримати цей контекст у робочій пам'яті.
6:13
Спочатку це керовано, але з ростом проєкту з'являються помилки.
6:16
Ви додаєте новий метод у сервіс, але забуваєте про його реєстрацію в DI.
6:20
Ви пишете Azure функцію і лише згодом розумієте, що прив'язку не додали до хоуст, джейсон чи шаблону розгортання.
6:24
Ніщо не попередить вас до часу виконання, коли ви будете зайняті налагодженням замість створення.
6:28
Сам код – це не найскладніша частина.
6:30
Складнощі в координації між файлами.
6:32
Кожен знає це відчуття стрибати між вкладками, від контролера до сервісу, потім до моделі, далі у конфігураційні файли і назад,
6:38
лише щоб врешті забути, навіщо ви взагалі відкрили цей файл.
6:41
Це дрібне відволікання, що повторюється десятки разів на день.
6:44
Ці взаємодії накопичуються, створюючи тертя, яке гальмує реальний прогрес.
6:48
Результат – повільніша доставка не тому, що повільно пишеться код, а тому, що синхронізація всього забирає увагу.
6:54
Ці накладні витрати зростають у хмарних проектах.
6:57
Azure розсіює ключові налаштування по багатьох місцях, локальних конфігураційних файлах змінних середовища,
7:03
шаблонах ARM або BICEP, конвоєрах CI, CD.
7:06
Те, що виглядає як один запит на функцію, часто охоплює чотири рівні абстракції.
7:11
Ця складність є обов'язковою.
7:12
Вона закладена в саму природу роботи цієї екосистеми.
7:15
Ось тут режим агента може стати справжнім проривом.
7:18
Замість того, щоб залишати всю координацію на вас, він розроблений для утримання ширшого контексту в багатьох файлах.
7:23
Це означає, що коли ви просите про зміни на одному рівні, він не ігнорує інші.
7:27
У демонстрації я створю нову функцію Azure і покажу, як агент допомагає, створюючи тіло методу,
7:32
генеруючи конфігурацію прив'язки, оновлюючи хоуст, JSON і навіть пропонуючи правильну реєстрацію DI.
7:38
Зазвичай це багатоетапний процес, розкиданий по різних файлах.
7:41
Агент може оптимізувати його в єдиний робочий процес.
7:44
Йдеться не про заміну вашого судження, а про усунення рутинної роботи, щоб ви могли зосередитися на виборі архітектури.
7:50
Люди можуть тримати в голові загальний план або начерки на дошці.
7:54
Ще може відстежувати деталі файл за файлом, не втрачаючи логічної нитки.
7:58
Те, що для нас є величезним когнітивним навантаженням, для агента – базовий контекст.
8:02
Різниця на практиці полягає в переході від постійного перемикання між вкладками до скоординованих змін, що залишаються синхронізованими.
8:07
Під час демонстрації я також покажу створений агентом запит на злиття Pull Request або різницю DI, щоб ви бачили, які саме правки були внесені.
8:12
Така прозорість має значення.
8:14
Ви отримуєте повний контроль для перегляду та схвалення, тоді як чорнова робота з оновлення багатьох файлів виконується за вас.
8:19
Тож замість того, щоб витрачати вечір на шивання фрагментів коду, ви спрямовуєте зміни, підтверджуєте згенеровані оновлення і переходите до проєктування вищого рівня.
8:26
Полегшення полягає не лише у збережених кліках чи натисканнях клавіш, а в можливості зосередитися на вирішенні реальних проблем, а не на згадуванні того, як пов'язані між собою десятки файлів.
8:34
Ця перевага найчіткіше проявляється, коли все ламається, адже навіть з кращою обробкою контексту системи дають збої, конфігурації зміщуються, а невідповідні посилання знову з'являються.
8:42
І ось тут починається наступне випробування, як помилки знаходяться та усуваються після їх виникнення.
8:47
Від пошуку помилок до автономних виправлень.
8:49
Подумайте, як часто ви стикалися з повідомленням про помилку, що прямо вказує на один файл.
8:53
Ви слідуєте трасуванням стека до названого методу, вносите невелике коригування і натискаєте «перебудувати».
8:58
Це здається очевидним рішенням, поки та сама помилка не з'являється знову, але вже в дещо іншій формі.
9:03
Саме тоді ви розумієте, що трасування стека показувало лише симптом.
9:06
Справжня проблема ховається зовсім в іншому місці, можливо, у допоміжному класі або всередині конфігураційного файлу, який ви не відкривали цілий тиждень.
9:11
Кожен розробник стикався з таким введенням в оману.
9:14
Те, що виглядає як проблема, насправді не завжди є місцем, де потрібне виправлення.
9:17
Це швидко з'їдає час. Ви вносите зміни, перезбираєте, чекаєте.
9:20
Потім з'являється нова помилка, яка веде до іншого файлу, ще одного налаштування та чергової перезбірки.
9:25
Цей цикл виглядає продуктивним, бо ви рухаєтеся, пишете код, компілюєте, але по суті це більше спроби і помилки, ніж реальне рішення.
9:32
Такий цикл може поглинути години, залишивши вас із дрібними виправленнями, але без реального прогресу у функціоналі, з якого ви починали.
9:38
Справжня ціна тут – це втрачені можливості.
9:40
Поки ви застрягли в ритмі перезбірка, спроба, ви не вирішуєте бізнес-завдання і не випускаєте функціонал, на який чекають користувачі.
9:47
Енергія витрачається на здогадки замість проєктування.
9:50
У моменті це відчувається як активна робота, але ці години не дають нічого, крім підтримки системи в робочому стані.
9:56
У команді цей поверхневий рух уповільнює все і створює накопичення функцій, які постійно відкладаються.
10:01
Ось тут робочий процес агента починає виглядати інакше.
10:04
Ідея не в тому, щоб зупинитися на одному рядку, який виділяє трасування стека.
10:08
Натомість він спроєктований так, щоб утримувати контекст на рівні системи, запитуючи не лише, що має робити цей файл,
10:14
а й яка послідовність змін потрібна для всіх пов'язаних частин, щоб відновити цілісність.
10:18
На практиці це означає, що він може пропонувати редагування, які охоплюють декілька файлів.
10:22
Наприклад, у демо ви побачите, коли метод потребує змін, агент може запропонувати відповідні редагування
10:26
у пов'язаних конфігураціях або шаблонах розгортання, замість того, щоб ви шукали їх самостійно.
10:31
Це перехід від автодоповнення до чогось значно ширшого.
10:34
Автодоповнення завершує рядки, а агент координує роботу між файлами, і ця координація найважливіша,
10:38
коли помилки не зосереджені в одному місці.
10:40
Візьмемо типовий сценарій Azure.
10:42
Ви створили новий додаток функцію, але після розгортання тригер черги дає збій, оскільки прив'язка не відповідає сигнаторі методу.
10:48
Зазвичай ви переглядаєте логи, з'ясовуєте, яка прив'язка помилкова, вручно коригуєте JSON функції
10:53
і, можливо, навіть змінюєте шаблон інфраструктури, якщо там також є невідповідність.
10:57
Кожен крок – це окрема гонитва, і кожне виправлення запускає черговий тест.
11:01
У режимі агента робочий процес інший.
11:04
Він може запропонувати зміну коду, згенерувати правильну прив'язку JSON для функції
11:07
та вивести редагування для скриптів розгортання, якщо вони не узгоджені.
11:10
Ви перевіряєте, підтверджуєте і рухаєтеся далі, не витрачаючи години на те, щоб зібрати кожен рівень докупи.
11:14
І довіра тут є ключовим фактором.
11:16
Ніхто не повинен відчувати, що у фоновому режимі відбуваються невидимі редагування.
11:18
Ось чому важливий процес перегляду.
11:20
У цій демонстрації ми пройдемо через це разом.
11:22
Агент пропонує скоординовані зміни.
11:24
Ми відкриємо DIV, щоб побачити, що саме було згенеровано, запустимо наші модульні тести,
11:29
перевіримо збірку локально і лише тоді вирішимо, прийняти чи відхилити зміни.
11:33
Цей цикл перевірки залишає за вами повний контроль, позбавляючи відрутинної роботи.
11:37
Варто підкреслити, агенти допомагають рухатися швидше, але вони не замінюють належні інженерні практики.
11:42
Вам все одно слід вважати перевірку коду та CI обов'язковими бар'єрами.
11:45
Дозвольте ще скоротити час на пошук помилок, але залиште автоматичні перевірки та людський контроль як запобіжний засіб.
11:51
Цей баланс вирішує проблему довіри та гарантує, що приріст швидкості не зашкодить стабільності.
11:55
Різниця у швидкості не є теоретичною.
11:58
Там, де виправлення помилок вручну може забрати півдня, узгоджені пропозиції скорочують цей час до хвилин.
12:03
Ізекономлений час спрямовується на роботу, на яку ви дійсно хочете витрачати енергію.
12:07
На функції, які помічають користувачі, та архітектурні рішення, що покращують вашу кодову базу.
12:11
Замість гасіння пожеж під час виконання програми, ви можете впевнено проєктувати все заздалегідь.
12:15
Тож цикл налагодження більше не повинен визначати ваш день.
12:18
З агентом, що пропонує оновлення між файлами, ви переходите від хаотичного пошуку до ритму перегляду та схвалення.
12:23
Ви перестаєте блокати колами помилок і починаєте розглядати налагодження як структурований, майже автоматизований крок у робочому процесі.
12:30
Цей соф звільняє ментальний простір і час для створення функцій, а не лише виправлення недоліків.
12:34
І коли виправлення помилок перестає бути лише боротьбою із симптомами, це відкриває двері до чогось більшого.
12:39
Як ви могли б розпочинати цілі функції у такий самий структурований спосіб?
12:43
Уявіть, якби той самий робочий процес, що пропонує узгоджені виправлення, міг також взяти специфікацію простою мовою і сформувати навколо неї робочу структуру.
12:50
Саме тут починається наступний етап розробки.
12:53
Розробка на основі специфікації без зайвих зусиль.
12:55
Одна з найцікавіших змін відбувається тоді, коли ви перестаєте думати лише категоріями файлів і методів, а починаєте формулювати роботу простою мовою.
13:02
Саме тут на допомогу приходить розробка на основі специфікацій без зайвих зусиль.
13:06
Уявіть, що ви пишете простий запит на нову функцію.
13:08
Додати робочий процес звітності, який генерує щомісячні підсумки, зберігає їх і робить доступними через адмінпанель.
13:14
Замість того, щоб отримувати лише кілька окремих фрагментів, ви отримуєте робочу структуру, вже інтегровану у ваш додаток.
13:20
Контролери створені, моделі підготовлені, сервіси зареєстровані, а конфігурація налаштована.
13:24
Цей перехід від опису намірів до появи конкретного каркаса у вашому проєкті робить цей підхід практичним, а не теоретичним.
13:31
У традиційних налаштуваннях розробка на основі специфікацій має важку репутацію.
13:35
У великих організаціях це зазвичай означає довгі документи з вимогами, багатосторінкові дизайн-макети та жорсткі діаграми, що всіх сповільнюють.
13:42
Вони мають сенс у регульованих галузях або в розподілених командах, але для повсякденного програмування більшість розробників їх пропускають.
13:47
Написання та підтримка детальних специфікацій потребують витрат, на які ніхто не має часу чи терпіння.
13:52
Це додаткова робота до реалізації функцій, і коли дедлайни підтискають, ці додаткові зусилля зазвичай приносяться в жертву.
13:57
Іронія очевидна, розробникам насправді подобається мислити ширшими категоріями.
14:01
Розуміння структури заздалегідь додає впевненості.
14:04
Проблема не в намірах, а в підтримці актуальності.
14:06
Як тільки специфікація починає розходитися з реальністю, її підтримка стає тягарем.
14:10
Ось чому в реальній роботі все частіше вдаються до імпровізації, а не повного проєктовання, навіть у компаніях, які офіційно підтримують ретельне планування.
14:17
Агентський робочий процес пропонує альтернативу.
14:20
Замість вимагати готовий документ з дизайном, він може допомогти перетворити специфікацію простою мовою на каркас, який можна доопрацювати.
14:26
Вам не потрібні UML-діаграми чи рукописні карти інтерфейсів, ви можете просто сказати «Створи модуль звітності з новою Ari Endpointом,
14:33
підключи його до сховища та захисти за допомогою рольового доступу, і система згенерує основу у файлах вашого NIT-рішення».
14:40
У демо я прочитаю специфікацію простою мовою, потім покажу створені агентом файли, контролери, моделі та реєстрацію сервісів,
14:47
і вкажу на місця, що потребували ручного доопрацювання.
14:51
Так ви зможете самостійно оцінити якість.
14:53
Це створює золоту середину між двома стилями розробки.
14:56
З одного боку, це вайбі-кодинг – швидко та вільно, але крихко для довгострокових систем.
15:01
З іншого боку, дизайн на основі специфікацій – надійно, але дуже повільно.
15:05
З допомогою агента ви описуєте ідею природною мовою, з'являється каркас, і ви можете працювати майже так само швидко,
15:10
як при вайбі-кодингу, зберігаючи переваги організованої структури.
15:14
Візьмемо знову той самий робочий процес звітності.
15:16
Зазвичай вам довелося б створити модель, побудувати сервіс даних, підключити контролер,
15:21
налаштувати безпеку та з'єднати все це в стартап.
15:23
Це означає перемикання між багатьма файлами з надією на збереження узгодженості.
15:27
З цим підходом каркас вибудовується миттєво.
15:29
Справжня економія полягає не стільки в зменшеній кількості рядків коду,
15:32
скільки в уникненні помилок між файлами, як-от забути зареєструвати новий сервіс після його створення.
15:37
Звісно, завжди виникає питання стилю.
15:39
Чи на в'яжеші шаблонний код або проігнорує конвенції?
15:42
На практиці агенти часто наслідують наявні шаблони проєкту у своїх пропозиціях.
15:46
У демо ви побачите обидві сторони.
15:48
Моменти, де він ідеально влучив у структуру наших контролерів,
15:51
і моменти, де його припущення не зовсім збіглися з очікуваннями.
15:54
Це поєднання є важливим.
15:55
Ви будете знати, чому можна довіряти, а що ще потрібно виправити.
15:58
Кінцевий результат – це не шаблонний код під копірку.
16:00
Це все ще ваш проєкт, просто з меншою кількістю рутинної роботи над каркасом.
16:04
Ви зберігаєте швидкість, спираючись на основу, яку можна вдосконалювати для майбутнього розвитку.
16:09
Замість того, щоб створення специфікацій було справою архітекторів, які мають терпіння до схем,
16:13
воно стає інструментом для будь-якого розробника, що хоче швидко експериментувати без втрати порядку.
16:17
І коли це стає частиною вашого щоденного робочого процесу,
16:20
специфікація перестає сприйматися як формальний корпоративний етап і стає легким способом опису.
16:25
Ви описуєте свій намір, система закладає основу, а ви зосереджуєтесь на опрацюванні деталей.
16:29
Більший вплив має не лише код, який ви створюєте, а те, що економія часу означає для вас тиждень за тижнем.
16:35
Більше годин на функціонал, менше виснажливої роботи з налаштуванням.
16:38
Це підводить нас безпосередньо до питання, яке найбільше хвилює кожного розробника.
16:42
Що ці зміни дають, насправді, з погляду продуктивності?
16:45
Дивіденди від продуктивності.
16:47
Справжнє питання не в тому, чи заощадите ви кілька хвилин тут і там,
16:50
а в тому, як ці дрібні зміни накопичуються в значні години протягом тижня.
16:54
Це і є дивіденди від продуктивності.
16:56
Повернення часу, який зазвичай непомітно витрачається на перемикання контексту,
17:00
повторні цикли збірки та ручне виправлення помилок.
17:02
Більшість розробників сприймають ці дрібні втрати як невід'ємну частину роботи.
17:05
10 хвилин на пошук значення конфігурації,
17:07
ще 15 на перезапуск після пропущеного посилання
17:09
або перестрибування між файлами для перевірки зв'язків.
17:12
Самі по собі вони здаються незначними.
17:14
Але додані разом протягом цілого спринту,
17:15
вони впливають на те, скільки реальної цінності буде доставлено.
17:18
Те, що виглядає як рутенні дії,
17:20
приховує реальне гальмування термінів виконання завдань.
17:22
Прихований тягар полягає не в часі компіляції чи швидкості друку.
17:25
Він у рваному ритмі, що нав'язується вашій концентрації.
17:27
Щоразу, коли ви переходите від одного файлу до іншого,
17:29
ваш мозок перезавантажується.
17:31
Це перезавантаження має свою ціну.
17:33
Перекладання повторюваних виправлень на агента полегшує цей тягар.
17:36
Замість того, щоб постійно відновлювати контекст,
17:38
ви спрямовуєте фокус туди, де це важливо,
17:40
на вирішення складніших архітектурних завдань.
17:42
Багато команд не відстежують ці мікровитрати,
17:44
бо вони не відображаються в ті китах джіра чи історії діт.
17:46
Робота, яка нікуди не веде, не логується,
17:48
але вона все одно споживає енергію.
17:50
І в міру масштабування кодових баз,
17:51
це тертя додається не просто лінійно.
17:53
Більше рівнів означає більше залежностей,
17:55
які треба тримати в пам'яті,
17:56
і більше шансів витратити час просто на узгодження структури
17:58
перед продовженням роботи.
17:59
Робочі процеси з агентами змінюють правила гри,
18:01
безпосередньо усуваючи ці втрати.
18:03
Вони не просто швидше заповнюють заготовки методів.
18:05
Вони скорочують цикли пошуку, виправлення та перезапуску,
18:08
які з'їдають цілі вечори.
18:09
Команди, що використовують агентні робочі процеси,
18:11
у багатьох випадках повідомляють про швидше розблокування роботи.
18:14
У цьому відео ми продемонструємо завдання,
18:16
до та після, щоб ви могли оцінити вплив.
18:18
Я запишу час, необхідний для реалізації тієї ж функції Azure вручну,
18:22
а потім з агентом, щоб ви побачили приріст продуктивності
18:24
в конкретних цифрах.
18:25
З погляду бізнесу цінність проявляється у швидкості проєктів.
18:29
Швидші цикли – це не лише про задоволення розробників.
18:32
Вони вирішують, чи вийдуть функції у цьому релізі,
18:34
чи відкладуться на квартали вперед.
18:35
Вони впливають на технічний борг, оскільки менше хаків
18:38
і регресій потрапляє до беклогу.
18:39
Плавніший робочий процес дозволяє командам рухатися вперед,
18:42
замість того, щоб переробляти зламані з попереднього спринту.
18:44
Така послідовність часом зменшує гасіння пожеж
18:47
і покращує результати доставки.
18:49
Існує також людський фактор.
18:50
День, витрачений на пошук помилок, виснажує будь-якого інженера.
18:53
Коли ви втомлені, якісне проєктування стає важчим,
18:56
деталі вислизають, а помилки накопичуються.
18:58
Перекладаючи механічні виправлення на агента,
19:00
розробники довше залишаються зосередженими.
19:02
Ця додаткова увага підвищує і продуктивність, і якість.
19:05
Коли вас не гальмують постійні перешкоди,
19:08
ви можете мислити ширше і планувати ефективніше.
19:10
Різниця на практиці виглядає так.
19:13
Нова функція Azure з багатьма прив'язками та інтеграціями служб
19:16
може розтягнутися на два повні дні без допомоги.
19:18
Через налаштування, тестування та виправлення помилок
19:21
у посиланнях завдання затягується.
19:24
З допомогою агента ту саму функцію можна створити за півдня.
19:27
Не тому, що ми щось спрощуємо,
19:29
а тому, що налаштування та оркестрація між файлами працюють одразу.
19:32
Терміни скорочуються завдяки усуненню хибних кроків та зайвої роботи.
19:35
Деякі розробники висловлюють слушне занепокоєння.
19:38
Чи не притупляє ваші власні навички покладання наші в питаннях підтримки?
19:41
Такий погляд часто не помічає того, що насправді змінюється.
19:44
Делегування рутинних завдань не послаблює вашу експертизу,
19:47
воно зберігає її для дизайну та архітектури.
19:50
Насправді ви отримуєте простір для вирішення складніших завдань
19:52
замість того, щоб витрачати енергію на дрібні виправлення.
19:55
Якщо спробуєте це, напишіть у коментарях, скільки годин ви зекономіли за спринт.
19:59
Я використаю цікаві відповіді у майбутніх відео.
20:01
Розуміння того, як інші команди сприймають ці зміни,
20:04
дає кращу картину реальної цінності поза межами демо.
20:07
Однак зауважте, автоматизація допомагає, але безпека все одно важлива.
20:10
Завжди запускайте тести та використовуйте перевірку коду для валідації змін від агента.
20:14
Вірте, що рутинної роботи стане менше, але дотримуйтеся тих самих правил безпеки.
20:18
Різниця у швидкості виправдовує себе лише тоді, коли якість залишається стабільною.
20:21
Надійні тести та розумний перегляд піар захищають ваш релізний конвейер від крихкої автоматизації.
20:26
Вигода полягає не стільки у швидкому написанні рядків коду,
20:28
скільки у звільненні ресурсу для створення кращих рішень.
20:31
З меншою втомою та меншою кількістю.