Vinster:
- Förmåga att urskilja var AI ger verklig hastighet i mjukvaruutvecklingens livscykel och var beslutet och ansvaret ligger hos ingenjören
- Förmåga att tillämpa en treskiktad ingenjörsdisciplin som verifierar varje kod och design som produceras genom sammanställning, testning och granskning.
- Ta för vana att rensa sammanhang för att utnyttja AI utan att dela konfidentiell källkod, referenser och kunddata
När man tittar på en dataingenjörs dag är bilden liknande i de flesta team: att förstå en affärsförfrågan, designa, skriva kod, läsa någon annans kod, felsöka (processen att ta reda på varför ett program fungerar fel och fixa det), skriva tester, förbereda dokumentation, granska kod och delta i möten. Med andra ord, den tid som ägnas åt det verkliga "ingenjörsbedömningen", det vill säga om en lösning är korrekt, säker och hållbar, krossas under repetitivt arbete. Det är här artificiell intelligens (AI förkortat; programvara som fungerar på text och kod med en stor språkmodell) kommer in i bilden. AI fattar inte beslutet åt dig; Den förbereder dig för beslutet, producerar ett kodskelett, begränsar buggen och lägger ett fungerade utkast framför dig. Under hela denna modul kommer vi att positionera AI inte som en "automatisk programmerare" utan som en disciplinerad parprogrammeringspartner vars utdata kompileras, testas och granskas varje gång.
I denna första enhet klargör vi tre saker: I vilka skeden av mjukvaruutvecklingens livscykel (de stadier som en programvara går igenom från idé till produktion: analys, design, kodning, testning, driftsättning, underhåll) tillför AI verkligt värde; vilka beslut som strikt bör ligga hos ingenjören; och vad är verifierings- och konfidentialitetsdisciplinen du måste följa när du gör detta. Utan detta tak installerat på rätt sätt kan tekniker på efterföljande enheter bli farliga; Eftersom ett fel i programvaran når miljontals användare samtidigt och kan förvandlas till en säkerhetsrisk.
Koncept: Hallucination: AI:s övertygande tillverkning av en metod, bibliotek, API eller beteende som faktiskt inte existerar. Kontext: Indata du ger till AI:n (kod, felmeddelande, krav, begränsningar). Verifiering: Kontrollera utdata på ett oberoende sätt (kompilering, testning, dokumentation). Dessa tre koncept är ryggraden i hela modulen.
I vilka företag är AI Accelerator, i vilka företag är det riskabelt?
Mjukvarujobb faller på ett tvådelat spektrum när det gäller resultat. I ena änden finns reversibelt förberedande arbete med låg risk; At the other end, there are difficult-to-return tasks that enter the production environment and may cause data loss, security vulnerabilities or interruptions. Värdet på AI varierar beroende på var du står på detta spektrum.
affärstyp
AI-bidrag
Ingenjörens roll
Kodskelett / pannplatta
Snabb generering av repetitiv struktur
Logik och kantstatuskontroll
felsökning
Hypotes och möjliga orsakslista
Reproduktion och rotorsaksbekräftelse
skriva prov
Testutkast och scenarioskapande
Meningsfull påstående och räckviddskontroll
refaktorering
Refaktoreringsförslag
Upprätthålla beteende genom testning
Dokumentation
Första utkast och struktur
Korrekthetskontroll mot kod
Arkitektur/säkerhetsbeslut
Lista över alternativ och för- och nackdelar
Slutligt beslut och ansvar
Regeln är enkel: risken för en AI-utgång är lika med skadan den kommer att åsamkas om den utgången gör ett fel. Att felaktigt föreslå ett variabelnamn är ofarligt; Felaktig autentisering (kontroll av att användaren verkligen är den de utger sig för att vara) gör hela systemet sårbart. Så den första frågan att ställa innan du använder utdata är: "Vad händer om detta är fel och vem märker det och när?"
Varning: AI producerar flytande och säker kod. Flytande är ingen garanti för noggrannhet. En språkmodell kan på ett trovärdigt sätt producera ett funktionsnamn som faktiskt inte existerar, en felaktig parametersekvens eller till och med ett osäkert mönster. I mjukvara finns detta inte kvar på papper; Den kompilerar, körs och exploderar i produktionen.
Beslut som bör överlåtas till ingenjören
Vissa beslut bör aldrig vara helt automatiserade; bär tekniska, juridiska och etiska risker:
- Godkännande för produktion: Frisläppandet av en kod i produktion och ansvaret för detta.
- Säkerhet och arkitektur: Dyra beslut som autentisering, auktorisering, kryptering och datamodell.
- Licens och upphovsrätt: Användbarheten av den producerade koden i den kommersiella produkten och licensöverensstämmelse.
- Arbeta med konfidentiell data: Transaktioner med kunddata, källkodshemligheter och identitetsinformation.
Varning: Även om AI:n säger "den här koden är säker och redo för produktion", är det oacceptabelt att acceptera detta utan säkerhetstestning, kodgranskning och validering under verklig belastning. I säkerhetskritiskt arbete är AI-utdata aldrig en ersättning för godkännande från en kompetent ingenjör; Alla utdata som leder till ett beslut måste oberoende verifieras och godkännas av den auktoriserade ingenjören före implementering.
Verifieringsdisciplin: Trelagerskontroll
Tillämpa tre lager av kontroll för att använda AI-utdata som en senior granskare snarare än blint. Detta är den grundläggande reflexen vi kommer att upprepa under hela modulen.
- Kompilering och statisk kontroll: Kompilerar/körs koden verkligen? Finns det typfel, oanvända variabler, obefintliga API:er? Vad säger det statiska analysverktyget (verktyget som undersöker koden utan att köra den)?
- Oberoende reproduktion (testning): Kör koden med små, kända ingångar och se om du får förväntad utdata. Prova kantfall (noll, noll, negativ, enorm).
- Källverifiering: Varje API, biblioteksversion och språkfunktion som AI använder ska verifieras från officiell dokumentation.
Verifieringsprompt (gör det enklare att kontrollera utdata): "Lista ALLA externa bibliotek, metoder och språkfunktioner som du använder i din kod. För var och en, ange vilken version den är tillgänglig i och märk den "måste verifieras från dokumentationen". Skapa inte några API:er som du är osäker på; om du inte är säker, skriv tydligt "osäker". Ange också eventuella kantfall som du har till dig."
Kritisera din egen koduppmaning: "Titta kritiskt på koden du just skrev, som en senior ingenjör som anställde dig. Ge konkreta saker under dessa tre rubriker: (1) logik-/kantfallsfel, (2) säkerhetsrisker, (3) prestanda- eller läsbarhetsproblem. För varje artikel, skriv "varför är problemet" och "föreslagen åtgärd". Om det inte finns något problem, försök inte hitta ett problem. det."
Svag prompt / Stark prompt
SVAG:"Skriv en användarautentiseringsfunktion till mig."(Resultat: oklart vilket språk, vilken regel, vilket felbeteende; generisk kod, ofta osäker eller ur sitt sammanhang.)STARK:"Skriv en e-postvalideringsfunktion för Python 3.11. Inmatning: sträng. Utdata: Sant om giltigt, Falskt annars. Regler: Ingen grundläggande sträng i US-format krävs. bibliotek Ett 5-exempeltest under funktionstilläggsblocket: giltigt, tomt, inget '@', dubbelt '@', innehåller endast mellanslag."
Skillnaden ligger i sammanhanget. Kraftfull uppmaning; Det inkluderar språk, version, input-output-kontrakt, begränsningar och testförväntningar. Denna enda disciplin minskar avsevärt risken för hallucinationer och osäker kod.
Minifodral
Fall 1 — Konstruerad metod. En utvecklare hör från AI att det finns en metod som heter date.addBusinessDays(5) i ett datumbibliotek och det förklaras på ett säkert sätt. När han tittar på dokumentationen ser han att det inte finns någon sådan metod, det korrekta sättet är en manuell slinga. Hallucinationen fångas innan den går i produktion med en 10-minuters verifiering.
Fall 2 — Kanttillståndsförlust. AI producerar en "beräkna medelvärde"-funktion; Det fungerar när det testas med 1 000 rader med data. Men när listan är tom ger den division med nollfel. Eftersom ingenjören lade till det tomma inmatningstestet ser han och åtgärdar felet innan det går live. Ett test med enkel kantförhållande förhindrar ett produktionslarm kl. 03.00.
Fall 3 – Integritetsrisk. En expert håller på att klistra in en fil med en faktisk databasanslutningssträng och API-nyckel i ett offentligt verktyg. minns institutionens policy; Den ersätter hemligheterna med <REDACTED>, reducerar koden till ett representativt exempel och ber om det. Därmed får han hjälp på 5 minuter, men hans identitetsuppgifter kommer inte ut.
Principen för att arbeta med hemlig kod och identitetsinformation
Den mest känsliga delen av programvaran; källkodshemligheter, identitetsinformation (API-nyckel, lösenord, token) och kund-/personuppgifter. Grundprincip: städa upp innan du delar, fråga bara problemets kärna med ett representativt exempel om möjligt.
Anonymiserat promptmönster: "Det finns ett fel i följande funktion. Jag ersatte den faktiska affärslogiken och dolda konstanter med representativa värden (API-nyckel, tabellnamn, fältnamngeneric). Problem: Jag får fel Y i ingång X. Hitta bara det logiska felet i denna representativa kod och förklara den korrigerade versionen. [representativ kod]"
Tips: Om du är osäker, gör det här testet: "Skulle min organisation få problem om jag skrev detta offentligt i ett forum?" Även om svaret är oklart, rensa det först. Återställning är alltid billigare än att jaga läckan senare.
Vanliga misstag
- Använda utdata utan att kompilera/testa. "AI skrev" är inte en motivering; Varje bit kod verifieras genom att köra den.
- Att göra förfrågningar utan sammanhang. Om språk, version, input-output och begränsningar inte anges blir koden generisk och ofta osäker.
- Dela konfidentiell information utan att tänka. API-nyckeln, lösenordet och kunddata ska inte släppas utan att de rensas.
- Blandar ihop exakt språk med noggrannhet. Ju mer självsäker AI talar, desto mer försiktig bör du vara; Säker ton är inget bevis.
- Delegera beslutet till AI. Beslutet att sätta i produktion, säkerhet och arkitektur ligger kvar hos ingenjören; AI producerar bara material.
Sammanfattningsvis
AI påskyndar de repetitiva och tidskrävande delarna av mjukvaruarbetet: skelettkod, testutkast, felavsmalning, dokumentation. Beslutet och ansvaret ligger dock kvar hos ingenjören. Varje utdata måste passera tre lager av kontroll (kompilera/statisk, testning, källkod). Att skriva uppmaningar med sammanhang och rensa dold information är två nyckelvanor som vi kommer att upprepa i varje enhet i denna modul. När du använder AI med disciplin får du fart; when you use it without discipline, you carry errors and vulnerabilities into production.
Applikationsuppgift
Välj en liten kodningsuppgift från ditt eget arbete eller från ett tänkt projekt (t.ex. en valideringsfunktion). Skriv först en svag prompt och få utdata. Använd sedan det kraftfulla promptmönstret från den här enheten: lägg till språk/version, input-output-kontrakt, begränsningar och testa förväntan. Lägg de två utskrifterna sida vid sida och skriv skillnaden. Kompilera sedan den robusta utgången och testa den med minst tre kantfall (null, noll/negativ, oväntat format) och notera vad du hittar i vilket test.
checklista
- [ ] Jag lade till språk, version och input-output-kontrakt i prompten.
- [ ] Jag skrev "Skapa det inte, säg till om du inte är säker" och omfattningsbegränsningen.
- [ ] Jag kompilerade/körde koden, kollade efter statiska varningar.
- [ ] Jag testade med minst tre kantfodral.
- [ ] Jag verifierade API:erna som användes från den officiella dokumentationen.
- [ ] Jag raderade alla hemliga koder/uppgifter eller använde företagsverktyg.
- [ ] Jag bekräftade att beslutet att sätta i produktion och säkerhet ligger kvar hos människan.