Maakt eerst een spec schrijven het team niet trager?

Minder dan de verkeerde wijziging reviewen. CodeLynq schrijft de conceptspec in een paar minuten; een spec goedkeuren die klopt is één klik. De tijd gaat naar beslissingen die anders, slechter, tijdens de code review genomen worden.

Wie keurt de spec goed?

Wie je team daarvoor aanwijst: een tech lead, de product owner of de developer die om de wijziging vroeg. De goedkeuring wordt vastgelegd bij de versie van de spec.

Wat als de spec niet blijkt te kloppen?

Pas hem aan en keur de nieuwe versie goed, of stuur de run terug met feedback. De volgende run bouwt tegen de laatst goedgekeurde versie.

Is dit hetzelfde als test-driven development?

Ze vullen elkaar goed aan. De spec bevat een teststrategie, en de run draait je testsuite voordat hij een pull request opent.

Spec-driven development met een AI coding agent

Wat is spec-driven development?

Spec-driven development is een manier van werken met AI coding agents waarbij een geschreven specificatie wordt afgesproken voordat er code wordt gegenereerd. De spec beschrijft het beoogde gedrag, de technische aanpak, welke delen van de codebase geraakt worden, de risico's en hoe het getest wordt. De agent bouwt tegen die spec, en het werk wordt beoordeeld op de spec, niet op een prompt van één regel.

Het bestaat omdat een AI-agent doet wat hem gezegd wordt, snel en vol overtuiging. Is de opdracht vaag, dan komt het misverstand pas in de review boven, als de code al geschreven is. Een spec haalt dat gesprek naar het begin, waar bijsturen een zin kost in plaats van een herschrijving.

Hoe CodeLynq het doet

Intake. Een verzoek komt binnen als notitie, vergadering, alert of een paar regels die je in CodeLynq typt.
Conceptspec. CodeLynq schrijft een technische spec op basis van je codebase: functionele interpretatie, technische aanpak, betrokken componenten, impact op datamodel en API, risico's, teststrategie en aannames.
Open vragen. Wat het verzoek onduidelijk laat, wordt in een validatiechat gevraagd in plaats van gegokt.
Goedkeuring. Iemand in je team keurt de spec goed. Op een taak die niet is goedgekeurd kan geen run starten.
Bouwen. De agent bouwt tegen de goedgekeurde versie, draait je tests, reviewt en scant zijn eigen diff en controleert je architectuurregels.
Pull request. De PR verwijst naar de taak en naar de exacte versie van de spec waarop hij gebouwd is.

Waarom een spec beter werkt dan een prompt

Misverstanden vang je in een alinea, niet in een diff van 400 regels.
Wie de spec goedkeurt, hoeft geen code te lezen om te weten wat er gebouwd wordt.
Reviewers toetsen de code aan een afgesproken bedoeling; dat maakt reviewen sneller en minder subjectief.
Elke wijziging heeft een geschreven reden die langer meegaat dan de chat waar hij vandaan kwam.

Specs geschreven op je echte codebase

Een spec is zo goed als wat de schrijver over de code weet. CodeLynq leest de structuur van je repositories, je conventies en wat eerdere reviews hebben geleerd, zodat 'betrokken componenten' echte bestanden en afhankelijkheden noemt in plaats van gokken. De architectuurregels van je team zitten in elke spec en elke run.

Vragen over spec-driven development

Maakt eerst een spec schrijven het team niet trager?: Minder dan de verkeerde wijziging reviewen. CodeLynq schrijft de conceptspec in een paar minuten; een spec goedkeuren die klopt is één klik. De tijd gaat naar beslissingen die anders, slechter, tijdens de code review genomen worden.
Wie keurt de spec goed?: Wie je team daarvoor aanwijst: een tech lead, de product owner of de developer die om de wijziging vroeg. De goedkeuring wordt vastgelegd bij de versie van de spec.
Wat als de spec niet blijkt te kloppen?: Pas hem aan en keur de nieuwe versie goed, of stuur de run terug met feedback. De volgende run bouwt tegen de laatst goedgekeurde versie.
Is dit hetzelfde als test-driven development?: Ze vullen elkaar goed aan. De spec bevat een teststrategie, en de run draait je testsuite voordat hij een pull request opent.