Добици:
- Способност да се разликује где АИ пружа стварну брзину у животном циклусу развоја софтвера и где одлука и одговорност остају на инжењеру
- Способност примене трослојне инжењерске дисциплине која верификује сваки код и дизајн произведен компилацијом, тестирањем и прегледом.
- Стекните навику чишћења контекста да бисте искористили АИ без дељења поверљивог изворног кода, акредитива и података о клијентима
Када погледате дан рачунарског инжењера, слика је слична у већини тимова: разумевање пословног захтева, пројектовање, писање кода, читање туђег кода, отклањање грешака (процес откривања зашто програм ради погрешно и поправљање), писање тестова, припрема документације, прегледање кода и присуствовање састанцима. Другим речима, време посвећено стварном „инжењерском просуђивању“, односно да ли је решење исправно, безбедно и одрживо, угушено је под понављајућим радом. Овде долази у обзир вештачка интелигенција (скраћено АИ; софтвер који ради на тексту и коду са великим језичким моделом). АИ не доноси одлуку уместо вас; Припрема вас за одлуку, производи скелет кода, сужава грешку и ставља пред вас урађени нацрт. Током овог модула позиционираћемо АИ не као „аутоматског програмера“, већ као дисциплинованог партнера за програмирање у пару чији се излаз сваки пут компајлира, тестира и прегледа.
У овој првој јединици појашњавамо три ствари: У којим фазама животног циклуса развоја софтвера (фазе кроз које софтвер пролази од идеје до производње: анализа, дизајн, кодирање, тестирање, примена, одржавање) АИ додаје стварну вредност; које одлуке треба стриктно да остану на инжењеру; и која је дисциплина верификације и поверљивости којих се морате придржавати када то радите. Без правилног постављања овог крова, технике на следећим јединицама могу постати опасне; Зато што грешка у софтверу истовремено допире до милиона корисника и може се претворити у безбедносни пропуст.
Концепти: Халуцинације: АИ убедљива измишљотина метода, библиотеке, АПИ-ја или понашања које заправо не постоји. Контекст: Унос који дајете АИ (код, порука о грешци, захтев, ограничења). Верификација: Провера излаза на независан начин (компилација, тестирање, документација). Ова три концепта су окосница читавог модула.
У којим предузећима је АИ акцелератор, у којим је ризичан?
Софтверски послови спадају у двосмерни спектар у смислу исхода. На једном крају су реверзибилни, нискоризични припремни радови; Са друге стране, постоје задаци који се тешко враћају и који улазе у производно окружење и могу изазвати губитак података, безбедносне пропусте или прекиде. Вредност АИ варира у зависности од тога где се налазите у овом спектру.
пословни тип
АИ допринос
Инжењерска улога
Шифра скелет / шаблон
Брзо генерисање репетитивне структуре
Логика и контрола статуса ивице
отклањање грешака
Хипотеза и листа могућих узрока
Репродукција и потврда основног узрока
писање тестова
Пробни нацрт и креирање сценарија
Смислена тврдња и провера обима
рефакторинг
Предлог за рефакторисање
Одржавање понашања кроз тестирање
Документација
Први нацрт и структура
Проверите исправност кода
Архитектонска/безбедносна одлука
Листа опција и предности и мане
Коначна одлука и одговорност
Правило је једноставно: ризик од АИ излаза једнак је штети коју ће претрпјети ако тај излаз направи грешку. Нетачно предлагање имена променљиве је безопасно; Неправилна аутентификација (провера да ли је корисник заиста онај за кога се представља) чини цео систем рањивим. Дакле, прво питање које треба поставити пре употребе излаза је: "Шта се дешава ако ово није у реду и ко то примети и када?"
Опрез: АИ производи течан и сигуран код. Течност није гаранција тачности. Језички модел може веродостојно да произведе име функције које заправо не постоји, нетачан низ параметара или чак небезбедни образац. У софтверу, ово не остаје на папиру; Саставља, покреће и експлодира у производњи.
Одлуке које треба препустити инжењеру
Неке одлуке никада не би требало да буду потпуно аутоматизоване; носи техничке, правне и етичке ризике:
- Одобрење за производњу: Пуштање кода у производњу и одговорност за то.
- Безбедност и архитектура: Скупе одлуке као што су аутентификација, ауторизација, шифровање и модел података.
- Лиценца и ауторска права: Употребљивост произведеног кода у комерцијалном производу и усклађеност лиценце.
- Рад са поверљивим подацима: Трансакције са подацима о клијентима, тајнама изворног кода и информацијама о идентитету.
Упозорење: Чак и ако АИ каже „овај код је сигуран и спреман за производњу“, прихватање овога без безбедносног тестирања, прегледа кода и валидације под реалним оптерећењем је неприхватљиво. У раду који је критичан за безбедност, АИ излаз никада није замена за одобрење од компетентног инжењера; Сваки резултат који води до одлуке мора бити независно верификован и одобрен од стране овлашћеног инжењера пре имплементације.
Дисциплина верификације: Трослојна контрола
Примените три нивоа контроле да бисте користили АИ излаз као старији рецензент, а не слепо. Ово је основни рефлекс који ћемо понављати током модула.
- Компилација и статичка провера: Да ли код заправо компајлира/покреће? Да ли постоје грешке у типу, некоришћене варијабле, непостојећи АПИ-ји? Шта каже алатка за статичку анализу (алатка која испитује код без покретања)?
- Независна репродукција (тестирање): Покрените код са малим, познатим улазима и видите да ли ћете добити очекивани излаз. Пробајте случајеве на ивици (нула, нула, негативна, велика).
- Верификација извора: Сваки АПИ, верзија библиотеке и језичка функција које АИ користи треба да буду верификовани из званичне документације.
Промпт за верификацију (олакшава проверу излаза): „Наведите СВЕ спољне библиотеке, методе и језичке функције које користите у свом коду. За сваку од њих наведите у којој је верзији доступна и означите је 'мора да буде верификовано из документације'. Немојте измишљати АПИ-је за које нисте сигурни; ако нисте сигурни, јасно напишите 'нисам сигуран', јасно напишите 'нисам сигуран' као посебну листу адреса.
Критикујте свој сопствени кодни упит: „Погледајте критички код који сте управо написали, као старији инжењер који вас је унајмио. Наведите конкретне ставке под ова три наслова: (1) грешке у логици/граничним случајевима, (2) безбедносни ризици, (3) проблеми са перформансама или читљивошћу. За сваку ставку напишите 'зашто је проблем' и 'предложени проблем не могу да решим', реците да не постоји проблем'. да га улепша“.
Слаба порука / јака промпт
СЛАБО:"Напишите ми функцију аутентификације корисника."(Резултат: нејасно који језик, које правило, које понашање грешке; генерички код, често несигуран или ван контекста.)СТРОНГ:"Напишите функцију валидације е-поште за Питхон 3.11. Улаз: стринг. Излаз: Тачно ако је валидно, Фалсе у супротном. Правила: нема потребе за основним низом НФЦ је довољан екстерни формат. Библиотека Тест са 5 узорака испод блока додавања функције: валидан, празан, без '@', двоструки '@', који садржи само размаке.
Разлика је у контексту. Снажан промпт; Укључује језик, верзију, улазно-излазни уговор, ограничења и очекивања од теста. Ова јединствена дисциплина у великој мери смањује ризик од халуцинација и несигурног кода.
Мини Цасес
Случај 1 — Измишљена метода. Програмер чује од вештачке интелигенције да постоји метод под називом дате.аддБусинессДаис(5) у библиотеци датума и то је објашњено на поуздан начин. Гледајући документацију, види да не постоји такав метод, исправан начин је ручна петља. Халуцинација се снима пре него што крене у производњу са 10-минутном верификацијом.
Случај 2 — Губитак ивичног стања. АИ производи функцију „израчунај просек“; Ради када се тестира са 1.000 редова података. Међутим, када је листа празна, даје грешку дељења нулом. Пошто је инжењер додао празан улазни тест, он види и исправља грешку пре него што се објави. Тест стања једне ивице спречава производни аларм у 3 ујутро.
Случај 3 — Ризик приватности. Стручњак се спрема да налепи датотеку са стварним низом везе са базом података и АПИ кључем у јавни алат. Сећа се политике институције; Он замењује тајне са <РЕДАЦТЕД>, своди код на репрезентативан пример и тражи га. Тако добија помоћ за 5 минута, али подаци о његовом идентитету не излазе.
Принцип рада са тајним кодом и информацијама о идентитету
Најосетљивији део софтвера; тајне изворног кода, информације о идентитету (АПИ кључ, лозинка, токен) и клијентски/лични подаци. Основни принцип: очистите пре дељења, питајте само суштину проблема са репрезентативним примером ако је могуће.
Анонимизовани образац упита: "Постоји грешка у следећој функцији. Заменио сам стварну пословну логику и скривене константе репрезентативним вредностима (АПИ кључ, називи табела, имена поља генерички). Проблем: Добијем грешку И у уносу Кс. Само пронађите логичку грешку у овом репрезентативном коду и објасните исправљену верзију. [репрезентативни код]"
Савет: Ако сте у недоумици, урадите овај тест: „Да ли би моја организација упала у невоље ако бих ово јавно написао на форуму?“ Чак и ако је одговор нејасан, прво га очистите. Ресетовање је увек јефтиније од каснијег тражења цурења.
Уобичајене грешке
- Коришћење излаза без компајлирања/тестирања. „АИ је написао“ није оправдање; Сваки део кода се проверава његовим покретањем.
- Изношење захтева без контекста. Ако језик, верзија, улаз-излаз и ограничења нису дати, код постаје генерички и често несигуран.
- Дељење поверљивих информација без размишљања. АПИ кључ, лозинка и подаци о клијентима не би требало да буду објављени без брисања.
- Бркање прецизног језика са тачношћу. Што АИ више самопоуздања говори, то треба да будете пажљивији; Самоуверен тон није доказ.
- Делегирање одлуке на АИ. Одлука о стављању у производњу, безбедност и архитектуру остаје на инжењеру; АИ производи само материјале.
Укратко
АИ убрзава делове софтверског рада који се понављају и одузимају много времена: скелетни код, израду тестова, сужавање грешака, документацију. Међутим, одлука и одговорност остаје на инжењеру. Сваки излаз мора проћи три нивоа контроле (компајлирање/статичко, тестирање, извор). Писање упутстава са контекстом и брисање скривених информација су две кључне навике које ћемо поновити у свакој јединици овог модула. Када користите АИ са дисциплином, добијате брзину; када га користите без дисциплине, преносите грешке и рањивости у производњу.
Задатак апликације
Изаберите мали задатак кодирања из сопственог рада или из замишљеног пројекта (нпр. функција валидације). Прво напишите слаб промпт и добијте излаз. Затим примените моћни образац одзива из ове јединице: додајте језик/верзију, улазно-излазни уговор, ограничења и очекивање теста. Ставите два отиска један поред другог и напишите разлику. Затим компајлирајте робустан излаз и тестирајте га са најмање три рубна случаја (нулл, нула/негативан, неочекивани формат) и забележите шта сте пронашли у ком тесту.
контролна листа
- [ ] Додао сам језик, верзију и инпут-оутпут уговор у промпт.
- [ ] Написао сам „Не измишљај, реци ми ако ниси сигуран“ и ограничење опсега.
- [ ] Превео/покренуо сам код, проверио да ли постоје статичка упозорења.
- [ ] Тестирао сам са најмање три рубна случаја.
- [ ] Проверио сам коришћене АПИ-је из званичне документације.
- [ ] Обрисао сам сваки тајни код/акредитиве или коришћени алат за предузећа.
- [ ] Потврдио сам да одлука о пуштању у производњу и безбедност остаје на човеку.