Коли ШІ пише код: інженерні навички, які зростають в цінності

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

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

Очевидно, щось змінилося. Інструменти на кшталт Claude Code, Codex, Copilot, Cursor та подібні вийшли за межі функції автодоповнення. Вони читають цілі репозиторії, редагують кілька файлів, виконують команди, пишуть тести, виявляють проблеми та продовжують працювати над завданням до його завершення. Особливо Claude Code вже давно вийшов за межі функції „напиши мені функцію“ та діє більше як інженерний агент, який працює всередині репозиторію. Це змінює сутність роботи.

Код стає дешевшим

Не так давно розробник міг присвятити півдня на створення однієї функції. Тепер цю функцію можна описати агенту:

Add JWT authentication.
Create login and refresh-token APIs.
Add PostgreSQL persistence.
Write integration tests.
Run the test suite.
Fix failures.

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

Що варто зазначити, так це те, що розробник не зник з процесу. Розробник став особою, відповідальною за результат, і ця різниця має значення.

У чому полягає суть прикладу Anthropic

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

Розробники повинні зосередитися на одному наслідку: більше створеного коду не означає меншої кількості інженерної роботи. Це може означати більшу відповідальність. Припустимо, Claude створює 5 000 рядків коду. Тепер хтось мусить відповісти на запитання:

Is the architecture correct?

Is authentication secure?What happens under 10,000 requests?Can this transaction fail halfway?Will this leak memory?What happens when Redis is unavailable?What happens when the database is slow?Did the AI introduce a race condition?

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

Ще одна серйозна дискусія з цього приводу

Згідно з публічними повідомленнями, колишній дослідник компанії Anthropic Джейкоб Коксон оголосив про свою відставку у вересні 2026 року. Його попередження стосувалося не того, чи може Claude писати якісний JavaScript чи чи може ШІ створити API на базі Spring Boot. Воно стосувалося того, куди рухаються все більш потужні системи штучного інтелекту. Його пост у X, за повідомленнями, надійшов до понад 100 мільйонів людей, у якому він стверджував, що провідні лабораторії занадто швидко рухаються у напрямку автономних та потенційно небезпечних систем.

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

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

Найбільша помилка

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

@GetMapping("/users")
public List<User> getUsers() {
    return userRepository.findAll();
}

Штучний інтелект може написати це за дві секунди. Чи варто це розглядати як готовий продукт? Можливо. Але що, якщо таблиця містить 20 мільйонів рядків? Що, якщо немає сторінкування? Що, якщо кінцева точка є публічною, а тип User містить конфіденційні поля, або п’ять тисяч людей використовують його одночасно? Код є технічно коректним, але інженерне рішення все одно може бути жахливим. Ось у чому різниця.

Що вивчати замість цього

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

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

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

Write this.
Refactor this.
Explain this.
Test this.
Fix this.
Convert this.

Дедалі ціннішим розробником є той, хто може відповісти щось на кшталт цього:

Don't build it this way.
Here's why.
Here's the simpler architecture.
Here's the failure mode you missed.
Here's what we should measure in production.

Штучний інтелект не скасовує потребу в мисленні

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

Урок полягає не в тому, щоб припинити використовувати ШІ, а в тому, щоб уникати повного передавання завдань на нього. Коли Claude пише рішення, прочитайте його. Розберіть його. Змініть його. Запитайте, чому воно працює та де воно зазнає невдач. Спробуйте створити меншу версію вручну, а потім знову зверніться до ШІ. Це значно краще, ніж постійне повторення цього циклу:

Prompt → Copy → Commit → Next task

Новий інженер програмного забезпечення

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

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

Що робити розробнику сьогодні

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

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