Знаєте, що спільного між фразою "Х замінить програмістів" і лялькою Барбі?

Обидвоє зʼявилися 1959 року.

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

І почалися вони, ви не повірите, з… COBOL. Навіть його назва розшифровується як Common Business-Oriented Language. Мова мала спростити створення бізнес-програм, обіцяючи, що менеджери та аналітики зможуть читати код, розуміти його логіку і навіть писати програмні рішення самостійно.

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

Нічого не нагадує?

Потім прийшов зоряний час предметно-орієнтованих мов, які ставили за мету прибрати необхідність писати алгоритми, натомість впроваджуючи декларативне програмування. Тепер можна було описувати що зробити, а не як робити. Замість писати цикл для вибірки даних і форматування звіту, аналітик міг сформулювати запит “Вибрати всі продажі по регіонах за квартал і підсумувати” мовою, близькою до англійської. І якщо у вас промайнула ця думка, то так — це SQL.

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

Наприкинці 1980-х індустрія задумуватись над тим, аби прибрати потребу в написанні коду — усе одно типові рішення усі однакові, навіщо їх щоразу писати? Краще описувати моделі й специфікації — а система генерує код. Так народилася парадигма CASE (Computer-Aided Software Engineering).

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

Нічого не нагадує?

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

А потім прийшли 90-і та принесли візуальну розробку. Тепер взагалі не треба було бути програмістом — наклікав собі вікна, наставив кнопки, притрусив простим як двері Visual Basic і, вуаля, ви тепер стартапер з власним продуктом (нічого не нагадує)?

Ну а далі цей локомотив лише набирав оберти: Excel, ERP-системи, Web та його no-code редактори, які зʼявилися задовго до самого терміну. Перші візуальні конструктори для вебу зʼявилися взагалі в середині 90-х років, коли сам веб ледь на ноги став. Ну хто з дідів не памʼятає Adobe Dreamweaver? Щоразу, коли хтось презентує "революційне" рішення для створення веб-рішень виключно мишкою, ми лише перевертаємось на інший бік і буркотим, що молодь знову вигадала дрімвівер. Бо ми знаємо його долю.

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

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

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

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

І лише Барбі сидітиме в своєму кабріолеті та дивитиметься на цю метушню з ледь помітною посмішкою.

@babichdev