Jos haluat tehdä jotain kunnolla, tee se itse. Tekoälyn avulla.

Jos yrityksesi verkkosivusto on hidas, hankala päivittää tai jokainen pienikin muutos vaatii kehittäjän apua, ongelma ei ole pelkästään tekninen. Se hidastaa myös ideoiden jakamista, palveluista kertomista ja asiakkaille vastaamista.

Monien muiden pienten ja keskisuurten yritysten tavoin ulkoistimme verkkosivustomme kehityksen ja ylläpidon. Lopulta hitaat sivut ja viikkoja tai kuukausia kestävät päivitykset saivat minut ottamaan uudistuksen omiin käsiini.

Tässä artikkelissa kerromme oman yrityssivustomme kautta kokemuksistamme pienen yrityksen verkkosivuston uudistamisesta tekoälyn avulla: mitä muutimme, mikä nopeutui ja missä ihmisen ohjausta tarvittiin edelleen. Käytin kehitykseen ja katselmointiin noin 60 tuntia hyödyntäen Codexia, Next.js:ää, Payload CMS:ää ja suunnittelijamme Figmassa tekemää työtä.

Ongelma ei ollut vain verkkosivusto

Olin sietänyt verkkosivustomme teknisiä ja toiminnallisia ongelmia noin vuoden ajan.

Suurempi ongelma oli kuitenkin se, miten vaikeaa osaamistamme ja ideoitamme oli välittää suoraan mahdollisille asiakkaille.

Yrittäjänä ja yrityksen perustajana keskustelen säännöllisesti asiakkaiden kanssa, selvitän heidän tarpeitaan, seuraan Salesforcen ja CRM:n kehityssuuntia ja vaihdan teknisiä ajatuksia kehittäjiemme kanssa.

Saatamme esimerkiksi keskustella sisäisesti Salesforce Data 360:stä, sen arkkitehtuurista tai mahdollisista käyttötapauksista ja löytää kiinnostavia teknisiä näkökulmia.

Asia, jonka kehittäjä olisi voinut jakaa suoraan, piti kierrättää usean ihmisen kautta ennen julkaisua.

Osa ongelmaa oli se, ettemme panostaneet sivustoomme kovin paljon. Sen ylläpidosta ja päivityksistä vastasi osa-aikainen freelancer, mutta järjestely ei toiminut.

Silloin aloin miettiä tuttua sanontaa:

Jos haluat tehdä jotain kunnolla, tee se itse.

Mielestäni sanonta sopii erityisen hyvin suoraan asiakasyhteyteen perustuvaan toimintatapaan.

Unohdamme nimittäin usein, kuinka paljon vaiheita, ihmisiä ja prosesseja on asiakkaiden ja varsinaisen työn tekijöiden välissä.

Kuinka monen välivaiheen kautta asiakkaan ongelma kulkee ennen kuin se saavuttaa kehittäjän? Entä kuinka monen lisävaiheen kautta kehittäjän tieto tai ratkaisu päätyy takaisin asiakkaalle?

Jokainen ylimääräinen vaihe kasvattaa etäisyyttä ongelmia kokevien ja niitä ratkaisevien ihmisten välillä.

Uskon, että juuri tekoäly voi auttaa lyhentämään tätä etäisyyttä.

Ei korvaamalla kehittäjiä, asiakasvastaavia tai muita asiantuntijoita, vaan poistamalla tarpeettomia välivaiheita ja rutiinityötä.

Näin palveluja toteuttavat ihmiset voivat työskennellä lähempänä asiakkaita, ymmärtää heidän tarpeensa ja ongelmansa suoraan ja vastata niihin ilman monikerroksista viestintäketjua.

Tekoälyn pitäisi tuoda toteutus lähemmäs asiakasta, ei luoda heidän väliinsä uutta kerrosta.

Juuri tähän halusin päästä verkkosivustomme kanssa.

Vastuu omiin käsiin PHP:stä huolimatta

