Spec Kitin käyttöönotto Claude Codessa vuonna 2026: määrittelyt kehotteiden sijaan

Mitä vibe-koodaukselle tapahtui toukokuussa 2026?#

Vuotta myöhemmin, 4. helmikuuta 2026, hän julkaisi jälkikäteen asiaa käsittelevän ketjun:

Sequoia Ascent 2026 -puheessaan hän muotoili asian vielä täsmällisemmin: ”Vibe-koodaus nostaa perustasoa — sitä, mitä kuka tahansa pystyy tekemään ohjelmistojen parissa. Agentic engineering säilyttää huipputason — ammattimaisen kehitystyön laatukynnyksen.” Samalla lavalla hän esitti alan sanastoon jääneen huomion: ”Vibe-koodaukseen vetoamalla ei voi tuoda ohjelmistoon haavoittuvuuksia. Olet edelleen vastuussa ohjelmistostasi, kuten ennenkin.”

Kaksi asiaa tapahtui rinnakkain. Syyskuussa 2025 GitHub julkaisi Spec Kit-työkalun, joka keräsi 107 000 tähteä 8 kuukaudessa. Helmikuussa 2026 AWS julkaisi yksityiskohtaisen lääkekehityksen tapaustutkimuksen, jossa kerrottiin: ”95 % liiketoimintalogiikasta tuotettiin määrittelyn perusteella, mikä säästi yli 80 tuntia.”

Toukokuun 2026 loppuun mennessä englanninkielisessä tietoympäristössä oli muodostunut yhteisymmärrys: vibe-koodaus työskentelytapana on aloittelijatason menetelmä. Seuraavana tulee Spec-Driven Development. Tässä oppaassa kerrotaan, miten lähestymistapa otetaan käyttöön.

Mitä Spec Kit ja Spec-Driven Development ovat?#

Menetelmän ydinajatus tiivistyy yhteen GitHubin virallisen dokumentaation lauseeseen:

Käytännössä tämä etenee neljässä vaiheessa (Spec Kit lisää yhden vaiheen ennen niitä: alla kuvatun konstituution):

1. Specify — kirjoita luonnollisella kielellä määrittely siitä, mitä haluat. MITÄ tehdään ja MIKSI. Ei MITEN.
2. Plan — agentti kokoaa määrittelyn pohjalta teknisen suunnitelman: käytettävät teknologiat, arkkitehtuurin ja komponentit.
3. Tasks — agentti jakaa suunnitelman konkreettisiksi, todennettaviksi tehtäviksi ja määrittää niiden riippuvuudet.
4. Implement — agentti tai sen aliagentit käy tehtävät läpi ja kirjoittaa koodin.

Implement-vaiheen jälkeen Spec Kitin nykyisessä versiossa on Converge-tarkistus: agentti vertaa valmista koodia määrittelyyn, suunnitelmaan ja tehtäviin ja lisää tasks.md-tiedostoon kaiken, mikä jäi puuttumaan. Suorita Implement- ja Converge-vaiheita vuorotellen, kunnes Converge vastaa ”Converged”.

Jokaisesta vaiheesta syntyy erillinen Markdown-tiedosto repositorioon. Claude Codessa jokainen vaihe on erillinen kauttaviivakomento: /speckit-specify, /speckit-plan, /speckit-tasks, /speckit-implement, ja tarkistus on /speckit-converge. Spec Kit -dokumentaatiossa samat komennot kirjoitetaan pisteellä (esimerkiksi /speckit.specify), mutta Claude Codessa Spec Kit asentaa ne taitoina, jotka käynnistetään yhdysmerkillä. Jos missä tahansa vaiheessa ilmenee ongelma, muokkaa Markdown-tiedostoa ja suorita seuraava vaihe uudelleen.

Spec Kit on SDD:n erityinen toteutus. Toukokuussa 2026 sillä oli jo yli 30 integraatiota eri tekoälyagentteihin. Spec Kit toimii samassa repositoriossa samalla tavalla Claude Coden, Cursorin, GitHub Copilotin, Codex CLI:n, Windsurfin, Qwenin, Tabninen, Amazon Q:n, Geminin, Goosen ja tusinan muun kanssa.

