Miten tekoäly ja DevOps muuttavat tapaamme kehittää tuotteita

Samaan aikaan GitHub kertoi, että sen tekoälytyökalut tekevät kehittäjistä 55 % nopeampia. Kuulostaa hyvältä, eikö?

Ongelma on, että perinteisissä organisaatioissa varsinainen ohjelmistokehitys vie vain 5–10 % T&K-toiminnan kokonaisajasta. Vaikka tekoälytyökalut siis tekisivät kehittäjistäsi kaksi kertaa nopeampia, organisaatiosi kokonaistehokkuus paranee vain 2,5–5 %.

Se ei ole etsimämme mullistava parannus.

Olen käyttänyt vuosia tekoälyohjatun kehityksen käyttöönottoon eri organisaatioissa – ketteristä startupeista tiukasti säänneltyihin suuryrityksiin. Voin sanoa, että merkittävään nopeutumiseen tarvitaan muutakin kuin tekoälypohjaisten koodausavustajien lisääminen työkaluketjuun. Koko kehitystapaa on ajateltava uudelleen.

Aloitamme kuudesta perusalueesta, jotka on saatava kuntoon, ennen kuin tekoäly voi tuoda merkittävän muutoksen. Sen jälkeen tarkastelemme käytännön tapoja toteuttaa tekoälyohjattua kehitystä – julkaisitpa verkkosovelluksia useita kertoja päivässä tai rakensitpa lääkinnällisiä laitteita, joiden sertifiointisyklit kestävät vuosia.

Kuusi keskeistä aluetta, jotka on saatava kuntoon

Ennen kuin syvennymme tekoälyohjattuun kehitykseen, puhutaan perusteista. Olen nähnyt liian monen organisaation siirtyvän suoraan tekoälytyökaluihin, vaikka perusasiat eivät ole kunnossa. Tässä ovat asiat, jotka on hoidettava ensin.

1. Agile-käytännöt – Jira-automaatio

Useimmat organisaatiot käyttävät Jiraa tai vastaavia työkaluja, ja useimpien kehittäjien mielestä tietojen manuaalinen päivittäminen on työlästä. Vaikka nämä työkalut sopivat hyvin raportointiin ja johtamisen seurantaan, niistä voi tulla ohjelmistokehityksen pullonkaula.

Moderni ohjelmistokehitys tarvitsee sujuvamman toimintatavan. Jira-tikettien manuaalisen päivittämisen sijaan nykyaikaiset työkalut mahdollistavat saumattoman yhteyden Gitin kanssa ja käyttävät haarojen nimiä työnkulun ensisijaisena tunnisteena. Kun teet muutoksen sovellukseen, luot vain haaran, jonka nimi on esimerkiksi HW-1234/feature-description, ja automaatio hakee Jira-tiketin tiedot siitä.

Näin säilytät jäljitettävyyden ja poistat kitkaa kehitysprosessista.

2. CI/CD ja laatutarkistusten automatisointi

Continuous Integration ja Continuous Deployment voivat vaikuttaa perusasioilta, mutta ilman tiukkaa automaatiota et pärjää tekoälyohjatun kehityksen aikakaudella. CI/CD-putkesi toimii suojakaiteena ja varmistaa, että tekoälyn tuottama koodi täyttää laatustandardisi.

Tällaiselta toimiva CI/CD-vähimmäiskokonaisuus voi näyttää:

name: Continuous Integration

on: [push, pull_request]

jobs:

test: runs-on: ubuntu-latest timeout-minutes: 5 steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 - run: npm ci - run: npm test - run: npm run lint

Yksinkertaista? Kyllä. Mutta tämän perustan päälle voit lisätä vähitellen kehittyneempiä tarkistuksia, myös tekoälylle suunnattuja validointeja.

3. Laadun varmistaminen jatkuvalla laadunvarmistuksella

Testisi eivät ole vain tarkistustyökaluja. Ne ovat elävää dokumentaatiota vaatimuksistasi. Tekoälyn tuottaman koodin kanssa tämä korostuu entisestään. Testit määrittävät hyväksyttävän toiminnan rajat, joten tekoälytyökaluillasi on selkeät tavoitteet, joihin pyrkiä.

