Перейти до вмісту
Ця стаття була перекладена з японської мови за допомогою ШІ
Читати японською
Ця стаття знаходиться в суспільному надбанні (CC0). Ви можете вільно використовувати її. CC0 1.0 Universal

Всебічний інженер в епоху Liquidware

Добре відомо, що генеративний ШІ може створювати зображення, продукуючи фотореалістичні картини, ілюстрації та малюнки, просто дотримуючись інструкцій.

Тим часом, у світі бізнесу, увага зосереджена на здатності генеративного ШІ генерувати програми.

Чат-ШІ реалізовано за допомогою фундаментальних великих мовних моделей, що робить його дуже вправним у спілкуванні різними мовами та перекладі між ними.

Мови програмування, що використовуються для створення програм, також є різновидом мови. Людські програмісти, в певному сенсі, перекладають вимоги до програмного забезпечення, отримані усно, на мови програмування.

З цієї причини розмовний генеративний ШІ, що використовує великі мовні моделі, також дуже вправний у програмуванні.

Крім того, програмування є видом інтелектуальної роботи, де правильність результату часто може бути перевірена автоматично та миттєво. Це пояснюється тим, що запуск створеної програми дозволяє автоматично визначити, чи досягнуті бажані результати.

Насправді, людські програмісти часто створюють тестові програми одночасно з основною програмою, щоб перевірити, чи функціонує основна програма належним чином, перевіряючи її поведінку в процесі розробки.

Генеративний ШІ також може прогресувати в програмуванні під час тестування, дозволяючи створити механізм, за якого, якщо людина надає точні інструкції, ШІ може автоматично ітерувати та завершувати програму, доки вона не пройде тести.

Звісно, через обмеження можливостей програмування генеративного ШІ та неоднозначність людських інструкцій, існує багато випадків, коли тести не можуть бути пройдені навіть після кількох ітерацій. Крім того, тести можуть бути недостатніми або неправильними, що часто призводить до помилок або проблем у завершеній програмі.

Однак, у міру вдосконалення можливостей генеративного ШІ, людські інженери вдосконалюють свої методи інструктування, а знання генеративного ШІ в програмуванні покращуються завдяки пошуку в Інтернеті, щодня розширюється сфера автоматичної генерації відповідних програм.

Крім того, з огляду на увагу ділового світу, провідні компанії, що проводять дослідження та розробки генеративного ШІ, також зосереджуються на покращенні можливостей програмування генеративного ШІ.

За таких обставин очікується прискорення розширення областей та обсягів, де автоматичне програмування можна довірити генеративному ШІ.

Існує багато випадків, коли люди, які ніколи раніше не розробляли програми, налаштовували базове середовище розробки на основі інформації з Інтернету, а потім дозволяли генеративному ШІ займатися програмуванням, завершуючи програми у спільній роботі.

Я сам, як програміст, використовую генеративний ШІ для програмування. Як тільки я освоюю його, я можу завершувати програмне забезпечення, не редагуючи програму взагалі, просто копіюючи програми у файли або вирізаючи та вставляючи згідно з інструкціями генеративного ШІ.

Звісно, є багато випадків, коли я стикаюся з труднощами. Це здебільшого через те, що мій комп'ютер або інструменти розробки програмного забезпечення мають дещо відмінні налаштування від типових конфігурацій, або безкоштовні програмні компоненти є новішими, ніж те, що вивчив генеративний ШІ, що призводить до прогалин у знаннях, або іноді мій запит є трохи незвичним.

У більшості випадків, якщо немає таких незначних відмінностей або особливих обставин, і я даю вказівку створити дуже поширену функцію програмного забезпечення, генеруються відповідні програми.

Назустріч ері рідкого програмного забезпечення (Liquidware)

Як розробник програмного забезпечення, я можу випускати розроблене мною ПЗ. І програмне забезпечення, яке ми, інженери, випускаємо, використовується різними користувачами.

Майбутнє, де будь-хто зможе здійснювати цю розробку програмного забезпечення за допомогою генеративного ШІ, є продовженням обговорення, що відбулося досі.

Однак це не просто зміна на стороні розробки програмного забезпечення. Значні зміни відбудуться також і на стороні користувача.

Інструктування генеративного ШІ усно, щоб автоматично додавати або змінювати функції програмного забезпечення, може здійснюватися не тільки на етапі розробки до випуску програмного забезпечення, але й під час його використання. Більше того, це можуть робити самі користувачі програмного забезпечення.

Розробникам програмного забезпечення просто потрібно визначити допустимі та незмінні діапазони та випустити програмне забезпечення з функцією налаштування, що працює на основі генеративного ШІ.