Ajokerran jälkeen repositoriossasi on koodin lisäksi sen määrittely, suunnitelma ja tehtävät. Kuukauden kuluttua voit palata projektiin, lukea spec.md-tiedoston ja ymmärtää, mitä tehtiin ja miksi. Tämä ei enää ole ”vibe-koodausta, jossa koodin olemassaolo unohtuu” — tiedostot ovat projektin työmuisti.

Miksi tätä tarvitsee vibe-koodaaja, joka ei kirjoita koodia?#

Spec Kit virallistaa suunnittelun erillisiksi vaiheiksi neljällä kauttaviivakomennolla. Logiikka: ”ajattele asia läpi” ja ”toteuta se” erotetaan toisistaan, jotta ne tapahtuvat eri konteksti-ikkunoissa. Jokainen vaihe saa puhtaan kontekstin, jota edellinen vaihe ei ole täyttänyt.

Kolme konkreettista hyötyä vibe-koodaajalle:

• Ennakoitavuus. Kun sanot agentille ”tee rekisteröitymislomake sähköpostivahvistuksella”, se arvaa itse 10 yksityiskohtaa, joista kolme on väärin siihen nähden, mitä tarkoitit. Kun sinulla on spec.md, jossa on käyttäjätarinat, hyväksymisskenaariot ja [NEEDS CLARIFICATION]-merkinnät kaikissa epäselvissä kohdissa, mitään ei tarvitse arvata.
• Projektin muisti. Kuukauden kuluttua et muista, mitä keskustelit agentin kanssa. Mutta spec.md, plan.md ja tasks.md ovat repositoriossa specs/###-feature/-kansiossa koodin vieressä. Ne kertovat paitsi, mitä tehtiin, myös miksi.
• Skaala. Yhden tai kahden tiedoston ominaisuudessa eroa tuskin huomaa. Ominaisuudessa, johon liittyy 20 tiedostoa ja 5 tietoyksikköä, ero on ”kaiken uudelleenkirjoittamisen 4 tunnin jälkeen” ja ”kaiken saattamisen päähaaraan 4 tunnissa” välillä. AWS Kiro osoitti, että TargetID-projektissa 95 % liiketoimintalogiikasta voidaan automatisoida määrittelyn pohjalta.

Vibe-koodauksen tärkein harha on se, että se tuntuu aluksi nopeammalta. Puoli tuntia, ja prototyyppi on valmis. Mutta viikon kuluttua prototyyppi hajoaa, ja se on helpompi heittää pois. Spec-Driven Development vie alussa hieman kauemmin (tunnin puolen tunnin sijaan), mutta viikon päästä työskentelet yhä samassa repositoriossa.

Spec Kitin asennus Claude Codeen (4 vaihetta)#

Vaihe 1. Asenna uv. Tämä tarvitsee tehdä vain kerran; uv jää järjestelmääsi.

# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

# Windows
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

Tarkista, että uv asentui:

uv --version

Vaihe 2. Asenna Spec Kit. Yksi komento:

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

Tarkista asennus:

specify --version

Vaihe 3. Alusta repositorio. Siirry projektikansioon (tai luo uusi kansio) ja suorita:

specify init --here --integration claude

Valitsin --integration claude valitsee Claude Coden suoraan. Ilman sitä Spec Kit pyytää valitsemaan agentin vuorovaikutteisesta luettelosta ja saattaa myös kysyä skriptityyppiä (macOSissa ja Linuxissa valitse sh). Jos kansio ei ole tyhjä, Spec Kit varoittaa yhdistävänsä tiedostonsa olemassa oleviin. Tallenna työ ensin commitilla ja suorita sitten komento uudelleen valitsimella --force.

Tämän jälkeen repositorioon ilmestyy seuraava rakenne:

.specify/
  memory/
    constitution.md        # projektin säännöt, täytetään komennolla /speckit-constitution
  scripts/
  templates/
    spec-template.md
    plan-template.md
    tasks-template.md
