Jira-agentti

Jokaisella Jiraa käyttävällä tiimillä on työnsä jo kirjattuna yhteen paikkaan: mitä pitää tehdä, miksi, kuka sitä pyysi, mitä siitä on keskusteltu ja mihin se liittyy. Jira on projektin muisti ja ohjauspyörä. Kun tekoälyagentteja tuodaan yritykseen, Jira ei siksi ole vain yksi integraatio muiden joukossa. Se on luontevin paikka aloittaa.

Jira-agentti tuo tekoälyagentin juuri sinne. Kuka tahansa tiimistä kirjoittaa tehtävän kommenttiin @agent ja kysymyksen. “Työn alla” -merkintä ilmestyy heti, ja muutaman minuutin kuluttua sen tilalle tulee vastaus, joka perustuu todelliseen koodikantaan ja tehtävän omaan historiaan.

Haaste

Useimmat tekoälytyökalut vaativat siirtymään muualle: chat-ikkunaan, päätteeseen tai uuteen sovellukseen. Sen jälkeen konteksti pitää kopioida sinne käsin, ja vastaus pitää kopioida takaisin, ennen kuin kukaan muu näkee sen. Projekteja ohjaaville ihmisille, tuoteomistajille ja projektipäälliköille, juuri tähän hyöty yleensä loppuu.

Agentin ajaminen yrityksen koodilla herättää lisäksi kolme kysymystä ennen yhtäkään kehotteisiin liittyvää. Kuka saa kysyä? Mihin agentti saa koskea? Ja missä se ajetaan niin, ettei mukana ole kenenkään kannettavaa, henkilökohtaisia oikeuksia tai pitkäikäisiä salaisuuksia?

Näin se rakennettiin

Kolme pientä osaa, joilla kullakin on yksi tehtävä:

• Jira-sovellus. Se seuraa kommentteja, joissa agentti mainitaan. Se vastaa vain käyttöön otetuissa projekteissa ja vain hyväksytyn ryhmän jäsenille, muuten se pysyy hiljaa. Kun pyyntö läpäisee tarkistukset, sovellus kirjoittaa paikkamerkin ja välittää pyynnön eteenpäin yhdessä tehtävän kuvauksen ja viimeisimmän keskustelun kanssa.
• Oma CI-ympäristösi. Pyyntö käynnistää lyhyen ajon tuoreella GitHub Actions -ajajalla, koodin vieressä. Ajojen välillä ei säily mitään.
• Agentti. Se lukee koodia ja niihin liittyviä Jira-tehtäviä, seuraa niiden välisiä linkkejä ja kirjoittaa vastauksen, jossa viitataan tiedostoihin, committeihin ja tehtäviin. Vastaus palaa Jira-sovellukselle, joka korvaa sillä oman paikkamerkkinsä.

Ensimmäinen kokonainen kierros, Jira-kommentista vastaukseen samassa keskustelussa, toimi muutamassa päivässä. Rakennuspalikat ovat kypsiä: Atlassianin sovellusalusta, GitHub Actions ja Anthropicin Claude Agent SDK. Suurin osa työstä on sen päättämistä, mitä agentti saa tehdä, ei sen saamista tekemään asioita.

Turvallinen suunnittelultaan

Agentista on hyötyä vain, jos siihen voi luottaa. Jokaisella askeleella on yksi selvä omistaja:

• Kuka saa kysyä päätetään Jirassa: projekti ja kysyjän ryhmä tarkistetaan ennen kuin mitään muuta tapahtuu.
• Missä se ajetaan on oma CI-ympäristösi, joka kerta tuoreella koneella.
• Mitä se saa tehdä on lukea. Jokainen agentin toimenpide tarkistetaan ennen kuin se suoritetaan: se voi lukea koodia ja sallittuja Jira-projekteja, ja se ohittaa rajatut kommentit ja luottamukselliset tehtävät. Se ei voi ajaa komentoja eikä muuttaa mitään.
• Salaisuudet ovat kukin tasan yhdessä paikassa. GitHubilla ei koskaan ole avainta, jolla voisi kirjoittaa Jiraan, ja vastaus allekirjoitetaan, joten Jira-sovellus hyväksyy sen vain omasta ajostasi.

