Як ми адаптуємося до ери штучного інтелекту інвестуючи не в AI, а в людей

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

Почну трохи про себе. Звати мене Сергій і на сьогоднішній день я маю 20+ років досвіду у ІТ. Починав як С++ інженер, та працював на різних керівних ролях у великих ІТ компаніях, від Engineering Director до СТО до Head of Sales. Зараз я власник кількох ІТ бізнесів і активно інвестую у ІТ стартапи.

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

Після виходу Chat GPT у масове використання ми зробили наступний крок до впровадження ШІ на масовому рівні, і це створило великий хайп навколо цієї технології. Були й інші події, але саме цю я вважаю найбільш значущою. Зараз важко знайти технологічну (і не тільки) компанію, яка не має у своїй назві, описі чи публічному повідомленні абревіатури AI (Artificial Intelligence). Масовий користувач сприймає це все як якесь диво, що раптово трапилося з ним. Ще вчора ми заходили в Google і шукали інформацію там чи у Wikipedia, а зараз усі йдуть і запитують у чату, що робити.

У день написання цього тексту моя донька гуляла з подругою, і вони знайшли яйця павука. Вранці вона розповіла мені про це. Коли я запитав, звідки вона знає, що це саме яйця павука, вона відповіла, що вони сфотографували їх і запитали у Chat GPT, що це. Поведінкові шаблони користувачів змінилися назавжди, і це сталося миттєво. Можливо, у майбутньому з’явиться інший формат взаємодії з ШІ, але те, що ШІ буде присутнім у нашому житті і що ми будемо покладатися на моделі — не викликає сумніву.

Як і у випадку з будь-якою іншою великою революційною технологією (а ШІ є саме такою), ми стикаємося з тим, що вона змінює навколишній світ. Нові технологічні прориви зазвичай змінюють світ на краще, але є й зворотний бік медалі. Один із негативних наслідків нових технологій — це те, що деякі індустрії або їх частини сильно змінюються чи взагалі перестають існувати. З появою верстатів змінилися умови праці та професії робітників заводів, із появою автоматичних комутаторів зникла професія телефоніста, який вручну з’єднував двох абонентів. Що зміниться з появою ШІ? Я не пишу цю статтю як відповідь на це питання, тому що цей матеріал дуже об’ємний, та й можна запитати про це у Chat GPT 😊. Контент знецінюється, багато що змінюється. Великий вплив спостерігається на інтелектуальні професії, але, думаю, що вплив на робітничі професії також не за горами.

Мене, як власника і керівника кількох ІТ-бізнесів, у першу чергу цікавить, який вплив матиме ШІ на мій бізнес. Я розділяю вплив ШІ на ІТ-бізнес для себе у двох напрямках: продуктовий бізнес і сервісний бізнес. В продуктах вплив величезний, особливо в контексті генеративного ШІ. Колись я планую написати про це більш детально. У цій статті я пишу про вплив ШІ на сервісний бізнес, розробку програмного забезпечення і професію програміста загалом.

Щодня ми отримуємо багато повідомлень, статей, інтерв’ю власників ІТ-компаній про те, що ШІ частково чи повністю замінить програмістів у їхніх компаніях. На момент написання цих слів минуло 2-3 дні, відколи керівник ШІ-стартапу, який розробляє генеративний ШІ для написання коду, заявив, що ШІ буде писати 90% коду через 3-6 місяців, а через рік — 100%. Це повідомлення викликало великий ажіотаж, і мені його кілька разів надсилали друзі та колеги. ІТ-спільнота розділилася у своїх поглядах. Є виражені оптимісти ШІ, які вважають, що вже завтра на дзвінках з командою місце людей займуть ШІ-агенти. Є й скептики, які думають інакше. Я зараховую себе більше до другої категорії і нижче спробую пояснити свою думку.

У той час як для всього світу ШІ з’явився, можна сказати, раптово (в історичному контексті — так точно), для ІТ-сфери це не новизна. Ми давно і в багатьох випадках використовуємо різні моделі ШІ та навчаємо їх для виконання різних типів задач. Просто ці задачі в більшості випадків стосувалися розпізнавання, прогнозування, класифікації тощо. З появою генеративних моделей у нас розширилися сфери застосування та можливості, а також з’явилося і продовжує з’являтися багато нових інструментів. Так, саме інструментів. Я вважав і вважаю ШІ саме інструментом у руках користувача. У нашому контексті користувач — це програміст, і в нього з’являються більш потужні інструменти у вигляді генеративних моделей. Але, як казали у мене в університеті: техніка в руках дикуна — просто шматок заліза. Ми вже давно маємо потужні інструменти, які дозволяють писати код швидко та якісно. Це різні асистенти, вбудовані у середовища розробки, а також ті, які ми встановлюємо додатково. Швидкість розробки постійно зростає, особливо на перших етапах, коли ми працюємо в так званому green field — коли ще нічого не написано. З ШІ цей процес прискориться ще більше. ШІ-модель може написати дуже багато коду, вона може навіть створити першу версію вашого продукту, розгорнути його на сервері й виконати багато інших завдань.