Hiljattain tekemässäni työssä havaitsimme laskentavirheen, jonka tekoälyn tuottama koodi oli aiheuttanut. Kattava testikokonaisuutemme, joka myös suunniteltiin ja toteutettiin tekoälyn avulla, havaitsi ongelman, joten pystyimme iteroimaan ratkaisua nopeasti.

4. Cloud Native -kehitys, jossa kaikki muutokset julkaistaan

Cloud Native ei tarkoita vain pilvessä ajamista, vaan modernien käyttöönottomallien omaksumista. Vercelin, Fly.io:n tai Herokun kaltaisten palvelujen avulla voimme ottaa jokaisen feature-haaran käyttöön automaattisesti ja luoda kertakäyttöisiä ympäristöjä testausta ja validointia varten.

Tämä lähestymistapa on erityisen arvokas, kun työskentelet tekoälyn tuottaman koodin kanssa. Sen avulla voit varmistaa muutokset nopeasti erillään muusta kokonaisuudesta ilman monimutkaisten ympäristöjen hallintaa.

5. Tietoturvatyökalut automaattiseen suojaukseen

Modernit tietoturvatyökalut voivat automaattisesti skannata riippuvuutesi, tarkistaa haavoittuvuudet ja jopa arvioida pull requesteja tietoturvaongelmien varalta. Tutustu esimerkiksi GitHub Advanced Securityyn tai GitLab Securityyn.

Tekoälyohjatussa kehityksessä tämä korostuu entisestään. Tietoturvatyökalusi ovat turvaverkkosi. Ne havaitsevat tekoälyn tuottaman koodin mahdolliset ongelmat ennen kuin ne päätyvät tuotantoon.

6. Organisoituminen Team Topologies -mallin mukaisesti

Conwayn lain mukaan ohjelmistoarkkitehtuurisi heijastaa organisaatiorakennettasi.

Matthew Skeltonin ja Manuel Paisin kehittämä Team Topologies -viitekehys auttaa organisoimaan tiimejä modernien kehityskäytäntöjen tueksi.

Katso Matthew'n esittely Team Topologies -mallista DevOps Conferencessamme: DevOps Topologies 10 years on: What have we learned about silos, collaboration, and flow?

Keskeiset elementit ovat:

Arvovirran mukaiset tiimit, jotka vastaavat tietyistä asiakkaalle tuotettavan arvon osista
Alustatiimit, jotka tarjoavat sisäisiä palveluita
Monimutkaisten alijärjestelmien tiimit, jotka vastaavat erikoistuneista komponenteista
Mahdollistavat tiimit, jotka tukevat muiden tiimien kyvykkyyksien kehittämistä

Miksi tämä rakenne on niin tärkeä tekoälytyökaluja käyttöön otettaessa? Se auttaa selkeyttämään, missä ja miten tekoälyavusta saadaan eniten hyötyä.

Näissä perusteissa ei ole kyse vain parhaista käytännöistä. Kyse on ympäristön luomisesta, jossa tekoälytyökalut voivat aidosti tuottaa arvoa. Ilman tätä perustaa vaarana on korttitalo, joka näyttää vaikuttavalta mutta sortuu todellisen maailman paineessa.Lue lisää artikkelistamme "Ohjelmistokehityksen transformointi tekoälyn ja DevOpsin avulla"

Missä tekoälystä on aidosti apua

Kun perusasiat ovat kunnossa, katsotaan, missä tekoäly voi todella vaikuttaa. Unohda markkinointihype – tässä on käytännön kokemukseeni perustuvaa tietoa siitä, mikä todella toimii.

Koodin tuottaminen ja täydentäminen

Kerron käytännön esimerkin. Tarvitsin hiljattain funktion viikon numeron laskemiseen. Sen sijaan, että olisin itse perehtynyt päivämäärien käsittelyn yksityiskohtiin, annoin tekoälyn hoitaa algoritmin.

Näin se eteni:

function getWeekNumber(date = new Date()) { const startDate = new Date(date.getFullYear(), 0, 1); const days = Math.floor((date - startDate) / (1000 * 60 * 60 * 24)); const weekNumber = Math.ceil((days + startDate.getDay() + 1) / 7); return weekNumber;}

