Кодування з ШІ: Неймовірна швидкість та ціна розуміння

Швидкість розробки з ШІ

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

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

Проєкт: Система пошуку інформації

Проєкт автора полягав у створенні системи пошуку тексту в стилі RAG (Retrieval-Augmented Generation), подібної до NotebookLM, але з більш суворими вимогами. Система призначена для обробки приватної бібліотеки PDF та отримання дослівних відповідей з цього корпусу, без перефразування чи галюцинацій. Мета — отримати точний уривок, який відповідає на запитання, щоб його можна було знову знайти в оригінальному PDF.

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

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

Для реалізації використовувалися Python, Streamlit, SQLite+FTS5, FAISS та модель sentence-transformer, все це було упаковано в контейнер Docker без екзотичних хмарних залежностей.

Процес розробки: Співпраця з ШІ

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

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

Автор зазначив, що робота з ШІ-помічником була схожа на роль керівника проєкту: навіть його напівготові побажання були передбачені та реалізовані за лічені секунди у вигляді переважно робочого коду. Коли код не працював, він копіював трасування стека в чат, дозволяючи агенту самостійно налагоджувати. Якщо ШІ застрягав, автор перемикав моделі (наприклад, з GPT5 на Grok), і вони налагоджували одна одну. Цей проєкт зайняв не більше 25 годин і призвів до створення понад 5000 рядків коду, що є значним досягненням для відносно складного інструменту.

Технічний борг та прозріння

Через місяць автор повернувся до проєкту, щоб контейнеризувати додаток у Docker, що здавалося завданням на суботній ранок. Натомість це перетворилося на "кошмар вихідного дня", повний проблем з конфігурацією Docker, неправильним вирішенням шляхів у контейнері, кешами вбудовувань та індексами FAISS, які не були чітко відокремлені від коду. Тести, що проходили на локальній машині, не працювали належним чином у CI/CD.

Автор визнає, що деякі з цих проблем були його провиною, оскільки він припускав, що його конвеєр CI/CD (також згенерований ШІ) "подбає про це". Коли ШІ запропонував, здавалося б, просте виправлення, автор хотів зберегти контроль і лише попросив вказівки, не дозволяючи ШІ змінювати код. Саме тоді він усвідомив, наскільки багато він аутсорсив. Він не тільки не розумів причини помилки, але й не міг ідентифікувати файл чи уривок, де потрібно було внести зміни. Він "не мав уявлення, що відбувається". Це контрастувало з попереднім проєктом, де він пам'ятав деталі реалізації.

Незручна правда та нова роль розробника

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

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

Автор робить висновок, що "вайб-кодування" (vibe coding) є одночасно хорошим і поганим. Швидкість є неймовірною, а переваги — реальними, і розрив у продуктивності між тими, хто агресивно використовує ці інструменти, і тими, хто ні, буде лише збільшуватися. Однак це обмін "інтимності реалізації" на "архітектурний контроль". Розробник перетворюється з майстра на диригента, з будівельника на керівника проєкту, з того, хто знає кожен гвинтик у машині, на того, хто довіряє роботу, яка зібрала автомобіль.

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

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

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

Ключові факти

Автор створив повноцінну систему пошуку інформації за близько 25 годин за допомогою ШІ-інструментів.
Пізніше автор витратив два дні на виправлення помилки в цій системі і зрозумів, що не розуміє, як працює його власний код.
Автор опублікував репозиторій на GitHub, не написавши жодного рядка коду самостійно.
ШІ-інструменти, такі як GitHub Copilot, значно прискорюють розробку, створюючи "реальні переваги у продуктивності".
Проєкт був системою пошуку тексту в стилі NotebookLM для приватної бібліотеки PDF, що повертає дослівні відповіді.