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