.claude/
  skills/
    speckit-constitution/SKILL.md
    speckit-specify/SKILL.md
    speckit-clarify/SKILL.md
    speckit-plan/SKILL.md
    speckit-checklist/SKILL.md
    speckit-tasks/SKILL.md
    speckit-analyze/SKILL.md
    speckit-implement/SKILL.md
    speckit-converge/SKILL.md
    speckit-taskstoissues/SKILL.md

Vaihe 4. Avaa Claude Code ja tarkista kauttaviivakomennot. Suorita samassa kansiossa:

claude

Kirjoita istunnossa /speckit. Komentojen speckit-* pitäisi näkyä ehdotuksissa. Jos ne eivät näy, käynnistä Claude Code uudelleen, jotta se lukee .claude/skills/-kansion uudestaan. Jos projektin juuressa on jo CLAUDE.md, Spec Kit jättää sen ennalleen. Se toimii sen rinnalla tiedostossa .specify/memory/constitution.md.

Spec Kit toimii myös ilman Claude Codea (se tukee yli 30 agenttia), mutta tämä opas käsittelee nimenomaan Claude-asennusta. Jos haluat asentaa kaksi työkalua heti, tutustu erillisiin oppaisiin CLAUDE.md:n käyttöönotosta ja Claude Coden Plan Modesta.

Spec Kit on ensimmäinen rakennuspalikka ”agentin työsopimuksessa”. Täydellinen kokonaisuus sisältää kaikki kolme osaa: tekoälykloonin (menetelmäsi Skills-taitoina ja aliagentteina), Second Brainin (rakenne business/, johon agentti palaa joka kerta) ja kontekstisuunnittelun (Spec Kit, Plan Mode, /compact). Nämä ovat ne kolme peruspilaria, joita ilman tekoäly hallusinoi.

Miten kirjoitat ensimmäisen määrittelysi (Specify)?#

Kirjoita Claude Codeen:

/speckit-specify

Sen jälkeen agentti pyytää sinua kuvailemaan ominaisuuden. Käytä tässä vaiheessa selkeää kieltä ilman teknistä sanastoa:

I want a registration form in my app. The user enters an email
and password, receives a confirmation email, and after confirming
lands on the dashboard. Confirmation expires after 48 hours. If the
email is still unconfirmed, delete the account within 5 minutes after
that deadline; never delete a confirmed account.

Tässä havainnollistavassa esimerkissä poiston toleranssiksi on täsmennetty 5 minuuttia 48 tunnin määräajan jälkeen. Varmista todellisessa tuotteessa toleranssi ennen Plan-vaihetta. Täsmällinen 48 tunnin määräaika vaatii suunnittelun ja testit, jotka toteuttavat tämän tiukemman vaatimuksen. Agentti kokoaa tiedoston specs/001-registration/spec.md. Avaa se, niin näet tämänkaltaisen rakenteen:

# Feature Specification: User Registration

**Feature Branch**: `001-registration`
**Created**: 2026-05-31
**Status**: Draft
**Input**: User Description: "I want a registration form..."

## User Scenarios & Testing *(mandatory)*

### Primary User Story
As a new user, I want to register an account with email confirmation,
so that I can access the dashboard with a verified identity.

### Acceptance Scenarios
1. **Given** I am on the registration page,
   **When** I submit valid email and password,
   **Then** I receive a confirmation email within 1 minute.
2. **Given** I clicked the confirmation link within 48 hours,
   **When** I land on the dashboard,
   **Then** I see my email confirmed in profile.
3. **Given** I have not confirmed at the 48-hour deadline,
   **When** cleanup runs within the next 5 minutes,
   **Then** my account is deleted and email is freed for re-registration.
4. **Given** my account is just under 48 hours old or already confirmed,
   **When** cleanup runs,
   **Then** the account is not deleted.

## Requirements *(mandatory)*

### Functional Requirements
- **FR-001**: System MUST accept registration via [NEEDS CLARIFICATION:
  email/password only, or also SSO/OAuth?]