Koodi toimii useimmissa tapauksissa, mutta koska viikon numeroa ei lasketa suoraan tammikuun ensimmäisestä päivästä, se ei todellisuudessa toimi oikein. Tämä korostaa tärkeää asiaa: tekoäly soveltuu erinomaisesti alustavien ratkaisujen tuottamiseen, mutta tarvitset asianmukaista testausta ja validointia.

Todellinen hyöty ei ole kehittäjien korvaamisessa. Se on työläiden ja toistuvien tehtävien hoitamisessa, jotta voit keskittyä liiketoimintalogiikkaan ja reunatapauksiin.

APIen ja kirjastojen ymmärtäminen

Tässä tekoäly todella loistaa. Sen sijaan, että selaisit dokumentaatiota tai Stack Overflow'ta, voit esittää suoria kysymyksiä APIsta ja saada kontekstiin sopivia vastauksia.

Esimerkiksi kun aloin käyttää uutta päivämäärien käsittelykirjastoa, en lukenut sivukaupalla dokumentaatiota, vaan saatoin kysyä:

"Miten käsittelen ISO-viikkonumeroita tässä kirjastossa?"
"Mitä eroa on paikallisten viikkojen ja UTC-viikkojen laskennassa?"
"Näytä esimerkkejä vuodenvaihteen rajatapauksien käsittelystä"

Vastaukset ovat yleensä käytännönläheisempiä ja kontekstuaalisempia kuin perinteinen dokumentaatio. Muista kuitenkin, että tekoälyn tiedon katkaisupäivän vuoksi kaikki viimeaikaisia API-muutoksia koskevat tiedot kannattaa varmistaa.

Boilerplate-koodin luominen

Uusien projektien aloittaminen tai vakiintuneiden mallien lisääminen tarkoitti ennen koodin kopioimista ja liittämistä vanhoista projekteista. Nyt tekoäly voi luoda boilerplate-koodin usein siistimpään muotoon kuin vanhat esimerkkiprojektisi.

Mielenkiintoista on, että tekoäly tuottaa usein rakenteeltaan parempaa boilerplate-koodia kuin ihmisen kirjoittama koodi. Se pystyy tähän, koska se yhdistää parhaat käytännöt tuhansista esimerkeistä.

Varmista vain, että vaatimuksesi ovat selkeitä. Hyvien ja keskinkertaisten tulosten ero riippuu usein siitä, kuinka hyvin osaat määritellä tarpeesi.

Uusien teknologioiden oppiminen

Kerron tämän käytännön esimerkin avulla.

Minun piti oppia Pythonilla tehtävästä äänianalyysistä, joka oli minulle vieras aihealue. Sen sijaan, että olisin käyttänyt tuntikausia dokumentaation lukemiseen, olisin voinut keskustella tekoälyn kanssa:

"Näytä minulle Pythonilla toteutettu äänianalyysin perusputki"
"Selitä, miten FFT-parametrit vaikuttavat analyysiin"
"Auta minua optimoimaan tämä reaaliaikaista käsittelyä varten"

Tärkeintä on käyttää tekoälyä oppimisen vauhdittajana, ei ymmärryksen korvaajana. Sinun on silti ymmärrettävä käsitteet, mutta tekoäly voi auttaa sinua etenemään oppimiskäyrällä nopeammin.

Varoituksen sana

Vaikka kaikki nämä kyvykkyydet ovat tehokkaita, niihin liittyy tärkeitä varauksia. Päätänkin tämän osion neljään tärkeimpään:

Tekoälyn tuottama koodi vaatii perusteellista testausta
Tietoturvavaikutukset on varmistettava
Reunatapaukset vaativat usein ihmisen näkemystä
Uusimmat ominaisuudet tai parhaat käytännöt eivät välttämättä näy vastauksissa

Huomioi nämä aina tekoälyn käyttöönotossa

Kun olemme tarkastelleet, missä tekoäly voi auttaa, siirrytään siihen, mitä sinun on oikeasti huomioitava, kun tuot tekoälyn osaksi kehitysprosessiasi. Olen kohdannut nämä haasteet toistuvasti toteuttaessani tekoälyohjattua kehitystä, ja haluan auttaa sinua välttämään samat sudenkuopat.

