Arkkitehti ei muuraa tiiliä: AI-koodauksen jakaminen kalliiden ja halpojen mallien kesken

Julkaistu Jul 20, 2026, kirjoittanut Štefan Moravík.
AI Agents AI Development Claude Code Cost Optimization
Tällä sivulla 11 min lukuaika
  1. 1Osa 1 — Ansa ja periaate
  2. 2Miten fable-architect-kuvio toimii
  3. 3Mitä mittasimme
  4. 4Osa 2 — Kuitit
  5. 5Toinen kanava: issue-tracker delegointiväylänä
  6. 6Mitä laajempi data opetti meille
  7. 7Päivitys — tikapuut liikkuivat allamme
  8. 8Osa 3 — Mihin tässä tietoisesti mennään
  9. 9Mitä voit tehdä maanantaina

Muutama päivä sitten Anthropic teki Fablesta pysyvän osan Max-tilauksia. Ajoitus kertoo olennaisen: se tuli heti sen jälkeen, kun OpenAI julkaisi GPT-5.6 Solin, ja — vielä olennaisempaa — heti sen jälkeen, kun Kimi K3 pudotti painonsa. Tarvittiin avoimen lähdekoodin malli pakottamaan suurin AI-laboratorio kohtaamaan todellisuus ja lopettamaan lippulaivansa ympärillä pyörinyt markkinointikohu. Pelkästään se ansaitsee maljan jokaiselta, joka maksaa nämä laskut.

Mutta “sisältyy tilaukseesi” ei ole sama asia kuin “halpa”, eikä se todellakaan ole sama kuin “halpa ikuisesti”. Siksi, kun Fable oli vielä laskutettavaa, rakensimme työnkulkumme uudelleen niin, että kallis malli on mekaanisesti estetty kirjoittamasta koodia. Se ajattelee, suunnittelee ja katselmoi. Halvemmat mallit näppäilevät. Tämä postaus näyttää, miten se toimii ja mitä se oikeasti mittautui jokaisessa litteraatissa, joita meillä on — 606 todellista sessiota, jotka kattavat tuotannossa olevan SaaS-monorepon, droonien operointisovelluksen, markkinointisivuston ja niitä palvelevat CI-agentit.

Osa 1 — Ansa ja periaate

Tässä rehellinen lähtökohtamme: emme voi enää toimia ilman frontier-malleja. Kukaan tiimissä ei pystyisi ylläpitämään nykyistä tuotosta ilman niitä — ja juuri tuo riippuvuus on se vipu, joka suurilla laboratorioilla on hallussaan. Meidän luennassamme nykyiset AI-tilaukset tarjoavat selvästi enemmän laskentatehoa kuin mitä ne maksavat; ne ovat markkinaosuuden valtaushintoja, ja sellaiset hinnat loppuvat aikanaan. Kun ne loppuvat, se, joka on rakentanut insinöörikulttuurinsa “rajattomien frontier-tokenien” varaan, maksaa mitä pyydetään.

Puolustuskeinoja on kaksi. Ensimmäinen on uskottavan poistumistien säilyttäminen: avoimet mallit kuten DeepSeek ja Kimi ovat se, mikä pakotti tämän viikon hintakorjauksen, ja ne pysyvät vipuna vain, jos oikeasti pidämme työnkulkumme siirrettävinä niille. Toinen on työnkulun kurinalaisuus: käytä frontier-tokeneita vain siellä, missä mikään halvempi ei toimi. Tämä postaus käsittelee jälkimmäistä — koska sen voi aloittaa maanantaina.

Periaate on niin vanha, että sillä on rakennus nimettynä mukaansa: arkkitehti ei muuraa tiiliä. Frontier-mallin etumatka keskiluokan malliin on valtava suunnittelussa, pilkkomisessa ja katselmoinnissa — ja lähes nolla, kun kirjoitetaan uudelleennimeäminen neljänkymmenen tiedoston läpi. Jaa siis roolit. Hintatikapuut kertoo saman dollareina:

Tuotostokenien listahinnat miljoonaa tokenia kohden: Fable 50 dollaria, Opus 25, Sonnet 15, Haiku 5

Miten fable-architect-kuvio toimii