Päätin sivuuttaa aiemmat ajatukseni mikromanageerauksesta ja ottaa sivuston itse vastuulleni.

Siinä oli vain yksi ongelma.

PHP ei ollut juuri kuulunut aiempaan ohjelmistokehittäjän työhöni.

Olen aina yrittänyt välttää sitä mahdollisimman paljon. Minulle se on melkein harhaoppia tai jumalanpilkkaa. Omasta mielestäni se ei ole edes ohjelmointikieli.

Toki liioittelen. Moni rakastaa PHP:tä, ja sitä käytetään laajasti verkkosivustoissa.

Mutta taidan vain olla liian nuori PHP-ongelmiin. Verkkokehityksessä sydämeni on aina sykkinyt enemmän Node.js:lle tai .NET-teknologioille.

Päätin silti katsoa, mitä meillä oli.

Ensimmäinen yritys: korjataan nykyinen sivusto

Aloitin sivuston uudistamisen 1. lokakuuta 2026.

Ensimmäinen ajatukseni oli suoraviivainen: siistitään nykyinen sivusto, refaktoroidaan koodipohja, poistetaan tarpeeton toisto ja parannetaan suorituskykyä.

En kuitenkaan pystyisi tuottamaan valtavasti koodia lyhyessä ajassa, joten päätin käyttää Codexia.

Kävin PHP-koodin läpi ja huomasin, että lähes jokaisessa sivupohjassa oli huomattavan paljon päällekkäistä koodia.

Eri ihmiset olivat toteuttaneet samankaltaisia osioita erilaisin menetelmin ja eri näkemyksin siitä, miten asioiden pitäisi toimia.

Sama ongelma näkyi ulkoasussa. Samaan tarkoitukseen tehdyt komponentit näyttivät eri sivuilla erilaisilta, ja värit, reunukset sekä elementtien väliset etäisyydet vaihtelivat.

Päätimme suunnittelijamme kanssa yhtenäistää sivuston tyylit ja komponentit. Ensin halusin kuitenkin saada nykyisen koodipohjan kohtuulliseen kuntoon.

Codexin avulla pystyin erottamaan uudelleenkäytettäviä komponentteja, poistamaan sivujen välistä päällekkäisyyttä, pienentämään koodipohjaa ja parantamaan suorituskykyä.

Kiinnostavaa oli, että kehotteet olivat varsin yksinkertaisia.

Esimerkiksi:

Ota tämä osio, [anna renderöidyn HTML-sivun osion tunniste], korvaa se ja erota siitä uudelleenkäytettävä komponentti. Tarkista sivuston kaikki muut sivut ja korvaa vastaavat toteutukset uudella. Poista lopuksi kaikki vanha ja käyttämätön koodi ja tarkista työsi.

Siinä se käytännössä oli.

Matkan varrella löysin paljon muitakin ongelmia.

Esimerkiksi jotkin navigointivalikon kuvakkeet näytettiin 32 pikselin kokoisina, mutta niiden kuvatiedostot olivat noin yhden megatavun kokoisia.

Kuvittele lataavasi megatavun kuvan vain pienen navigointikuvakkeen näyttämistä varten.

Pyysin siis Codexilta:

Ota [kuva], analysoi se, suurenna tarvittaessa ja muunna WebP-muotoon. Optimoi se sivun latausnopeutta varten, muuta se todelliseen näyttökokoon (esimerkiksi 32 × 32 pikseliä) ja pienennä tiedostokokoa mahdollisimman paljon tinkimättä visuaalisesta laadusta.

Toistimme tämän eri puolilla sivustoa: korvasimme tarpeettoman suuret kuvat ja siistimme koodipohjaa.

Ja se toimi.

Se oli varsin vaikuttavaa.

Työskentelin tämän ensimmäisen vaiheen parissa 1.–10. lokakuuta noin neljä tuntia työpäivässä, viikonloput pois lukien.

Käytin siis noin 28 tuntia PHP-koodipohjan siistimiseen ja nykyisen WordPress-sivustomme optimointiin.

