Як кодування за допомогою штучного інтелекту змінить розробку програмного забезпечення

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

Переклад інтерв’ю інженера-програміста Google Едді Османа Джорджелі Орозу з англійської мови

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

Важко повірити, що трохи більше двох років тому, у листопаді 2022 року, відбувся перший випуск ChatGPT. Це був момент, коли великі мовні моделі (LLM) почали отримувати широке впровадження. Незважаючи на те, що LLM побудовані напрочуд просто , вони дають вражаючі результати в різних сферах. Написання коду виявляється, мабуть, однією з їхніх найсильніших сторін. Це не так вже й дивно, враховуючи, як:

Програмування передбачає набагато простішу граматику, ніж будь-яка людська мова
Існує величезна кількість високоякісних навчальних даних для використання цими LLM у формі робочого вихідного коду завдяки програмному забезпеченню з відкритим кодом і скануванню GitHub та іншим безкоштовним сховищам коду (такий вид сканування та навчання є відбувається, незалежно від того, етично це чи ні)

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

Основні ЗМІ малюють все більш драматичну картину індустрії розробки програмного забезпечення. У березні Business Insider писав про те, що «інженери програмного забезпечення наближаються до з’ясування того, чи справді штучний інтелект може зробити їх безробітними», а у вересні Forbes запитав : «Чи стають інженери програмного забезпечення застарілими?» Хоча такі статті широко охоплюють, вони надходять від людей, які самі не є інженерами програмного забезпечення, не використовують ці інструменти штучного інтелекту та не знають про ефективність (і обмеження!) цих нових інструментів кодування GenAI.

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

Едді Осман — розробник програмного забезпечення та керівник інженерних розробок, який може спостерігати, як інструменти GenAI справді формують інженерію програмного забезпечення. Він працює в Google 12 років і зараз очолює відділ досвіду розробників Chrome. Google є компанією в авангарді інновацій GenAI. У 2017 році компанія написала дослідницьку статтю про архітектуру Transformers , яка є основою для його магістратури. Сьогодні Google створив одну з найдосконаліших базових моделей із Gemini 2.0 і є одним із найбільших конкурентів OpenAI.

Едді узагальнив свої спостереження та прогнози в статті The 70% problem: Hard trues about AI-assisted coding . Це обґрунтований погляд на сильні та слабкі сторони інструментів штучного інтелекту, який підкреслює фундаментальні обмеження цих інструментів, а також позитивні сторони, які є надто хорошими , щоб не прийняти їх як інженер. Він також пропонує практичні поради для інженерів програмного забезпечення від молодшого до старшого щодо того, як отримати максимальну віддачу від цих інструментів. З дозволу Едді, це відредагована версія його статті, опублікована повторно, з доданими моїми думками в кінці. Цей випуск охоплює:

Як розробники насправді використовують ШІ. Дуже різні використання «bootstrappers» проти «iterators». Можливо, причина, чому один інструмент навряд чи однаково добре працюватиме для обох груп?
Проблема 70%: Парадокс кривої навчання ШІ. Менш обговорювані проблеми з ШІ: «парадокс двох кроків назад», прихована ціна «швидкості ШІ» та «парадокс знань».
Що насправді працює: практичні шаблони. AI-перший проект, постійна розмова та шаблони «довіряй, але перевіряй».
Що це означає для розробників? Почніть з малого, залишайтеся модульними та довіряйте своєму досвіду.
Розвиток агентної інженерії програмного забезпечення. Перехід до співпраці зі штучним інтелектом, мультимодальних можливостей, автономних, але керованих підходів і середовища розробки «спочатку англійська».
Повернення програмного забезпечення як ремесла? Повернення втраченого мистецтва полірування та ренесанс персонального програмного забезпечення.
Додаткові думки. Гарний час, щоб оновити, що таке розробка програмного забезпечення насправді і як це була мрія не потребувати розробників з 1960-х років. І все-таки попит на досвідчених інженерів цілком може зрости в майбутньому, а не зменшитися.

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

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

Я помітив дві чіткі моделі того, як команди використовують ШІ для розробки. Давайте назвемо їх «завантажувачами» та «ітераторами». Обидва вони допомагають інженерам (і навіть нетехнічним користувачам) скоротити розрив від ідеї до реалізації (або MVP).

1. Як розробники насправді використовують ШІ

The Bootstrappers: від нуля до MVP

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

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

Результати можуть бути вражаючими. Нещодавно я спостерігав, як сольний (solo) розробник використовував Bolt, щоб миттєво перетворити дизайн Figma на робочий веб-додаток. Він не був готовий до продакшена, але був достатньо добрим, щоб отримати добрі початкові відгуки користувачів.

Ітератори: щоденний розвиток