Agentin oikeuksien laajentaminen on aina tietoinen ja tarkastettu muutos lyhyeen listaan, ei koskaan sivuvaikutus.

Miksi ei vain Rovoa?

Atlassianilla on oma, Jiraan sisäänrakennettu tekoälynsä, Rovo. Jos se jo tekee sen, mitä tiimisi tarvitsee, se on yksinkertaisin valinta. Oma agentti kannattaa, kun työ menee tehtävää syvemmälle:

• Se toimii siellä, missä koodisi on. Agentti työskentelee omassa CI-ympäristössäsi, repositorion vieressä, sinun buildillasi, testeilläsi ja työkaluillasi. Juuri se mahdollistaa siirtymisen tehtävästä testattuun pull requestiin eikä vain yhteenvetoon.
• Omat mallisi, oma tilauksesi. Valitset mallin tehtävän mukaan, nopean ja edullisen rutiinihakuihin ja vahvemman sinne, missä tarvitaan harkintaa, ja maksat jo olemassa olevalla tekoälytilauksellasi etkä uudella käyttöperusteisella mittarilla.
• Omat sääntösi, kirjallisina. Se, mitä agentti saa lukea ja tehdä, on lyhyt lista omassa repositoriossasi. Se tarkastetaan kuten mikä tahansa muu muutos, ja jokainen toimenpide tarkistetaan sitä vasten.
• Omat ohjeesi, oma osaamisesi. Ohjeet, jotka tekevät agentista hyvän juuri teidän työssänne, ovat koodin vieressä ja paranevat jokaisen tarkastetun muutoksen myötä. Ne pysyvät teidän, käytittepä jatkossa mitä työkaluja tahansa.
• Mikä tahansa lähde, ei vain Atlassianin. Virheseuranta, sisäiset järjestelmät, dokumentaatio: kaikesta, millä on rajapinta, voi tulla agentille yksi lukutyökalu lisää.

Mitä tiimit voivat kysyä

Koska agentti on siellä, missä kysymykset jo ovat, hyödyllisimmät pyynnöt ovat arkisia:

• “Onko tämä jo toteutettu?” Tehtäviä tehdään usein niin, ettei kukaan linkitä työtä niihin. Agentti etsii sitä yhdistetystä historiasta ja vastaa pull requestilla ja koodilla.
• “Etsi liittyvät tehtävät.” Kaksoiskappaleet ja unohtuneet riippuvuudet listattuna, kullekin yhden rivin perustelu.
• “Mihin kohtaan koodia tämä muutos tulisi?” Lähtökohta arviointiin ja suunnitteluun, tiedostoviittauksineen.
• “Tiivistä tämä tehtävä ja sen linkit.” Nopea tilannekatsaus jokaiselle, joka tulee keskusteluun myöhässä.

Tehtävästä pull requestiin

Vastaukset ovat turvallinen ensimmäinen askel. Todellinen hyöty syntyy, kun agentti myös tekee työn. Pieneen, hyvin kuvattuun tehtävään tuoteomistaja kirjoittaa:

@agent fix this

ja loppu kulkee samaa reittiä kuin tiimin jokainen muutos jo nyt:

1. Agentti ottaa tehtävän. Se lukee kuvauksen, keskustelun ja linkitetyt tehtävät ja löytää oikean kohdan koodista.
2. Se tekee muutoksen omaan haaraansa, tuoreella CI-ajajalla, ei koskaan kenenkään koneella eikä koskaan suoraan päähaaraan.
3. Se ajaa projektin omat testit ja antaa tuloksen erilliselle tarkastaja-agentille, joka arvioi muutoksen näkemättä ensimmäisen agentin päättelyä.
4. Se avaa pull requestin, joka on linkitetty tehtävään, ja vastaa Jirassa linkillä ja lyhyellä yhteenvedolla siitä, mitä muuttui ja miksi.
5. Ihminen tarkastaa ja hyväksyy sen, täsmälleen kuten minkä tahansa muun pull requestin. Agentti voi ehdottaa, mutta vain ihmiset voivat yhdistää.
6. Nykyinen putkesi jatkaa siitä. Yhdistäminen käynnistää saman CI:n, joka jo nyt buildaa ja vie staging-ympäristöön, joten korjausta voi kokeilla siellä minuuteissa hyväksynnän jälkeen.

