Добре відомо, що генеративний ШІ може створювати фотореалістичні зображення, ілюстрації та картини, просто отримуючи інструкції.
Тим часом, у світі бізнесу, увага зосереджується на здатності генеративного ШІ генерувати програми.
Розмовний ШІ працює на базі великих мовних моделей, фундаментальної технології, і чудово справляється з розмовою різними мовами та перекладом між ними.
Мови програмування, що використовуються для створення програм, також є різновидом мови. Людські програмісти, в певному сенсі, перекладають вимоги до програмного забезпечення, отримані усно, на мови програмування.
Ось чому розмовний генеративний ШІ, який використовує великі мовні моделі, також дуже добре вміє програмувати.
Крім того, програмування є інтелектуальним завданням, де правильність результатів часто можна перевірити автоматично та негайно. Це тому, що створену програму можна виконати та автоматично перевірити, чи вона видає бажаний результат.
Насправді, коли людські програмісти створюють програму, вони часто одночасно створюють тестові програми для перевірки результатів, розробляючи основну програму, перевіряючи, чи вона функціонує, як передбачалося.
Генеративний ШІ також може прогресувати в програмуванні, тестуючи таким же чином. Якщо людина надає точні інструкції, ШІ може автоматично ітерувати та завершувати програму, доки вона не пройде всі тести.
Звичайно, через обмеження можливостей програмування генеративного ШІ та неоднозначність людських інструкцій існує багато випадків, коли тести не можна пройти навіть після численних ітерацій. Більше того, неадекватні або неправильні тести часто призводять до помилок або проблем у завершеній програмі.
Однак, оскільки можливості генеративного ШІ покращуються, а людські інженери вдосконалюють свої методи інструктування, у поєднанні з механізмами розширення знань генеративного ШІ в програмуванні за допомогою пошуку в Інтернеті, сфера автоматичного генерування відповідних програм розширюється з кожним днем.
Крім того, завдяки увазі бізнес-світу, провідні компанії, що займаються дослідженнями та розробками генеративного ШІ, також активно інвестують у покращення можливостей програмування генеративного ШІ.
У цій ситуації очікується, що розширення сфери та обсягу автоматизованих завдань програмування, які можна довірити генеративному ШІ, прискориться.
Існує багато випадків, коли люди, які ніколи раніше не розробляли програми, налаштовували базове середовище розробки, використовуючи інформацію з Інтернету, а потім покладалися на генеративний ШІ для програмування, завершуючи проєкти разом як команда з двох.
Як програміст, я сам використовую генеративний ШІ для програмування. Як тільки я опаную це, я зможу завершувати програмне забезпечення, взагалі не редагуючи програму, просто копіюючи та вставляючи код у файли згідно з інструкціями генеративного ШІ.
Звичайно, є багато випадків, коли я застрягаю. Це здебільшого через незначні відмінності між налаштуваннями мого комп'ютера або інструменту розробки програм та загальними конфігураціями, або через те, що безкоштовні компоненти програмного забезпечення новіші, ніж ті, на яких навчався генеративний ШІ, що спричиняє прогалину в знаннях, або тому, що мої запити дещо незвичайні.
У випадках без таких незначних розбіжностей або особливих обставин, і коли дано вказівку створити дуже поширені функції програмного забезпечення, відповідні програми генеруються в більшості ситуацій.
Назустріч ері рідкого програмного забезпечення
Як розробник програмного забезпечення, я можу випускати створені мною програми, і це програмне забезпечення, випущене нами, інженерами, потім використовується різними користувачами.
Майбутнє, де розробкою програмного забезпечення може займатися будь-хто за допомогою генеративного ШІ, є продовженням обговореної теми.
Однак це не лише зміна з боку розробки програмного забезпечення; значні зміни також відбуваються на стороні користувачів.
Завдання словесного інструктування генеративного ШІ для автоматичного додавання або зміни функцій у програмному забезпеченні може виконуватися не лише на етапі розробки перед випуском програмного забезпечення, а й під час його використання. Більше того, це може виконувати сам користувач програмного забезпечення.
Розробники програмного забезпечення можуть визначити межі того, що можна і що не можна змінювати, а потім випустити програмне забезпечення з функціями налаштування на базі генеративного ШІ.
Це дозволило б користувачам просити генеративний ШІ змінювати незначні незручності або вподобання щодо дизайну екрана в програмному забезпеченні.
Крім того, користувачі могли б додавати корисні функції, знайдені в інших програмах, поєднувати кілька операцій в один клік або переглядати часто відвідувані екрани на одному дисплеї.
Для розробників програмного забезпечення уможливлення такого налаштування користувачами пропонує значні переваги: це усуває зусилля з реалізації запитів на функції самостійно, і це може підвищити популярність програмного забезпечення, уникаючи негативних відгуків та незадоволення щодо зручності використання.
Коли користувачі можуть вільно змінювати екрани та функції таким чином, концепція значно відхиляється від того, що ми традиційно називаємо «програмним забезпеченням».
Було б доречніше назвати це «рідким програмним забезпеченням» (Liquidware), маючи на увазі щось ще більш гнучке та адаптивне, ніж програмне забезпечення (яке вже гнучкіше, ніж апаратне), і те, що ідеально підходить користувачеві.
Функції колись реалізовувалися виключно апаратним забезпеченням. Потім з'явилося взаємозамінне програмне забезпечення, що уможливило функції за допомогою поєднання апаратного та програмного забезпечення.
Звідси ми можемо передбачити появу рідкого програмного забезпечення, що означає частини, які можуть бути змінені генеративним ШІ. Отже, функції будуть реалізовані за допомогою апаратного забезпечення + програмного забезпечення (наданого розробниками) + рідкого програмного забезпечення (зміни користувачів).
В еру рідкого програмного забезпечення ідеї користувачів щодо модифікацій вибухнуть.
Проривна ідея модифікації, винайдена одним користувачем, може стати гарячою темою в соціальних мережах, що спонукає інших імітувати та модифікувати різні програми рідкого програмного забезпечення.
Більше того, ймовірно, з'явиться рідке програмне забезпечення, здатне інтегровано працювати з різними програмними застосунками. Це означає, що користувачі зможуть переглядати стрічки новин з кількох різних платформ соціальних мереж в одній програмі, або результати пошуку можуть інтегрувати результати з численних платформ.
Таким чином, у світі, де рідке програмне забезпечення широко розповсюджене, різні пристрої, включаючи ПК та смартфони, надаватимуть функції, які ідеально підходять для індивідуального життя та діяльності кожного з нас.
Сучасний феномен
Для таких інженерів-програмістів, як я, вкрай важливо розуміти, що Liquidware — це не футуристична концепція чи щось, що з’явиться через кілька років.
Це тому, що навіть дуже просте Liquidware вже досяжне.
Наприклад, припустимо, я інженер, який розробляє веб-додаток для електронної комерції своєї компанії.
Такий веб-додаток матиме бази даних, системи управління продажами та системи відправлення товарів на серверах, керованих внутрішньо або за контрактом через хмарний сервіс. Коли користувач здійснює покупку, ці системи зв’язуються для обробки збору платежів та відправлення товару.
Основні бізнес-системи та бази даних, подібні до цих, не можуть бути довільно змінені.
Однак дизайн веб-екрана електронного комерційного сайту, орієнтованого на користувача, може бути змінений відповідно до індивідуальних потреб користувачів без значних проблем. Звісно, якби зміни одного користувача вплинули на екрани інших користувачів, це було б проблемою, але індивідуальні налаштування, специфічні для користувача, є цілком прийнятними.
Наприклад, можна уявити різні модифікації: збільшення тексту, зміна фону на темний тон, переміщення часто натисканих кнопок для зручнішої роботи лівою рукою, сортування елементів за ціною на екрані списку або відображення деталей двох продуктів поруч.
Технічно ці модифікації можуть бути досягнуті шляхом зміни файлів конфігурації та програм, таких як HTML, CSS та JavaScript, які відображають екран у браузері.
З точки зору безпеки, ці файли спочатку працюють у веб-браузері. Отже, ті частини, які можуть бути змінені інженером, що добре знається на веб-додатках, обробляють лише функції та дані, які безпечно змінювати.
Таким чином, на стороні сервера веб-додатку електронної комерції можна створити механізм для окремого зберігання цих файлів для кожного зареєстрованого користувача, додати екран для розмови з чат-ШІ, а потім модифікувати HTML, CSS та JavaScript файли цього користувача на сервері відповідно до його запитів.
Якби цей текст, разом із існуючою інформацією про конфігурацію веб-додатка електронної комерції та вихідним кодом, було представлено генеративному ШІ, він, ймовірно, надав би кроки та необхідні програми для додавання такої функціональності.
Таким чином, Liquidware вже є актуальною темою; не було б дивно, якби це було поточним явищем прямо зараз.
Всебічні інженери
Навіть за умови розширення сфери автоматичного програмування, керованого ШІ, та настання ери рідкого програмного забезпечення, розробка програмного забезпечення все ще не може здійснюватися виключно генеративним ШІ.
Однак, безперечно, що акцент на програмуванні в розробці програмного забезпечення значно зменшиться.
Крім того, для безперебійної розробки програмного забезпечення потрібен широкий спектр знань та інженерних навичок, починаючи від загального програмування до хмарної інфраструктури, мереж, безпеки, платформ, фреймворків розробки та баз даних — усього системного стеку, щоб вся система функціонувала.
Персонал з такими знаннями та навичками називають full-stack інженерами.
Традиційно кілька full-stack інженерів займалися загальним дизайном, тоді як решта інженерів спеціалізувалися на програмуванні або зосереджувалися на конкретних непрограмних областях в системному стеку, таким чином розділяючи ролі.
Однак, оскільки генеративний ШІ бере на себе аспект програмування, витрати на розробку програмного забезпечення значно зменшаться, що призведе до планування різних нових проєктів розробки програмного забезпечення.
Отже, в кожному проєкті розробки інженери, які можуть просто писати програми, будуть значною мірою непотрібні; натомість, буде попит на велику кількість full-stack інженерів.
Більше того, за цього сценарію просто мати full-stack знання та навички буде недостатньо. Це тому, що типи програмного забезпечення, необхідні в різних проєктах розробки, будуть диверсифікуватися, тобто розробка не завжди буде запитуватися з використанням того самого системного стеку. Крім того, безсумнівно, зростатимуть вимоги до складних систем, що вимагають кількох системних стеків.
Наприклад, системний стек для веб-додатка відрізняється від системного стеку для бізнес- або основних систем. Тому інженеру full-stack веб-додатків не можна доручати проєкт розробки основної системи.
Аналогічно, веб-додатки, мобільні додатки та програми для ПК мають різні системні стеки. У світі вбудованого програмного забезпечення, такого як IoT, системний стек повністю відрізнятиметься для кожного вбудованого пристрою.
Однак, оскільки акцент на програмуванні зменшується, а загальні витрати на розробку програмного забезпечення падають, розробка складних систем, що поєднують програмне забезпечення з цими різними системними стеками, ймовірно, зросте.
Хоча така розробка вимагатиме збирання кількох окремих full-stack інженерів, інженери, які можуть контролювати всю систему та займатися базовим дизайном, відіграватимуть вирішальну роль.
Це означає, що буде попит на інженерів з всебічними знаннями та навичками в численних системних стеках, що виходять за межі окремих системних стеків.
Такі інженери, ймовірно, будуть називатися всебічними інженерами.
І так само, як попит на інженерів, які можуть лише програмувати, зменшиться через генеративний ШІ, зрештою настане ера, коли попит на full-stack інженерів, обмежених одним системним стеком, також зменшиться.
Якщо ви бажаєте залишатися активним ІТ-інженером у ту епоху, ви повинні негайно розпочати шлях до того, щоб стати всебічним інженером.
Роль всебічних інженерів
Мови програмування, платформи та фреймворки, що розроблятимуться, є різноманітними.
Однак всебічному інженеру не потрібно опановувати всі з них, адже вони також можуть отримувати допомогу від генеративного ШІ.
Якщо ви доручите це генеративному ШІ, навіть мови програмування, платформи або фреймворки, якими ви ніколи раніше не користувалися, можуть бути згенеровані просто шляхом надання словесних інструкцій.
Звичайно, існує ризик внесення помилок або вразливостей безпеки, або накопичення технічного боргу, що може ускладнити майбутні модифікації.
Для виявлення та зменшення цих ризиків необхідні знання конкретної мови або бібліотеки. Однак ці знання також можна отримати від генеративного ШІ. Всебічний інженер повинен лише вміти надійно будувати процедури та механізми для виявлення та запобігання цим проблемам, або для їх усунення після виникнення.
Ці процедури та механізми не змінюються кардинально з різними системними стеками. Якщо процедури та механізми для запобігання помилкам та вразливостям безпеки та забезпечення майбутньої розширюваності формалізовані, тоді решту можна залишити генеративному ШІ або інженерам, які спеціалізуються на цих конкретних областях.
Всебічним інженерам не потрібно володіти детальними знаннями або довгостроковим досвідом роботи з кожним окремим системним стеком.
Однією з головних ролей всебічного інженера є проєктування розподілу функцій та взаємодії кількох складних програмних систем, що спільно працюють у різних системних стеках.
Крім того, розгляд того, як розробляти та керувати всім програмним забезпеченням, також є ключовою роллю всебічного інженера.
Всебічне програмне забезпечення
Давайте розглянемо, для якого виду розробки програмного забезпечення потрібен всебічний інженер.
Раніше я наводив приклад розробки веб-додатку для електронної комерції.
Під керівництвом керівника, якому вищим керівництвом було доручено оновити цей веб-додаток для електронної комерції, команда планування може висунути наступні вимоги:
Інтеграція платформи спільноти користувачів: Це означає надання платформи не лише для спеціалізованого додатку або сайту електронної комерції, а й для того, щоб користувачі могли спілкуватися про самі продукти та способи їх використання. Метою є утримання користувачів, ефект «сарафанного радіо», збагачення контенту за рахунок внесків користувачів, а також інтеграція зворотного зв'язку (як позитивного, так і негативного) у розробку продуктів, планування нових продуктів та маркетинг.
Сумісність з усіма пристроями: Це забезпечує доступ до спільноти користувачів та інформації про продукти з різних пристроїв, включаючи не лише веб-додатки, а й програми для смартфонів, голосових помічників, переносні пристрої та розумну побутову техніку.
Сумісність з усіма платформами: Це включає не лише власну платформу спільноти користувачів компанії, а й, наприклад, розміщення товарів та обмін відгуками на комплексних сайтах електронної комерції, інтеграцію із соціальними мережами, а також функціональний та інформаційний зв'язок з різними інструментами ШІ.
Оновлення бізнес-системи: Тимчасово пов'язуючи її з існуючими системами управління продажами та доставки товарів, це також передбачає оновлення цих систем. Після оновлення план включає агрегацію даних про продажі в реальному часі та прогнозування попиту, а також інтеграцію з системами управління запасами. Крім того, поетапно буде впроваджуватися зв'язок з регіонально розподіленими системами запасів, що надаються компаніями доставки, та послугами доставки з боку перевізника, що вимагає поступової адаптації інтеграцій інформаційної системи відповідно.
Сумісність з рідким програмним забезпеченням: Усі користувацькі інтерфейси, звичайно, будуть сумісні з рідким програмним забезпеченням. Крім того, внутрішні користувацькі інтерфейси для розробки та планування продуктів (такі як агрегація інформації та зворотний зв'язок), відділи операцій системи та звіти для керівництва також будуть перетворені на рідке програмне забезпечення.
Якби було представлено план розробки такого складного програмного забезпечення, традиційна команда розробників програмного забезпечення, ймовірно, не прийняла б його відразу. Або, під час обговорень системних специфікацій, вони б логічно продемонстрували потребу у величезних витратах на розробку та час, спонукаючи до значних скорочень специфікацій.
Однак, що, якби генеративний ШІ міг автоматизувати більшість програмування, і більше половини запропонованих системних стеків вже були досвідченими для когось із команди? І що, якби команда мала досвід успішного запуску нових системних стеків, платформ та фреймворків з нуля за допомогою генеративного ШІ? І що, якби ви, як всебічний інженер, вже почали цей шлях і мали намір продовжувати його?
З цієї точки зору, це має виглядати як дуже привабливий проєкт. Ви б отримали можливість працювати з командою планування, яка висуває амбітні пропозиції від вищого керівництва, та командою розробників з потенціалом вирости у всебічну команду розробників програмного забезпечення.
Є також впевненість у існуючих системах. Це також проєкт, який можна поступово розвивати за допомогою гнучкого процесу розробки, починаючи з швидких, високоефективних функцій та збираючи зворотний зв'язок від перших користувачів.
Враховуючи все це, розробка цього всебічного програмного забезпечення повинна здатися дуже привабливим проєктом.
Висновок
Завдяки автоматичному програмуванню, керованому генеративним ШІ, рідке програмне забезпечення та всебічна розробка програмного забезпечення вже стають сучасною реальністю.
У цьому контексті, ІТ-інженерам все частіше потрібно виходити за межі full-stack і прагнути стати всебічними інженерами.
Крім того, їхній обсяг повноважень розшириться ще більше, виходячи за рамки ІТ-систем, щоб охопити всебічне бізнес-інженерію — інженерію самої організаційної діяльності, шляхом з'єднання клієнтів, внутрішніх співробітників та ШІ — та всебічну громадську інженерію.
І навіть далі, я передбачаю появу галузі, яка називається всебічна соціальна інженерія, спрямована на всебічне покращення суспільства.