Tässä vaiheessa luulin teknisten muutosten olevan valmiit.

Tarvitsimme enää suunnittelijaltamme viimeistellyn uuden ilmeen, ja voisimme jatkaa eteenpäin.

Pidin siis tauon aktiivisesta kehityksestä.

Tilanne kuitenkin paheni odottamatta.

14. lokakuuta: sivusto lakkasi toimimasta

En työskennellyt aktiivisesti sivuston parissa 10.–14. lokakuuta, mutta seurasin palvelimen mittareita silloin tällöin.

Aluksi ajattelin, että syynä saattoivat olla äskettäin tekemäni muutokset.

Aloin tutkia asiaa ja käytin myös ChatGPT:tä nykyisen sivuston ja palvelimen asetusten selvittämiseen.

Selvityksen perusteella ongelma ei vaikuttanut johtuvan koodimuutoksistani.

Sivustomme toimi palvelimella, jossa oli 2 Gt RAM-muistia ja kaksi suoritinta. Olisin odottanut sen riittävän sivustollemme.

En tarkoita, että GTranslate olisi huono tuote.

Ongelma oli luultavasti usean infrastruktuuriimme liittyvän tekijän yhteisvaikutus. Lisäosa edellytti meiltä aktiivista ylläpitoa ja säätämistä, jotta kaikki toimisi oikein.

Tiimimme oli päivittänyt sallittujen IP-osoitteiden luetteloita, säätänyt verkkoasetuksia ja tehnyt muita väliaikaisia korjauksia.

Ne eivät kuitenkaan ratkaisseet ongelmaa pitkällä aikavälillä.

Rehellisesti sanottuna en halunnut enää ylläpitää infrastruktuuria käännöslisäosan ympärillä.

Jossain vaiheessa se alkoi ärsyttää niin paljon, että taisin saada jonkinlaisen psykoosin ja päätin rakentaa koko sivuston uudelleen alusta.

Sen sijaan, että korjaisin taas yhden WordPress-lisäosan, päätin korvata itse WordPressin.

Ja samalla PHP:n.

Uudelleenrakennus Node.js:n, Next.js:n, Reactin ja Payload CMS:n avulla

Aloitin siis sivuston uudelleenrakentamisen 14. lokakuuta.

Halusin vähentää riippuvuutta lisäosista ja rakentaa yhtenäisen alustan, jossa olisi sisällönhallinta, integroidut käännökset ja hallittavissani oleva rakenne.

JavaScript ja Node.js ovat minulle tuttuja, ja olin aiemmin toteuttanut niillä useita projekteja.

Miksi Payload CMS?

Koska se rakentuu Next.js:n ympärille, ja Next.js vaikutti minusta varsin hyvältä vaihtoehdolta.

Halusin ratkaisun, jossa voisin käyttää tuttua teknologiapinoa sen sijaan, että ottaisin käyttöön taas uuden joukon työkaluja ja riippuvuuksia.

Payload ja Next.js antoivat myös järkevän arkkitehtuuripohjan, joten kaikkea ei tarvinnut keksiä alusta.

Ja kyllä, teki mieli vain sanoa agentille:

Kirjoita koko WordPress-sivusto uudelleen haluamallani Node.js-, Next.js-, React- ja Payload CMS -teknologiapinolla. Tee se oikein ja kunnolla, tarkista kaikki, käytä aliagentteja äläkä häiritse minua.

Minun oli kuitenkin edettävä toista kautta.

Ensimmäinen alfaversio oli käytännössä suora siirto tietokantaa lukuun ottamatta.

Lisäsimme useita uusia tietokokonaisuuksia ja järjestimme sisällönhallinnan uudelleen. Halusin CMS:n käyttökokemuksen muistuttavan enemmän Pipedrivea tai HubSpotia: navigointi vasemmalla ja sisältö oikealla.

Nykyisen sivuston siirtäminen