- **FR-002**: System MUST send confirmation email within 60 seconds
- **FR-003**: Confirmation MUST expire at 48 hours; the system MUST
  delete still-unconfirmed accounts no later than 5 minutes after that
  deadline and MUST NOT delete confirmed accounts
- **FR-004**: System MUST log all registration attempts for [NEEDS
  CLARIFICATION: how long do we retain logs - 30 days, 90 days, forever?]

### Key Entities
- User: email, password_hash, email_verified_at, created_at, deleted_at
- ConfirmationToken: token, user_id, expires_at, used_at

## Success Criteria *(mandatory)*
- **SC-001**: 95% of confirmation emails delivered within 60 seconds (p95)
- **SC-002**: 0 accidental deletions of confirmed accounts
- **SC-004**: No deletion before 48 hours; every eligible unconfirmed
  account is deleted by age 48 hours 5 minutes under the tested workload
- **SC-003**: Registration completion rate > 60% (from form open to dashboard)

Huomaa [NEEDS CLARIFICATION: ...]-merkinnät. Spec Kit lisää ne tarkoituksella jokaiseen kohtaan, johon agentti ei saanut tekstistäsi yksiselitteistä vastausta. Ennen Plan-vaihetta sinun on joko vastattava niihin käsin spec.md-tiedostossa tai suoritettava /speckit-clarify. Jälkimmäisessä agentti käy epäselvät kohdat läpi ja kysyy niistä keskustelussa.

Spec Kitin sisäänrakennettu /speckit-clarify-komento korvaa ääneen sanotun ”kysy minulta kysymyksiä”. Vaikutus on sama: älä siirry Plan-vaiheeseen ennen kuin kaikki [NEEDS CLARIFICATION]-merkinnät on poistettu spec.md-tiedostosta.

spec.md-tiedostossa ei pidä olla teknologioita. Siinä ei pidä mainita Reactia, Postgresia, Prismaaa tai Redistä. Määrittely kuvaa järjestelmän toimintaa käyttäjän ja liiketoiminnan näkökulmasta. Teknologiapino määritetään seuraavassa vaiheessa.

Mitä Claude tekee Plan-vaiheessa?#

Kun spec.md on valmis, suorita:

/speckit-plan

Voit halutessasi antaa teknologioita koskevat vihjeet suoraan komennossa:

/speckit-plan Next.js App Router, Prisma, PostgreSQL, Resend for email

Claude lukee kolme lähdettä: spec.md-tiedoston, CLAUDE.md-tiedoston (tai memory/constitution.md-tiedoston) sekä repositoriossa olevan koodin. Tuloksena on plan.md, jonka rakenne on suunnilleen tällainen:

# Implementation Plan: User Registration

## Technical Context
- Framework: Next.js 14 App Router
- Database: PostgreSQL via Prisma
- Email: Resend (single transport)
- Validation: Zod schema in shared lib
- Auth: NextAuth.js with credentials provider

## Architecture Decisions

### 1. Token storage
Tokens stored in DB (table ConfirmationToken), not in JWT.
Reason: need server-side revoke on email re-register.

### 2. Email delivery
Async via cron `/api/cron/send-confirmation` triggered immediately
after registration. Retries handled by Resend.

### 3. Auto-delete cron
Run `/api/cron/cleanup-unconfirmed` every minute. Delete rows only where
created_at <= NOW() - INTERVAL '48 hours' AND email_verified_at IS NULL.
The clarified example allows at most 5 minutes of deletion delay.
Verify scheduler lag and completion time against that bound; report
a missed bound as a failure, not a successful daily cleanup.

## Data Model
See data-model.md

## API Contracts
See contracts/
- POST /api/auth/register
- POST /api/auth/confirm
- GET /api/auth/resend-confirmation

## Implementation Phases
1. Database migration (Prisma schema + migration file)
2. API routes (3 endpoints)
3. UI: registration form + confirmation success page
4. Cron jobs (send + cleanup)
5. Email template
6. Integration tests