Це дозволить користувачам просити генеративний ШІ змінювати незначні проблеми зручності використання або переваги дизайну екрану.

Крім того, стане можливим додавати зручні функції, знайдені в інших програмах, виконувати комбінацію кількох операцій одним кліком або переглядати часто відвідувані екрани на одному дисплеї.

З точки зору розробника програмного забезпечення, увімкнення такої кастомізації користувачами пропонує значні переваги. Це усуває необхідність додавати функції на основі запитів користувачів, і, враховуючи, що це може збільшити популярність програмного забезпечення, уникнувши негативних відгуків і невдоволення щодо зручності використання, це великий виграш.

Коли користувачі можуть вільно змінювати екрани та функції таким чином, концепція значно відхиляється від того, що ми традиційно називали «програмним забезпеченням».

Було б доречно назвати його «рідким програмним забезпеченням» (liquidware), щоб підкреслити, що воно ще більш гнучке та адаптивне, ніж програмне забезпечення (яке є гнучким у порівнянні з апаратним забезпеченням), і що воно ідеально підходить користувачеві.

У минулому функції реалізовувалися виключно апаратним забезпеченням, але потім з'явилося замінне програмне забезпечення, що дозволило реалізувати функції комбінацією апаратного + програмного забезпечення.

Звідси ми можемо уявити появу рідкого програмного забезпечення, яке стосується частин, що можуть бути змінені генеративним ШІ. Таким чином, загальні функції будуть реалізовані за допомогою апаратного забезпечення + програмного забезпечення (наданого розробниками) + рідкого програмного забезпечення (модифікації користувачів).

В цю еру рідкого програмного забезпечення ідеї модифікації з боку користувачів вибухнуть.

Проривна ідея модифікації, винайдена одним користувачем, може стати гарячою темою в соціальних мережах, що призведе до того, що інші будуть наслідувати та модифікувати різне рідке програмне забезпечення.

Також, неминуче з'явиться рідке програмне забезпечення, яке може інтегрувати та обробляти різні типи програмного забезпечення. Це дозволить користувачам переглядати стрічки з кількох різних платформ SNS в одній програмі або інтегрувати результати пошуку з численних платформ.

Таким чином, у світі, де рідке програмне забезпечення поширене, різні пристрої, включаючи ПК та смартфони, надаватимуть функції, які ідеально відповідатимуть життю та діяльності кожної окремої особи.

Сучасне явище

Для інженерів програмного забезпечення, таких як я, важливо те, що "рідке програмне забезпечення" (liquidware) – це не футуристична концепція чи щось, що з'явиться через кілька років.

Це тому, що дуже просте рідке програмне забезпечення вже є досяжним.

Наприклад, припустімо, що я інженер, який розробляє веб-додаток для електронної комерції своєї компанії.

Такі веб-додатки зазвичай мають бази даних, системи управління продажами та системи відправлення товарів на серверах, керованих компанією або за контрактом з хмарними сервісами. Коли користувач здійснює покупку, ці системи взаємодіють для збору платежів та відправлення товарів.

Основні системи та бази даних для цих операцій не можуть бути змінені довільно.

Однак, якщо дизайн веб-сайту електронної комерції, який бачать користувачі, модифікується для зручності кожного користувача, це зазвичай не викликає проблем. Звісно, якщо зміни одного користувача впливають на екран іншого користувача, це проблема, але індивідуальні налаштування, специфічні для користувача, є прийнятними.

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

Технічно ці модифікації можна досягти, змінюючи файли конфігурації та програми, такі як HTML, CSS та JavaScript, які відображають екран у браузері.

З точки зору безпеки, ці файли спочатку виконуються у веб-браузері, тому вони можуть бути модифіковані інженерами, які знайомі з веб-додатками. Отже, вони обробляють лише функції та дані, які безпечно змінювати.

Таким чином, на стороні сервера веб-додатку електронної комерції можна було б зберігати ці файли окремо для кожного зареєстрованого користувача, додати екран для розмови з чат-ШІ та створити механізм для модифікації файлів HTML, CSS та JavaScript цього користувача на сервері відповідно до його запитів.

Якщо ви надасте цей текст, разом з інформацією про конфігурацію та вихідним кодом існуючого веб-додатку електронної комерції, генеративному ШІ, він, ймовірно, надасть кроки та необхідні програми для додавання такої функціональності.

Таким чином, "рідке програмне забезпечення" вже є актуальною темою; не було б дивно, якби це було поточним явищем.

Всебічний інженер

