Microsoft low-code платформи і ШІ: кінець епохи великих команд, чи нова реальність для ІТ-спеціалістів?

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Нещодавно, обговорюючи розміри команд, почув скарги колег з .NET-проєктів: мовляв, нормальна команда — це 10-12 людей, а клієнт скоротив їх до шести. Щоразу, коли чую, що шість людей — це мало, згадую свої останні три проєкти, де над масштабними рішеннями працювало по 3, 4 і навіть 2 особи. Такий розрив у сприйнятті, як на мене, — чіткий індикатор кардинальних змін в IT, особливо з появою ШІ. Але чи справді це так несподівано?

Я — Даніїл Безлюднов, технічний менеджер в ЕРАМ Україна. Вже 11 років займаюся розробкою, архітектурою і продажами рішень на базі MS Dynamics 365 CRM та Power Platform — звичайних low-code платформ від Microsoft — а також наймом фахівців у відповідні команди. Мій досвід у цих технологіях, яким вже понад 20 років, дозволяє стверджувати, що розробка в них завжди велася в рази швидше, ніж на звичайному стеку, як-от .Net/Java+React/Vue/Angular. За моїми спостереженнями, це прискорення може сягати вчетверо. Така ефективність не є чимось надзвичайним, а радше рутиною. Наприклад, для нас звична справа — деплой рішення в продакшн у перший день розробки, або ж створення повноцінного рішення для системи керування інцидентами за два тижні, чи розробка застосунку від А до Я однією людиною за три тижні. Чому саме так? Пояснень багато, і вони полягають у самій архітектурі платформи, її стандартизованих підходах та можливостях, які значно спрощують та прискорюють процеси розробки.

Аж раптом з’являються GPT-3/3.5 та весь цей бум навколо штучного інтелекту. Знову ми чуємо ті самі гасла про «розробники будуть не потрібні через 2 роки», які з’являються кожні два роки. Хвилі скорочень, а потім — найм сотень програмістів на мільйонні контракти. Дехто панікує так, наче вперше бачить таку ситуацію. Насправді, сподіваюся, що всі вже заспокоїлись щодо ШІ і тепер спокійно собі пишуть... кхм-кхм, промптять код за допомогою Copilot/Claude/Codex чи ще якоїсь новомодної IDE. Але що ми як індустрія маємо після всього цього?

Цей матеріал буде корисним для розробників, архітекторів, бізнес-аналітиків, QA-спеціалістів та менеджерів, які цікавляться, як low-code та ШІ впливають на продуктивність, структуру команд і майбутнє IT-професій. Поділюсь своїми спостереженнями про те, як змінилися запити бізнесу, яких спеціалістів шукають зараз і які знання стануть фундаментом для успішної кар’єри у найближчі десять років.

Зміни в потребах бізнесу

Бізнес завжди мав три основні вимоги, які з розвитком технологій лише посилюються: 1) швидше, 2) за менші гроші, 3) саме те, що він хоче (і, звісно, без багів). Штучний інтелект кардинально впливає на всі ці аспекти.

1. Швидкість. Швидкість, з якою ШІ допомагає писати код, вже давно стала фактом. Для мене це очевидно з 2023 року, коли я зміг написати свій перший плагін для Dataverse, використовуючи ШІ, витративши на це всього лише два речення запиту та близько двадцяти натискань клавіші Enter. Цей приклад наочно демонструє, як інтеграція ШІ може прискорювати розробку навіть складних компонентів.
2. Гроші. Тут, звісно, завжди виникають виклики. Якщо раніше витрати на розробку були чітко структуровані, а будь-яке відхилення від бюджету ретельно контролювалося, то тепер з’являється нова стандартна стаття витрат — оплата за використання токенів ШІ-моделей. Мій колега нещодавно витратив 300 доларів на токени за 2 дні, але зробив сайт для хакатону. Для бізнесу це ставить нагальні питання щодо співвідношення ціни та користі від таких інвестицій. Адже, як показала ситуація з Uber, коли весь річний бюджет на ШІ команди витратили за лічені тижні, неконтрольоване використання ШІ може призвести до непередбачуваних та значних витрат, які можуть нівелювати всю потенційну економію від скорочення одного інженера. Хоча, з іншого боку, якщо ШІ забезпечує 10-30% реальної продуктивності, чи не вигідніше залишити, наприклад, дев’ять розробників замість десяти, а зарплату десятого перерозподілити на оплату токенів? Це спонукає нас замислитися: чи справді автоматизація за допомогою ШІ завжди є дешевшою в абсолютному вимірі?
   