On tärkeää mainita, ettemme rakentaneet koko sivustoa tyhjästä.

Meillä oli jo sisältöä, sivurakenteita, suunnitteluideoita ja vuosien työ takana.

Tämä on itse asiassa luultavasti sivustomme neljäs suuri versio.

Aloitimme vuonna 2019 Flaton-nimisellä WordPress-teemalla. Meillä oli silloin jopa eri logo.

Myöhemmin kehitimme oman teemamme, päivitimme sitä ja jatkoimme käyttöliittymän parantamista.

Suunnittelijamme oli myös työskennellyt uusimman design-järjestelmän parissa jo ennen tämän siirron alkua.

Kyse oli siis olemassa olevan sivuston täydellisestä teknisestä siirrosta ja uudelleenjärjestelystä, ei kokonaan uuden tuotteen rakentamisesta tyhjästä.

Sisällön siirtoa varten poimimme kaiken WordPressistä ja käytimme tekoälyagenttia kohdistamaan sen uuteen Payload CMS:n tietokantamalliin.

Agentti auttoi muokkaamaan sisällön uuteen rakenteeseen sopivaksi sen sijaan, että kaikki olisi vain kopioitu toiseen tietokantaan.

Käytimme agentteja myös uuden sivuston käyttöönottoon, PHP-toteutuksesta siirtymiseen sekä vanhojen PHP-tiedostojen ja asetusten siivoamiseen palvelimelta.

Oliko tämä elegantein tapa?

Luultavasti ei.

Meille se oli kuitenkin nopein tapa saada kaikki siirrettyä ja toimintaan.

Uudelleenkirjoituksessa rikkoutuneiden asioiden korjaaminen

Kun ensimmäinen uudelleenkirjoitus oli valmis, edessäni oli käytännössä sama sivusto muutamin pienin eroin.

Sitten aloin korjata virheitä.

Jossain liukusäädin ei enää toiminut. Jossain sivun rakenne oli siirtynyt paikaltaan. Jotkin komponentit eivät käyttäytyneet aivan kuten ennen.

Näitä ongelmia korjatessani huomasin, ettei kaikkia komponentteja ollut korvattu kunnolla.

Joissain sivupohjissa oli edelleen raakaa HTML:ää, kun taas toisiin oli tehty uusia komponentteja, jotka muistuttivat hieman jo olemassa olevia uudelleenkäytettäviä komponenttejamme.

Aloin siis tunnistaa ja luetteloida näitä kohtia sekä korjata niitä yksi kerrallaan.

Kehote oli suunnilleen tällainen:

Hei, tässä on osio [anna osion nimi tai tunniste]. Korvaa se olemassa olevalla uudelleenkäytettävällä komponentilla [anna komponentin nimi]. Säilytä sama tai vastaava semantiikka ja toiminta, poista vanha toteutus ja siivoa käyttämätön koodi.

Jatkoin vanhojen toteutusten korvaamista, palvelinpuolen renderöinnin parantamista, välimuistin käyttöönottoa ja komponenttien optimointia.

Käytin tähän toiseen vaiheeseen 14.–23. lokakuuta noin neljä tuntia työpäivässä, yhteensä noin 32 tuntia.

Yksi agentti toteuttaa, toinen tarkistaa ja ihminen päättää

Kiinnostavaa oli myös se, miten järjestin kehityksen ja käyttöönoton.

En käyttänyt vain yhtä agenttia tekemään kaikkea.

Käytin useita agentteja eri tehtäviin ja loin uudelleenkäytettäviä ohjekokonaisuuksia (skills) sivuston käyttöönottoa varten.

Nämä ohjekokonaisuudet sisälsivät ohjeet käytettävistä käyttöönottoskripteistä, ajettavista testeistä ja prosessin eri vaiheiden käsittelystä.

Kehityksen aikana agentit loivat myös työkaluja ja skriptejä sivuston testaamiseen ja käyttöönottoon.