data-model.md kuvaa tietoyksiköt ja niiden suhteet. contracts/ sisältää API-sopimusten rungot joko OpenAPI YAML -muodossa tai TypeScriptin pyyntö- ja vastaustyyppeinä. Tämä ei ole koodia, vaan aie, jonka Claude muuntaa myöhemmin oikeiksi reiteiksi.

Plan-vaiheen tärkein etu on puhdas konteksti. Claude ei yritä pitää sekä määrittelyä että toteutusta mielessään yhtä aikaa. Se miettii asian ensin läpi, kirjaa päätöksen tiedostoon ja jatkaa vasta sitten.

Seuraavaksi on valinnainen /speckit-analyze-komento. Se suoritetaan Tasks-vaiheen jälkeen ja ennen Implement-vaihetta. Se tarkistaa spec.md-, plan.md- ja tasks.md-tiedostot ristiriitojen varalta sekä sen, kattavatko suunnitelma ja tehtävät kaikki määrittelyn vaatimukset. Se ei muokkaa tiedostoja, vaan tuottaa raportin. Käytännössä kyseessä on muodollinen järkevyystarkistus ennen toteutusta.

Miten työ jaetaan tehtäviin (Tasks)?#

Kun sinulla on spec.md ja plan.md, suorita:

/speckit-tasks

Claude laajentaa suunnitelman tasks.md-tiedostoksi:

# Tasks: User Registration

## Phase 1: Database (no dependencies)
- [ ] T-001: Add User model to prisma/schema.prisma (parallel-safe)
- [ ] T-002: Add ConfirmationToken model to prisma/schema.prisma (after T-001)
- [ ] T-003: Generate migration `add-user-registration` (after T-002)

## Phase 2: API contracts (no dependencies)
- [ ] T-004: Create Zod schemas in shared/validation/auth.ts
- [ ] T-005: Define TypeScript types in shared/types/auth.ts (after T-004)

## Phase 3: Routes (depends on Phase 1+2)
- [ ] T-006: Implement POST /api/auth/register
- [ ] T-007: Implement POST /api/auth/confirm
- [ ] T-008: Implement GET /api/auth/resend-confirmation

## Phase 4: UI (parallel with Phase 3)
- [ ] T-009: Build /register page with form
- [ ] T-010: Build /register/confirm/[token] page
- [ ] T-011: Build /register/success page

## Phase 5: Cron + integration (depends on Phase 3+4)
- [ ] T-012: Cron /api/cron/send-confirmation
- [ ] T-013: Cron /api/cron/cleanup-unconfirmed
- [ ] T-014: Email template registration-confirmation.tsx
- [ ] T-015: Integration tests (Playwright), including cleanup just
  before 48h, exactly at 48h, deletion by 48h 5m, delayed-job failure,
  and protection of confirmed accounts

## Notes
- T-001, T-004, T-009-T-011 are parallel-safe (different files)
- T-002 conflicts with T-001 (same file: schema.prisma) - run sequentially
- T-006 needs T-003 (migration applied) and T-005 (types)

Huomaa merkinnät parallel-safe ja after T-NNN. Ne muodostavat riippuvuuskaavion, jonka avulla vaiheita voidaan myöhemmin suorittaa rinnakkain. Koko Spec Kitin nopeutustapa perustuu tähän mekanismiin: jotkin tehtävät voi antaa viidelle eri Claude Code -istunnolle kerralla, kun taas toiset on suoritettava tiukassa järjestyksessä.

Spec Kit hoitaa tämän automaattisesti yhdellä komennolla suoraan pakkauksesta.

Valinnainen /speckit-taskstoissues-komento ottaa tasks.md-tiedoston ja luo luettelon perusteella GitHub-ongelmia, joista jokaisesta on linkki spec.md-tiedostoon. Tämä on hyödyllistä, jos työskentelet tiimissä tai haluat seurata edistymistä GitHub Projectsissa.

Miten toteutus tehdään aliagenttien avulla (Implement)?#

/speckit-implement