fable-architect-taito on noin 100 rivin markdown-tiedosto plus yksi shell-koukku, joka ladataan aina, kun Claude Code -sessio ajetaan frontier-mallilla. Se pakottaa työnjaon:

  • Arkkitehti tekee: kuulustelee vaatimusta, tutkii koodikantaa, tekee jokaisen suunnittelupäätöksen — lähestymistapa, tietovirta, nimet, allekirjoitukset, reunatapaukset — pilkkoo työn riippumattomiin osiin, katselmoi palautetut diffit, ajaa varmistukset ja kirjoittaa kaiken proosan (suunnitelmat, briefit, PR-tekstit, commit-viestit).
  • Arkkitehti ei koskaan tee: kirjoita tai muokkaa lähdetiedostoa. Ei koodia chattiin lukuun ottamatta lyhyitä allekirjoituksia briefissä.
Vuokaavio fable-architect-silmukasta: arkkitehti tutkii ja päättää, kirjoittaa yhden briefin per osa, toteuttaja-ala-agentit palauttavat diffit, arkkitehti katselmoi; vartiointikoukku estää arkkitehtia muokkaamasta koodia suoraan

Kolme asiaa tekevät tästä toimivaa käytännössä eikä vain diassa.

1. Briefi on rajapinta

Jokainen osa saa yhden toteutusbriefin. Toteuttaja aloittaa tuoreesta konteksti-ikkunasta — kaikki, mikä ei ole briefissä, on löydettävä uudelleen tai arvattava. Tämä rajoite on ominaisuus: se pakottaa arkkitehdin päättämään valmiiksi ennen delegointia. Briefi sisältää päätöksiä, ei vaihtoehtoja.

## Implementation brief: <slice>
Goal:         one sentence, observable outcome
Context:      what exploration already found — excerpts, the nearest
              pattern to mirror, line anchors, gotchas
Files:        paths to create/modify — this slice's exclusive ownership
Design:       the decided approach — data flow, names, signatures, edges
Constraints:  project rules that apply: style, layers, security
Out of scope: what not to touch, including files owned by other slices
Delegation:   may this slice spawn sub-implementers, and how many
Verify:       exact commands and expected outcome

Kaksi noista riveistä on uudempia kuin muut, ja ne ovat olemassa siksi, että toteuttajataso vaihtui allamme — katso päivitys alta.

2. Pakottaminen, ei fiilis

PreToolUse-vartiointikoukku tarkkailee sessiota: jos arkkitehti yrittää muokata muuta kuin proosatiedostoa, lupakysely laukeaa. Kyselyn hyväksyminen on dokumentoitu poikkeus triviaaleille muokkauksille (kirjoitusvirhe, versionumeron nosto — tapaukset, joissa delegoinnin ylimääräinen vaiva maksaa enemmän kuin näppäily). Kitka on politiikka. Ilman koukkua “kalliin mallin ei pitäisi koodata” kestää tasan ensimmäiseen määräaikaan asti.

3. Katselmointisilmukka sulkee laatuaukon

Arkkitehti lukee agentin raportin ja varsinaisen diffin — luottamatta kumpaankaan yksinään — ja ajaa keskeiset varmistuskomennot uudelleen, kun väitteellä on väliä. Löytyi ongelma? Korjaus menee takaisin samalle agentille, jolla on yhä koko työkontekstinsa. Ei käsin korjaamista, ei tuoretta uudelleensynnytystä.

Huomaa, että tämä on arkkitehdin varmistus, ja se pysyy. Sen sijaan olemme alkaneet poistaa varmistusta, jota ennen kirjoitimme briefeihin — ohjeita, jotka kehottivat toteuttajaa tarkistamaan itsensä. Uudemmat toteuttajamallit tekevät sen pyytämättä, ja niiden kehottaminen tekemään se uudelleen ostaa toisen kierroksen, josta olet jo maksanut.

FlowHunt Logo

Valmis kasvattamaan liiketoimintaasi?

Aloita ilmainen kokeilujakso tänään ja näe tulokset muutamassa päivässä.

Mitä mittasimme

