Прибуток:
- Здатність розрізняти, де штучний інтелект забезпечує реальну швидкість у життєвому циклі розробки програмного забезпечення, а де рішення та відповідальність залишається за інженером
- Здатність застосовувати трирівневу інженерну дисципліну, яка перевіряє кожен код і дизайн, створений шляхом компіляції, тестування та перегляду.
- Візьміть у звичку очищати контекст, щоб використовувати ШІ, не передаючи конфіденційний вихідний код, облікові дані та дані клієнтів
Коли ви дивитеся на день інженера-комп’ютерника, картина схожа в більшості команд: розуміння бізнес-запиту, проектування, написання коду, читання чужого коду, налагодження (процес з’ясування, чому програма працює неправильно, і виправлення її), написання тестів, підготовка документації, перегляд коду та відвідування нарад. Іншими словами, час, витрачений на справжнє «інженерне судження», тобто на те, чи є рішення правильним, безпечним і стійким, розчавлюється повторюваною роботою. Ось тут і вступає в гру штучний інтелект (скорочено ШІ; програмне забезпечення, яке працює з текстом і кодом за допомогою великої мовної моделі). ШІ не приймає рішення за вас; Він готує вас до прийняття рішення, створює скелет коду, звужує коло помилок і ставить перед вами відпрацьовану чернетку. У цьому модулі ми будемо позиціонувати ШІ не як «автоматичний програміст», а як дисциплінованого партнера з парного програмування, результати якого компілюються, перевіряються та переглядаються щоразу.
У цьому першому розділі ми пояснюємо три речі: на яких етапах життєвого циклу розробки програмного забезпечення (стадії, які програмне забезпечення проходить від ідеї до виробництва: аналіз, проектування, кодування, тестування, розгортання, обслуговування) ШІ додає реальну цінність; які рішення повинні суворо залишатися за інженером; і яких правил перевірки та конфіденційності ви повинні дотримуватися, роблячи це. Без правильно встановленого даху техніка на наступних блоках може стати небезпечною; Тому що помилка в програмному забезпеченні досягає мільйонів користувачів одночасно і може перетворитися на вразливість безпеки.
Поняття: Галюцинація: переконливе створення штучним інтелектом методу, бібліотеки, API або поведінки, яких насправді не існує. Контекст: дані, які ви надаєте ШІ (код, повідомлення про помилку, вимога, обмеження). Перевірка: перевірка результату незалежним способом (компіляція, тестування, документування). Ці три концепції є основою всього модуля.
У яких компаніях AI Accelerator використовується, а в яких ризиковано?
Роботи з програмним забезпеченням за своїми результатами мають двосторонній спектр. На одному кінці є оборотні підготовчі роботи з низьким рівнем ризику; З іншого боку, є завдання, які важко повернути, які потрапляють у виробниче середовище та можуть спричинити втрату даних, уразливості системи безпеки або збої. Значення AI змінюється залежно від того, де ви стоїте в цьому спектрі.
тип бізнесу
внесок ШІ
Роль інженера
Скелет коду / шаблон
Швидке генерування повторюваної структури
Логіка та контроль стану краю
налагодження
Список гіпотез і можливих причин
Відтворення та підтвердження першопричини
написання контрольних робіт
Створення тестового проекту та сценарію
Змістовне твердження та перевірка обсягу
рефакторинг
Пропозиція рефакторингу
Підтримання поведінки через тестування
Документація
Перший проект і структура
Перевірка правильності щодо коду
Архітектурне/безпекове рішення
Перелік варіантів, плюси і мінуси
Остаточне рішення і відповідальність
Правило просте: ризик виходу штучного інтелекту дорівнює збитку, який він зазнає, якщо цей результат буде помилковим. Неправильна пропозиція назви змінної нешкідлива; Неналежна автентифікація (перевірка того, що користувач дійсно є тим, за кого себе видає) робить всю систему вразливою. Отже, перше запитання, яке потрібно поставити перед використанням результату: «Що станеться, якщо це не так, і хто це помітить і коли?»
Застереження: ШІ створює плавний і впевнений код. Вільне мовлення не є гарантією точності. Мовна модель може створити ім’я функції, яке насправді не існує, неправильну послідовність параметрів або навіть небезпечний шаблон. У програмному забезпеченні це не залишається на папері; Він компілюється, запускається та розгортається у виробництві.
Рішення, які слід залишити інженеру
Деякі рішення ніколи не повинні бути повністю автоматизованими; несе технічні, юридичні та етичні ризики:
- Затвердження для виробництва: випуск коду у виробництво та відповідальність за це.
- Безпека та архітектура: дорогі рішення, такі як автентифікація, авторизація, шифрування та модель даних.
- Ліцензія та авторські права: можливість використання створеного коду в комерційному продукті та відповідність ліцензії.
- Робота з конфіденційними даними: операції з клієнтськими даними, секретами вихідного коду та ідентифікаційною інформацією.
Попередження: навіть якщо штучний інтелект каже, що «цей код безпечний і готовий до виробництва», прийняття цього без перевірки безпеки, перевірки коду та перевірки під реальним навантаженням є неприйнятним. У критично важливих для безпеки роботах результати штучного інтелекту ніколи не замінять схвалення від компетентного інженера; Будь-який результат, який веде до прийняття рішення, повинен бути незалежно перевірений і затверджений уповноваженим інженером перед впровадженням.
Перевірочна дисципліна: Трирівневий контроль
Застосуйте три рівні контролю, щоб використовувати вихід ШІ як старший рецензент, а не наосліп. Це основний рефлекс, який ми будемо повторювати протягом усього модуля.
- Компіляція та статична перевірка: чи дійсно код компілюється/запускається? Чи є помилки типу, невикористовувані змінні, неіснуючі API? Що говорить інструмент статичного аналізу (інструмент, який перевіряє код без його запуску)?
- Незалежне відтворення (тестування): запустіть код із невеликими відомими вхідними даними та подивіться, чи ви отримаєте очікуваний результат. Спробуйте крайові випадки (нульовий, нульовий, негативний, величезний).
- Перевірка джерела: кожен API, версія бібліотеки та функція мови, яку використовує ШІ, мають бути перевірені з офіційної документації.
Підказка перевірки (полегшує перевірку результату): «Перелічіть УСІ зовнішні бібліотеки, методи та мовні функції, які ви використовуєте у своєму коді. Для кожної з них вкажіть, у якій версії вона доступна, і позначте її «має бути перевірено з документації». Не вигадуйте API, у яких ви не впевнені; якщо ви не впевнені, чітко напишіть «не впевнений». Також перелічіть будь-які граничні випадки, які ви не розглянули, як окремий список».
Критикуйте свій власний код: «Погляньте критично на код, який ви щойно написали, як старший інженер, який найняв вас. Наведіть конкретні пункти під цими трьома заголовками: (1) логічні/граничні помилки, (2) ризики безпеки, (3) проблеми з продуктивністю або читабельністю. Для кожного пункту напишіть «чому проблема» та «пропоноване вирішення». Якщо проблеми немає, скажіть «Я не міг знайти проблему»; не намагайтеся щоб прикрасити його».
Слабка підказка / Сильна підказка
СЛАБКО: «Напишіть мені функцію автентифікації користувача». (Результат: незрозуміло, яка мова, яке правило, яка поведінка помилок; загальний код, часто небезпечний або поза контекстом.) СИЛЬНИЙ: «Напишіть функцію перевірки електронної пошти для Python 3.11. Вхід: рядок. Вихід: True, якщо дійсний, False в іншому випадку. Правила: порожній рядок False; відповідність RFC не потрібна, достатньо основного формату. НЕ ВИКОРИСТОВУЙТЕ зовнішній формат. бібліотека. Тест із 5 зразків під блоком додавання функції: дійсний, порожній, без «@», подвійний «@», містить лише пробіли."
Різниця в контексті. Потужна підказка; Він включає мову, версію, контракт введення-виведення, обмеження та очікування тесту. Ця єдина дисципліна значно знижує ризик галюцинацій і небезпечного коду.
Міні-чохли
Випадок 1 — Надуманий метод. Розробник чує від штучного інтелекту, що в бібліотеці дат існує метод під назвою date.addBusinessDays(5), і він пояснюється в впевненій формі. Дивлячись на документацію, він бачить, що такого методу немає, правильний спосіб - ручний цикл. Галюцинація фіксується перед тим, як вона йде у виробництво з 10-хвилинною перевіркою.
Випадок 2 — Втрата крайового стану. ШІ створює функцію «обчислити середнє»; Він працює при тестуванні з 1000 рядками даних. Однак, коли список порожній, він дає помилку ділення на нуль. Оскільки інженер додав порожній вхідний тест, він бачить і виправляє помилку, перш ніж вона буде опублікована. Перевірка стану одного краю запобігає сигналу тривоги о 3:00.
Випадок 3 — ризик конфіденційності. Експерт збирається вставити файл із фактичним рядком підключення до бази даних і ключем API у загальнодоступний інструмент. Пам'ятає політику установи; Він замінює секрети на <REDACTED>, скорочує код до типового прикладу та запитує його. Таким чином, він отримує допомогу за 5 хвилин, але його особисті дані не виходять.
Принцип роботи з секретним кодом та ідентифікаційною інформацією
Найбільш чутлива частина програмного забезпечення; секрети вихідного коду, ідентифікаційна інформація (ключ API, пароль, маркер) і клієнтські/особисті дані. Основний принцип: очистіть перед тим, як ділитися, запитуйте лише суть проблеми з репрезентативним прикладом, якщо це можливо.
Анонімний шаблон підказки: «У наступній функції сталася помилка. Я замінив фактичну бізнес-логіку та приховані константи репрезентативними значеннями (ключ API, імена таблиць, імена полів generic). Проблема: я отримую помилку Y у вхідних даних X. Просто знайдіть логічну помилку в цьому репрезентативному коді та поясніть виправлену версію. [репрезентативний код]»
Порада. Якщо сумніваєтеся, пройдіть цей тест: «Чи матиме моя організація проблеми, якщо я напишу це публічно на форумі?» Навіть якщо відповідь незрозуміла, спочатку поясніть її. Скидання завжди дешевше, ніж пошук витоку пізніше.
Поширені помилки
- Використання результату без компіляції/тестування. «ШІ написав» не є виправданням; Кожен фрагмент коду перевіряється шляхом його запуску.
- Створення запитів без контексту. Якщо мова, версія, введення-виведення та обмеження не задані, код стає загальним і часто небезпечним.
- Обмін конфіденційною інформацією без роздумів. Ключ API, пароль і дані клієнта не повинні розкриватися без очищення.
- Плутання точної мови з точністю. Чим впевненіше ШІ говорить, тим обережніше вам слід бути; Впевнений тон – це не доказ.
- Делегування рішення АІ. Рішення про запуск виробництва, безпеки та архітектури залишається за інженером; ШІ створює лише матеріали.
Підсумовуючи
AI прискорює повторювані та трудомісткі частини роботи з програмним забезпеченням: базовий код, складання тестів, звуження помилок, документація. Однак рішення та відповідальність залишається за інженером. Кожен вихід має пройти три рівні контролю (компіляція/статичний, тестування, джерело). Написання підказок із контекстом і очищення прихованої інформації — дві ключові звички, які ми будемо повторювати в кожному розділі цього модуля. Якщо ви дисципліновано використовуєте ШІ, ви отримуєте швидкість; коли ви використовуєте його без дисципліни, ви переносите помилки та вразливі місця у виробництво.
Аплікаційне завдання
Виберіть невелике завдання кодування з вашої роботи або з уявного проекту (наприклад, функція перевірки). Спочатку напишіть слабку підказку та отримайте результат. Потім застосуйте потужний шаблон підказок із цього блоку: додайте мову/версію, договір вводу-виводу, обмеження та тестове очікування. Покладіть два роздруківки поруч і напишіть різницю. Потім скомпілюйте надійний вихід і протестуйте його принаймні з трьома граничними випадками (нульовий, нульовий/негативний, неочікуваний формат) і запам’ятайте, що ви знайдете в якому тесті.
контрольний список
- [ ] Я додав мову, версію та договір введення-виведення до підказки.
- [ ] Я написав «Не вигадуй, скажи мені, якщо ти не впевнений» і обмеження обсягу.
- [ ] Я скомпільував/запустив код, перевірив наявність статичних попереджень.
- [ ] Я тестував принаймні три крайні випадки.
- [ ] Я перевірив API, які використовуються в офіційній документації.
- [ ] Я скинув усі секретні коди/облікові дані або використав корпоративний інструмент.
- [ ] Я підтвердив, що рішення про запуск виробництва та забезпечення безпеки залишається за людиною.