Teknologiavalinnoilla on merkittävä vaikutus ohjelmistokehitysprojektien onnistumiseen sekä projektin tuloksena syntyvän ohjelmiston kestävyyteen, käytettävyyteen ja kustannuksiin [1]. Projektin alussa määritellään usein siinä käytettävät pääteknologiat, joiden lisäksi projektin aikana tehdään valintoja yksittäisten käyttökohteiden ja ominaisuuksien mukaan. Käyn tässä blogissa läpi muutamia asioita, jotka tulisi huomioida eri teknologiavalinnoissa.
Alustat
Alustan valinnassa tärkeimpänä ovat ohjelmiston vaatimukset alustan ominaisuuksien suhteen. Monesti sovellukseen riittää yksinkertainen virtuaalipalvelin, eikä nopeaa skaalautuvuutta ja vahvaa integraatiota esimerkiksi pilvipalvelujen ekosysteemiin ja palveluihin tarvita. Tällöin sovelluksen ajaminen ja ylläpito on usein halvempaa ja yksinkertaisempaa. Lisäksi alustan vaihtaminen onnistuu myös tarvittaessa melko vaivattomasti. Pilvipalveluita saatetaan kuitenkin tarvita esimerkiksi tilanteissa, joissa automaattinen skaalautuvuus, lähes 100% saatavuus tai jokin muu tekninen vaatimus sitä edellyttää. Yrityksillä saattaa myös olla jo jokin pilvipalvelu valmiiksi käytössä muissa projekteissa, jolloin voi olla järkevää rakentaa uudet projektit samalle alustalle.
Tietoturvan ja yksityisyyden näkökulmasta palvelinten sijainti sekä palveluntarjoajan kotimaa ovat tärkeitä. Esimerkiksi yhdysvaltalaiset yritykset saattavat joutua käskystä luovuttamaan palvelimillaan olevia tietoja hallitukselle Cloud Act -asetuksen nojalla. [2]. Voikin olla hyödyllistä suosia Eurooppalaisia toimijoita kuten Hetzneriä tai kotimaisia toimijoita kuten UpCloudia tai Seclania, mikäli tietosuoja on keskeisenä vaatimuksena.
Kestävyyden näkökulmasta alustan energiankäyttö ja sen tuottamiseen käytettävät menetelmät on hyvä tunnistaa. Green Web Foundation ylläpitää rekisteriä eri alustojen ympäristövaikutuksista [3]. Lisäksi kannattaa suosia alustoja, jotka tarjoavat mahdollisimman kattavat ympäristövaikutusten seurannan työkalut.
AI
Yhä useammassa ohjelmistossa käytetään tekoälymalleja ratkaisuna johonkin toiminnallisuuteen. Vaikka kielimallit ovatkin trendikkäitä, eivät ne ole aina oikea ratkaisu ongelmiin. Ennen kielimallien käyttöä kannattaa arvoida niiden kyvykkyyksiä haluttuun tehtävään ja tehdä sen pohjalta päätös tulisiko niitä käyttää. Kielimalleja käytettäessä tulisi mallit ja tarjoajat valita siten, että tehtävään käytetään pienintä mahdollista mallia, joka suoriutuu tehtävästä halutulla varmuusasteella. Näin voidaan säästää kustannuksissa ja energiankulutuksessa sekä nopeuttaa mallin käyttöä. Tällaisia malleja voidaan myös ajaa helpommin omassa infrastruktuurissa tai käyttäjän päätelaitteella, jolloin mallitoimittajakohtaisilla hinnan tai saatavuuden vaihteluilla on pienempi vaikutus ohjelmiston toimivuuteen ja kustannuksiin.
Jossain sovelluksissa suurempien mallien ajaminen on kuitenkin tarpeen tai malleja ei jostain syystä haluta ajaa omassa infrastruktuurissa. Tällöin on hyödyllistä käyttää esimerkiksi openrouteria tai vastaavaa työkalua, jonka kautta voi tarvittaessa vaihtaa malleja tai käyttää useampia eri malleja eri käyttötarkoituksiin ilman muutoksia rajapintaan. Tällä voidaan myös välttää tiettyyn mallitoimittajaan syntyvä toimittajaloukku.
Yksityisyyden ja tietosuojan kannalta mallien toimittajiin pätevät samat huomiot kuin alustoihin eli malleja tarjoavan yrityksen sijainti on merkittävä tekijä. Tekoälymalleissa valitettavasti pääosa tarjoajista on joko Yhdysvalloista tai Kiinasta. Mistral lienee tunnetuin eurooppalainen tekoälymallien tarjoaja.
Ohjelmointikielet
Uusia ohjelmointikieliä julkaistaan jatkuvasti ja aiempiin tulee uusia ominaisuuksia ja parannuksia. Toisaalta teknologiat pysyvät usein pitkään käytössä ja uusien ohjelmointikielien käyttöön tuleminen on usein melko hidasta. Ohjelmointikieliä on myös moniin eri tarkoituksiin ja yksi kieli on harvoin paras ratkaisu kaikkiin ongelmiin.
Ohjelmointikielen valinnassa tärkeää olisi huomioida käytetyn alustan tuki ohjelmointikielelle. Esimerkiksi pilvialustojen tuki eri kielille on vaihtelevaa. Samoin eri laitteistolla voi olla vaihteleva tuki eri ohjemointikielille. Esimerkiksi sulautetuissa järjestelmissä parhaimpia vaihtoehtoja ovat yleensä matalan tason kielet kuten C, C++, Rust ja Zig.
Kielen tekniset ominaisuudet tulee myös ottaa huomioon. Vahva tyyppijärjestelmä ja virheenhallinta auttavat pitämään koodin laadun hyvänä ja hidastavat teknisen velan kerääntymistä projektin aikana. Tällaiset ohjelmointikielet ohjaavat käsittelemään monia mahdollisia virhetilanteita jo ennen kuin koodia voidaan ajaa. Virheiden löytyminen kehityksen aikana, eikä vasta loppuasiakkaalla olevasta tuotteesta onkin usein toivottavaa. Suorituskykyiset ohjelmointikielet saattavat myös vähentää suoraan ohjelman ajon kustannuksia ja energiankulutusta [4].
Kehitystiimin osaaminen on myös tärkeää huomioida. Vaikka monet kehittäjät pystyvätkin usein hyppäämään uuteen ohjelmointikieleen melko nopeasti, on hyvä varmistaa olisiko jokin jo osattu kieli hyvä ratkaisu ongelmaan. Tällöin kehittäjillä menee vähemmän aikaa totutella ohjelmointikielen käyttöön.
Ohjelmointikielillä on vaihtelevat kirjastoekosysteemit ja usein yksi merkittävä tekijä valinnassa on se, onko tarpeellisia ominaisuuksia mahdollisesti toteutettu jo valmiiksi. Tällä voi olla merkittävä vaikutus ohjelmistokehitysprosessin nopeuden kannalta, mutta valmiiden kirjastojen käyttö altistaa ohjelmiston helposti ns. supply chain -hyökkäykselle, jossa keskitettyyn kirjastohallintaan, esimerkiksi NPM:ään, ujutetaan haittaohjelmia sisältäviä paketteja. Ulkoisten kirjastojen käytössä kannattaakin selvittää, onko kirjasto aktiivisesti ylläpidetty ja miettiä, onko ominaisuus helpompi vain toteuttaa itse. Lisäksi on tärkeää tuoda kirjastojen automaattinen valvonta osaksi CI/CD-putkea.
Melko uutena ilmiönä on tekoälytyökalujen vaikutus teknologioiden valinnassa. Valintaan saattaa vaikuttaa tekoälymallien "osaaminen" tietystä ohjelmointikielestä eli se kuinka hyvin kyseisen kielen generointi onnistuu mallilla tai kuinka hyvin malli osaa vastata kielen käyttöön liittyviin kysymyksiin. Tässä on kuitenkin riskinä se, että käytetään teknisesti heikompaa ratkaisua, koska ei luoteta omiin tai tiimin taitoihin ottaa haltuun ongelmaan sopivampia teknologioita ilman merkittävää ulkoista avustusta. Nykyiset tekoälymallit ovat myös sen verran päteviä, että lähes minkä vain yleisessä käytössä olevan ohjelmointikielen generointi onnistuu riittävän hyvin.
Frameworkit
Erityisesti web-sovelluksissa on tyypillistä, että ohjelmisto rakennetaan jonkin frameworkin päälle, jossa suuri osa yleisistä toiminnoista on toteutettu valmiiksi. Frameworkit saattavat myös usein ohjata kehittäjiä toteuttamaan asioita tietyllä tavalla (ns. opinionated). Frameworkeja on erilaisia ja niitä on sekä frontendiin, palvelinpuolelle ja molempiin. Esimerkkejä TypeScript-kielen frameworkeista ovat esimerkiksi Express.js, Next.js ja SvelteKit.
Frameworkin valinnalla voi olla myös merkittävä vaikututus ohjelmiston suorituskyvyn kannalta vaikka käytössä oleva ohjelmointikieli pysyisikin samana ja suorituskyvyn huomiointi onkin tärkeä osa frameworkin valintaa.
Frameworkia valittaessa on hyvä huomioida soveltuvuus omaan käyttökohteeseesi, päivitystuki ja ominaisuudet. Jotkut vahvasti tiettyyn asiaan suuntautuneet frameworkit (opinionated) ovat yleensä sujuvia käyttää, mikäli oma käyttökohteesi on hyvin tuettu. On kuitenkin mahdollista joutua tilanteeseen, jossa framework ei tue haluamaasi toimintoa ja joudut tekemään vaikeita kiertoratkaisuja.
Ajoympäristöt
Joissain ohjelmointikielissä on mahdollista valita käytettävä ajoympäristö. Esimerkiksi JavaScript/TypeScript-ekosysteemissä on kolme yleisesti käytettyä ajoympäristöä: Node, Deno ja Bun. Näillä on omat hyvät ja huonot puolensa. Node on yleisimmin käytetty ja parhaiten tuettu, mutta se on usein hitaampi kuin Deno ja Bun. Deno keskittyy vahvasti turvallisuuteen vaatimalla, että iso osa toiminnallisuuksista, kuten tiedostojen luku otetaan erikseen käyttöön. Myös kolmannen osapuolen kirjastojen skriptien ajo on oletuksena estetty. Bun taas on uusin ja monilla mittareilla suorituskykyisin.
Ajoympäristön valintaan vaikuttavat ohjelmiston vaatimukset, yrityksen kehityskäytöntö- ja työkaluvaatimukset sekä käytetyn alustan tuki ajoympäristöille. On myös huomioitava, että jotkin kirjastot saattavat tukea vain tiettyä ajoympäristöä.
Tietokannat
Tietokannoissa SQL-pohjaiset tietokannat ovat hallitsevia ja ominaisuuksiltaan kattavimpia. Yleisimpiä SQL-tietokantoja ovat PostgreSQL ja MySQL ja nämä ovatkin hyviä valintoja useimpiin projekteihin pääasialliseksi tietokannaksi. SQLite on myös yleistynyt lähiaikoina yksinkertaisuutensa takia. Yleisesti SQLite on ollut suosittu lähinnä paikallisena päätelaitteella olevana tietokantana. Muita tietokantoja kannattaa harkita, mikäli ne ovat ominaisuuksiltaan sopivampia sovellukseen tai tiettyyn toiminnallisuuteen. Esimerkiksi Discord-viestintäalusta käyttää ScyllaDB-tietokantaa suurien viestimäärien tallentamiseen ja lukemiseen nopeasti [5].
Tekoälysovellusten myötä vektoritietokannat ovat myös yleistyneet osana ohjelmistoja. Vaikka sekä PostgreSQL että SQLite tarjoavat lisäosina vektorimahdollisuuden, voi olla hyödyllisempää ottaa käyttöön oma vektortietokanta näitä varten, sillä nämä lisäosat eivät ole ominaisuuksiltaan ja suorituskyvyltään tarkoitusta varten tehtyyn vektoritietokantaan verrattavissa [6]. Tämä on erityisen tärkeää, jos tekoälyn tiedonhaku on kriittinen osa ohjelmiston toimintaa.
AI-kehitystyökalut
Tekoälypohjaisten kehitystyökalujen käyttö on myös yleistynyt nopeasti, vaikka niiden todellinen vaikutus tuottavuuteen onkin vielä kyseenalaista [7] ja usein arviot tuottavuuden lisäämisestä perustuvat käyttäjäkyselyihin, jotka eivät välttämättä ole luotettava tapa mitata todellista tuottavuutta [8]. Työkaluilla voi tuottaa paljon sisältöä nopeasti, mikä vaikuttaa tehokkaalta, mutta lähemmässä tarkastelussa suuri osa sisällöstä saattaa olla ylimääräistä tai osin virheellistä. Tälläinen "höttösisältö" näkyy sekä generoidussa koodissa, että muussa sisällössä kuten dokumentaatiossa ja se tekee kehitysprojektin vetäjälle koodin katselmoinista kuormittavampaa ja enemmän aikaa vievää. Arvaamattomuus ja vaihteleva laatu ovatkin näiden työkalujen suurimpia heikkouksia yhdistettynä paikoitellen ylimitoitetun hypen luomaan epäselvyyteen työkalujen todellisista kyvykkyyksistä. Lisäksi työkaluissa on riskinä kehittäjän heikompi ymmärrys koodista ja järjestelmistä sekä omistajuuden puuttuminen eli koodi mielletään tekoälyn tuottamaksi, eikä sen toiminnasta oteta samanlaista vastuuta, kuin jos se olisi itse kirjoitettua.
On kuitenkin tapoja, joilla näiden työkalujen käytettävyyttä voidaan parantaa. Ensinnäkin työkaluissa käytetyt tekoälymallit ovat tärkeitä tuotoksen laadussa. Anthropicin Claude Opus- ja Claude Sonnet -mallit ovat edelleen parhaimpia koodin luonnissa. OpenAI:n GPT-codex-mallit ovat myös päteviä ja Google julkaisi myös juuri Gemini 3 -mallin, joka eri mittareilla vaikuttaa olevan lähes samalla tasolla edellä mainittujen kanssa [9]. Omalla laitteella ajettavista malleista Qwen3-coder-30b on hyvä laadun ja laitevaatimusten tasapainossa noin 18GB:n muistivaatimuksella kvantisoituna. Toisekseen kehitystiimissä pitää tiedostaa edellämainitut riskit ja huolehtia, että kehittäjät ottavat täyden vastuun tekoälyn tuotoksista eikä vastuun ulkoistamista tekoälylle sallita.
Kehityksessä tekoälytyökalut ovat parhaimmilaan prototyypeissä ja nopeatempoisessa ideoiden validoinnissa. Ne toimivat myös hyvin määriteltyihin ja eristettyihin ongelmiin. Luotettavuus ja laatu kärsivät kuitenkin koodikannan koon kasvaessa, joskin tätä ongelmaa voidaan vähentää muutamilla toimilla. Tekoälyn käytössä on hyödyllistä jos projektin rakenne ja dokumentaatio ovat jo valmiiksi johdonmukaista. Lisäksi tekoälylle tarkoitetun, koodin rakennetta ja käytänteitä dokumentoivan, "agents.md" tai vastaavan määrittelytiedoston olemassaolo on hyödyllistä. Tällöin tekoälymallien on helpompi rakentaa ominaisuuksia johdonmukaisesti aiemman rakenteen kanssa. Lisäksi mallin konteksti-ikkunan koko on merkittävä tekijä tuotoksen laadussa koodikannan koon kasvaessa, sillä muuten malli ei pysty käsittelemään koko koodikantaa kerralla ja "unohtaa" asioita. Tekoälytyökalujen käytössä suositeltavaa olisi käyttää sellaista työkalua, joka on toimittajariippumaton ja sallii eri mallien käytön helposti. Näin vältytään toimittajaloukulta, sillä tekoälytyökalujen ja mallien tarjoajat saattavat lyhyellä varoitusajalla nostella hintoja tai hidastaa mallien toimintaa. Opencode on yksi esimerkki työkalusta, joka täyttää edellä mainitut vaatimukset. Paikallisten mallien ajaminen taas onnistuu esimerkiksi Ollama- ja LM studio -työkaluilla.
Laadulliset työkalut
Useimmissa projekteissa on vähintään kaksi koodin laatua parantavaa työkalua käytössä: formatter ja linter. Formatter-työkalut yhtenäistävät koodin ulkonäköä erilaisilla säännöillä, jotta eri kehittäjien kirjoittama koodi näyttää yhdenmukaiselta ja mahdollisimman selkeältä. Linter-työkalut etsivät koodista yleisiä virheitä ja mahdollisia ongelmia sekä ehdottavat korjauksia niihin.
Kehitystökalut ovat tärkeitä sekä ohjelmistokehittäjän että tekoälymallien kannalta. Monet tekoälytyökalut, kuten aiemmin mainittu opencode mahdollistavat sen, että malli voi ajaa muita kehitystyökaluja ja saada näin tietoa ohjelmassa olevista virheistä ja tehdä muutoksia koodiin sen perusteella. Työkalujen tulisi olla mahdollisimman nopeita ja resurssitehokkaita, jotta iterointinopeus saadaan pidettyä mahdollisimman korkeana ja kehittäminen onnistuu matalampitehoisillakin laitteilla.
Uusia kehitystyökaluja julkaistaan ajoittain ja onkin hyödyllistä selvittää projektin alussa, onko käytettävissä uudempia työkaluja eikä automaattisesti ottaa aiemmissa projekteissa olleita käyttöön. Esimerkiksi Typescript-ekosysteemissä Biome on korvannut pitkälti Prettierin ja Eslintin omassa käytössäni. Se yhdistää molempien työkalujen ominaisuudet ja on vielä moninkertaisesti nopeampi ja vie vähemmän laiteresursseja. Samoin Pythonin kanssa Ruff ja uv ovat itselläni korvanneet Black, flake8, isort ja pip työkalut samasta syystä. Paremmat kehitystyökalut nopeuttavat kehittäjän lisäksi myös CI/CD-putkessa tapahtuvaa automaattista laadunvalvontaa.
Testaustyökalut
Testaus on tärkeässä osassa ohjelmiston laadunvarmistuksessa. Monien ohjelmointikielien omat työkalut sisältävätkin nykyään jonkinlaisen testaustoiminnallisuuden ja se onkin usein hyvä ottaa alussa käyttöön. Voi kuitenkin olla hyödyllistä ottaa käyttöön kolmannen osapuolen testaustyökaluja, sillä ne saattavat olla kehittyneempiä ja sisältää hyödyllisiä ominaisuuksia kuten testikattavuuden seurannan ja testiraporttien näyttämisen.
Lähteet
[1] T. Rinne, "Adapting Sustainable Software Development Methods Into Agile Processes", UTUPub, 2024.
[2] Eurojust, "The CLOUD Act", https://www.eurojust.europa.eu/publication/cloud-act, 2022
[3] Green Web Foundation, "The Green Web Directory", https://app.greenweb.org/directory/, [Accessed Dec. 8, 2025]
[4] T. Salonen, "Green Coding and Energy Efficiency in REST APIs: Empirical Evaluation", UTUPub, 2025.
[5] B. Ingram, "How Discord Stores Trillions of Messages, "https://discord.com/blog/how-discord-stores-trillions-of-messages, 2023, [Accessed Dec. 8, 2025]
[6] A. Jacobs, "The Case Against pgvector", http://alex-jacobs.com/posts/the-case-against-pgvector/, 2025, [Accessed Dec. 8, 2025]
[7] N. Dunlap, "AI coding assistants increase developer output, but not company productivity", https://www.faros.ai/blog/ai-software-engineering, 2025, [Accessed Dec. 8, 2025]
[8] J. Becker, N. Rush, E. Barnes, D. Rein, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study, 2025, [Accessed Dec. 8, 2025]
[9] Google, https://storage.googleapis.com/deepmind-media/Model-Cards/Gemini-3-Pro-Model-Card.pdf, 2025