Selvittääksemme, onko tämä todellinen taloudellinen mekanismi vai vain miellyttävä rituaali, kaivoimme läpi jokaisen Claude Code -litteraatin projekteissamme, poistimme API-pyyntöjen tuplakappaleet ja hinnoittelimme jokaisen tokenin nykyisillä listahinnoilla. Kolme hypoteesia, kirjattu ennen sessioiden lukujen katsomista:

  • H1 — Toteuttajat hoitavat näppäilyn. Jos totta, toteuttaja-ala-agenttien pitäisi tuottaa enemmän tuotostokeneita kuin arkkitehdin pääsilmukan delegoiduissa sessioissa.
  • H2 — Delegointi on halvempaa. Jos totta, toteuttajien työn uudelleenhinnoittelu arkkitehtimallin hinnoilla pitäisi tulla merkittävästi kalliimmaksi kuin mitä todella maksoimme.
  • H3 — Laatu pitää. Vaikein: delegoitu koodi ei saisi vaatia enempää uudelleentyöstöä kuin arkkitehdin näppäilemä koodi.

Pelisäännöt. Yksi API-pyyntö kattaa monta litteraattiriviä, jotka toistavat saman käyttöobjektin — ryhmittelimme pyyntötunnuksen mukaan, laskimme syöte- ja välimuistitokenit kerran per pyyntö ja otimme tuotoksen maksimiotoksen (naiivi rivikohtainen summaus ylilaskee 2–3×). Kustannukset käyttävät nykyisiä Anthropicin listahintoja — Fable $10/$50, Opus $5/$25, Sonnet $3/$15 per miljoona syöte-/tuotostokenia — välimuistilukujen ollessa 10 % syötteen hinnasta ja välimuistikirjoitusten TTL-kohtaisten hintojen mukaiset. 31 / 354 interaktiivisen tallennusvaraston sessiosta täyttää fable-architect-session kriteerit konservatiivisella luokittelijalla; luvut näyttävät kahdeksan kalleinta. Raportoimme suhteet ja prosentit, emme absoluuttista kulutustamme.

Osa 2 — Kuitit

Ryhmitelty pylväskaavio tuotostokeneista sessiota kohden: toteuttaja-ala-agentit tuottavat enemmän kuin arkkitehdin pääsilmukka useimmissa suurimmissa sessioissa

H1 — Sekalaista… sanoi ensimmäinen kirjanpito. Suurimmissa delegointisessioissa hypoteesi pitää ratkaisevasti — jopa 2,3× enemmän toteuttajan tuotosta kuin arkkitehdin tuotosta. Mutta kaikkien 31 fable-architect-session yli arkkitehti tuotti silti enemmän kuin toteuttajat, 3,59 M vs. 3,15 M tokenia. Osittain se on reilua — arkkitehdin tuotos sisältää kaikki suunnitelmat, briefit ja katselmointiprosan, mikä on täsmälleen sen työtä — ja osittain se näytti sessioilta, jotka delegoivat yhden osan ja pitivät loput. Sitten muistimme, ettei sivuston uudistus ollut tuntunut lainkaan arkkitehtipainotteiselta, ja lähdimme etsimään tokeneita, joita ala-agenttikirjanpito ei nähnyt.

Toinen kanava: issue-tracker delegointiväylänä

Ala-agenttikirjanpidossa on sokea piste: se näkee vain delegoinnin, joka tapahtuu session sisällä. Sivustouudistussessio — yllä olevan kaavion suurin pylväs — osoittautui kokonaan joksikin muuksi: yksittäinen arkkitehtisilmukan sessio, joka pyöri 107 tuntia putkeen (292 ajastettua herätystä), pilkkoi uudistuksen GitHub-issueiksi, merkitsi ne CI-putkeamme varten ja sitten valvoi: kyseli ajoja, katselmoi putken pull requesteja ja kirjasi jatko-issueita sitä mukaa kun QA nosti esiin bugeja.

Näppäily tapahtui jossain, minne sessiokohtainen kaivuumme ei ollut edes katsonut: erillisessä itse isännöityjen runnerien laivueessa, jossa putken vaiheet suunnittelu → toteutus → aukkoarviointi → katselmointi toteutuivat 252 itsenäisenä Opus-sessiona 4,5 päivän aikana, koskettaen 48 eri issuea ja PR:ää.

Aikajana: yksi arkkitehtisilmukan sessio kattaa neljä ja puoli päivää; sen alla päiväpylväät näyttävät lähettämänsä Opus-issue-putken sessiot

