Trumpas atsakymas: dirbtinio intelekto pagalba sukurtas kodas dažnai skaitomas neįprastai tvarkingai ir „vadovėliškai“: nuoseklus formatavimas, bendriniai pavadinimai, mandagūs klaidų pranešimai ir komentarai, kurie pakartoja akivaizdžius dalykus. Jei jame trūksta realaus pasaulio kruopštumo – domeno kalbos, nepatogių apribojimų, kraštutinių atvejų – tai įspėjamasis ženklas. Kai jį įtvirtinate savo saugyklų šablonuose ir išbandote, ar nėra gamybinės rizikos, jis tampa patikimas.
Svarbiausios išvados:
Konteksto patikrinimas : jei neatsispindi srities terminai, duomenų formos ir apribojimai, traktuokite tai kaip rizikingą.
Pernelyg didelis šlifavimas : per daug dokumentacijos eilučių, vienoda struktūra ir nuobodūs pavadinimai gali rodyti bendrinių terminų generavimą.
Klaidų drausmė : stebėkite plačius išimčių aptikimus, prarytas klaidas ir neaiškų registravimą.
Abstrakcijos apipjaustymas : šalinkite spekuliatyvius pagalbininkus ir sluoksnius, kol liks tik mažiausia teisinga versija.
Realybės testai : pridėkite integracijos ir kraštinių atvejų testus; jie greitai atskleidžia „švaraus pasaulio“ prielaidas.
Dirbtinio intelekto pagalba programavimas dabar yra visur ( „Stack Overflow“ kūrėjų apklausa, 2025 m .; „GitHub Octoverse“ (2025 m. spalio 28 d.) ). Kartais jis puikus ir sutaupo jums popietę. Kitais atvejais jis... įtartinai išbaigtas, šiek tiek bendro pobūdžio arba „veikia“, kol kas nors paspaudžia vieną mygtuką, kurio niekas nebandė 🙃. Tai veda prie klausimo, kurį žmonės nuolat kelia kodo apžvalgose, interviu ir privačiose asmeninėse žinutėse:
Kaip paprastai atrodo dirbtinio intelekto kodas
Tiesioginis atsakymas: tai gali atrodyti bet kaip. Tačiau yra tam tikrų dėsningumų – švelnių signalų, o ne teismo įrodymų. Įsivaizduokite tai kaip spėjimą, ar pyragas buvo iš kepyklos, ar iš kažkieno virtuvės. Glajus gali būti per daug tobulas, bet kai kurie namų kepėjai taip pat yra tiesiog siaubingai geri. Ta pati atmosfera.
Žemiau pateikiamas praktinis vadovas, kaip atpažinti dažniausiai pasitaikančius dirbtinio intelekto pirštų atspaudus, suprasti, kodėl jie atsiranda, ir, svarbiausia, kaip dirbtinio intelekto sugeneruotą kodą paversti kodu, kuriuo pasitikėtumėte gamybinėje aplinkoje ✅.
🔗 Kaip dirbtinis intelektas prognozuoja tendencijas?
Paaiškina mokymosi pagal šablonus, signalus ir prognozavimą realiomis sąlygomis.
🔗 Kaip dirbtinis intelektas aptinka anomalijas?
Apima išskirtinių verčių aptikimo metodus ir įprastas verslo programas.
🔗 Kiek vandens sunaudoja dirbtinis intelektas?
Išskaido duomenų centro vandens naudojimą ir mokymų poveikį.
🔗 Kas yra dirbtinio intelekto šališkumas?
Apibrėžia šališkumo šaltinius, žalą ir praktinius būdus jai sumažinti.
1) Pirma, ką žmonės turi omenyje sakydami „DI kodas“ 🤔
Kai dauguma žmonių sako „DI kodas“, jie paprastai turi omenyje vieną iš šių:
-
iš raginimo sukurtas kodas
-
Kodas buvo stipriai užpildytas automatinio užbaigimo funkcija , kai kūrėjas stumtelėjo, bet iki galo nerašė kodo.
-
Dirbtinio intelekto perrašytas kodas , skirtas „išvalymui“, „našumui“ arba „stiliui“.
-
Kodas, kuris atrodo lyg būtų gautas iš dirbtinio intelekto, net jei taip nėra (taip nutinka dažniau, nei žmonės pripažįsta).
Ir štai esminis dalykas: dirbtinis intelektas neturi vieno stiliaus . Jis turi tendencijų . Daugelis šių tendencijų kyla iš bandymo būti iš esmės teisingam, plačiai skaitomam ir plačiai saugiam... dėl ko ironiška, bet rezultatas gali atrodyti šiek tiek vienodas.
2) Kaip paprastai atrodo dirbtinio intelekto kodas: trumpa vaizdinė medžiaga atskleidžia 👀
Atsakykime į antraštę aiškiai: kaip paprastai atrodo dirbtinio intelekto kodas.
Dažnai tai atrodo kaip kodas, kuris yra toks:
-
Labai „tvarkinga kaip vadovėlis“ – nuosekli įtrauka, nuoseklus formatavimas, viskas nuoseklu.
-
Neutraliai parašyta daug „naudingų“ komentarų, kurie nelabai padeda.
-
Pernelyg apibendrintas – sukurtas taip, kad apdorotų dešimt įsivaizduojamų scenarijų, o ne du tikrus.
-
Šiek tiek per daug struktūrizuota – papildomos pagalbinės funkcijos, papildomi sluoksniai, papildoma abstrakcija... tarsi pakavimas savaitgalio kelionei su trim lagaminais 🧳.
-
Trūksta nepatogių kraštutinių klijų, kuriuos kaupia tikros sistemos (funkcijų žymės, senos keistenybės, nepatogūs apribojimai) ( Martin Fowler: Funkcijų perjungimas ).
Bet taip pat – ir aš tai kartosiu, nes tai svarbu – žmonių kūrėjai taip pat gali rašyti. Kai kurios komandos tai užtikrina. Kai kurie žmonės tiesiog yra tvarkingi keistuoliai. Sakau tai su meile 😅.
Taigi, užuot „aptikus dirbtinį intelektą“, geriau paklausti: ar šis kodas elgiasi taip, lyg būtų parašytas realiame kontekste? Būtent kontekstas yra ta vieta, kur dirbtinis intelektas dažnai praslysta.
3) „Keistas slėnis“ – kai per daug tvarkinga 😬
Dirbtinio intelekto generuojamas kodas dažnai turi tam tikrą „blizgesį“. Ne visada, bet dažnai.
Dažni „pernelyg tvarkingi“ signalai
-
Kiekviena funkcija turi dokumentacijos eilutę, net jei ji akivaizdi.
-
Visi kintamieji turi mandagius pavadinimus, tokius kaip
„result“,„data“,„items“,„payload“,„responseData“. -
Nuolatiniai klaidų pranešimai , skambantys kaip vadovas: „Apdorojant užklausą įvyko klaida“.
-
Vienodi modeliai nesusijusiuose moduliuose , tarsi viską būtų parašęs tas pats kruopštus bibliotekininkas.
Subtilus išdavystė
Dirbtinio intelekto kodas gali atrodyti lyg būtų sukurtas pamokai, o ne produktui. Tai tarsi… tvoros dažymas apsirengus kostiumu. Labai tinkama, šiek tiek netinkama veikla prie aprangos.
4) Kas daro dirbtinio intelekto kodą gerą? ✅
Apverskime tai. Nes tikslas nėra „pagauti dirbtinį intelektą“, o „siųsti kokybiškai“
Gera dirbtinio intelekto padedamo kodo versija
-
Pririštas prie jūsų tikrosios srities (jūsų pavadinimai, duomenų formos, apribojimai).
-
Suderinta su jūsų architektūra (šablonai atitinka saugyklą, o ne bendrą šabloną).
-
Testuota atsižvelgiant į jūsų riziką (ne tik į laimingo kelio vienetų testus) ( „Software Engineering at Google“: Unit Testing ; The Practical Test Pyramid “).
-
Peržiūrėta apgalvotai (kažkas paklausė „kodėl taip?“, o ne tik „ar kompiliuojasi“) ( „Google Engineering Practices: The Standard of Code Review “).
-
Sutrumpinta iki to, ko jums reikia (mažiau įsivaizduojamo ateities užtikrinimo).
Kitaip tariant, puikus dirbtinio intelekto kodas atrodo taip, lyg… jį parašė jūsų komanda. Arba bent jau jūsų komanda jį tinkamai pritaikė. Kaip išgelbėtas šuo, kuris dabar žino, kur yra sofa 🐶.
5) Šablonų biblioteka: klasikiniai dirbtinio intelekto pirštų atspaudai (ir kodėl jie atsiranda) 🧩
Štai modeliai, kuriuos ne kartą mačiau dirbtinio intelekto padedamose kodų bazėse, įskaitant tuos, kuriuos asmeniškai išvaliau. Kai kurie iš jų yra geri. Kai kurie yra pavojingi. Dauguma tėra... signalai.
A) Pernelyg didelis gynybinis nulinis patikrinimas visur
Pamatysite sluoksnius:
-
jei x nėra: grąžinti... -
try/except išimtis -
keli atsarginiai numatytieji nustatymai
Kodėl: Dirbtinis intelektas stengiasi išvengti vykdymo klaidų.
Rizika: Jis gali paslėpti tikrus gedimus ir apsunkinti derinimą.
B) Bendrosios pagalbinės funkcijos, kurios neužsitarnauja savo egzistavimo
Patinka:
-
proceso_duomenys() -
handle_request() -
validate_input()
Kodėl: abstrakcija atrodo „profesionaliai“.
Rizika: gausite funkcijas, kurios atlieka viską, bet nieko nepaaiškina.
C) Komentarai, kurie pakartoja kodą
Energijos pavyzdys:
-
„Padidinti i vienetu“
-
„Grąžinti atsakymą“
Kodėl: Dirbtinis intelektas buvo apmokytas aiškinti.
Rizika: komentarai greitai genda ir sukelia triukšmą.
D) Nenuoseklus detalių gylis
Viena dalis yra labai detali, kita dalis – paslaptingai miglota.
Kodėl: greitas dėmesio nukrypimas... arba dalinis kontekstas.
Rizika: silpnosios vietos slypi neaiškiose zonose.
E) Įtartinai simetriška struktūra
Viskas vadovaujasi tuo pačiu principu, net kai verslo logika neturėtų vadovautis.
Kodėl: DI mėgsta kartoti patikrintas formas.
Rizika: reikalavimai nėra simetriški – jie yra gumbuoti, kaip blogai supakuoti maisto produktai 🍅📦.
6) Palyginimo lentelė – būdai įvertinti, kaip paprastai atrodo dirbtinio intelekto kodas 🧪
Žemiau pateikiamas praktinis įrankių rinkinių palyginimas. Tai ne „DI detektoriai“, o kodo realybės patikrinimai . Nes geriausias būdas atpažinti abejotiną kodą yra jį išbandyti, peržiūrėti ir stebėti esant spaudimui.
| Įrankis / metodas | Geriausia (auditorijai) | Kaina | Kodėl tai veikia (ir maža ypatybė) |
|---|---|---|---|
| Kodo peržiūros kontrolinis sąrašas 📝 | Komandos, vadovai, vyresnieji | Nemokama | Priverčia užduoti „kodėl“ klausimus; aptinka bendrinius modelius... kartais atrodo kaprizinga ( „Google Engineering Practices: Code Review “) |
| Vieneto + integracijos testai ✅ | Visiems siuntimo ypatybės | Laisvas | Atskleidžia trūkstamus kraštutinius atvejus; dirbtinio intelekto kode dažnai trūksta gamyboje reikalingų įrenginių ( „Google“ programinės įrangos inžinerija: vienetų testavimas ; praktinių bandymų piramidė ) |
| Statinė analizė / Lintingas 🔍 | Komandos su standartais | Nemokama / Mokama | Pažymi neatitikimus; tačiau neaptinka „neteisingos idėjos“ klaidų ( ESLint dokumentai ; GitHub CodeQL kodo skenavimas ) |
| Tipo tikrinimas (jei taikoma) 🧷 | Didesnės kodų bazės | Nemokama / Mokama | Atskleidžia neaiškias duomenų formas; gali būti erzinanti, bet verta ( TypeScript: Static Type Checking ; mypy dokumentacija ) |
| Grėsmių modeliavimas / Piktnaudžiavimo atvejai 🛡️ | Į saugumą orientuotos komandos | Nemokama | Dirbtinis intelektas gali ignoruoti priešišką naudojimą; tai verčia jį būti į dienos šviesą ( OWASP grėsmių modeliavimo atmintinė ) |
| Našumo profiliavimas ⏱️ | Darbas su daug duomenų, naudojant vidinę sistemą | Nemokama / Mokama | Dirbtinis intelektas gali pridėti papildomų ciklų, konvertavimo, paskirstymo – profiliavimas nemeluoja ( „Python“ dokumentai: „The Python Profilers “) |
| Domenui skirti testavimo duomenys 🧾 | Produktas + inžinerija | Nemokama | Greičiausias „kvapo testas“; netikri duomenys sukuria netikrą pasitikėjimą ( „pytest fixtures“ dokumentai ) |
| Poros apžvalga / žingsnis po žingsnio 👥 | Mentorystė + svarbūs PR | Nemokama | Paprašykite autoriaus paaiškinti pasirinkimus; dirbtinio intelekto kodui dažnai trūksta istorijos ( „Software Engineering at Google“: Code Review ) |
Taip, stulpelis „Kaina“ yra šiek tiek kvailokas – nes brangiausia dažniausiai yra dėmesys, o ne įrankiai. Dėmesys kainuoja... viską 😵💫.
7) Struktūrinės užuominos dirbtinio intelekto padedamame kode 🧱
Jei norite gilesnio atsakymo, kaip paprastai atrodo dirbtinio intelekto kodas, atitolinkite vaizdą ir pažiūrėkite į struktūrą.
1) Techniškai teisingas, bet kultūriškai neteisingas pavadinimas
Dirbtinis intelektas linkęs pasirinkti pavadinimus, kurie yra „saugūs“ daugelyje projektų. Tačiau komandos kuria savo dialektą:
-
Jūs jį vadinate
„AccountId“, o dirbtinis intelektas –„userId“. -
Jūs tai vadinate
„LedgerEntry“, o dirbtinis intelektas –„transaction“. -
Jūs tai vadinate
„FeatureGate“, o jis –„configFlag“.
Niekas iš to nėra „blogai“, bet tai užuomina, kad autorius ilgai negyveno jūsų domene.
2) Kartojimas be pakartotinio naudojimo arba pakartotinis naudojimas be priežasties
Kartais dirbtinis intelektas:
-
kartoja panašią logiką keliose vietose, nes ji „neprisimena“ viso saugyklos konteksto iš karto, arba
-
verčia pakartotinai naudoti per abstrakcijas, kurios sutaupo tris eilutes, bet kainuoja tris valandas vėliau.
Tokie ir yra mainai: mažiau spausdinimo dabar, daugiau galvojimo vėliau. Ir ne visada esu tikras, ar tai geri mainai, matyt... priklauso nuo savaitės 😮💨.
3) „Tobulas“ moduliškumas, nepaisantis realių ribų
Pamatysite kodą, suskirstytą į tvarkingus modulius:
-
validatoriai/ -
paslaugos/ -
tvarkytojai/ -
utils/
Tačiau ribos gali nesutapti su jūsų sistemos siūlėmis. Žmogus linkęs atspindėti architektūros problemines vietas. Dirbtinis intelektas linkęs atspindėti tvarkingą diagramą.
8) Klaidų tvarkymas – kur dirbtinio intelekto kodas tampa… sudėtingas 🧼
Klaidų tvarkymas yra vienas iš svarbiausių rodiklių, nes tam reikia nuovokos .
Stebėtini modeliai
-
Plačių išimčių aptikimas naudojant neaiškų registravimą ( „Pylint“ dokumentai: „bare-except “)
-
Klaidų prarijimas ir numatytųjų reikšmių grąžinimas
-
Grąžinama „sėkmė: klaidinga“, o ne pateikiami reikšmingi nesėkmės duomenys
-
Pakartotiniai ciklai be pertraukos ar apribojimo (arba su keistai parinkta riba, pvz., 3, nes 3 atrodo gerai) ( AWS normatyvinės gairės: pakartotinis bandymas su pertrauka ; AWS kūrimo priemonių biblioteka: skirtasis laikas, pakartotiniai bandymai ir pertrauka su virpesiu )
Kaip gerai atrodo
-
Nesėkmės yra specifinės
-
Klaidos yra veiksmingos
-
Žurnalavimas apima kontekstą (ID, įvestis, atitinkamą būseną)
-
Jautrūs duomenys nėra kaupiami žurnaluose (DI kartais tai pamiršta 😬) ( OWASP registravimo atmintinė ; OWASP 10 geriausių 2025 m.: saugumo registravimas ir įspėjimų apie gedimus )
Labai žmogiškas bruožas – parašyti šiek tiek susierzinusį klaidos pranešimą. Ne visada, bet tai atpažįstama, kai jį pamato. Dirbtinio intelekto klaidų pranešimai dažnai būna ramūs, kaip meditacijos programėlė.
9) Kraštutiniai atvejai ir produkto realybė – „trūkstamas kruopštumas“ 🧠🪤
Tikros sistemos yra netvarkingos. Dirbtinio intelekto išvesties rezultatams dažnai trūksta tos tekstūros.
Komandų „ryžto“ pavyzdžiai:
-
Funkcijų žymos ir daliniai išleidimai ( Martin Fowler: Funkcijų perjungimas )
-
Atgalinio suderinamumo gudrybės
-
Keistos trečiųjų šalių skirtosios datos
-
Seni duomenys, kurie pažeidžia jūsų schemą
-
Nenuoseklios didžiųjų ir mažųjų raidžių, kodavimo arba lokalizacijos problemos
-
Verslo taisyklės, kurios atrodo savavališkos, nes yra savavališkos
Dirbtinis intelektas gali susidoroti su kraštutiniais atvejais, jei jam nurodote, bet jei jų aiškiai neįtraukiate, jis dažnai sukuria „švaraus pasaulio“ sprendimą. Švarūs pasauliai yra nuostabūs. Švarių pasaulių taip pat nėra.
Gaunama šiek tiek įtempta metafora: dirbtinio intelekto kodas yra kaip visiškai nauja kempinė – jis dar nesugėrė virtuvės katastrofų. Štai ir viskas 🧽. Ne pats geriausias mano darbas, bet beveik teisinga.
10) Kaip padaryti, kad dirbtinio intelekto pagalba sukurtas kodas atrodytų žmogiškai – ir, svarbiausia, būtų patikimas 🛠️✨
Jei naudojate dirbtinį intelektą kodo braižymui (o daugelis žmonių tai daro), galite gerokai pagerinti rezultatus, pasitelkdami kelis įpročius.
A) Iš anksto įterpkite savo apribojimus
Užuot sakę „Parašykite funkciją, kuri…“, pabandykite:
-
numatomos sąnaudos / išvestis
-
našumo poreikiai
-
klaidų politika (kelti, grąžinti rezultato tipą, žurnaluoti + nepavykti?)
-
pavadinimų konvencijos
-
esami šablonai jūsų saugykloje
B) Prašykite kompromisų, o ne tik sprendimų
Raginimas su:
-
„Pateikite du metodus ir paaiškinkite kompromisus.“
-
„Ko čia vengtumėte daryti ir kodėl?“
-
„Kur tai lūžta gamyboje?“
Dirbtinis intelektas yra geresnis, kai priverčiate jį galvoti apie riziką.
C) Priverskite jį ištrinti kodą
Rimtai. Klauskite:
-
„Pašalinkite bet kokias nereikalingas abstrakcijas.“
-
„Supaprastinkite tai iki mažiausios teisingos versijos.“
-
„Kurios dalys yra spekuliatyvios?“
Dirbtinis intelektas linkęs pridėti. Puikūs inžinieriai linkę atimti.
D) Pridėkite testus, kurie atspindi realybę
Ne tik:
-
„grąžina laukiamą produkciją“
Bet:
-
keista įvestis
-
trūkstami laukai
-
lygiagretumas
-
daliniai gedimai
-
integracijos lygio elgesys ( „Google“ programinės įrangos inžinerija: didesnis testavimas ; praktinė testavimo piramidė )
Jei nieko kito nedarai, daryk štai ką. Testai yra melo detektorius, ir jiems nerūpi, kas parašė kodą 😌.
11) Baigiamosios pastabos + trumpa santrauka 🎯
Taigi, kaip paprastai atrodo dirbtinio intelekto kodas : jis dažnai atrodo švarus, bendro pobūdžio, šiek tiek per daug paaiškintas ir šiek tiek per daug linkęs įtikti. Svarbiausias dalykas yra ne formatavimas ar komentarai – trūkstamas kontekstas: domenų pavadinimai, nepatogūs kraštutiniai atvejai ir architektūrai būdingi pasirinkimai, atsirandantys naudojant sistemą.
Trumpa apžvalga
-
Dirbtinio intelekto kodas nėra vieno stiliaus, tačiau dažnai būna tvarkingas, išsamus ir pernelyg bendro pobūdžio.
-
Geriausias požymis yra tai, ar kodas atspindi jūsų tikruosius apribojimus ir produkto griežtumą.
-
Nesutelkite dėmesio į aptikimą – susitelkite į kokybę: testus, peržiūrą, aiškumą ir ketinimus ( „Google“ inžinerijos praktika: kodo peržiūra ; programinės įrangos inžinerija „Google“: vienetų testavimas ).
-
Dirbtinis intelektas tinka pirmajam juodraščiui. Jis netinka paskutiniam juodraščiui. Toks yra visas žaidimas.
Ir jei kas nors bandys jus sugėdinti už dirbtinio intelekto naudojimą, tiesą sakant... nekreipkite dėmesio į triukšmą. Tiesiog atsiųskite patikimą kodą. Tik patikimas kodas yra vienintelis lankstumas, kuris išlieka 💪🙂.
DUK
Kaip galite sužinoti, ar kodą parašė DI?
Dirbtinio intelekto padedamas kodas dažnai atrodo šiek tiek pernelyg tvarkingas, beveik kaip „vadovėlis“: nuoseklus formatavimas, vienoda struktūra, bendriniai pavadinimai (pvz., „data“ , „items“ , „result “) ir subalansuoti, nušlifuoti klaidų pranešimai. Jis taip pat gali būti pateikiamas su daugybe dokumentacijos eilučių ar komentarų, kurie tiesiog pakartoja akivaizdžią logiką. Didesnis signalas yra ne stilius – tai įprasto šiurkštumo nebuvimas: domeno kalba, saugyklų konvencijos, nepatogūs apribojimai ir klijai, užtikrinantys sistemų stabilumą.
Kokie yra didžiausi pavojaus signalai DI sugeneruotų klaidų tvarkyme?
Stebėkite plačius išimčių aptikimus ( išskyrus „Exception “), „prarytas klaidas“, kurios tyliai grąžina numatytąsias reikšmes, ir neaiškų žurnalavimą, pvz., „Įvyko klaida“. Šie šablonai gali paslėpti tikras klaidas ir apsunkinti derinimą. Griežtas klaidų apdorojimas yra konkretus, veiksmingas ir pateikia pakankamai konteksto (ID, įvesties duomenis, būseną), neįtraukiant jautrių duomenų į žurnalus. Pernelyg didelė gynyba gali būti tokia pat rizikinga, kaip ir nepakankama gynyba.
Kodėl dirbtinio intelekto kodas dažnai atrodo pernelyg sukonstruotas arba pernelyg abstrahuotas?
Dažnas dirbtinio intelekto polinkis – „atrodyti profesionaliai“ pridedant pagalbines funkcijas, sluoksnius ir katalogus, kurie numato hipotetinius ateities įvykius. Pamatysite bendrinius pagalbininkus, tokius kaip process_data() arba handle_request() ir tvarkingas modulių ribas, kurios labiau tinka diagramai nei jūsų sistemos siūlėms. Praktiškas sprendimas yra atimtis: apkarpykite spekuliacinius sluoksnius, kol gausite mažiausią teisingą versiją, kuri atitinka jūsų reikalavimus, o ne tuos, kuriuos galite paveldėti vėliau.
Kaip atrodo geras dirbtinio intelekto pagalba sukurtas kodas tikroje saugykloje?
Geriausias dirbtinio intelekto pagalba sukurtas kodas skaitomas taip, tarsi jūsų komanda jį būtų pareiškusi: jame naudojami jūsų srities terminai, suderinamos jūsų duomenų formos, jūsų saugyklos modeliai ir jis atitinka jūsų architektūrą. Jis taip pat atspindi jūsų riziką – ne tik sėkmingus kelius – atlikdamas prasmingus testus ir apgalvotą peržiūrą. Tikslas nėra „paslėpti dirbtinį intelektą“, o susieti juodraštį su kontekstu, kad jis veiktų kaip gamybinis kodas.
Kokie testai greičiausiai atskleidžia „švaraus pasaulio“ prielaidas?
Integracijos testai ir kraštinių atvejų testai paprastai greitai atskleidžia problemas, nes dirbtinio intelekto išvestis dažnai daro prielaidas apie idealius įvesties duomenis ir nuspėjamas priklausomybes. Naudokite konkrečioms sritims skirtus įrenginius ir įtraukite keistus įvesties duomenis, trūkstamus laukus, dalinius gedimus, skirtojo laiko limitus ir lygiagretumą ten, kur tai svarbu. Jei kodas turi tik laimingo kelio vienetų testus, jis gali atrodyti teisingai, tačiau vis tiek nepavykti, kai kas nors paspaudžia vieną nepatikrintą mygtuką gamyboje.
Kodėl dirbtinio intelekto parašyti pavadinimai atrodo „techniškai teisingi, bet kultūriškai neteisingi“?
Dirbtinis intelektas dažnai pasirenka saugius, bendrinius pavadinimus, kurie tinka daugelyje projektų, tačiau komandos laikui bėgant sukuria specifinį dialektą. Taip atsiranda neatitikimų, tokių kaip „userId“ ir „AccountId“ arba „transaction“ ir „LedgerEntry“ , net jei logika gera. Šis pavadinimų pokytis rodo, kad kodas nebuvo parašytas „gyvenant“ jūsų domeno ir apribojimų ribose.
Ar verta bandyti aptikti dirbtinio intelekto kodą kodo peržiūrose?
Paprastai produktyviau peržiūrėti kokybę, o ne autorystę. Žmonės taip pat gali rašyti švarų, per daug komentuotą kodą, o dirbtinis intelektas, vadovaujamas, gali sukurti puikius juodraščius. Užuot vaidinę detektyvą, stenkitės pabrėžti projektavimo pagrindimą ir galimus gedimus gamyboje. Tada patvirtinkite atlikdami testus, derindami architektūrą ir taikydami klaidų prevencijos priemones. Spaudimo testavimas yra geresnis nei vibracijos testavimas.
Kaip paraginti dirbtinį intelektą, kad kodas būtų patikimesnis?
Pradėkite nuo apribojimų įvedimo iš anksto: numatomų įvesčių / išvesčių, duomenų formų, našumo poreikių, klaidų politikos, pavadinimų suteikimo konvencijų ir esamų jūsų saugyklos šablonų. Klauskite kompromisų, o ne tik sprendimų – „Kur tai gali sukelti problemų?“ ir „Ko vengtumėte ir kodėl?“ Galiausiai, priverstinai atimkite: nurodykite jam pašalinti nereikalingą abstrakciją ir sukurti mažiausią teisingą versiją prieš ką nors išplėsdami.
Nuorodos
-
„Stack Overflow“ – „Stack Overflow“ kūrėjų apklausa 2025 m. – survey.stackoverflow.co
-
„GitHub“ – „GitHub Octoverse“ (2025 m. spalio 28 d.) – github.blog
-
„Google“ – „Google“ inžinerijos praktika: kodo standarto apžvalga – google.github.io
-
Abseil – „Google“ programinės įrangos inžinerija: vienetų testavimas – abseil.io
-
Abseil – programinės įrangos inžinerija „Google“: kodo apžvalga – abseil.io
-
Abseil – „Google“ programinės įrangos inžinerija: didesnis bandymas – abseil.io
-
Martin Fowler - Martin Fowler: funkcijų perjungimas - martinfowler.com
-
Martin Fowler – Praktinio testo piramidė – martinfowler.com
-
OWASP – OWASP grėsmių modeliavimo atmintinė – cheatsheetseries.owasp.org
-
OWASP – OWASP registravimo atmintinė – cheatsheetseries.owasp.org
-
OWASP – OWASP 10 geriausių 2025 m.: saugumo registravimo ir įspėjimų apie gedimus sistema – owasp.org
-
ESLint – ESLint dokumentai – eslint.org
-
„GitHub“ dokumentai – „GitHub CodeQL“ kodo nuskaitymas – docs.github.com
-
„TypeScript“ – „TypeScript“: statinis tipų tikrinimas – www.typescriptlang.org
-
mypy - mypy dokumentacija - mypy.readthedocs.io
-
Python – Python dokumentacija: Python profiliuotojai – docs.python.org
-
„pytest“ – „pytest“ įrangos dokumentai – docs.pytest.org
-
„Pylint“ – „Pylint“ dokumentai: išskyrus „bare-except“ – pylint.pycqa.org
-
„Amazon Web Services“ – AWS norminiai nurodymai: bandykite dar kartą su atidėjimu – docs.aws.amazon.com
-
„Amazon Web Services“ – AWS kūrimo biblioteka: skirtasis laikas, pakartotiniai bandymai ir atsilikimas su „jitter“ – aws.amazon.com