Другий табір використовує такі інструменти, як Cursor, Cline, Copilot і WindSurf для щоденного робочого процесу розробки. Це менш яскраво, але потенційно більш трансформаційно.

Використання ШІ для доповнення коду та пропозицій
Використання ШІ для складних завдань рефакторингу
Створення тестів і документації
Використання ШІ як «парного програміста» для вирішення проблем

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

2. Проблема 70%: Парадокс кривої навчання ШІ

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

Джерело: Пітер Янг на X

Ця «проблема 70%» розкриває щось важливе щодо поточного стану розробки за допомогою ШІ. Початковий прогрес здається чарівним: ви можете описати те, що хочете, і такі інструменти ШІ, як v0 або Bolt, створять робочий прототип, який виглядає вражаюче. Але потім настає реальність.

Шаблон два кроки назад

Те, що зазвичай відбувається далі, відбувається за передбачуваною схемою:

Ви намагаєтеся виправити невелику помилку
ШІ пропонує зміну, яка виглядає розумною
Це виправлення порушує ще щось
Ви просите ШІ виправити нову проблему
Це створює ще дві проблеми
І знову повторіть

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

Прихована вартість «AI Speed»

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

Рефакторинг згенерованого коду на менші цілеспрямовані модулі
Додавання обробки крайових випадків (edge case), які пропустив ШІ.
Посилення визначень типів та інтерфейсів
Ставлення під сумнів архітектурних рішень
Додавання комплексної обробки помилок

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

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

Прогалина в знаннях

Найуспішніші неінженери, яких я бачив, користуючись інструментами кодування ШІ, використовують гібридний підхід:

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

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

Парадокс знання

Ось найнелогічніша річ, яку я виявив: інструменти ШІ допомагають досвідченим розробникам більше, ніж новачкам. Це здається дивним. Чи не повинен ШІ спростити кодування?

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

Це створює те, що я називаю «парадоксом знання»:

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

Я спостерігав, як senior інженери використовують ШІ для:

Швидко прототипувати ідеї, які вони вже розуміють
Створення базової реалізації, які потім можна вдосконалити
Досліджують альтернативні підходи до відомих проблем
Автоматизують рутинні завдання кодування

Тим часом junior часто:

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

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

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

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

Наслідки для майбутнього

Ця «проблема 70%» свідчить про те, що поточні інструменти кодування ШІ найкраще розглядати як:

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

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

Хороші новини? Цей розрив, ймовірно, зменшиться, коли інструменти вдосконалюватимуться. Але наразі найбільш прагматичний підхід полягає у використанні ШІ для прискорення навчання, а не для його повної заміни.

3. Що насправді працює: практичні шаблони

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

Патерн «ШІ перша чернетка».

Нехай AI створить базову реалізацію

Перегляньте вручну та відредагуйте для модульності
Додайте комплексну обробку помилок
Пишіть ретельні контрольні роботи
Документуйте ключові рішення

Шаблон «Постійна розмова».

Почніть нові чати зі штучним інтелектом для кожного окремого завдання

Тримайте контекст зосередженим і мінімальним
Часто переглядайте та фіксуйте зміни
Підтримуйте тісні петлі зворотного зв’язку

Шаблон «Довіряй, але перевіряй».

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

4. Що це означає для розробників?

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

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

Якщо ви тільки починаєте розробку за допомогою ШІ, ось моя порада:

Почніть з малого

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

Залишайтеся модульними

Розбийте все на невеликі сфокусовані файли
Підтримуйте чіткі інтерфейси між компонентами
Задокументуйте межі вашого модуля

Довіртеся своєму досвіду

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

5. Розвиток агентної інженерії програмного забезпечення

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

Що я маю на увазі під «агентом»? Замість того, щоб просто реагувати на підказки, ці системи можуть планувати, виконувати та повторювати рішення з підвищенням автономності.

Якщо вам цікаво дізнатися більше про агентів, включно з моїм поглядом на Cursor/Cline/v0/Bolt, вас може зацікавити мій останній виступ з JSNation вище.

Ми вже бачимо перші ознаки цієї еволюції:

Від респондентів до співавторів

Наявні інструменти здебільшого чекають на наші команди. Але подивіться на такі нові функції, як використання комп’ютера Anthropic у Claude або здатність Cline автоматично запускати браузери та запускати тести. Це не просто прославлене автозаповнення. Вони дійсно розуміють завдання та беруть на себе ініціативу для вирішення проблем.

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

Завчасно виявляйте потенційні проблеми
Запускати набори тестів
Переглядати елементи інтерфейсу користувача та роблять знімки екрана
Пропонуватм та впроваджувати виправлення
Перевіряти роботу рішень (це може бути великою проблемою)

Мультимодальне майбутнє

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

Візуальне розуміння (скріншоти інтерфейсу користувача, макети, діаграми)
Словесні мовні розмови
Взаємодія із середовищем (браузери, термінали, API)

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