3. Без багів. Щодо багів, то тут також є нюанси — їх стає більше. Аналітичні звіти, такі як від FAROS і DORA, демонструють різні цифри, але всі вони вказують на суттєве зростання відсотка помилок, що виникають при використанні ШІ в розробці.

Як виконати побажання клієнта?

Найцікавіші зміни в еру ШІ відбуваються у можливості відповідати на запити клієнта. Швидке прототипування, яке було недоступним раніше, при правильному використанні творить дива. Я постійно чую історії про те, як «робили пів року і відмовилися від функціоналу», «ролбекнули фічу, бо зламала інше і потім так і не повернули», «зупинили роботу по фічі посередині без подальшого поновлення». Це все — явний waste, марна трата ресурсів. Зазвичай це трапляється, коли бізнес бачить першу версію через тиждень у кращому випадку, а часто й через місяць і заявляє: «Що це таке? Я ж це не так собі уявляв і ви взагалі мене не так зрозуміли!». Або ж буває класична ситуація, як у мене на одному з проєктів: «Наші пріоритети змінилися — тепер „копаємо“ фічу 326, а не 428». Якщо ми можемо представити демонстраційну версію швидше, це дозволяє скоріше відмовитися від поганої ідеї, отримати нові побажання і, зрештою, або швидше прийти до бажаного кінцевого результату, або взагалі оперативніше відмовитися від поточної потреби (бо дорого, складно, не подобається тощо).

Наприклад, одна з наших найкращих команд ефективно використовує ШІ-інструменти для швидкого циклу розробки: зустрічі конвертуються в MD-файли вимог, потім — в HTML-прототипи, далі одразу в Canvas Apps, і тестування пишеться на Playwright. Все це реалізується через самостворених агентів, скілів та MCP-серверів. Така схема працює на ура, і в команді всього дві людини. Клієнт при цьому дуже задоволений. Тож бізнес активно шукає способи кращого використання ШІ, а також фахівців, які зможуть йому в цьому допомогти. Саме на цьому полі ми зараз активно працюємо.

Зміни в профілі кандидата

Кого ж ми зараз шукаємо в цьому бурхливому світі технологій? Клієнт, звичайно, хоче бачити єдинорогів з 5 роками досвіду в ChatGPT і 7 роками з Claude Code... ну, ви зрозуміли. Проте, коли вдається приземлити очікування клієнтів, все зводиться до одного з двох ключових напрямків:

Кандидат «вміє в Claude/Codex/Copilot» та «вміє працювати з agentic ШІ».

На додаток до цього, кандидат «вміє розробляти агентів». Ну, а все інше — як і було раніше. Існують також проєкти, які прагнуть створити декілька десятків простеньких RAG (генерацій з доповненою вибіркою) систем з Copilot Studio і шукають для цього людей з річним (!) досвідом роботи з технологією, якій наразі лише 2,5 року. Так, раніше існував Power Virtual Agent, але ним користувалися одиниці. Стандартний профіль розробника в нашому світі MS Business Application починає виглядати так: «потрібна людина, яка сяде і розбереться в тому, що продукт-менеджер навайбкодив за вечір, і виведе це в продакшен».

