Розробники і стосунки з АІ: у чому штучний інтелект кращий за нас і як це використати

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

Вітаю! На зв’язку В’ячеслав Колдовський, зараз працюю на посаді керівника компетентностей в SoftServe Academy. А ще я автор ютуб та телеграм-каналів «Programming Mentor». В професійному IT з 1990-х, маю досвід професійного розробника з широким спектром технологій. Займаюсь створенням і впровадженням навчальних рішень, оцінкою і розвитком професійних навичок розробників, підготовкою до інтерв’ю та побудовою систем компетентностей IT-компаній. Сертифікований Google Cloud Architect Professional, Ph.D. Ентузіаст генеративного штучного інтелекту.

Вступ

Зайдемо трохи здалеку, але це важливо для контексту.

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

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

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

Часова шкала технологій

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

Це не зараз все швидко розвивається, це раніше все відбувалося повільно, — Сем Альтман

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

Software Engineer 1.0

Маргарет Хамільтон, авторка терміну «software engineer», поруч з лістингами коду програми Аполлон NASA

Згадаймо, яким був програміст версії 1.0. Це період кінця 1950-х, коли з’явилися мови програмування високого рівня, і до початку 2000-х. Коли я в дев’яностих тільки починав програмувати, доступ до знань був обмежений. Ми користувалися книжками, паперовою документацією, статтями в журналах. Комунікація відбувалася через телефон або електронну пошту (у моєму випадку — FIDO). Інструменти розробника були примітивними, системи контролю версій — дуже незручними. Можливо, тут знайдуться ті, хто пам’ятає «Visual SourceUnsafe»? :)

У той час моделі розробки програмного забезпечення були здебільшого лінійними, як-от Waterfall або V-model. Процеси були повільними, і швидкість розробки вимірювалася місяцями, якщо не роками.

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

Software Engineer 2.0

Типовий Software Engineer 2.0 очима AI

Потім настала ера Software Engineer 2.0 — десь з першої декади двотисячних і до нашого часу. З поширенням вебу, Google, StackOverflow та онлайн-курсів, доступ до знань не просто «спростився», він став миттєвим. Вчитися стало простіше, поріг входження значно знизився.

Комунікація стала глобальною завдяки Slack, Teams, Zoom, Google Meet, Discord і т. п. Інструменти розробника значно вдосконалилися, з’явилися системи контролю версій з CI/CD — тепер не так страшно і не зовсім просто «щось зламати» в проєкті.

Моделі розробки — переважно Agile, використання практик DevOps/DevSecOps. Це дозволяє нормально сприймати зміни вимог і поставляти рішення швидше. Процес видачі релізів скоротився до тижнів і навіть днів.

Найбільш принципова зміна в тому, що просто неймовірно зросла динамічність процесу. Якщо взяти умовного розробника 1.0 з минулого і розказати йому, що можна на «якомусь гітхабі» взяти на себе задачу, написати шматок коду для неї, а потім натиском однієї кнопки запустити процес, де той код полетить в хмару, запустить купу автоматизованих процесів і перевірок, і якщо все пройде успішно, то автоматично потрапить у прод за лічені хвилини, і це все можна зробити не виходячи з дому — то не факт, що він би повірив. А якби повірив, то просто не зміг би це уявити, бо все зав’язано на технологіях, яких в минулому не існувало взагалі.

Просто для порівняння: в кінці 90-х в одній продуктовій компанії у нас щотижня виділявся цілий день винятково на інтеграцію коду в одну кодову базу. Ми в цей день не писали нічого, крім того, що було потрібно, щоб проєкт міг збиратися і запускатися з кодом всіх учасників. Інтегрувати все до купи вдавалося далеко не завжди, тоді «неінтегрований» код переносився на наступний раз. Інтегрований код «пропалювали» на CD-R, підписували маркером і роздавали всім членам команди.

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

Software Engineer 3.0