Claude aloittaa tasks.md-tiedoston ensimmäisestä tehtävästä. Jokainen tehtävä käy läpi lyhyen kierroksen: relevanttien tiedostojen lukeminen, muutoksen kirjoittaminen, testien suorittaminen ja tehtävän merkitseminen [x]. Aliagentteja kutsutaan automaattisesti tarpeen mukaan: erillinen agentti koodikatselmointiin, toinen lintterin suorittamiseen ja kolmas regressioiden tarkistamiseen.

Ja erikseen säännöistä:

Spec Kit virallistaa tämän kierroksen. spec.md on totuuden lähde, plan.md sisältää tekniset päätökset ja tasks.md toimii tarkistuslistana. Jos Claude ajautuu väärille raiteille missä tahansa vaiheessa, palaa määrittelyyn ja sano: ”Tämä ei vastaa vaatimusta FR-003; tee uudelleen.” Ei pitkiä kehotteita, joissa pyydetään ”muistamaan, mistä keskustelimme...” — koko historia on tiedostoissa.

Jos olet ottanut käyttöön Dynamic Workflows in Opus 4.8, voit automatisoida Spec Kitin kokonaan: yksi /speckit-implement-komento saa Clauden rinnakkaistamaan työn, kokoamaan tulokset yhteen ja tarkistamaan ne. Yläraja on 1000 samanaikaista aliagenttia. Useimmille ominaisuuksille riittää 10–30.

Kun kaikki [x]-ruudut on merkitty ja seuraavan osion tarkistus vastaa ”Converged”, tarkasta pull request (tai useat pull requestit, jos tehtäviä on paljon) ja yhdistä muutokset. Artefaktit spec.md, plan.md ja tasks.md jäävät repositorioon ominaisuuden dokumentaatioksi. Vuoden päästä sinun ei tarvitse päätellä logiikkaa koodista.

Miten tarkistat, ettei agentilta jäänyt mitään huomaamatta (Converge)?#

/speckit-converge

Ensin agentti tekee yhteenvedon löydöksistään ja antaa niille vakavuustasot. Sen jälkeen seuraa toinen kahdesta tuloksesta. ”Converged” tarkoittaa, ettei puutteita ole, tasks.md on pysynyt tavu tavulta muuttumattomana ja voit siirtyä tarkastukseen. ”Tasks appended” tarkoittaa, että puutteita löytyi ja ne lisättiin tasks.md-tiedoston Convergence-osioon. Agentti kertoo niiden määrän.

Converge ei muokkaa eikä poista koodia; sen ainoa kirjoitustoimi on uusien tehtävien lisääminen tiedostoon tasks.md. Siksi sitä voi käyttää huoletta, mutta vasta sen jälkeen, kun /speckit-implement on käsitellyt nykyisen tasks.md-tiedoston. Jokainen seuraava kierros löytää vähemmän puutteita.

Miten Spec Kit eroaa CLAUDE.md-tiedostosta ja Plan Modesta?#

Vertaa niitä viiden ominaisuuden perusteella:

Spec Kitin termein kyseessä on .specify/memory/constitution.md. Alustuksen yhteydessä Spec Kit voi joko käyttää olemassa olevaa CLAUDE.md-tiedostoa konstituution pohjana tai luoda sen rinnalle erillisen tiedoston. Itse pidän CLAUDE.md-tiedostossa koko projektin kattavan ”sopimuksen” (teknologiapino, sanasto, käyttöönoton protokolla) ja käytän Spec Kitin konstituutiota ominaisuuksiin liittyviin sääntöihin, kuten ”kaikki lomakkeet validoidaan Zodilla; manuaalisia tarkistuksia ei tehdä”.

Plan Modeen liittyvä yhteys on yksinkertaisempi. Plan Mode on nopea yhden istunnon tila, jossa ”suunnitellaan ennen koodin kirjoittamista”. Se toimii hyvin pienissä muutoksissa (virheen korjaaminen tai funktion refaktorointi). Suuressa ominaisuudessa Plan Mode jää jälkeen, koska yhden istunnon konteksti-ikkuna on liian pieni 3000-riviselle suunnitelmalle, kuten selitän suoraan live-istunnossa:

Spec Kit on konkreettinen kontekstisuunnittelun työkalu. Se siirtää ”arkkitehtuurin pöytäliinan” keskustelusta tiedostoihin. Spec.md pysyy repositoriossa, ja jokainen uusi Claude-istunto lukee sen uudelleen — sinun ei tarvitse toistaa itseäsi.

Suuren projektin asennus:

1. CLAUDE.md — teknologiapino, sanasto ja asiat, joita ei pidä tehdä. Tiedosto on juuressa.
2. .specify/memory/constitution.md Spec Kitille — tätä työnkulkua koskevat säännöt.
3. specs/001-feature-A/spec.md, plan.md, tasks.md — ensimmäinen ominaisuus.
4. specs/002-feature-B/spec.md, plan.md, tasks.md — toinen ominaisuus.
5. Päivittäisessä työssä käytä joko komentoa /speckit-implement (valmiille tehtäville) tai /plan (muutoksen nopeaan tarkistamiseen).

Millaisia todellisia käyttötapauksia on?#

Konkreettisia tapauksia:

• AWS Kiro — lääkekehitysagentti. AWS Industries -blogikirjoituksessa 18. helmikuuta 2026 julkaistu tiimi kuvailee TargetID-projektia. Kolme kehittäjää, kolme viikkoa, lääkekehitysagentti. Artikkelin mukaan Kiro tuotti yli 95 % liiketoimintalogiikan koodista ja säästi yli 80 kehitystuntia. Lisäksi: ”Kiron kirjoittama README-dokumentaatio säästi arviolta 8 tuntia” ja ”iteratiivisia kehote-ja-korjaus-kierroksia oli 40 % vähemmän”.
• Rackspace Technology. Samassa AWS-blogissa Rackspace kertoo: ”saimme valmiiksi 52 viikon arvioidun työn vain 3 viikossa” ja ”tehokkuus kasvoi 90 %”. Kyseessä ei enää ole pieni ominaisuus, vaan kokonainen yritystason projekti.
• GitHub Spec Kitin kasvu. Toukokuun 7. päivänä 2026 repositoriolla oli 93 000 tähteä; toukokuun 31. päivään mennessä niitä oli 107 000. Kasvua oli 14 000 tähteä kolmessa viikossa. Kasvuvauhti on selvä merkki siitä, että lähestymistapa valtaa markkinaosuutta.

Lukijalle tämä tarkoittaa, ettei lähestymistapa ole teoreettinen: vakavasti otettavat tiimit käyttävät sitä jo tuotantoympäristössä.

Milloin Spec Kit EI sovellu?#

Ei sovellu nro 1 — pienet muokkaukset. Jos tehtävänä on ”nimetä muuttuja uudelleen”, ”korjata tekstin kirjoitusvirhe” tai ”lisätä lokimerkintä”, Specify → Plan → Tasks -vaiheiden läpikäynti kestää kauemmin kuin itse muokkaus. Pienissä muokkauksissa Plan Mode tai suora kehote Claude Codessa on nopeampi.

Ei sovellu nro 2 — reaaliaikaiset kokeilut. Kun et vielä tiedä, mitä haluat, ja sinun täytyy ”tutkia” käyttöliittymää tai koota nopeasti prototyyppi nähdäksesi, ”toimiiko se”, määrittelystä ei ole hyötyä. Arvo on juuri siinä, että improvisoit. Idean kokeilemisen tasolla improvisointi on juuri se, mikä toimii — ei määrittely.

Ei sovellu nro 3 — vanha koodi, jossa on monimutkainen tila. Vahva vastaväite on, että todellisuus muuttuu määrittelyjä nopeammin. Esimerkiksi tilauslaskutuksessa tiimi kuvailee laskutusjaksot ja verosäännöt, mutta viikkoa myöhemmin talousosasto pyytää ottamaan käyttöön Euroopan arvonlisäveron. Määrittely on vanhentunut jo ennen julkaisua. Kun liiketoimintalogiikka muuttuu nopeasti, määrittelyjen ylläpidosta tulee taakka.

