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

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

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

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

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

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

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

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

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

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

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

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

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

Множник бази даних

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

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

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

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

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

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

Типи:

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

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

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

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

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

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

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

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

Примусіть лінтингом

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

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

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

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

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

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

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