Sen sijaan, että selittäisin koko käyttöönottoprosessin joka kerta, pystyin käyttämään samoja ohjeita ja toimintatapoja uudelleen.

Tarkistamisessa tukeuduin vahvasti Gitiin seuratakseni muutoksia ja nähdäkseni, mitä koodipohjassa oikeasti tapahtui.

Git-muutosvertailujen ja tiedostokohtaisen katselmoinnin avulla tunnistin päällekkäistä koodia, toistuvia malleja, tarpeettomia haaroja ja monimutkaisia if-else-rakenteita.

Aina kun huomasin jotain tällaista, pyysin agenttia korjaamaan sen.

Payload CMS ja Next.js määrittivät pitkälti arkkitehtuurin, joten halusin agenttien noudattavan näiden kehysten vakiintuneita käytäntöjä kokonaan uuden arkkitehtuurin keksimisen sijaan.

Annoin myös erillisille agenteille tehtäväksi tarkistaa toteutuksen.

Prosessi oli varsin suoraviivainen:

Yksi agentti toteuttaa, toinen tarkistaa ja ihminen päättää, mikä on oikein ja mikä väärin.

Ja ihminen tarkastelee varsinaista sivustoa, ei pelkkää koodia.

Tarkistin käyttöliittymää käsin, katsoin sivujen renderöintiä, testasin komponentteja ja etsin visuaalisia ongelmia, jotka eivät välttämättä näkyneet pelkästä koodista.

Toimin tässä kehittäjänä, koodin katselmoijana, manuaalisena testaajana ja laadunvarmistajana.

Noin 30 % ajastani kului koodin katselmointiin, toteutusten tarkistamiseen ja tulosten varmistamiseen.

Lisäsin myös agenttien tekemiä tarkistuksia ennen käyttöönottoa, jotta jäljellä olevat ongelmat löytyisivät ja toistuvien muokkauskierrosten jäljiltä jäänyt koodi siistiytyisi.

Tekoäly nimittäin tuottaa valtavasti koodia.

Jos kukaan ei kiinnitä huomiota sen tuottamaan koodiin, vanha tekninen velka voi helposti vain vaihtua uudeksi.

Sivuston kääntäminen tekoälyagenttien avulla

Toinen tärkeä osa toteutusta olivat käännökset.

Aiemmin käytimme GTranslatea sisällön reaaliaikaiseen kääntämiseen.

Tällä kertaa halusin hoitaa käännökset suoraan omalla alustallamme.

Käytimme tekoälyagenttia kääntämään englanninkielisen sisältömme sivuston kaikille muille kielille.

Kehote oli seuraava:

Käännät sisältöä englannista kielelle [kohdekieli].

Analysoi sisällön englanninkielinen versio ja tunnista brändien nimet, teknologiakohtaiset termit, tuotenimet ja muut erisnimet.

Varmista ennen kääntämistä, että ymmärrät sisällön alkuperäisen tarkoituksen ja täsmällisen merkityksen. Säilytä käännöksessä alkuperäinen merkitys ja tarkoitus mahdollisimman tarkasti ja noudata kohdekielen kielioppia ja luontevaa ilmaisutapaa. Kohdekieli: [kohdekieli].

Säilytä brändien nimet, tuotenimet ja teknologiakohtainen terminologia tarvittaessa.

Tarkista käännöksesi lopuksi ja varmista, että merkitys on säilynyt, kieli kuulostaa luontevalta eikä mitään sisältöä ole jäänyt pois.

Käännä kaikki sisältö, myös artikkelin otsikko, väliotsikot, leipäteksti ja kaikki siihen liittyvät metatiedot.

Tavoitteena ei ollut vain kääntää sanoja. Halusin sisällön noudattavan kohdekielen käytäntöjä ja kuulostavan paikallisille lukijoille luontevalta.

Pidimme myös brändikohtaiset tiedot erillään käännettävästä sisällöstä, jotta yritysten nimet, tuotenimet ja muut tärkeät termit eivät kääntyisi väärin.