H1, uudelleenarvioituna — Vahvistettu projektin mittakaavassa. Laske molemmat kanavat ja kuva kääntyy: putki näppäili 10× enemmän tuotostokeneita kuin sen lähettänyt arkkitehtisilmukka (9,07 M vs. 877 k), kaikki Opus-hinnoilla. Tämän toteutusaallon ajaminen arkkitehdin mallilla olisi maksanut 2,1× enemmän — yhdestä uudistuksesta, yhdessä viikossa, ennen session sisäisten ala-agenttien laskemista. Issue on vain karkeampi briefi: sama rajapinta, sama talous, yksi taso ylempänä.

Pylväskaavio session kustannuslisästä, jos arkkitehtimalli olisi näppäillyt toteuttajan tokenit: 2–54 prosenttia

H2 — Vahvistettu, pienellä kierteellä. Toteuttajien tarkkojen tokenmäärien uudelleenhinnoittelu arkkitehtimallin hinnoilla tekee jokaisesta sessiosta kalliimman — +2 %:sta +54 %:iin, 17 % kahdeksan kalleimman yli. Oikeaa rahaa, mutta vähemmän kuin 2× tuotoshintaero antaa ymmärtää. Kierre: tuotos ei ole se, mihin raha menee. Suurimmassa sessiossa arkkitehdin välimuistiluvut maksoivat noin 13× sen kaiken verran, mitä se näppäili — hallitseva kuluerä on kalliin mallin suuren orkestrointikontekstin pitäminen ja uudelleenlukeminen, ei näppäily. Delegointi rajaa tuotoslaskun; seuraava vipu on arkkitehdin kontekstin pitäminen kevyenä.

H3 — Ei mitattu tässä. Token-kirjanpito ei näe koodin laatua. Mitä voimme sanoa havaintojen perusteella: katselmointisilmukka on kantava — raportit ja diffit ovat riittävän usein eri mieltä, että molempien lukeminen on ehdotonta — ja kontekstiltaan lämpimälle agentille ohjatut korjaukset konvergoivat nopeasti. Jos toistat tämän ja mittaat uudelleentyöstön kunnolla, haluamme nähdä sen, erityisesti jos se kumoaa meidät.

Mitä laajempi data opetti meille

  • Käyttöönotto on gradientti, ei kytkin. Droonioperaatioiden sovelluksessa — pienempi, nopeammin liikkuva — 18 % sessioista ajaa fable-architect-kuviota; vanhemmassa SaaS-monorepossa 9 %. Kaikkein ahkerimmin delegoinut projekti teki sen molemmilla rakeisuustasoilla yhtä aikaa: session sisäiset toteuttajabriefit ja 252 putkisessiota, jotka lähetettiin issue-trackerin kautta.
  • CI-laivue ei aja taitoa — koska se on toteuttaja. Automaattiset runner-sessiomme eivät koskaan synnytä toteuttaja-ala-agenttia, ja aluksi se näytti käyttöönoton puutteelta. Kehotteet sanovat muuta: jokainen on putken vaihe — varmista, katselmoi, aukkoarviointi — ja noin kuusi kymmenestä työskentelee tietyn issuen tai PR:n parissa. Projektin mittakaavassa putken runnerit ovat toteuttajataso.
  • Halvin taso ei ole vielä ollut ensimmäistäkään työpäivää. Kaikki 78+ toteuttaja-ajoa olivat Opus-luokkaa; Sonnet-tasoinen mekaanisten muokkausten taso lisättiin vasta äskettäin, eikä sitä ole kutsuttu. Mitä säästöjä tämä mittaa, ne ovat lattia.

Rajapinta on koko pointti: briefi sisään, diffi ulos — issue sisään, PR ulos. Sinä päivänä, kun hinnankorotus iskee, vaihdat muurarin, et prosessia.

Täysi avoimuus. Mallit varmennettu litteraattimerkkijonoista, ei oletettu. Korjasimme itseämme kahdesti (rivikohtainen tokenien ylilaskenta, sitten placeholder-hintataulukko). Vastafaktuaali olettaa, että arkkitehti olisi kuluttanut samat tokenmäärät kuin toteuttajat — virhemarginaalit kulkevat molempiin suuntiin. Putkisessiot elävät litteraattivarastossa, jota kaksi ensimmäistä kaivukierrostamme eivät kattaneet; kirjanpidon raja piilotti meiltä 9 M tokenin delegointikanavan, ja sinun vastaavassasi on todennäköisesti sellainen myös. Yhden insinöörin projektit, pääosin review-and-fix- ja feature-työtä — ei kontrolloitu vertailumittaus. Korpus myös sulkeutuu ennen kuin Opus 5 julkaistiin: jokainen yllä oleva luku on Fable arkkitehtina Opus-4-luokan toteuttajien päällä. Askelmien hinnat eivät muuttuneet, kun Opus 5 saapui, joten mitatut suhteet pätevät — mutta katso seuraavasta osiosta, mikä muuttui.

Päivitys — tikapuut liikkuivat allamme

Opus 5 julkaistiin sen jälkeen, kun nämä mittaukset suljettiin, eikä hintatikapuissa muuttunut mikään: Opus on edelleen $5/$25 per miljoona syöte-/tuotostokenia, Fable edelleen $10/$50, ja yllä oleva kaavio on edelleen oikein. Se mikä muuttui, on kyvykkyys kullakin askelmalla. Anthropic asemoi Opus 5:n harppaukseksi syvässä päättelyssä ja pitkäjänteisessä agenttisessa työssä — eli täsmälleen siinä työssä, josta arkkitehdin rooli muodostuu, puoleen arkkitehtitason hinnasta.

Tämä osoittaa suoraan omaan H2-kierteeseemme. Jos arkkitehdin hallitseva kustannus on välimuistiluvut ja välimuistiluvut laskutetaan 10 %:lla syötteen hinnasta, Opus 5:llä ajettava arkkitehti lukee orkestrointikontekstiaan uudelleen $0,50 miljoonalta tokenilta Fabelin $1,00 sijaan. Erä, joka maksoi 13× kaiken sen, mitä arkkitehti näppäili, puolittuu. Emme ole mitanneet tätä — se on aritmetiikkaa samalla yhtä suurten tokenmäärien oletuksella, jonka merkitsimme 2,1×-vastafaktuaalille, ja se on seuraava asia, jonka aiomme testata. Jos se pitää, mielenkiintoinen kysymys lakkaa olemasta mitkä mallit valita ja muuttuu kysymykseksi tarvitseeko arkkitehti ylintä askelmaa lainkaan.

Kolme asiaa uudessa toteuttajatasossa muuttaa itse kuviota, ei vain sen hintaa:

  • Se tarttuu ala-agentteihin herkästi — päinvastoin kuin edeltäjänsä, joka piti suostutella delegoimaan ylipäätään. Toteuttaja, joka hiljaa synnyttää omat toteuttajansa, moninkertaistaa laskun kenenkään katsomatta. Siksi briefin Delegation:-rivi: osa kertoo nyt, saako se haarautua ja kuinka leveälle.
  • Se varmistaa oman työnsä ilman kehotusta. Vanhemmille malleille kirjoitetut varmistusohjeet ostavat nyt redundantin toisen kierroksen, joten ne poistuvat briefeistä. Arkkitehdin katselmointisilmukka on koskematon.
  • Se laajentaa laajuutta. Out of scope: lakkaa olemasta vakioteksti ja muuttuu riviksi, joka pitää osan osana.

Ja askelma, jota emme koskaan käyttäneet, terävöityi sillä välin kun emme katsoneet: Sonnet 5 saapuu lähelle Opus-tasoa koodaustyössä hintaan $3/$15, ja esittelyhinnoittelu on sitä alempi elokuun loppuun asti. “Mitä säästöjä tämä mittaa, ne ovat lattia” oli varaus, kun kirjoitimme sen. Nyt se lukee aliarviointina.

Osa 3 — Mihin tässä tietoisesti mennään

Ohjaamme tarkoituksella kohti jakoa, johon uskomme jokaisen insinööritiimin lopulta pakotettavan: kalliit frontier-mallit vain ideointiin, arkkitehtuuriin ja katselmointiin; yhä halvemmat mallit itse ohjelmointiin. Tänään toteuttajamme ovat Opus-luokkaa. Mikään työnkulussa ei muutu, kun niistä tulee Sonnet-luokkaa, DeepSeek-luokkaa tai Kimi-luokkaa — rajapinta on rakenteellisesti malliriippumaton. Siinä on koko strateginen arvo: sinä päivänä, kun tuki loppuu ja lasku kaksinkertaistuu, tämän kurinalaisuuden omaavat tiimit vaihtavat yhden konfiguraatiorivin. Ilman sitä olevat tiimit neuvottelevat koko kustannusrakenteensa uudelleen paineen alla.

Fable-architect on pieni askel — käyttöönotto on osittaista eikä halvin taso ole nähnyt ensimmäistäkään ajoa. Mutta se on askel, joka rakentaa lihaksen: kirjoittaa briefejä, jotka määrittelevät osan täysin, katselmoida diffejä joita et näppäillyt, kohdella kalliin mallin huomiota budjettina. Ja uudistusaalto näyttää, mihin lihas johtaa: kun briefit toimivat, issuet toimivat, ja kallis malli lakkaa osallistumasta toteutukseen kokonaan.

Mitä voit tehdä maanantaina

  1. Jaa roolit agenttikehyksessäsi. Yksi session tason sääntö: frontier-malli suunnittelee ja katselmoi; delegoi kaikki tiedostomuokkaukset halvemmalle toteuttaja-agentille. Claude Codessa tämä on taito plus ala-agenttien määritelmät — iltapäivän verran säätöä.
  2. Tee rajasta mekaaninen. Lisää esimuokkauskoukku, joka haastaa kalliin mallin omat tiedostokirjoitukset. Sääntö, jonka rikkomisesta ei seuraa mitään, rikotaan perjantaihin mennessä.
  3. Kirjoita briefit kiinteällä mallipohjalla. Tavoite, konteksti, tiedostot, suunnittelu, rajoitteet, rajaukset, delegointibudjetti, varmistus. Mallipohja on kurinalaisuus — ja delegointibudjetti on se, mikä estää toteuttajaa palkkaamasta hiljaa omiaan.
  4. Katselmoi sekä raportti että diffi. Älä luota kumpaankaan yksinään; aja uudelleen ne varmistuskomennot, joilla on väliä.
  5. Mittaa oma jakosi. Litteraattisi sisältävät jo datan — ryhmittele pyynnön mukaan, hinnoittele mallin mukaan ja katso, kuka oikeasti näppäilee. Meidän datamme näytti meille käyttämättömän halvan tason ja 9 M tokenin delegointikanavan, josta emme tienneet.
  6. Laajenna rajapinta briifeistä issueihin. Briefi delegoi tunnin työtä; issue delegoi päivän. Kun issuesi kantavat hyväksymiskriteerit, joiden perusteella putki voi toimia, kallis malli voi kirjata työtä trackeriin ja valvoa sen sijaan, että istuisi silmukassa jokaisen osan kohdalla.
  7. Pidä poistumistie lämpimänä. Aja halpaa tai avointa mallia toteuttajana yhdelle matalan riskin osalle viikossa. Siirrettävyys, jota et koskaan harjoittele, on siirrettävyyttä jota sinulla ei ole.
  8. Hinnoittele arkkitehti uudelleen, älä vain muurari. Jokainen mallijulkaisu siirtää askelmia liikuttamatta tikapuita. Jos suurin osa arkkitehtikulustasi on kontekstia eikä näppäilyä, halvempi arkkitehtitaso on arvokkaampi kuin halvempi toteuttajataso — tarkista omista litteraateistasi, kumpaa olet ostamassa.

Laboratoriot kertovat meille jatkossakin, että niiden huippumallit ovat minkä tahansa hinnan arvoisia, ja — raivostuttavaa kyllä — harkintatyössä ne ovat pääosin oikeassa. Liike ei ole pidättäytyä. Se on lopettaa frontier-hintojen maksaminen for-silmukoista.

Usein kysytyt kysymykset

Štefan on AI- ja ohjelmistoinsinööri, joka rakentaa FlowHunt-palvelua. Tuotteen lisäksi hän suunnittelee kehittäjille agentic-ohjelmistojen insinöörityötyönkulkuja, jotka vähentävät kehityskustannuksia samalla kun parantavat koodin laatua.

Štefan Moravík
Štefan Moravík
AI- ja ohjelmistoinsinööri

Orchestroi monimallisia AI-tiimejä FlowHuntilla

Rakenna AI-agenttityönkulkuja, jotka ohjaavat jokaisen tehtävän oikealle mallille — frontier-päättely sinne missä sillä on väliä, tehokkaat mallit volyymityöhön.