Навіть якщо сфера автоматичного програмування за допомогою ШІ розширюється, і ера рідкого програмного забезпечення вже почалася, розробка програмного забезпечення поки що не може здійснюватися виключно генеративним ШІ.

Однак, безперечно, що роль програмування у розробці програмного забезпечення значно зменшиться.

Крім того, для безперебійної розробки програмного забезпечення потрібні широкі знання та інженерні навички, не лише загальне програмування, а й хмарна інфраструктура, мережі, безпека, платформи, фреймворки розробки та бази даних — охоплюючи всю систему від верху до низу.

Персонал з такими знаннями та навичками називають full-stack інженерами.

Досі кілька full-stack інженерів займалися загальним дизайном, тоді як інші інженери або зосереджувалися виключно на програмуванні, або спеціалізувалися на конкретних не-програмних областях у системному стеку, розподіляючи ролі таким чином.

Однак, оскільки генеративний ШІ бере на себе частину програмування, витрати на розробку програмного забезпечення значно знизяться, що призведе до планування різних нових розробок програмного забезпечення.

Отже, кожен проект розробки вимагатиме дуже мало інженерів, які можуть просто писати код; натомість знадобиться велика кількість full-stack інженерів.

Крім того, у цій ситуації просто мати full-stack знання та навички буде недостатньо. Це тому, що різні проекти розробки програмного забезпечення вимагатимуть різноманітних типів програмного забезпечення, тобто розробка не завжди буде запитуватися в межах одного системного стеку. Також, попит на складні системи, що вимагають кількох системних стеків, обов'язково зросте.

Наприклад, системний стек для веб-додатку відрізняється від системного стеку для бізнес- або основних систем. Тому full-stack інженеру веб-додатків не можна довіряти проект розробки основної системи.

Більше того, веб-додатки, мобільні додатки та настільні програми мають різні системні стеки. У світі вбудованого програмного забезпечення, такого як IoT, системний стек повністю змінюється залежно від пристрою, в який він вбудований.

Однак, якщо акцент на програмуванні зменшується, а загальна вартість розробки програмного забезпечення знижується, розробка композитних систем, що поєднують програмне забезпечення з різними системними стеками, повинна зрости.

Хоча це вимагатиме збирання кількох окремих full-stack інженерів для розробки, інженери, які можуть бачити всю картину та виконувати базовий дизайн, займатимуть вирішальну позицію.

Це означає, що попит на інженерів із всебічними знаннями та навичками в численних системних стеках, що долають межі окремих системних стеків, зросте.

Таких інженерів, ймовірно, називатимуть всебічними інженерами.

І так само, як попит на інженерів, які можуть лише програмувати, зменшиться через генеративний ШІ, зрештою настане ера, коли попит на full-stack інженерів, обмежених одним системним стеком, також зменшиться.

Якщо ви бажаєте залишатися активним ІТ-інженером у ту еру, ви повинні негайно почати прагнути стати всебічним інженером.

Роль всебічного інженера

Мови програмування, платформи та фреймворки, що підлягають розробці, різноманітні.

Однак це не означає, що потрібно вивчити їх усі. Це тому, що всебічний інженер також може отримувати допомогу від генеративного ШІ.

Якщо доручити генеративному ШІ, навіть мови програмування, платформи або фреймворки, якими ви ніколи не користувалися особисто, можуть бути згенеровані просто шляхом надання усних інструкцій.

Звісно, існує ризик впровадження помилок або вразливостей безпеки, або накопичення технічного боргу, що може ускладнити майбутні модифікації.

Щоб ідентифікувати та зменшити ці ризики, необхідні знання конкретної мови або бібліотеки. Однак ці знання також можна отримати від генеративного ШІ. Всебічному інженеру потрібно лише вміти ретельно розробити процедури та механізми для виявлення та запобігання цим проблемам, або для їх вирішення постфактум.

Ці процедури та механізми не сильно змінюються залежно від відмінностей у системному стеку. Якщо вдасться формалізувати процедури та механізми для придушення впровадження помилок та вразливостей безпеки, а також для забезпечення майбутньої розширюваності під час розробки, тоді решту можна доручити генеративному ШІ або інженерам, які володіють цими конкретними областями.

Всебічний інженер не повинен володіти детальними знаннями або тривалим досвідом роботи з кожним окремим системним стеком.

Більше того, однією з головних ролей всебічного інженера є розробка того, як функції розподіляються та як вони взаємодіють у складному програмному забезпеченні, що спільно працює на кількох різних системних стеках.

