Минулого місяця ШІ-асистент згенерував Python-скрипт для робочого проєкту. Результат працював без помилок. Дані виглядали надійно. Але ручна перевірка виявила прихований патерн N+1 запитів у викликах бази даних. Для невеликого набору даних код працював нормально. Але якщо масштабувати його до тисяч записів, застосунок спочатку зробить один запит для батьківських об'єктів, а потім тисячі наступних запитів для пов'язаних даних. Результатом стало б катастрофічне падіння продуктивності, яке не виявив би жоден юніт-тест.
Це реальність сучасної розробки програмного забезпечення. Інструменти ШІ тепер займаються кодуванням, налагодженням та архітектурними порадами зі швидкістю, з якою не може зрівнятися жодна людина. Ця швидкість справжня. Проте вона докорінно змінює суть вашої роботи. Вам більше не платять переважно за написання синтаксису. Вам платять за аудит, проектування архітектури та виявлення саме таких невидимих пасток.
Тиха небезпека «логічно правильного, але помилкового» коду
Код, згенерований ШІ, часто виглядає правильним, тому що він компілюється, запускається і повертає очікуване значення. На поверхні логіка здається цілісною. Але всередині вона може бути непомітно порушена.
Візьмемо регулярні вирази. ШІ може запропонувати вам патерн, який ідеально підходить для пошуку адрес електронної пошти або ідентифікаторів в англійській мові. Але запустіть цей самий вираз проти німецьких умлаутів, арабської писемності або граничних випадків нормалізації Unicode — і він мовчки зазнає невдачі. Код не є помилковим у тому сенсі, що він викликає виняток. Він просто ігнорує валідні реальні дані.
Запити до баз даних несуть подібний ризик. ШІ може написати запит PostgreSQL, який повертає правильні рядки під час тестування, але водночас переповнює ваші таблиці мертвими кортежами (dead tuples), ігнорує використання індексів або змушує виконувати послідовне сканування, що паралізує роботу продуктивного середовища. Те, що працює на демонстраційному наборі даних, і те, що працює під реальним навантаженням, — це дві різні речі. Машина не відчуває затримки. Вона не оплачує рахунки за хмарні послуги.
Від написання до верифікації
Суттєвий зсув полягає в переході від питання «як мені це написати?» до «як мені це перевірити?». Коли ШІ готує перший чернетку, ваше когнітивне навантаження має зміститися на наступні етапи. Ви повинні читати код так, як його читає аудитор з безпеки, а не так, як втомлений автор переглядає власну роботу.
Це вимагає іншого рівня дисципліни. Упередженість щодо автоматизації (automation bias) — це реальність. Коли інструмент видає впевнений, синтаксично бездоганний результат, людський мозок розслабляється. Ви припускаєте правильність, бо подача виглядає професійно. Спротив цьому імпульсу тепер є ключовою навичкою. Ви повинні вважати кожну пропозицію лише гіпотезою, доки не доведете протилежне.
Робота з машиною
Отримання корисного результату від ШІ-асистента для кодування — це не про швидше друкування. Це про скорочення дистанції між навчальними даними машини та вашою специфічною реальністю. Ви можете зменшити цю дистанцію за допомогою кількох конкретних практик.
Будьте точними у своїх промптах. Тут неоднозначність не створює поезію; вона створює баги. Промпт на кшталт «оптимізуй цю функцію» провокує на загальні поради. Замість цього напишіть: «рефактори цей цикл Python, щоб використовувати одне масове оновлення бази даних замість ітеративних збережень». Конкретика звужує простір варіантів.
Надавайте реальний контекст. ШІ не знає, що ви запускаєте Django 4.2 на PostgreSQL 15 всередині Kubernetes-кластера з суворим 30-секундним таймаутом запиту, якщо ви про це не скажете. Повідомте йому версії ваших залежностей, ваші внутрішні бібліотеки та ваші непідлягаючі обговоренню обмеження. Контекст — це не декорація, це огородження.
Підкріплюйте відповіді власними документами. Retrieval-Augmented Generation, або RAG, — це не просто модне слово для чат-ботів. Направте свого асистента на ваші фактичні специфікації API, ваші записи про архітектурні рішення та конвенції вашої кодової бази. Коли модель бере факти з вашої документації, а не вгадує їх на основі навчальних даних, розрив між загальною порадою та придатним для використання кодом різко скорочується.
Розбивайте складну роботу на окремі завдання. Патерни агентів працюють найкраще, коли кожен крок має вузьку сферу застосування. Не просіть про повний рефакторинг мікросервісу одним махом. Спочатку попросіть схему даних. Перевірте її. Потім попросіть скрипт міграції. Перевірте його. Тільки після цього переходьте до сервісного рівня.