Автономний, але керований

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

Найефективнішими командами у 2025 році можуть бути ті, які навчаться:

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

Перше англійське середовище розробки

«Найпопулярнішою новою мовою програмування є англійська».

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

Цей перехід до агентської розробки вимагатиме від нас розвитку наших навичок:

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

6. Повернення програмного забезпечення як ремесла?

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

Джерело: Гаррі Тан на X

Пастка демо-якості

Це стає зразком: команди використовують ШІ для швидкого створення вражаючих демонстрацій. Щасливий шлях працює чудово. Інвестори та соціальні мережі в захваті. Але коли справжні користувачі почнуть клацати? Ось тоді все розвалюється.

Я бачив це на власні очі:

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

Це не просто помилки P2. Це різниця між програмним забезпеченням, яке люди терплять, і програмним забезпеченням, яке люди люблять.

Втрачене мистецтво

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

Одержимість повідомленнями про помилки
Тестування на повільних з’єднаннях
Витончене поводження з кожним крайнім випадком
Зробити функції легкодоступними/li>
Тестування з реальними, часто нетехнічними користувачами

Така увага до деталей (можливо) не може бути згенерована ШІ. Це походить від співчуття, досвіду та глибокої турботи про ремесло.

Ренесанс персонального програмного забезпечення

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

Пишається своїм ремеслом
Подбає про дрібні деталі
Зосередиться на повній взаємодії з користувачем
Збірка для крайніх випадків
Створює справді самодостатній код

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

Підсумок

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

Те, що штучний інтелект робить, це дозволяє нам ітерації та експерименти швидше, що потенційно призводить до кращих рішень завдяки більш швидкому дослідженню. Але це станеться лише в тому випадку, якщо ми будемо підтримувати нашу інженерну дисципліну і використовуватимемо штучний інтелект як інструмент, а не як заміну належного програмного забезпечення. Пам’ятайте: мета не полягає в тому, щоб швидше написати більше коду. Це створення кращого програмного забезпечення. Штучний інтелект може допомогти нам у цьому за умови розумного використання. Але ми все ще повинні знати, що означає «краще» і як його отримати.

Додаткові думки

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

Гарний час, щоб подумати, що таке розробка програмного забезпечення насправді

Значна частина інформації про інструменти штучного інтелекту для розробки програмного забезпечення зосереджена на можливостях генерації коду, і це справедливо. Інструменти штучного інтелекту вражають тим, що створюють робочий код із підказок або пропонують вбудований код під час створення програмного забезпечення. Але яку частину процесу створення програмного забезпечення становить саме кодування? Близько 50 років тому Фред Брукс вважав, що це близько 15-20% всього витраченого часу. Ось думки Брукса з The Mythical Man-Month :

«Протягом кількох років я успішно використовую наступне емпіричне правило для планування програмного завдання:

⅓ планування

⅙ кодування

¼ тестування компонентів і раннє тестування системи

¼ перевірка системи, всі компоненти в ручну».

Я вважаю, що сьогодні інженери програмного забезпечення, ймовірно, проводять свій час так:

20% планування
40% кодування (код + тести)
20% перегляд коду (код інших)
20% готовність до виробництва + розгортання + невеликі виправлення протягом цього + моніторинг + попередження

У той же час створення видатного програмного забезпечення має багато інших частин:

Що : придумайте, що будувати. Це може включати мозковий штурм, проектування, тестування користувачами, роботу з менеджерами продукту та бізнес-стейкхолдерами тощо. Для стартапів ця фаза може зайняти дуже мало часу («просто створіть і подивіться, чи це працює!»). Однак для відомих компаній це може зайняти більше часу, ніж будівництво («ми повинні переконатися, що те, що ми створюємо, не спантеличить наших існуючих клієнтів!»).
Як: складіть план створення продукту/функції/послуги. Продумайте наслідки для архітектури, залежності, як перевірити продукт тощо. Знову ж таки, стартапи можуть пропустити цей етап, і команда може відразу перейти до планування. Але для великих компаній з більшою кількістю послуг і залежностей відмова від планування знову зашкодить команді. Тож більшість команд планують певний вид, використовуючи документацію з дизайну, RFC або ADR.
Збірка: запровадьте функцію або продукт: напишіть код і переконайтеся, що він працює.
Перевірте : ще раз перевірте, чи він працює належним чином перед відправкою у прод. Це особливо важливо у випадках, коли доставка пов’язана з великими ставками: наприклад, відправка регресу в банківський додаток може мати фінансові наслідки для клієнтів і бізнесу! Ми детально розповіли про забезпечення якості в технологічній галузі.
Відправити : об’єднайте зміни та надішліть клієнтам. Існує багато стратегій для внесення змін у прод. Ми розглянули деякі з них у розділі «Доставка до виробництва».
Моніторинг і виклик: Виявляйте, коли з продуктом щось не так. Якщо стався збій, усуньте його якомога швидше, а потім переконайтеся, що подібний збій більше не повториться. Ми розглянули ці загальні підходи в практиках здорового виклику та в найкращих практиках огляду інцидентів і посмертного аналізу .
Обслуговування: вислуховуйте скарги та відгуки клієнтів і вирішуйте, які помилки вимагають виправлення, а які запити функцій мають бути пріоритетними. І з’ясуйте, які відгуки не враховувати.
Перенесення : якщо продукт зазнає великих змін або якщо технічний стек зазнає серйозних змін (наприклад, нова структура), можливо, знадобляться міграції. Більше ми розглянули в розділі «Міграції зроблено добре» .