Prompt engineering -taidot ovat välttämättömiä

Sinun on opittava uusi taito, jota kukaan meistä ei osannut odottaa vielä muutama vuosi sitten: prompt engineering. Kyse ei ole vain siitä, että pyydät tekoälyä kirjoittamaan koodia, vaan siitä, että saat tuloksia, joita voit todella käyttää tuotannossa.

Näytän, mitä tarkoitan.

Kun tarvitsin funktion viikkonumeron laskemiseen, pyyntö ”funktio viikkonumeroiden laskemiseen” tuotti pelkkää roskaa. Minun piti oppia olemaan tarkka:

"Tarvitsen funktion, joka käsittelee ISO-päivämääriä, käyttää ISO-viikkonumerointia ja antaa selkeät virheet virheellisistä syötteistä."

Kyvystäsi kirjoittaa selkeitä prompteja tulee yhtä tärkeä kuin koodaustaidoistasi.

Huolellisuus lakiasioissa ja immateriaalioikeuksissa

Olet luultavasti kuullut GitHub Copilotia koskevasta oikeusjutusta: marraskuussa 2022 Microsoftia, GitHubia ja OpenAI:ta vastaan nostettiin ryhmäkanne, jossa väitettiin GitHub Copilotin loukanneen avoimen lähdekoodin kehittäjien tekijänoikeuksia tuottamalla koodia ilman asianmukaista tekijämainintaa. Microsoft on luvannut puolustaa käyttäjiä tekoälyn tuottamaan koodiin liittyviltä tekijänoikeusvaatimuksilta, mutta koska oikeudellinen viitekehys on edelleen kehittymässä, sinun on käytettävä tekoälyn tuottamaa koodia harkiten.

Haastavaa on se, että tekoälyn tuottama koodi ei saa automaattisesti tekijänoikeussuojaa. Sitä on muokattava riittävästi, jotta siitä tulee omaa työtäsi. Käytännössä tämä tarkoittaa, ettet voi vain kopioida ja liittää tekoälyn tuottamaa sisältöä. Sinun on ymmärrettävä se, muokattava sitä ja integroitava se kunnolla koodikantaasi.

Tietoturva ja tietosuoja

Tässä on jotain, minkä pitäisi pelottaa sinua: kaikesta, minkä liität ChatGPT:hen, voi tulla koulutusdataa tuleville versioille.

Älä koskaan jaa:

API-avaimia tai salaisuuksia
Sisäisiä arkkitehtuurin yksityiskohtia
Omistettuja algoritmeja
Asiakasdataa
Tietoturvan kannalta arkaluonteista koodia

Jos sinun täytyy käyttää tekoälyä arkaluonteisen koodin kanssa, luo anonymisoituja esimerkkejä tai ota käyttöön yksityisiä instansseja. Kyllä, se vaatii ylimääräistä työtä, mutta se on parempi kuin selittää tietoturvatiimillesi, miksi sisäiset algoritminne näkyvät muiden ihmisten tekoälyvastauksissa.

Testaus ja validointi

Muistatko mainitsemani viikkonumerovirheen? Tekoäly antoi minulle koodia, joka näytti täydelliseltä, mutta epäonnistui tietyillä viikonpäivillä vuodesta riippuen. Siksi tarvitset vankkaa testausta – tekoäly antaa itsevarmasti myös väärää koodia.

Tässä on testauskäytäntömme, ja se toimii erinomaisesti:

Kirjoita testit ennen koodin generointia (kyllä, TDD toimii myös tekoälyn kanssa)
Testaa reunatapaukset erikseen
Validoi todellisen datan avulla
Automatisoi validointi CI/CD:n avulla
Seuraa tuotantoympäristön toimintaa

Tässä on käytännön esimerkki viikkonumeroprojektistamme:

test('should return week 13 for 25th of March 2025', () => {expect(getWeekNumber(new Date('2025-03-25'))).toBe(13);});

Kirjoita tällaiset testit jo ennen kuin pyydät tekoälyltä koodia. Kun tekoäly antaa sinulle hyvännäköisen ratkaisun, joka palauttaa viikon 13 sijaan viikon 12, huomaat sen heti. Testeistäsi tulee turvaverkkosi.