Nyt voimme hallita käännöksiä suoraan CMS:ssämme ilman lisäosaa, joka kääntää kaiken reaaliajassa.

Tekoälykäännökset eivät tietenkään ole täydellisiä, varsinkaan Salesforcea, CRM:ää ja ohjelmistokehitystä käsittelevässä teknisessä sisällössä.

Jos siis vierailette sivustollamme omalla kielellänne ja huomaatte epäluontevaa, huonosti kirjoitettua tai epäselvää tekstiä, lähettäkää minulle yksityisviesti.

Korjaan asian.

Kun Figma, Codex ja GPT-6 kohtasivat

Sillä välin suunnittelijamme sai uuden design-järjestelmän valmiiksi Figmassa. Tässä kohtaa asiat alkoivat muuttua kiinnostaviksi.

Figma tukee MCP-integraatiota, ja käytämme jo OpenAI:ta Salesforcen ja muiden alustojen kanssa. Yhdistin siis Figman OpenAI-tiliini.

Näin pystyin ottamaan linkin Figman solmuun, oli se sitten painike, osio tai muu komponentti, ja antamaan sen GPT-6:ta käyttävälle Codexille. Codex otti suunnitelman ja toteutti sen suoraan sivustollemme.

Aiemman komponenttien erottelutyön ansiosta se pystyi soveltamaan uutta design-järjestelmää eri sivuille sen sijaan, että samat muutokset olisi toteutettu erikseen joka paikassa. Sen sijaan, että kirjoittaisin CSS:n käsin ja säätäisin jokaisen sisämarginaalin, kulman pyöristyksen ja komponentin asettelun, pystyin hyödyntämään suunnittelijan Figma-työtä ja toteuttamaan sen koodipohjassa.

Täysin automaattista se ei tietenkään ollut. Minun piti edelleen tarkistaa koodi, HTML-rakenne, komponenttien toiminta ja kohdat, joissa OpenAI oli saattanut oikaista tai ymmärtää vaatimukset väärin.

Kukin komponentti vaati keskimäärin noin kaksi kierrosta.

Juuri siihen keskityin eniten.

Mitä oikeasti saavutimme

Uuden Node.js-toteutuksen, välimuistin, palvelinpuolen renderöinnin ja muiden optimointien ansiosta sivut latautuvat nyt keskimäärin alle sekunnissa. Ennen uudistusta aikaa kului noin viisi tai kuusi sekuntia.

Tarkastelimme selaimen suorituskykymittareita, kuten sivun renderöintiä, Largest Contentful Paint -mittaria ja asettelun siirtymiä. Semrush-auditoinneilla arvioimme sivuston teknistä kuntoa, indeksointirobottien pääsyä sisältöön, navigointia ja muita teknisiä asioita.

Arvioin suorituskykyä myös paljon yksinkertaisemmalla tavalla.

Vanhalla sivustolla näin viiveet itse sekä mobiilissa että tietokoneella. Sivujen lataaminen kesti, eikä käyttökokemus ollut erityisen miellyttävä.

Uudessa toteutuksessa eron huomasi heti.

Sivusto vain tuntuu selvästi nopeammalta.

Silmin havaittava nopeus ei tietenkään korvaa teknisiä mittauksia. Minulle se oli silti tärkeä merkki, koska juuri tämän todelliset kävijät kokevat.

Toinen tärkeä parannus koski teknisten ongelmien määrää.

Syys–lokakuun tienoilla Semrush raportoi noin 2 000 ongelmaa, ja määrä oli enimmillään lähes 3 000.

Nyt ongelmia on noin 400. Niistä noin 200 liittyy Cloudflaren sähköpostisuojausmekanismiin, jonka linkit raportoidaan rikkinäisinä sisäisinä linkkeinä.

Parannettavaa on edelleen, mutta lähtötilanteeseen verrattuna ero on valtava.

Sivuston ylläpidosta suoraan asiakkaille suunnattuun sisältöön