Інструменти штучного інтелекту сьогодні можуть дуже допомогти у частині «Створення». Але ось хороше запитання: наскільки вони корисні для інших 7 речей, які також є частиною розробки програмного забезпечення?

Не потребує розробників: мрія з 1960-х років

Люди, які не мають технічних знань, створюють робоче програмне забезпечення, не покладаючись на розробників програмного забезпечення, були мрією з 1960-х років. Кодування означає переклад того, що хочуть люди (клієнти, бізнес-учасники, менеджер із продуктів тощо), до того, що розуміє комп’ютер. LLM пропонують нам вищий рівень абстракції, де ми можемо перетворити англійську мову на код. Однак ця нова абстракція не змінює природу того, як створюється програмне забезпечення — і що таке програмне забезпечення — а це:

Як створюється програмне забезпечення (і що таке програмне забезпечення — це більше, ніж просто код!)

Інструменти GenAI не змінюють процес, але вони роблять деякі частини кодування більш ефективними:

Як інструменти GenAI змінюють нашу роботу програмістів

За всю історію розвитку технологій нові інновації обіцяли можливість для бізнесменів згорнути або обійти «технічну» частину та отримати просто робоче програмне забезпечення з підказок високого рівня. Це було прагнення:

1960-ті роки: мова програмування високого рівня COBOL . COBOL розшифровується як «загальна мова, орієнтована на бізнес». Оголошена мета цієї мови полягала в тому, щоб дозволити діловим людям без досвіду програмування використовувати її.
1990-ті: Visual Basic . Мова програмування, призначена для дуже низької кривої навчання, а також візуальне середовище, де можна створювати форми за допомогою перетягування.
Кінець 2010-х: рух без коду . За допомогою шаблонів і візуального редагування такі рішення без коду, як Bubble, пропонують спосіб створення програмних додатків.

Не дивно, що кілька стартапів із кодування GenAI прагнуть до однієї мети: дозволити будь-кому створювати програмне забезпечення за допомогою англійської мови. У минулому ми досягли успіху в простіших випадках використання. Наприклад, сьогодні для створення веб-сайту не потрібні знання кодування: люди, які не мають технічних знань, можуть використовувати візуальні редактори та такі сервіси, як Wix.com, Webflow, Ghost або WordPress.

Чим вищий рівень абстракції, тим важче визначити, як саме має працювати програмне забезпечення. Рішення без коду вже стикалися з цим обмеженням. Як пише консультативний технічний директор Алекс Хадсон у своїй статті The no-code delusion :

«Розробка цих синтаксисів загалом зіткнулася з проблемою вираження: як тільки вони стають досить простими, щоб швидко їх зрозуміти, вони вже не є достатньо виразними, щоб використовувати їх у багатьох сценаріях. І навпаки: деякі мови мають можливість визначати власну мову всередині себе, так звані доменно-залежні мови (DSL). Деякі з цих мов коли-небудь були по-справжньому успішними серед спільноти розробників загалом, головним чином тому, що вони знову роблять речі надзвичайно складними».

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

Агенти штучного інтелекту: велика обіцянка, але також велика «невідомість» у 2025 році

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

Агенти штучного інтелекту, з іншого боку, знаходяться в зародковому стані. Більшість із нас не використовували їх широко. Є лише один загальнодоступний агент, Девін , за 500 доларів на місяць, і перші відповіді неоднозначні .

У цю сферу вливатиметься багато венчурного фінансування. Ми побачимо, як буде запущено більше інструментів кодування штучного інтелекту, і в результаті ціна також напевно впаде. GitHub Copilot, ймовірно, зробить щось на кшталт Copilot Workspace (агентний підхід) загальнодоступним у 2025 році. І ми, ймовірно, побачимо продукти від стартапів, схожих на те, що заснував колишній технічний директор Stripe Девід Сінглтон ( /dev/agents .)

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

Попит на досвідчених програмістів може зрости

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

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

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