Toteutusstrategia

Näin pääset alkuun: valitse ensimmäiseen tekoälytoteutukseesi jotain ei-kriittistä. Se voi olla esimerkiksi apufunktio tai sisäinen työkalu. Ota käyttöön kunnollinen testaus, kokeile erilaisia prompteja ja selvitä, mikä toimii. Varmista, että tiimisi oppii luottamaan prosessiin.

Älä yritä korvata kehittäjiäsi tekoälyllä – se ei ole tarkoitus. Lisäät heidän työkalupakkiinsa tehokkaan työkalun, mutta heidän on opittava käyttämään sitä turvallisesti ja tehokkaasti.

Onnistumisen mittaaminen DevOps-mittareilla

Puhutaan mittareista. Ei sellaisista näennäismittareista, jotka näyttävät hyvältä esityksissä, vaan mittareista, jotka todella kertovat, auttaako tekoäly kehitysprosessiasi.

Neljä olennaista mittaria

Kun arvioit, miten tekoälyn käyttöönotto toimii, keskity samoihin neljään mittariin, joita toivottavasti jo seuraat. Älä anna tekoälykohtaisten mittareiden, kuten ”tuotettujen koodirivien”, häiritä – ne eivät kerro mitään hyödyllistä.

Käydään läpi, mitä kannattaa mitata ja mitä olen nähnyt käytännössä:

Muutosten läpimenoaika

Tämä mittaa, kuinka kauan muutoksen saaminen tuotantoon kestää. Tekoälyn avulla tämän pitäisi parantua, eikö niin? Asia on kuitenkin monimutkaisempi.

GE Healthcare -projektissa kehittäjät pystyivät kirjoittamaan koodia nopeammin tekoälyn avulla, mutta kokonaisläpimenoaika muuttui tuskin lainkaan sääntelyvaatimusten vuoksi.

Web-kehitysprojekteissa olen kuitenkin nähnyt tiimien lyhentävän läpimenoaikaansa merkittävästi, kun ne yhdistävät tekoälyn hyvään automaatioon. Et vain kirjoita koodia nopeammin – parannat koko prosessia, jossa ideoista tehdään toimivia ohjelmistoja.

Palautumisaika

Kun jokin hajoaa, kuinka nopeasti pystyt korjaamaan sen?

Tämä on ratkaisevan tärkeää tekoälyn tuottaman koodin kanssa, sillä vastaan tulee odottamattomia ongelmia. Aiemmin esittelemässäni viikkonumeron laskentaesimerkissä löysimme ja korjasimme virheen nopeasti, koska käytössämme oli hyvät testit ja käyttöönottoprosessit.

Tavoitteesi tulisi olla säilyttää tai parantaa palautumisaikaa myös tekoälyä käyttöönottaessasi. Jos se pitenee, etenet todennäköisesti liian nopeasti.

Käyttöönottojen tiheys

Tuoreen tutkimuksen mukaan 75 % organisaatioista tekee nyt käyttöönottoja useita kertoja viikossa. Jos teet käyttöönoton kerran päivässä, olet hyvällä tasolla.

Tekoälyn avulla voit tehdä käyttöönottoja useammin, mutta älä pakota sitä – tiheyden tulisi määräytyä liiketoimintatarpeidesi mukaan.

Projekteissani olen huomannut, että tekoäly auttaa eniten pienissä, usein tehtävissä muutoksissa:

Virheiden korjaamisessa
Pienten ominaisuuksien lisäämisessä
Riippuvuuksien päivittämisessä.

Suuret arkkitehtuuripäätökset vaativat edelleen ihmisen ajattelua ja suunnittelua.

Epäonnistumisaste

Tätä kannattaa seurata tarkasti, kun alat käyttää tekoälyä. Epäonnistumisasteesi ei pitäisi kasvaa vain siksi, että käytät tekoälyn tuottamaa koodia. Jos näin käy, validointiprosesseja on vahvistettava.

Seuraan tuotantoympäristön virheitä tarkasti, erityisesti tekoälyn käyttöönoton alkuvaiheessa.

Olen havainnut, että tekoälyyn liittyvät virheet johtuvat yleensä vaatimusten väärinymmärryksestä eivätkä varsinaisista koodausvirheistä – tekoäly kirjoittaa syntaktisesti oikeaa koodia, joka ratkaisee väärän ongelman.