Mikään tässä ketjussa ei ole tiimille uutta. Jira pysyy paikkana, jossa työtä pyydetään, pull requestit pysyvät paikkana, jossa muutokset hyväksytään, ja julkaisuputki pysyy ennallaan. Agentti yksinkertaisesti täyttää aukon “jonkun pitäisi korjata tämä” ja “tässä on tarkastusvalmis muutos” välillä. Tehtävät, jotka olisivat odottaneet viikkoja jonkun tunnin työpanosta, saapuvat nyt pull requestina.

Samat turvasäännöt pätevät, laajennettuna täsmälleen yhdellä askeleella: tämä kulku saa kirjoittaa haaraan ja avata pull requestin, ei mitään muuta. Se ei voi yhdistää, julkaista eikä koskea päähaaraan.

Agentin opettaminen

Uudet pyyntötyypit opetetaan agentille kirjoitettuina ohjeina, selkokielisinä ohjeina koodin vieressä, joten tiimi parantaa agenttia samalla tavalla kuin mitä tahansa muuta: tarkastetulla muutoksella. Edullisemmat ja nopeammat mallit hoitavat rutiinihaut, ja vahvempaa mallia käytetään vain siellä, missä tarvitaan harkintaa.

Etkö käytä Jiraa?

Mikään tässä ei ole Jira-kohtaista. Ajatus on yksinkertainen: paikka, jossa tiimisi jo suunnittelee työnsä, on paikka, jossa agentilta kannattaa pyytää apua. Jira sattuu olemaan se paikka tälle tiimille.

Sama ratkaisu toimii Linearin, GitHub Issuesin, Azure Boardsin, GitLabin, Asanan tai minkä tahansa muun kanssa, joka osaa ilmoittaa toiselle järjestelmälle uudesta kommentista. Vain pieni osa, joka kuuntelee mainintoja ja kirjoittaa vastauksen, vaihtuu. Agentti, sen säännöt, sen ohjeet ja CI, jossa se ajetaan, pysyvät täsmälleen samoina.

Tulokset

Jira-sovellus, CI-ajo ja vain luku -agentti ovat käytössä, ja koko kierros toimii: maininta, paikkamerkki, agenttiajo, vastaus. Seuraavaksi tulevat ohjeet yllä mainittuihin pyyntöihin ja sen jälkeen tehtävästä pull requestiin -kulku: sama putki, jolla on oikeus kirjoittaa haaraan ja avata pull request ihmisten tarkastettavaksi.

Tarvitsetko jotain vastaavaa?

Mieti tätä: backlogissanne on satoja tehtäviä. Suurin osa niistä on vanhoja ja jää sinne ikuisiksi ajoiksi. Vain kriittiset tehtävät tulevat tehdyiksi. Tämä johtuu yksinkertaisesti siitä, että yksinkertaisenkin tehtävän tekemiseen voi kulua tunti. Yllä kuvatun kaltainen tekoälyautomaatio voi muuttaa tämän kaiken. Tiimisi voi delegoida yksinkertaisia tehtäviä tekoälyagenttien hoidettavaksi suoraan projektinhallintatyökalusta, kuten Jirasta. Eikä sinun tarvitse edes olla ohjelmoija tehdäksesi tämän. Kun agenttien käyttämät taidot on kirjoitettu hyvin, tekoälyagentit hoitavat yksityiskohdat, ja paras kehotteiden kirjoittaja on usein projektipäällikkö, joka ymmärtää hyväksymiskriteerit ja pysyy korkealla tasolla.

Ota meihin yhteyttä, kerro tilanteestasi, niin ehdotamme ratkaisun, joka säästää aikaa ja rahaa!