Tai vienas iš tų įkyrių, šiek tiek nerimą keliančių klausimų, kurie vis dažniau užklumpa vėlyvus „Slack“ pokalbius ir kavos virimo diskusijas tarp programuotojų, įkūrėjų ir, tiesą sakant, visų, kurie kada nors susidūrė su paslaptinga klaida. Viena vertus, dirbtinio intelekto įrankiai tampa vis greitesni, aštresni, beveik neįtikėtinai greitai sukuria kodą. Kita vertus, programinės įrangos inžinerija niekada nebuvo vien sintaksės kūrimas. Panagrinėkime tai iš naujo – nenuklysdami į įprastą distopinį mokslinės fantastikos scenarijų, kai „mašinos perims valdžią“.
Straipsniai, kuriuos galbūt norėsite perskaityti po šio:
🔗 Geriausi dirbtinio intelekto įrankiai programinės įrangos testavimui
Atraskite dirbtiniu intelektu paremtus testavimo įrankius, kurie kokybės užtikrinimą padaro išmanesnį ir greitesnį.
🔗 Kaip tapti dirbtinio intelekto inžinieriumi
Žingsnis po žingsnio vadovas, kaip sėkmingai kurti karjerą dirbtinio intelekto srityje.
🔗 Geriausi dirbtinio intelekto įrankiai be kodo
Lengvai kurkite dirbtinio intelekto sprendimus be programavimo, naudodami geriausias platformas.
Programinės įrangos inžinieriai yra svarbūs 🧠✨
Po visomis klaviatūromis ir steko pėdsakais inžinerija visada buvo problemų sprendimas, kūrybiškumas ir sisteminis sprendimų priėmimas . Žinoma, dirbtinis intelektas gali per kelias sekundes sukurti ištraukas ar net sukurti programėlę, tačiau tikri inžinieriai sukuria tai, ko mašinos iki galo nepaliečia:
-
Gebėjimas suvokti painų kontekstą .
-
Kompromisų darymas (greitis, kaina ir saugumas... visada žongliravimas).
-
Darbas su žmonėmis , o ne tik su kodu.
-
Aptinkami keisti kraštutiniai atvejai, kurie neatitinka tvarkingo modelio.
Įsivaizduokite dirbtinį intelektą kaip neįtikėtinai greitą, nenuilstantį praktikantą. Naudingas? Taip. Architektūros valdymas? Ne.
Įsivaizduokite: augimo komanda nori funkcijos, kuri būtų susieta su kainodaros taisyklėmis, sena atsiskaitymo logika ir tarifų apribojimais. Dirbtinis intelektas gali sukurti jos dalis, bet sprendimas, kur įdėti logiką , ką pašalinti ir kaip nesugadinti sąskaitų faktūrų perkėlimo metu – tai priklauso nuo žmogaus. Tuo ir skiriasi.
Ką iš tikrųjų rodo duomenys 📊
Skaičiai stulbinantys. Struktūrizuotuose tyrimuose kūrėjai, naudojantys „GitHub Copilot“, užduotis atliko ~55 % greičiau nei tie, kurie programavo savarankiškai [1]. Platesnio masto ataskaitos? Kartais iki 2 kartų greičiau, kai dirbtinis intelektas integruotas į darbo eigas [2]. Dirbtinio intelekto įrankių naudojimas taip pat yra didžiulis: 84 % kūrėjų naudoja arba planuoja naudoti dirbtinio intelekto įrankius, o daugiau nei pusė specialistų juos naudoja kasdien [3].
Tačiau yra vienas trūkumas. Recenzuoti darbai rodo, kad programuotojai, padedami dirbtinio intelekto, dažniau rašydavo nesaugų kodą ir dažnai pernelyg pasitikėdavo savimi [5]. Būtent todėl sistemose pabrėžiami apsauginiai barjerai: priežiūra, patikrinimai, žmonių atliekamos peržiūros, ypač jautriose srityse [4].
Greita greta: dirbtinis intelektas ir inžinieriai
| faktorius | Dirbtinio intelekto įrankiai 🛠️ | Programinės įrangos inžinieriai 👩💻👨💻 | Kodėl tai svarbu |
|---|---|---|---|
| Greitis | Žaibo užvedimo fragmentai [1][2] | Lėčiau, atsargiau | Neapdorotas greitis nėra prizas |
| Kūrybiškumas | Apribota savo mokymo duomenų | Iš tikrųjų gali sugalvoti | Inovacija nėra šablonų kopijavimas |
| Derinimas | Siūlo paviršiaus taisymus | Supranta, kodėl sugedo | Pagrindinė priežastis svarbi |
| Bendradarbiavimas | Solo operatorius | Moko, derasi, bendrauja | Programinė įranga = komandinis darbas |
| Kaina 💵 | Pigu už užduotį | Brangus (atlyginimas + išmokos) | Maža kaina ≠ geresnis rezultatas |
| Patikimumas | Haliucinacijos, rizikingas saugumas [5] | Pasitikėjimas auga su patirtimi | Saugumas ir pasitikėjimas svarbūs |
| Atitiktis | Reikalingi auditai ir priežiūra [4] | Taisyklių ir auditų dizainas | Daugelyje sričių nederybų objektas |
Dirbtinio intelekto programavimo pagalbininkų antplūdis 🚀
Tokios priemonės kaip „Copilot“ ir LLM pagrindu veikiančios IDE keičia darbo eigą. Jos:
-
Akimirksniu sukurkite standartinį projektą.
-
Pateikite pertvarkymo patarimų.
-
Paaiškinkite API, kurių niekada neliečiate.
-
Netgi išspjauna testus (kartais pleiskanojančius, kartais kietus).
Kuo skiriasi? Jaunesniojo lygio užduotys dabar yra trivialios. Tai pakeičia tai, kaip pradedantieji mokosi. Griežtai nagrinėti nesibaigiančius ciklus yra mažiau aktualu. Protingesnis kelias: leiskite dirbtiniam intelektui parašyti juodraštį, tada patikrinti : parašyti teiginius, paleisti sąsajų testus, agresyviai testuoti ir peržiūrėti, ar nėra paslėptų saugumo spragų, prieš sujungiant [5].
Kodėl dirbtinis intelektas vis dar nėra visiškas pakaitalas
Būkime atviri: dirbtinis intelektas yra galingas, bet kartu ir... naivus. Jis neturi:
-
Intuicija – nesąmonių reikalavimų gaudymas.
-
Etika – teisingumo, šališkumo, rizikos įvertinimas.
-
Kontekstas – žinojimas , kodėl funkcija turėtų arba neturėtų egzistuoti.
Kalbant apie kritiškai svarbią programinę įrangą – finansų, sveikatos apsaugos, aviacijos ir kosmoso – nerizikuojama vien tik juodosios dėžės sistema. Sistemos aiškiai parodo: žmonės yra atsakingi – nuo testavimo iki stebėjimo [4].
„Vidurio išėjimo“ efektas darbo vietose 📉📈
Dirbtinis intelektas labiausiai paveikia įgūdžių skalės vidurį:
-
Pradedančiojo lygio kūrėjai : pažeidžiami – pagrindinis programavimas automatizuojamas. Augimo kelias? Testavimas, įrankių kūrimas, duomenų patikros, saugumo peržiūros.
-
Vyresnieji inžinieriai / architektai : saugesni – atsakingi už dizainą, vadovavimą, sudėtingumą ir dirbtinio intelekto valdymą.
-
Nišos specialistai : Dar saugiau – saugumas, įterptosios sistemos, mašininio mokymosi infrastruktūra, dalykai, kuriuose svarbios srities ypatybės.
Pagalvokite apie skaičiuotuvus: jie neišnaikino matematikos. Jie pakeitė, kurie įgūdžiai tapo nepakeičiami.
Žmogaus bruožai, dėl kurių dirbtinis intelektas užklumpa
Keletas inžinerinių supergalių, kurių dirbtiniam intelektui vis dar trūksta:
-
Grumtynės su niūriu, spagečių palikimu kodu.
-
Vartotojų nusivylimo įvertinimas ir empatijos įtraukimas į dizainą.
-
Orientacija į biuro politiką ir derybas su klientais.
-
Prisitaikymas prie paradigmų, kurios dar net nėra išrastos.
Ironiška, bet žmogiškieji dalykai tampa didžiausiu pranašumu.
Kaip išlaikyti savo karjerą perspektyvią 🔧
-
Organizuokite, o ne konkuruokite : elkitės su dirbtiniu intelektu kaip su bendradarbiu.
-
Dviguba apžvalga : grėsmių modeliavimas, specifikacijos kaip testai, stebimumas.
-
Sužinokite apie srities gylį : mokėjimai, sveikatos apsauga, aviacija ir kosmosas, klimatas – kontekstas yra viskas.
-
Sukurkite asmeninį įrankių rinkinį : „Linters“, „fuzzers“, tipizuotos API, atkuriamos versijos.
-
Dokumentų sprendimai : ADR ir kontroliniai sąrašai leidžia atsekti dirbtinio intelekto pakeitimus [4].
Tikėtina ateitis: bendradarbiavimas, o ne pakeitimas 👫🤖
Tikrasis vaizdas nėra „DI prieš inžinierius“. Tai DI su inžinieriais . Tie, kurie pasikliauja, dirbs greičiau, mąstys plačiau ir perkraus sunkų darbą. Tie, kurie priešinasi, rizikuoja atsilikti.
Realybės patikrinimas:
-
Įprastas kodas → DI.
-
Strategija + kritiniai sprendimai → Žmonės.
-
Geriausi rezultatai → Dirbtiniu intelektu papildyti inžinieriai [1][2][3].
Užbaigimas 📝
Taigi, ar inžinieriai bus pakeisti? Ne. Jų darbai keisis. Tai mažiau „programavimo pabaiga“, o daugiau „programavimas vystosi“. Laimės tie, kurie išmoks valdyti dirbtinį intelektą, o ne su juo kovos.
Tai nauja supergalia, o ne rožinis apsirengėlis.
Nuorodos
[1] „GitHub“. „Tyrimas: „GitHub Copilot“ poveikio kūrėjų produktyvumui ir laimei kiekybinis įvertinimas“ (2022). https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/
[2] „McKinsey & Company“. „Kūrėjų produktyvumo išlaisvinimas naudojant generatyvųjį dirbtinį intelektą“ (2023 m. birželio 27 d.). https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/unleashing-developer-productivity-with-generative-ai
[3] „Stack Overflow“. „2025 m. kūrėjų apklausa – dirbtinis intelektas“ (2025). https://survey.stackoverflow.co/2025/ai
[4] NIST. „Dirbtinio intelekto rizikos valdymo sistema (DI RMF)“ (2023–). https://www.nist.gov/itl/ai-risk-management-framework
[5] Perry, N., Srivastava, M., Kumar, D. ir Boneh, D. „Ar vartotojai rašo daugiau nesaugaus kodo su dirbtinio intelekto asistentais?“ ACM CCS (2023). https://dl.acm.org/doi/10.1145/3576915.3623157