Але що далі? Яким буде Software Engineer 3.0? Чи потрібен він взагалі? Можливо, у нас в галузі й немає ніяких проблем, і якось воно буде розвиватися як «мінорні версії» 2X?

Однак навряд хтось не погодиться, що проблем у нас достатньо, і ось їх неповний перелік:

• Недосконалість технологій, інструментів, платформ: технології розвиваються, але залишаються неідеальними.
• Варіативність архітектурних рішень, технологій, платформ: частково це є наслідком попереднього: вирішуючи одні проблеми, ми створюємо інші. Різноманіття має бути благом, а в реальності є серйозним викликом.
• Стабільними є лише постійні зміни технологій: мабуть, єдине, що в цій професії стабільне — це необхідність вивчати щось нове.
• Технічний борг: невирішені проблеми мають тенденцію до накопичення, і наступає момент, коли кількість переходить у якість.
• Кіберзагрози: безпека стає все більш критичною, помилки тут коштують особливо дорого, як і вирішення питань безпеки.
• Регуляції, стандарти, комплаєнси: необхідність відповідати вимогам, часто неузгодженим і суперечливим, у різних локаціях.
• Інтернаціоналізація: продукти повинні бути доступними для глобальної аудиторії.
• Інертність адаптації до зміни вимог: хоч Agile говорить, що зміни ми любимо, насправді це не так.
• Складність рішень: хоч якість інструментів покращується, це не зменшує загальну складність систем і всього, що з цього випливає.
• Дороговизна: як наслідок всіх чинників, вартість розробки зростає. Це тисне на бізнес і часто стає причиною таких складнощів в галузі як масові скорочення, наприклад.
• Повільність: незважаючи на зростання продуктивності розробників, деякі процеси залишаються повільними, і хоча поправити код та отримати його на проді ми можемо за лічені хвилини, шлях від ідеї до продукту часто потребує занадто багато часу.
• Недостатньо кваліфікованих фахівців: зарплати у кваліфікованих розробників є високими не просто так, і незважаючи на періодичні коливання на ринку праці, загальна тенденція полягає в тому, що попит на професіоналів перевищує пропозицію.
• Складно давати імена сутностям: є така одвічна проблема, тут не буду розписувати, всі знають.

В чому основна проблема IT

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

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

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

Але чи можливо це взалі? Може робота розробника в IT настільки особлива, що нею може займатися лише людина, а не AI? Давайте трохи заглибимося в те, з чим саме насправді ми працюємо.

Що таке програмний код

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

Бо насправді, програмний код — це думка розробника, записана мовою, яка зрозуміла йому та комп’ютеру. Не більше, але іноді трохи менше, в аспекті «зрозуміла йому».

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

Хоча здавалося б, що фундаментальні основи галузі вже достатньо добре вивчені, і з моменту виходу високорівневих мов програмування пройшло достатньо часу. Тут важливо підкреслити, що сучасні мейнстрімні мови — Python, JS, C#, Rust, Go і далі по списку насправді не дуже принципово відрізняються від мов, створених в 1950-1970-х роках. Вони все ще базуються на схожих концепціях: процедурне програмування, об’єктно-орієнтований підхід, функціональні конструкції — усе це закладалося ще в той час.

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

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

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

Генеалогічне дерево мов програмування — якщо не бачили, то дуже рекомендую

Що таке програмна інженерія

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

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

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

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

• Алгоритми: основні методи вирішення задач, враховуючи обмеженість ресурсів і оптимальність у кожній конкретній ситуації.
• Структури даних: способи організації даних.
• Парадигми програмування: формують мислення розробника та підхід до вирішення задач.
• Архітектури програмних систем: визначає структуру системи та взаємодію її компонентів, враховуючи обмеження середовища та вимоги.
• Патерни, принципи, практики: набір рекомендацій та перевірених часом рішень, що дозволяє робити рішення уніфікованими, надійними і зрозумілими для інших.
• Мови, бібліотеки, фреймворки: інструменти, що визначають технологічний стек проєкту, диктують його структуру, обмеження. В ідеальній ситуації мають підбиратися під задачу, на практиці ж часто підбираються під рівень компетентності команди чи розробника.
• Інструменти, системи контролю версій, CI/CD: дозволяють безпосередньо реалізувати рішення. Їх вибір впливає на хід виконання роботи, терміни виконання проєкту та якість кінцевого продукту.
• ОС, мережі, контейнери, хмарні платформи: визначають середовище розгортання, виконання і масштабування програмного забезпечення, враховують обмеження інфраструктури, забезпечують безпеку, доступність і продуктивність системи.

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

