здається, зараз є дві категорії людей:
- Ті, хто в це щиро вірить, захоплюється і навіть купує курси про «створення стартапу без коду».
- Ті, хто реально розуміють стан речей у розробці.
Я займаюся розробкою більше 10 років (хоч і з перервою, коли був сфокусований виключно на бізнесі), і хочу поділитися своїм баченням того, що відбувається сьогодні в індустрії — і яку роль у цьому відіграють AI-агенти.
Як я реально використовую ШІ
Я активно використовую ШІ в роботі.
І ось у яких випадках це справді дає сильний ефект:
- Швидкий старт або “масове генерування” Коли потрібно “нафігачити” багато коду, щоб хоча б щось побачити на екрані. Наприклад: великі UI-віджети, CRUD-модулі з бізнес-сутностями, сторінки з пагінацією, фільтрами, великим обсягом даних. У таких випадках 5–15 хвилин на формування грамотного промпта — і за кілька хвилин ти маєш робочу заготовку. Це ще не архітектура і точно не продакшн-рішення, але вже є з чим працювати.
- Генерація тестових даних Згенерувати 100–1000 записів для бази, імітацію чату, замовлень, користувачів — і одразу можна тестувати логіку навколо них. Це економить купу часу.
- Аналіз власного коду Перевірка, рефакторинг, пошук потенційних помилок, альтернативні підходи — дуже корисно.
- Приклади в новій технології Коли працюєш з новою бібліотекою або підходом, ШІ дозволяє швидко зрозуміти базову структуру, API, типові патерни.
Але після ШІ починається справжня робота І ось тут найважливіше.
Після того як ШІ щось згенерував — починається реальна робота розробника. І майже завжди це: аналіз того, що він зробив; перевірка логіки; перевірка безпеки; рефакторинг; виправлення дивних або небезпечних рішень. Іноді результат дуже влучний. Іноді — просто сміття. Іноді — виглядає правильно, але має приховані проблеми. Практично завжди це загадка. Є великий “соблазн” прийняти відповідь ШІ за істину. Але це небезпечно. Без розуміння архітектури, контексту та бізнес-логіки можна легко побудувати нестабільний або вразливий продукт.
ШІ — мастхев. Але думати потрібно більше.
ШІ сьогодні — це маст-хев для розробника. Але парадокс у тому, що з ним думати потрібно навіть більше, ніж без нього. Бо: потрібно правильно поставити задачу, сформулювати обмеження, врахувати архітектуру, перевірити результат, інтегрувати його в систему. Постановка задачі ШІ сама по собі вимагає знання архітектури, патернів і практик. Без цього він просто згенерує щось “схоже”.
Міф продукту без коду Теза про “повноцінний продукт без жодного рядка коду” — на сьогодні це міф.
Можна:
- швидко зібрати прототип,
- зробити MVP,
- згенерувати інтерфейс,
- автоматизувати частину процесів.
Але щоб створити:
- стабільний,
- безпечний,
- масштабований,
- бізнес-релевантний продукт —
потрібен інженер. ШІ може писати код.
Але хтось має:
- визначати архітектуру,
- формувати технічні вимоги,
- контролювати безпеку,
- планувати рефакторинг,
- приймати технічні рішення.
І цей “хтось” — програміст.
Чи зміниться все кардинально?
Є спокуса думати, що з кожним роком усе буде настільки краще, що програмісти стануть непотрібними. Технології справді ставатимуть кращими. Роль розробника — змінюватиметься. Інструменти — еволюціонуватимуть. Але концепція залишиться.
Щоб ШІ створив якісний продукт — йому потрібен той, хто:
- розуміє систему,
- формулює завдання,
- задає рамки,
- контролює якість.
Ми багато десятиліть тому долетіли до Місяця.
Здавалося, що далі прогрес піде ще швидше і масштабніше. Світ змінився, технології стали неймовірними — але фундаментальні принципи складних систем нікуди не зникли. Так само і з розробкою.