Kun tarkastelet kaikkia näitä mittareita yhdessä

Näin voit hyödyntää näitä mittareita käytännössä:

Ala seurata niitä ennen kuin otat tekoälyn käyttöön. Muodosta lähtötaso. Seuraa sitten, miten ne muuttuvat, kun otat tekoälytyökaluja käyttöön. Etsi toistuvia ilmiöitä:

Menevätkö yksinkertaiset muutokset läpi nopeammin, kun taas monimutkaiset vievät saman verran aikaa?
Löydättekö enemmän ongelmia testauksessa tuotantoympäristön sijaan?
Käyttääkö tiimisi vähemmän aikaa toისტuvaan peruskoodiin ja enemmän arkkitehtuuriin?

Muistatko GitHubin suuren väitteen 55 % nopeammasta kehityksestä? Todellisuudessa saatat nähdä maltillisia parannuksia joillakin alueilla ja et lainkaan toisilla. Se on ihan hyvä. Tavoitteesi on tasainen, kestävä parantuminen – ei mullistava muutos.

Mittarit eivät valehtele. Jos läpimenoaikasi lyhenee eikä epäonnistumisasteesi kasva, teet jotain oikein. Jos molemmat kehittyvät huonompaan suuntaan, ota askel taaksepäin ja tarkista prosessisi.

Tehdään yhteenveto

Kun olemme käyneet läpi tekoälyohjatun kehityksen käytännön näkökulmat, sanon tämän suoraan: tekoäly ei mullista ohjelmistokehitystä yhdessä yössä.

Olen oppinut eri organisaatioissa toteutetuista käyttöönotosta, että tekoäly toimii parhaiten, kun sitä pidetään yhtenä työkaluna kehitystyökalupakissa – joskin erittäin tehokkaana sellaisena.

Tekoälyn todellinen arvo ohjelmistokehityksessä ei ole kehittäjien korvaamisessa eikä edes koodin kirjoittamisessa nopeammin. Kyse on siitä, mihin käytämme aikaamme. Sen sijaan, että kamppailisit toistuvan peruskoodin kanssa tai etsisit tietoa API-dokumentaatiosta, voit keskittyä ohjelmistokehityksen haastavimpiin osa-alueisiin:

Käyttäjien tarpeiden ymmärtämiseen
Kestävien arkkitehtuurien suunnitteluun
Monimutkaisen liiketoimintalogiikan käsittelyyn

Muistatko alussa mainitsemani esimerkin – GE Healthcaren projektin?

Kaikista maailman tekoälytyökaluista huolimatta et muuta kolmen vuoden lääkinnällisen laitteen kehityssykliä kolmen kuukauden sprintiksi. Voit kuitenkin tehdä noista kolmesta vuodesta tuottavampia antamalla tekoälyn hoitaa rutiinitehtävät, kun tiimisi keskittyy monimutkaisiin haasteisiin, jotka vaativat ihmisen näkemystä.

Jos harkitset tekoälyn käyttöönottoa kehitysprosessissasi, aloita kuvaamistani perusteista. *

Varmista, että CI/CD-putkesi on kunnossa
Varmista, että testauksesi on kattavaa
Ymmärrä tiimisi rakenne

Ota sitten tekoälytyökaluja vähitellen käyttöön siellä, missä ne sopivat omaan tilanteeseesi.

Ennen kaikkea seuraa edelleen näitä neljää keskeistä mittaria. Ne kertovat, parantaako tekoäly todella kehitysprosessiasi vai tuoko se vain lisää monimutkaisuutta.

Ohjelmistokehityksen tulevaisuudessa tekoäly ei korvaa kehittäjiä. Kyse on siitä, että kehittäjät, jotka osaavat hyödyntää tekoälytyökaluja tehokkaasti, pärjäävät paremmin kuin ne, jotka eivät osaa. Varmista, että kuulut ensimmäiseen ryhmään.

Tämä blogi perustuu Markon puheenvuoroon Kööpenhaminassa järjestetyssä GOTO-konferenssissa vuonna 2023. Katso Markon puheenvuoro: