Чи потрібен мені розробник, чи досить AI?

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

Нас запитали про це напряму, не гіпотетично, під час розмови про проєкт.

Ми дали чесну відповідь, не захисну.

Відповідь, так і ні. І корисна частина не в так чи ні. Вона в тому, де реально проходить межа.

Інструменти на кшталт Claude Code, Codex та інших AI-агентів для коду реально можуть писати хороший софт. Вони можуть читати кодову базу, планувати реалізацію, редагувати кілька файлів, ганяти тести, використовувати git, вивчати помилки і ітерувати, коли щось ламається.

Ми самі використовуємо ці інструменти. Вони надзвичайно продуктивні. І вони стануть набагато здатнішими.

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

Цікавіше питання в тому, що лишається цінним, коли саме виконання стає все дешевшим.

WHAT AI CHANGES

1. AI вже може дивовижно багато у виконанні

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

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

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

Але є важлива відмінність.

Написати рішення, не те саме, що визначити рішення.

HARDEST PART

2. Найскладніша частина ніколи не була в наборі коду

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

Специфікація, це не бізнес. Це чиясь інтерпретація того, що бізнесу потрібно в конкретний момент.

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

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

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

Вузьке місце зміщується вгору за течією.

GENERATION VS JUDGMENT

3. Генерація подешевшала. Судження ні.

Ми писали про це з іншого кута раніше: вартість AI ніколи не була в генерації. Вона була в верифікації.

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

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

Ми бачили цей розрив напряму, не гіпотетично, у Чотири AI погодились. Ми все ще нічого не перевірили.

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

AI WILL IMPROVE

4. AI стане кращим. Це не робить аргумент проти нього.

Саме тут, як нам здається, дискусії про AI і розробку софту часто стають надмірно захисними.

Моделі покращаться. Вони будуть пам'ятати більше. Вони будуть розуміти більші кодові бази. Вони будуть міркувати краще. Вони будуть використовувати більше інструментів. У них будуть кращі можливості тестування. У них буде кращий контекст проєкту. Вони будуть вчитись на попередніх взаємодіях.

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

Ми не вважаємо, що з цим варто сперечатись. Ми вважаємо, що це варто використовувати.

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

ARCHITECT ANALOGY

5. Великі архітектори не витрачають кар'єру на малювання кожної лінії

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

Це не робить його менш важливим. Це робить його роль іншою.

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

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

Софт рухається в точно тому самому напрямку.

SOFTWARE ARCHITECT

6. Коли код стає дешевим, архітектура стає важливішою

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

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

AI все більше може допомагати реалізовувати ці рішення. Але рішення все одно мають звідкись приходити. Це шар судження. І він може стати найціннішим шаром у всьому процесі розробки софту.

JUDGMENT LAYER

7. Комусь потрібно розуміти продукт, не лише промпт

Це та відмінність, що ми б провели між AI-інструментом для коду і інженерною командою.

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

Це не аргумент проти AI. Це причина використовувати AI всередині компетентної команди.

WHERE ENGINEERING MOVES

8. AI не прибирає інженерію. Він змінює, де інженерія відбувається.

Помилка в тому, щоб думати, що якщо AI може писати код, інженерія зникла. Це не так.

Частина інженерної роботи зміщується від реалізації в бік: discovery → архітектура → специфікація → оркестрація → верифікація → еволюція.

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

Бо коли реалізація коштує $100 замість $10,000, кількість речей, що можна побудувати, стає величезною. Складне питання стає: які з них реально варто побудувати?

MEMORY

9. Продукт, це більше, ніж його поточна кодова база

Є ще одна відмінність, що легко недооцінити.

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

Частину цього можна задокументувати. Багато з цього історично живе в людях.

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

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

ACCOUNTABILITY

10. Хто володіє результатом?

Є ще один шар, що технологія не може просто стерти. Відповідальність.

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

У AI-агента немає частки в бізнесі. У компетентної команди є.

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

SHOULD YOU USE AI

11. То чи варто використовувати AI? Однозначно.

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

Так. Використовуй його.

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

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

І все це може покращити фінальний продукт.

Правильна відповідь, це не захищати старий процес розробки. Це зробити процес кращим.

WRONG QUESTION

12. Неправильне питання: «Чи може AI побудувати мій сайт?»

Ймовірно може. Краще питання: чи може AI побудувати правильний сайт для мого бізнесу? І потім: хто вирішує, що означає «правильний»?

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

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

Саме тут команда стає цінною.

NEW TEAM

13. Найкращі команди не конкуруватимуть з AI. Вони працюватимуть над ним.

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

Це рівно той самий зсув, що ми розібрали з боку найму у Як отримати роботу у 2026: співбесіда змінилась. Те саме судження, що робить людину найманою зараз, це те, що робить команду вартою того, щоб її зберегти.

І вони будуть агресивно використовувати AI під цим шаром. Результат може реально бути кращим софтом, виробленим швидше, з меншими втратами зусиль. Це і є можливість.

Реальний розлом буде не AI проти людей. Він все більше буде між командами, що знають, як використовувати AI, і командами, що не знають. А під цим: командами, що знають, що вони будують, проти команд, що просто будують те, що їм сказали побудувати.

Перша група буде використовувати AI, щоб помножити своє судження. Друга буде використовувати AI, щоб помножити свій випуск. Це не одне й те саме.

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

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

PREMIUM CONNECTS

14. Що це означає для того, чим насправді є «преміальність»

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

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

Іронія AI в розробці софту в тому, що чим кращим AI стає у виконанні, тим менш цінним виконання стає як відмінність. Це вже відбувається.

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

Саме це відбулось в інших професійних дисциплінах. Архітектори не зникли, коли з'явився CAD. Дизайнери не зникли, коли з'явився Photoshop. Інженери не зникли, коли став потужним симуляційний софт. Інструменти змінили, на що професіонали витрачають час. Інженерія софту проходить через той самий перехід.

SO DO YOU NEED ONE

15. То чи потрібен тобі розробник?

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

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

Ця людина може писати код. Вона може керувати розробниками. Вона може працювати через AI-агентів. Вона може робити все три.

Робота змінюється. Відповідальність ні.

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

Команди, що розуміють цей перехід, не будуть конкурувати з AI. Вони будуть будувати кращі продукти завдяки йому.