Suorituskyky ei ollut ainoa parannus.

Saavutimme myös jotain luultavasti vielä tärkeämpää: paljon sujuvamman tavan luoda ja hallita sisältöä.

Aiemmin sivun muuttaminen edellytti, että joku päivitti sivupohjat käsin, muokkasi sisältöä ja hoiti teknisen työn.

Sen sijaan, että kierrättäisimme kokemuksemme usean ihmisen kautta verkkosisällöksi, voimme hoitaa suurimman osan rutiinityöstä alustamme avulla.

Kehittäjän ei tarvitse ryhtyä tekstisuunnittelijaksi. Asiakasvastaavan ei tarvitse ryhtyä kehittäjäksi. Eikä idean keksijän pitäisi joutua odottamaan kuukausia, että joku toteuttaa sen sivustolle.

Tämä ei tarkoita mitäänsanomattoman tekoälymassan tuottamista.

Otetaan esimerkiksi tämä artikkeli.

Sitä ei oikeastaan kirjoiteta käsin. Ideat ja ajatukset sanellaan, muutetaan tekstiksi ja viimeistellään.

Voimme sanoa esimerkiksi: ”Muotoile tämä uudelleen, tee tuosta kohdasta sujuvampi, poista turhat sanat ja käytä kohteliaampaa kieltä.”

Ideat, kokemukset ja kertomus ovat silti meidän.

Tekoäly auttaa muuttamaan ajatuksemme luettavaksi tekstiksi aivan kuten se auttoi muuttamaan suunnittelun ja tekniset vaatimukset oikeaksi koodiksi.

Juuri tällaisen työnkulun halusimme.

Sama toimintatapa sopii teknisiin artikkeleihin, asiakastarinoihin, palvelukuvauksiin ja muuhun sisältöön, jota haluamme jakaa.

Aiemmin tukeuduimme vahvasti tekstisuunnittelijoihin ja sivuston ylläpitäjiin, jotka muokkasivat teknisten asiantuntijoiden muutamasta sanasta kokonaisia artikkeleita.

Tekninen asiantuntija käyttää muutaman minuutin työnsä selittämiseen, ja tekstisuunnittelija muuttaa sen tuhansiksi sanoiksi.

Isoja, näyttäviä artikkeleita, joissa on paljon tekstiä, selityksiä ja melko usein myös runsaasti täytettä.

Varsinainen kehittäjä kuvaisi saman projektin luultavasti muutamalla lauseella:

”Joo, tehtiin se homma. Se oli helppoa. Kiinnostavaa. Ja hauskaa.”

Ehkä hän mainitsee siinä sivussa joitain liiketoimintahyötyjä. Tosin asiakasvastaavan pitäisi luultavasti osata selittää ne paljon paremmin.

Haluamme, että kehittäjämme kertovat lyhyesti, mikä toteutuksessa oli kiinnostavaa, mikä oli teknisesti haastavaa ja mistä oli hyötyä, ja palaavat sitten muiden kiinnostavien töiden pariin.

Sen sijaan, että he käyttäisivät tuntikausia kaiken kuvaamiseen ihmiselle, joka lopulta muuttaa sen artikkeliksi.

Tällaista rutiinityötä halusimme poistaa.

Tätä tarkoitan myös sillä, että toteutus tuodaan lähemmäs asiakasta.

Tekoäly voi auttaa poistamaan näiden ihmisten välistä rutiinityötä, jolloin tieto kulkee paljon suoremmin sitä omaavilta sitä tarvitseville.

Kehitystyö ja kustannukset

Tämä ei tietenkään tarkoita, että koko sivusto olisi rakennettu uudelleen 245 €:lla.

Summa ei sisällä omaa aikaani, suunnittelijamme työtä, infrastruktuuria eikä sivustoon vuosien aikana tehtyjä aiempia investointeja.

Olemme kehittäneet ja parantaneet sivustoamme vuodesta 2019: vaihtaneet teemoja, päivittäneet ulkoasua, luoneet sisältöä ja muokanneet rakennetta.