Ми, розробники, добре знаємо, що вивести щось в продакшен після Proof of Concept (POC) — це задача в рази довша, ніж сам POC. Наприклад, я створив агента для покращення рівня використання ШІ за 2 години, але виводив його в прод близько 15 годин. Це було пов’язано з необхідністю пропрацювати сценарії використання, інтеграції, досвід користувача та ще безліччю базових речей, які перетворюють мінімальний прототип на справжній продукт. Що це означає для світу розробки? Якщо раніше до нас надходила детальна специфікація, то тепер часто приходить вже готовий POC від продукт-овнера. В принципі, це все. Далі йде така ж розробка, тільки швидше і з більшою кількістю багів. Безпека, інтеграції, високе навантаження та інші критичні аспекти нікуди не зникли. Тепер лише потрібно вміти робити це все за допомогою промптінгу. Писали в блокнот, потім в IDE, тепер у чат... Яка, по суті, різниця?

Персональні спостереження за українським (і не тільки) ринком кандидатів з MS Dynamics та Power Platform

Складається враження, що багато фахівців залишилися у 2022 році, і це дуже сумно. Близько 30% кандидатів взагалі не мають жодного слова у своєму резюме про AI/Copilot. Ще 30% досі користуються ШІ лише в режимі чату (GPT або, в кращому випадку, Gemini). Наступні 30% використовують ШІ виключно для генерації коду. Залишок у 10% — це ті, кого дуже важко знайти і найняти (принаймні, в моїх умовах). Сподіваюся, що в інших дисциплінах ситуація з навичками використання ШІ є кращою.

У поточних ринкових реаліях значна частина моїх інтерв’ю з кандидатами починається з ключового питання: «Який у вас досвід використання ШІ для персональної продуктивності?». Так я одразу розумію, чи людина щось використовувала, а якщо так, то як саме, чи бачить продуктивність, чи бачить мінуси, чи знає, як їх обходити тощо. Більшість відповідей звучить так: «Так, я користуюсь GPT (або, в кращому випадку, Copilot) для написання коду». Але мені хотілося б почути щось на кшталт: «Цей ШІ вже дістав мене своїми галюцинаціями... У мене вже і кодінг-агент, і скіли під технології, і контекст я контролюю, але все одно час від часу він галюцинує. Хоча навіть при цьому деякі таски я точно роблю вдвічі швидше, але, звичайно, є безліч речей, які варто змінювати руками, наприклад, мінімальні зміни в конфігах, стилях, змінних тощо. Це точно швидше робити вручну».

Між цими двома типами відповідей — приблизно 1-2 роки активного використання можливостей ШІ. Виходить, що більшість людей на ринку праці почали ним користуватися приблизно з моменту появи Claude 4.5. Ну що ж, це краще, ніж нічого. З цим можна працювати, і саме через це я також поступово беру класних спеціалістів без досвіду ШІ на наші внутрішні 2-3-місячні краш-курси з персональної продуктивності з ШІ. Поки що немає достатньо достовірної вибірки, щоб узагальнювати результати, але ті декілька кейсів, які ми мали, були дуже успішними.

Зміни у щоденній роботі

Що ж змінилося для звичайного фахівця Power Apps чи MS Dynamics у щоденній роботі? Відповідь буде залежати від конкретної професії:

• Бізнес-аналітики і консультанти — замість того, щоб працювати виключно в Jira/Confluence, тепер активно використовують такі інструменти, як Cursor/Claude Code. У мене є подруга-Product Manager, яка вже два роки працює виключно в Cursor; вона генерує Playwright-тести від різних персон, з мітингів робить сторі та потім брейнштормить їх з ШІ. Ще чотири роки тому вона нічого складнішого за Jira не відкривала. Також часто контекст (сторі, документація тощо) BA і консультанти беруть безпосередньо з репозиторія.
• Розробники — замість традиційної IDE тепер основним робочим вікном є чат. Замість криків «Та чого воно не працює!», тепер частіше лунають крики «Та чого ти знову це зробив!» або «Та цього ж не існує!». Замість Jira/Rally/ADO для ведення задач використовуються MD-файли.
• Тестувальники — дивно, але в нашому світі Power Apps вони стають не дуже потрібними, особливо на проєктах з малим бюджетом. Писати тест-кейси вже не є проблемою для розробника, а тестувати може автоматизований інструмент, як-от Playwright. На малому масштабі це працює досить ефективно. На більшому ж масштабі варто говорити скоріше про quality engineering, а не лише про ручне тестування.
• Архітектори — писати тонну архітектурних документів стало в рази легше завдяки ШІ. Діаграми малюються, здавалося б, «О! ніби гарно з одного промпту!». Проте потім з’ясовується: «але тут не так... і там... і ось... ой! Краще вже це руками в Visio/Draw.io/etc намалювати!». Це показує, що ШІ значно прискорює створення чернеток, але фінальна деталізація та корекція все ще потребує людського втручання.
• Менеджери — деякі репорти, що раніше були недоступними або вимагали значних витрат часу, тепер можна створити за лічені хвилини. Команди стали меншими. Значну частину циклу розробки програмного забезпечення (SDLC) тепер можна оптимізувати за допомогою агентів ШІ.

Щодо інших спеціалістів (дизайнерів, експертів з безпеки тощо) — не можу сказати з повною впевненістю. Занадто рідко доводиться працювати з ними, щоб мати репрезентативну вибірку.

А все інше, що стосується основних інженерних процесів, залишається як і було. Ми досі збираємо вимоги, взаємодіємо в команді, проводимо демо та створюємо прототипи, тестуємо, доставляємо і релізимо на прод, і виконуємо ще багато звичайної інженерної роботи. Однак світ MS Dynamics та Power Apps виявився доволі непогано підготовленим до цих змін, і ось чому:

• Стандартизація коду: Більшість коду бізнес-правил у цих платформах є стандартним, і він пишеться ШІ на ура, що значно прискорює розробку.
• Guardrails: Платформою давно закладено дуже багато захисних механізмів, що не дозволяє навіть поганому ШІ-коду розламати весь застосунок, забезпечуючи стабільність.
• Гнучкість релізів: Платформа та команди готові до швидких і частих релізів, що дозволяє оперативно впроваджувати зміни та адаптуватися.
• Малі команди: Стандартний розмір команди — 3±2 особи, і ці команди вже доволі малі, тому немає потреби когось скорочувати. Люди давно готові працювати в невеликих колективах з перетинами в обов’язках, що сприяє ефективності.

На чому зараз сфокусуватись спеціалісту Power Apps чи MS Dynamics?

Відповідь проста і однозначна: вчити ШІ. Хіба ви очікувались чогось іншого? :) Фокуси навчання і практики лежать у двох основних площинах, які необхідно опанувати:

• Використання ШІ для персональної продуктивності. Сюди входять такі інструменти, як-от GitHub Copilot, Claude Code, Codex та інші. По суті це нові, інтелектуальні IDE, які значно підвищують ефективність розробника.
• Нові технології, які допомагають впроваджувати ШІ в застосунки. Мова про такі інструменти як MS Copilot Studio, Dynamics Copilots, Microsoft Foundry, M365 Copilot та інші, які дозволяють створювати інтелектуальні рішення безпосередньо в екосистемі Microsoft.

Ці дві площини тісно перетинаються в загальних знаннях про LLM, відмінності між agents vs skill vs instruction, Prompt/Context engineering, agents harness, MCP та tokenomics. Ці знання є фундаментом, який забезпечить успішну роботу і розвиток у наступні 10 років.

Висновок

Зміни в ШІ стабілізуються. Нові моделі і способи роботи з інструкціями стають схожими на нові JS-фреймворки — трансформації постійні, а фундаментальних — немає. Світ MS Business Application був гарно пристосований до впровадження ШІ через стандартизовані підходи, малі команди і швидкість впровадження рішень. Загалом спокійно продовжуємо розвиватись, бо ІТ-індустрія завжди була про стояння на вістрі технологій і нон-стоп навчання.