Крім того, розгляд того, як повинно розроблятися та управлятися все програмне забезпечення, також стає важливою роллю для всебічного інженера.

Всебічне програмне забезпечення

Розглянемо, який тип розробки програмного забезпечення вимагає всебічного інженера.

Раніше я наводив приклад розробки веб-додатку для електронної комерції.

Під керівництвом відповідального керівника, якому вище керівництво компанії доручило переробити цей веб-додаток для електронної комерції, команда планування може висунути такі вимоги:

Трансформація платформи користувацької спільноти. Це означає не просто додаток або сайт для електронної комерції, а надання платформи, де користувачі продукту можуть взаємодіяти один з одним щодо самих продуктів та їх використання. Метою є утримання користувачів, ефект "сарафанного радіо", збагачення контенту за рахунок внесків користувачів та інтеграція зворотного зв'язку щодо розробки продукту (як позитивного, так і негативного) з плануванням нових продуктів та маркетингом.

Сумісність з усіма пристроями (Omni-device Compatibility). Це дозволяє отримати доступ до спільноти користувачів та інформації про продукти не тільки з веб-додатків, але й з додатків для смартфонів, голосових помічників, переносних пристроїв, розумних домашніх приладів та всіх інших пристроїв.

Сумісність з усіма платформами (Omni-platform Compatibility). Це включає не тільки власну платформу користувацької спільноти компанії, але й, наприклад, списки продуктів та обмін відгуками на загальних сайтах електронної комерції, інтеграцію із соціальними мережами, а також функціональне та інформаційне зв'язування з різними інструментами ШІ.

Оновлення бізнес-системи. Тимчасово зв'язуючись з існуючими системами управління продажами та доставки товарів, ці системи також будуть оновлені. Після оновлення передбачається агрегування даних про продажі в режимі реального часу, прогнозування попиту та інтеграція з системами управління запасами. Крім того, оскільки поступова інтеграція з регіональними розподіленими системами запасів та службами доставки товарів, що надаються компаніями-перевізниками, буде прогресувати, інформаційні системи також повинні поступово інтегруватися відповідно.

Сумісність з рідким програмним забезпеченням (Liquidware Compatibility). Звісно, всі користувацькі інтерфейси будуть сумісні з рідким програмним забезпеченням. Крім того, всі внутрішні користувацькі інтерфейси, такі як ті, що призначені для агрегування інформації та зворотного зв'язку для розробки та планування продуктів, відділів системної експлуатації та управлінських звітів, також будуть перетворені на рідке програмне забезпечення.

Якби був представлений план розробки такого складного програмного забезпечення, традиційна команда розробників програмного забезпечення, ймовірно, не прийняла б його негайно. Або ж, у процесі уточнення системних специфікацій, вони логічно продемонстрували б необхідність величезних витрат на розробку та часу, і наполягли б на значному скороченні специфікацій.

Однак, що якби генеративний ШІ міг автоматизувати більшу частину програмування, і більше половини представлених системних стеків були знайомі комусь у команді, і команда мала попередній досвід успішного впровадження нових системних стеків, платформ та фреймворків з нуля за допомогою генеративного ШІ? І що якби ви, як всебічний інженер, вже ступили на цей шлях і мали намір продовжувати його?

З цієї точки зору, це має виглядати як дуже привабливий проект. Ви отримаєте можливість працювати з командою планування, яка висуває амбітні пропозиції під керівництвом лідера планування, та командою розробки, яка має потенціал перетворитися на команду розробників всебічного програмного забезпечення.

Також є впевненість у існуючих системах. Це також проект, який дозволяє використовувати гнучкі процеси розробки, де функції з високим впливом можуть бути швидко створені, а система може зростати поступово за рахунок зворотного зв'язку від ранніх користувачів.

Враховуючи це, розробка цього всебічного програмного забезпечення має виглядати як привабливий проект.

На завершення

Завдяки автоматичному програмуванню за допомогою генеративного ШІ, рідке програмне забезпечення (liquidware) та всебічна розробка програмного забезпечення вже стають сучасною реальністю.

В такій ситуації ІТ-інженерам все більше потрібно виходити за межі full-stack і прагнути стати всебічними інженерами.

Крім того, далі їхня сфера діяльності розшириться до всебічного бізнес-інжинірингу, який комплексно розробляє організаційні заходи, з'єднуючи клієнтів, внутрішніх співробітників та ШІ за межами ІТ-систем, а також до всебічного інжинірингу спільнот.

І ще далі, я вважаю, з'явиться галузь під назвою всебічний соціальний інжиніринг, спрямований на всебічне вдосконалення суспільства.