Yksi lisäriski on väärä hallinnan tunne: rakenteet ovat tyylikkäitä, mutta agentit jättävät ohjeet usein huomiotta tai noudattavat malleja liian kirjaimellisesti. Tuloksena on rakenteellisesti oikeaa koodia, joka ei sovi omaan repositorioosi — määrittely ei takaa, että agentti ymmärsi sen tarkoittamallasi tavalla.

Alan analyytikot ovat varoittaneet vesiputousmallista: suuren määrittelyn kirjoittaminen ennen koodia on tie, joka on jo kerran johtanut alan vaikeuksiin 200-sivuisten vaatimusmäärittelyjen aikaan. Insinöörit ovat suhtautuneet lähestymistapaan varoen siitä lähtien, ja varovaisuus on perusteltua.

Mitä asialle voi tehdä? Ehdotan yksinkertaista sääntöä: vertaa ominaisuuden kokoa määrittelyn kirjoittamiseen kuluvaan aikaan. Jos ominaisuuden toteutus kestää alle 2 tuntia, älä kirjoita määrittelyä — Plan Mode on nopeampi. Jos ominaisuuden toteutus kestää viikon, käytä ehdottomasti Spec Kitiä; ajansäästö maksaa tunnin määrittelytyön takaisin viisinkertaisesti. Valitse itse, jos toteutus kestää 2 tunnista viikkoon. Itse kirjoitan määrittelyn jopa puolen päivän ominaisuuksista, koska repositorioon jäävä artefakti on arvokkaampi kuin säästetyt 30 minuuttia.

Mitä seuraavaksi: miten Spec Kit liitetään projektiin?#

Konkreettinen suunnitelma seuraaville 7 päivälle:

• Päivä 1. Asenna uv ja Spec Kit (5–10 minuuttia). Tarkista, että /speckit-*-komennot näkyvät Claude Codessa. Älä yritä soveltaa niitä olemassa olevaan projektiin — aloita uudesta.
• Päivä 2. Valitse todellinen ominaisuus, jonka aiot rakentaa. Suorita /speckit-specify vapaamuotoisella kuvauksella. Avaa spec.md, lue se ja vastaa kaikkiin [NEEDS CLARIFICATION]-merkintöihin. Älä kiirehdi Plan-vaiheeseen.
• Päivä 3. Suorita /speckit-plan ja anna vihjeitä teknologiapinostasi. Lue plan.md, erityisesti Architecture Decisions -osio. Jos jokin ei sovi sinulle, muokkaa sitä käsin.
• Päivä 4–5. Suorita /speckit-tasks ja sen jälkeen /speckit-analyze, jotta voit tarkistaa määrittelyn, suunnitelman ja tehtävät. Suorita sitten /speckit-implement. Seuraa, kuinka Claude merkitsee tasks.md-tiedostoon kohtia [x]. Se voi juuttua johonkin — se on normaalia. Palaa spec.md-tiedostoon, täsmennä vaatimus ja käynnistä /speckit-implement uudelleen yksilöidyllä tehtävällä. Kun tehtävät on tehty, suorita /speckit-converge ja toista Implement- ja Converge-vaiheet, kunnes vastaus on ”Converged”.
• Päivä 6–7. Tarkasta pull request (tai pull requestit). Yhdistä muutokset. Lue spec.md ja plan.md — ne ovat ominaisuutesi dokumentaatio tulevaksi vuodeksi.

Samalla kannattaa lukea:

• CLAUDE.md:n käyttöönotto vuonna 2026 — Spec Kitin konstituution perusta.
• Plan Mode Claude Codessa — nopea vaihtoehto pieniin tehtäviin.
• Kontekstisuunnittelu vuonna 2026 — miksi Spec Kit toimii.
• Skills, Subagents, MCP vai Plugins — mitä Spec Kitiin kannattaa lisätä omaa työnkulkua varten.
• Dynamic Workflows Claude Codessa — miten voit käynnistää useita aliagentteja kerralla Implement-vaihetta varten.

Täydellinen kontekstityönkulku: tekoälyklooni + Second Brain + kontekstisuunnittelu.

Lisää materiaaleja on saatavilla Ailootissa.