Шлях від ідеї до робочого прототипу справді значно скоротився і буде скорочуватися й надалі. Ця, перша генеративна частина, дійсно зазнає великих змін зараз, і вона так сильно хвилює уми людей в індустрії та за її межами. Але, як каже VP R&D однієї з моїх компаній, створення першої робочої версії продукту (саме робочої версії, а не прототипу!) — це перші легші 90% проєкту, а наступні важчі 90% ще попереду. І це зрозуміють тільки ті, хто розробляв продукти від початку до виходу на ринок. Тому на перших етапах ШІ може дійсно забезпечити велику швидкість, яка, ймовірно, згодом буде спадати. Код має складність, і в міру його зростання складність також збільшується. Якщо цей процес не контролювати, то в певний момент складність може стати неконтрольованою, і технічний борг уб’є проєкт. Може виникнути ситуація, коли внесення простої правки буде настільки складним процесом, що простіше буде переписати модуль чи навіть увесь проєкт. Більш-менш працюючий софт, яким користуються багато людей, — це десятки, сотні, а інколи й мільйони рядків коду. Якщо це все віддати під контроль ШІ і лише додавати в нього побажання щодо нового функціоналу, то дуже скоро ми можемо дійти до неконтрольованої складності проєкту. Окрім технічних труднощів, які я бачу у використанні ШІ, є ще й соціальні виклики.

Ті, хто працював у командах, знають, що процес розробки програмного забезпечення — це не лише кодинг. Кодинг — це невелика частина процесу, особливо коли продукт уже на ринку. Далі вмикаються зовсім інші процеси: збір і обробка даних, планування, дизайн, пріоритизація тощо. SDLC (Software Development Life Cycle) — це комплексний і постійний процес, що має циклічну структуру.У ньому бере участь багато людей, і саме їхня ініціатива визначає подальші кроки. ШІ не наділений ініціативністю. Тому, на моє переконання, новий генеративний ШІ та його наступні версії — це потужний інструмент, який змінить нашу продуктивність, змінить деякі підходи, але процес розробки програмного забезпечення кардинальних змін не зазнає.

Завтра ми писатимемо код швидше, але все одно його потрібно буде контролювати, переглядати, інтегрувати, тестувати. І все це має робити людина.

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

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

Під цим я розумію перегляд коду, згенерованого ШІ, на:

• якість,
• складність,
• відповідність завданню,
• інтеграцію у проєкт.

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

Я нагадаю, що техлід і архітектор — це найвищі звання та найбільша відповідальність серед інженерів, які все ще hands-on. І ось це, на мою думку, найскладніший момент, який має пережити наша індустрія. До позиції техліда чи архітектора люди йдуть роками, і багато хто взагалі не доходить до цього рівня. Щоб піднятися вгору до такої ролі, потрібно вивчити значно більше аспектів професії, ніж звичайному інженеру, який працює в ролі кодера і виконувача завдань із беклогу. Крім того, щоб вирости до рівня техліда, потрібно проявити ініціативу і цікавитися своєю професією за межами щоденних завдань. Зараз перед нами, як керівниками ІТ-бізнесу з розробки програмного забезпечення, стоїть амбіційне завдання:

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

Як вам така задача? 😊

Я думаю над цією задачею вже кілька років. На початку, під час всіх all-hands зі своїми інженерами, я просив їх стежити за розвитком ШІ та адаптуватися до змін в індустрії. Паралельно я зрозумів, що хочу поділитися з ними конкретними кроками в цьому напрямку, а не просто давати абстрактні поради на кшталт: «Вчіться, і все буде добре».

Поступово у мене сформувалася ідея, яку я назвав Engineering Backbone. Я пройшов шлях від Junior Software Engineer до System Architect, CTO, Head of Sales, CEO. Це повний цикл як інженерної кар’єри, так і бізнесової. На кожному етапі я багато навчався і звертався в першу чергу до класиків того напряму, яким займався. Це завжди давало гарний ефект і результати. Тому зараз я маю велику бібліотеку книг і авторів з різних напрямів ІТ та бізнесу. Це підштовхнуло мене перетворити Engineering Backbone на курс — своєрідну освіту сучасного працівника в ІТ-сфері. У першу чергу цей курс стосується програмістів, але деякі його частини я рекомендую всім, хто працює в ІТ-бізнесі, включаючи нетехнічні професії, такі як HR, Sales, Marketing тощо.

Я прийняв рішення інвестувати в додаткову освіту своїх людей, щоб вони були:

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

Як було написано вище, Engineering Backbone — це курс, який я розробляю (ще не завершив) для співробітників моїх компаній. Цей курс складається з десяти напрямків. Подаю їх англійською мовою:

1. Object oriented programming, object oriented design
2. Algorithms and data structures
3. Data bases
4. Cloud solutions
5. Debugging and troubleshooting
6. Quality Assurance
7. SDLC and Agile
8. Architecture
9. UI\UX
10. Soft skills and business communication

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

Тепер давайте порахуємо:

• Ми маємо курс, що складається переважно з технічної літератури.
• У ньому 10 розділів.
• У кожному розділі — в середньому 4 книги.

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

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

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

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

Сподіваюся, вона наштовхне когось на роздуми та реакції, подібні до моїх або ж цілком протилежні😊. Я буду дуже радий якщо хтось додасть важливі пункти до моїх 10, які я взяв за основу для курсу. Також буду радий отримати поради щодо матеріалів курсу.