Майбутнє побудови додатків AI залежить від безпеки типів

Код, згенерований штучним інтелектом, може компілюватися, але без суворої безпеки типів цей успіх дуже короткочасний. Безпека типів – це поруччя, яке зупиняє крихкий код від гниття в приховані помилки та збої під час виконання системи при її масштабуванні.

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

Проблема стимулювання

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

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

Два види помилок

Коли код, згенерований штучним інтелектом виконується, ви зазвичай бачите два види проблем безпеки типів:

1. Помилки часу компіляції

• Що відбувається: Компілятор виявляє несумісність між оголошеним типом і тим, що було передано.
• Як людина виправляє це: Вирішує, чи помилковий виклик (перетворити 42 на рядок) чи функціональний підпис помилковий (змінити його на прийняття типу число).
• Як штучний інтелект “виправляє” це: Зміна типу аргументу на будь-що. Проблема “вирішена”, але ви просто видалити поруччя, яке б зупинило майбутні помилки.

2. Помилки часу виконання

• Що відбувається: Компілятор вважає, що все гаразд (часто через послаблення типів), але справжнє значення під час виконання не відповідає припущенню.
• Як людина виправляє це: Відслідковує змінну до її джерела (наприклад, API або запиту до бази даних) і виправляє тип на межі, щоб дані надходили як правильний рядок.
• Як штучний інтелект “виправляє” це: Без контексту він гадає. Можливо, він обгортає все в String(…), або просто розширює тип знову. Аварія зникає в цьому місці, але логіка тепер розбита. Числа, призначені для математики, раптом стають рядками.

Цей цикл помилок часу виконання → “виправлення” штучним інтелектом → послаблення типізації швидко накопичується. Результатом є кодова база, яка компілюється і викидає менше помилок часу виконання, але не може бути довіреною. Уявіть систему планування лікарів, де зміни лікарів керуються додатком. Несумісність типів прослизає: int для годин обробляється як рядок. Штучний інтелект “виправляє” це, послаблюючи тип до будь-що. Код компілюється, і помилка зникає, але розрахунки змін лікарів тихо розбиваються, подвоюючи лікарів і залишаючи цілий флігель лікарні без охорони.

Базовий множник

Момент, коли ви підключаєтеся до бази даних, помилки множаться і їх причини стають важчими для відстеження. SQL типізований з причини. Кожна схема (INT, TEXT, UUID, BOOLEAN) кодує припущення про ваші дані.

Коли штучний інтелект спрощує все до рядок | будь-що, ви втрачаєте ці гарантії:

• Погані записи: вставляння “true” в булеве поле компілюється, але пошкоджує базу даних.
• Погані читання: запит повертає NULL, але штучний інтелект припускав рядок, що призводить до аварії під час виконання.
• Зламані відносини: якщо ключ відносини очікується як UUID, але штучний інтелект обробляє його як рядок і помилково надсилає сміттєві значення, з’єднання не аварійні, але вони не повертають жодних даних. Це приховує помилки, поки вони не з’являться пізніше як відсутні або несумісні результати..

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

Чому зрілі команди забезпечують сувору типізацію

Сувора типізація не про те, щоб сповільнити розробників. Це про те, щоб зробити масштабування можливим.

Типи:

• Кодують намір у код.
• Зробіть рефакторинг безпечним і передбачуваним.
• Піймають цілі класи помилок, перш ніж вони потраплять у виробництво.
• Покажіть майбутнім розробникам (і штучному інтелекту) точно, як використовувати функцію чи об’єкт.

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

Як змусити штучний інтелект до безпеки типів

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

Надайте правильний контекст

Дайте йому інтерфейси та типи, які він може використовувати. Покажіть приклади використання. Будьте переконані щодо правильного способу структурування коду.

Надайте суворі інструкції

Чітко повідомте штучному інтелекту не використовувати будь-що, ніколи не дозволяйте невідомо і щоб кожна метод, об’єкт і змінна мали тип. Очікуйте, що йому буде важко слідувати цим інструкціям (особливо на першому проході).

Застосуйте лінтинг

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

Ітеруйте з перевірками

Помилки часу компіляції, реєстрація часу виконання, клікові тести. Кожна ітерація змушує штучний інтелект затягувати типи і рухатися ближче до коду рівня виробництва.

Кращий спосіб побудови

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

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

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