З якою роботою AI справляється найкраще

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

Так, це правда, що він допускає помилки і часто до готового рішення приходить не відразу, а чим складнішою є задача і чим менш типовою вона є, тим гірше в нього виходить (поки що). Але почекайте, чи не можна це ж саме сказати про розробників-людей? Звичайно, можна.

Але є задачі, з якими AI справляється вже значно краще за людей. Можу навести багато прикладів — почнемо з типових алгоритмічних задач. Я проводив багато інтерв’ю розробників і скажу з абсолютною впевненістю: людей, які люблять ці задачі і можуть їх гарно вирішувати, на ринку набагато менше, ніж має бути. Далеко не кожен готовий сидіти тижнями і місяцями на Leetcode чи Codewars і «набивати руку» на таких задачках. Швидше за все, досвідчений розробник почне переконувати, що він готовий «вирішувати реальні задачі, а не писати алгоритми», але насправді весь код, що ми пишемо, є алгоритмами, і в реальності мало того, що код просто працює, важливо ще, щоб він працював достатньо ефективно. У той же час сучасні AI-моделі вирішують подібні задачки з легкістю. І поки кандидат на інтерв’ю ще намагається розібратися з умовою, AI вже має готове рішення, та ще й покриє його юніт-тестами.

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

О, саме час згадати про імена. Здавалося б, наскільки очевидно, що в програмуванні дуже важливо давати гарні імена сутностям? Невдале ім’я може стати причиною неправильного розуміння поведінки коду і суттєво ускладнить його підтримку. Тим не менше, розробники часто страждають тим, щоб дати яке-небудь ім’я зараз (поки думка не пропала), розраховуючи, що колись знайдеться час, щоб перейменувати. Чи варто мені нагадувати очевидну істину, що немає нічого більш постійного, ніж тимчасове? В той же час AI не лінується давати влучні і гарні імена.

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

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

Та й загалом в розробці є багато рутинних речей, які людям не дуже вдається робити, бо вони однотипні і нецікаві. Наприклад, оптимізація форматування коду під певні вимоги, виправлення дрібних недоліків, оновлення стилів відповідно до прийнятих стандартів або адаптація під нові вимоги linting-інструментів. Людям такі задачі здаються нудними і часто відкладаються «на потім», у той час як AI виконує їх швидко, акуратно і без нарікань. Навіть коли справа доходить до написання складних конфігурацій або налаштувань, таких як CI/CD пайплайни чи Docker-файли, AI демонструє неабияку влучність.

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

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

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

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

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

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

А дебажити з AI, розбирати лог-файли та повідомлення про помилки? Чарує, наскільки легко йому подекуди це вдається.

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

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

Software Engineer 3.0: AI + людина в програмній інженерії

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

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

Етапи інтеграції AI в програмну інженерію

Але щоб зрозуміти стан речей, потрібно виділити етапи інтеграції AI:

1. Автодоповнення в IDE: підказки і автодоповнення коду — це щось на зразок GitHub Copilot зразка 2022 року, який просто дописував код по ходу написання, часто невпопад, з помилками і без розуміння контексту проєкту.
2. AI-генерація фрагментів коду і документів по запиту: на цьому етапі AI отримує можливість «спілкуватися» з розробником, виконувати команди, задачі з рефакторингу, написання тестів та документації, краще розуміти контекст і загалом бути значно зручнішим.
3. AI для всього проєкту: тут ми вже не обмежуємо AI лише частинами задач в проєкті, він може взагалі почати проєкт на основі заданого промпту і виконувати будь-які задачі з кодом, звертаючись до потрібних файлів і генеруючи нові.
4. Автономні AI агенти: ключова особливість цього етапу в тому, що ми від серії ітерацій «розробник-промпт-AI-результат» переходимо до моделювання в AI роботи повноцінної команди розробників, які мають задані ролі, цілі, і найголовніше, володіють значною автономністю, щоб ітеративно рухатися у виконанні проєкту. Проте людина в цьому процесі залишається задіяною, щоб «наглядати» за процесом, давати вказівки, контролювати, коригувати дії, приймати результат і тому подібне.
5. Повна автоматизація — AGI: на цьому етапі AI фактично виконує всю роботу, і роль людини хіба що в тому, аби сформулювати задачу і прийняти результат. Проте якщо врахувати, що під AGI мають на увазі штучний інтелект, що не лише відповідає, а і здатен перевершувати людину, то можливо, без людини тут можна обійтися взагалі — AI все зробить.

І якщо б мене попросили оцінити наше становище за шкалою від 1 до 5, то я назвав би десь між 3 і 4, причому ближче до четвірки, ніж до трійки. Як назвати цей етап? Мені подобається термін «AI-Augmented Software Development» аналогічно з «AR — Augmented Reality». Основний пойнт в тому, що AI вже не просто асистент, який робить якісь примітивні задачі за запитом розробника, а здатен робити значно більше, на рівних з розробниками-людьми. Ми вступаємо в епоху агентів. Є цікаві інструменти, що використовують цей підхід, але поки що це не основний формат взаємодії з AI. Хоча все рухається настільки швидко, що стан речей може змінитися за лічені тижні і місяці.

І якщо ви мені не вірите, що AI здатен більш-менш працювати автономно, то запрошую ознайомитися з рейтингом SWE Bench, де відбувається справжнє змагання AI-агентів у вирішенні прикладних задач з розробки, і найкращі з них вже здатні виконувати понад 50% (а для моделі OpenAI o3 заявлено 71.7%). І це число змушує серйозно сприймати те, наскільки далеко і незворотно просунувся цей процес. До речі, AI-розробника Devin можна вже зараз «найняти» за достатньо скромні для штатів гроші в $500 на місяць (що тим не менше для нас є цілком стартовою зарплатою джуна), додати його в Slack і грузити тасками.

Трохи про цікаві АІ-інструменти

Загалом цікавих AI-інструментів для розробників вже дуже багато, і крім згаданого Github Copilot, мені особисто дуже подобається IDE Cursor — і хоча формально до Copilot він дуже близький, всі нюанси в деталях, і в цьому питанні особисто для мене Cursor — фаворит. Проте є й інші цікаві варіанти, наприклад, привабливо виглядає Windsurf від Codeium, як і AI-доповнення для безлічі інших IDE.

Але є інструменти за межами звичайних IDE. Наприклад, Vercel розвиває v0.dev і це цілком собі «дорослий» інструмент для того, щоб нашвидкоруч зверстати візуальний компонент, що з мінімальними правками здатен перекочувати в React/Tailwind CSS проєкт. Популярний серед студентів сервіс Replit отримав Replit AI Agent — засновану на AI-агентах технологію, здатну провести весь шлях проєкту від задачі до деплою. Дуже схожий за концепцією є bolt.new від розробників StackBlitz. Хоча вони поки що не виглядають достатньо зрілими платформами для серйозних розробників, швидше спрощують життя тим, хто лише навчається. Але це «поки що».

Коли я говорив про рев’ю коду, то тут вельми цікаво виглядає Code Rabbit. До речі, безкоштовно доступний для відкритих проєктів на гітхабі. А якщо говорити про інтеграцію з останнім, то власникам Github Copilot відкриваються цікаві можливості прямо у вебінтерфейсі гітхабу.

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

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