Viimeisimmässä siirrossa hyödynnettiin suuri osa tästä työstä.

Kiinnostavaa on kuitenkin se, kuinka paljon sain aikaan noin 60 tunnin omalla panoksellani käyttämällä tekoälyä kehitykseen, refaktorointiin, testaukseen, käyttöönottoon ja koodin katselmointiin.

Mikä muuttui käytännössä

Alla verrataan toteutukseen kulunutta kalenteriaikaa freelance-kehittäjän kanssa työskenneltäessä. Kyse ei ole projektibudjeteista eikä suoraan vertailukelpoisista työtuntimääristä.

Esimerkiksi yhden sivun tekemiseen saattoi kulua noin 40 tuntia kehitystyötä, joka jakautui usealle viikolle työn ja jatkuvien parannusten lomaan.

Arviot alkavat siitä, kun idea ja vaatimukset on määritelty. Ideointi ja vaatimusten määrittely ovat itsessään tärkeitä vaiheita, eikä niitä lasketa tähän mukaan.

Mitä seuraavaksi?

Tekninen perusta on nyt paikallaan.

Meillä on alusta, jota voimme ylläpitää muokkaamatta sivuston jokaista yksityiskohtaa käsin.

Voimme tietenkin halutessamme yhä muokata kaikkea suoraan. Nyt voimme kuitenkin vain sanoa sivustoa ylläpitävälle agentille:

Hei, lisää [artikkeli], käytä näitä kuvia: [kuvat], luo sisällöstä infografiikoita tai taulukoita ja julkaise se muodossa [asiakastarina tai blogiartikkeli].

Sama pätee nykyisten sivujen päivittämiseen.

Esimerkiksi:

Ota tämä sivu [anna URL-osoite tai sivun otsikko], etsi tämä osio [anna osion nimi, otsikko tai tunniste], päivitä se, vaihda kuva ja päivitä tai täydennä tekstiä ohjeideni perusteella. Varmista, että kaikki noudattaa nykyistä design-järjestelmäämme. Säilytä komponentin toiminnallisuus ja tarkista muutokset.

Haluammepa vaihtaa kuvan, täydentää palvelukuvausta, julkaista artikkelin tai päivittää kokonaisen osion, voimme kertoa tavoitteemme, tarkistaa tuloksen ja tarvittaessa tehdä korjauksia.

Näin säästyy tuntikausia rutiinityötä, ja ajan voi käyttää ideoiden kehittämiseen, asiakkaiden tarpeiden tutkimiseen ja hyödyllisen sisällön luomiseen.

Ja kyllä, tilanne on nyt huomattavasti parempi melkein joka näkökulmasta.

Infrastruktuuri on valmis. Alustaa on helppo ylläpitää. Kerro vain selkeästi, mitä tarvitset, ja agentti voi lisätä sen minuuteissa. Sisältöä on helpompi julkaista, ja hallitsemme sivuston toimintaa paljon paremmin.

Nyt voimme keskittyä ideoihin teknisten yksityiskohtien sijaan.

Tärkeämpi muutos liittyy kuitenkin siihen, miten voimme työskennellä asiakkaidemme kanssa.

Sen sijaan, että kehittäjien, asiakasvastaavien, markkinoinnin ja sivuston ylläpitäjien välillä olisi useita vaiheita ja prosesseja, voimme tehdä tiedonvaihdosta paljon suorempaa.

Asiakkaan ongelmat ymmärtävät ihmiset voivat jakaa osaamistaan, ja ratkaisuja rakentavat ihmiset voivat kuulla, mitä asiakkaat todella tarvitsevat.

Teknologian ei koskaan pitänyt olla ongelma, jonka ratkaisemiseen käytämme suurimman osan ajastamme.

Sen piti auttaa meitä viemään ideamme asiakkaiden ulottuville.

Ja nyt teknologia ei vihdoin enää ole riesa.