Het grootste deel van een backlog wordt in vergaderingen bepaald. Iemand zegt "de export loopt vast bij grote klanten", iemand anders zegt "en op de factuurpagina moeten ook creditnota's staan", en allebei belanden ze in een notitiedocument dat niemand meer opent. Een week later is de opvolging een herinnering, en is de backlog wat iemand toevallig de energie had om in de tracker te typen.
Voor dat gat bouwden we in CodeLynq twee stappen: notities omzetten in taken, en de backlog groomen waar die taken in terechtkomen. Allebei doen ze een voorstel. Een mens beslist.
De notities naar binnen
Er zijn twee manieren. Je plakt ruwe vergadernotities in een project, of je importeert een vergadering uit Fireflies. Een organisatie koppelt Fireflies één keer met een API-key; daarna kan iedereen in een project een recente vergadering uit een lijst kiezen en bepalen wat er geïmporteerd wordt: de Fireflies-samenvatting met de actiepunten, het volledige transcript met sprekers, of "auto", dat de samenvatting neemt als die er is en anders het transcript.
Plaud zit er nog niet in, en dat zeggen we liever hier dan dat je het in de instellingen ontdekt. De enige programmatische toegang die Plaud nu biedt, is een MCP-server die in je eigen client draait, en die kan onze backend niet aanroepen. Daarom staat er bij Plaud in de app dat het eraan komt. Tot dat verandert, plak je Plaud-notities gewoon zoals andere notities. Importeren is ook een keuze die je per vergadering maakt: er wordt niets automatisch volgens een schema binnengehaald.
Van notities naar taken
Het model leest de titel van de vergadering en de tekst, en geeft alleen technisch werk terug. Elke taak krijgt een titel, een beschrijving, een type (feature, bugfix, refactor of chore) en een prioriteit. "Vervolgafspraak plannen" en "de klant mailen" laat het bewust weg: een backlog vol agendaherinneringen is geen backlog.
Elke gevonden taak wordt als concept aangemaakt en blijft gekoppeld aan de vergadernotitie waar hij uit komt, zodat je zes weken later nog ziet in welk gesprek een taak begon. Er draait niets. Een concepttaak heeft nog geen specificatie, en er wordt geen code geschreven voordat een specificatie is goedgekeurd.
Wat het extraheren niet doet, is ook goed om te weten. Het leest de notities, niet je code, dus "repareer de export" wordt een taak met een redelijke beschrijving maar zonder idee waar die export zit. Het vergelijkt niet met je bestaande backlog, dus de derde vergadering over dezelfde bug levert de derde taak over die bug op. En als de aanroep van het model mislukt, wordt de notitie opgeslagen zonder taken. Wij leggen die fout aan onze kant vast, maar op je scherm ziet het eruit als een vergadering waar niets uit kwam. Had een vergadering duidelijk werk opgeleverd en is de lijst leeg, probeer het dan opnieuw.
Grooming: een voorstel, geen besluit
Staan de taken erin, dan kan een projectbeheerder de backlog groomen. CodeLynq neemt elke open taak in het project (niet gearchiveerd, niet klaar, niet mislukt) samen met wat het project over zichzelf weet: de tech stack, architectuurprincipes, codeerafspraken, domeinkennis en randvoorwaarden. Het model krijgt de rol van engineering lead en geeft per taak terug:
- Een prioriteit: laag, gemiddeld, hoog of kritiek.
- Een schatting: S, M, L of XL.
- Een onderbouwing: één zin die de schatting uitlegt.
- Een rang: een plek in één volgorde voor de hele backlog, 1 eerst, op basis van afhankelijkheden, urgentie en waarde.
Op dat moment wordt er niets opgeslagen. Je krijgt een tabel met elke taak, wat die eerst was ("was gemiddeld/M") en wat er wordt voorgesteld, en je kunt elke prioriteit, schatting of rang aanpassen voordat je het toepast, of het hele voorstel weggooien. Bij toepassen wordt elke waarde gecontroleerd en komt er een regel in het auditlog, zodat je later ziet wie een rangorde accepteerde en wanneer. Schattingen en rangen blijven daarna op de taak met de hand aan te passen.
We maakten grooming een voorstel om dezelfde reden dat de AI bij ons niet mag mergen. Een rangorde is een oordeel over je bedrijf: welke klant zit te wachten, welke deadline is echt, welk "kritiek" werd uit frustratie gezegd. Het model ziet tekst. Het is goed in zien dat taak zeven afhangt van taak twee en dat een tekstwijziging van één regel geen L is. Het kan niet weten dat de directievergadering donderdag is.
Waar de schatting voor is
De onderbouwing staat er zodat je er snel tegenin kunt gaan. "M: raakt het export-endpoint en de achtergrondtaak" vertelt je wat het model aannam. Weet jij dat de export vorige maand is herschreven, dan maak je er S van en ga je door.
De schatting doet later ook werk. Als een taak draait, is de omvang een van de dingen die bepalen welk model hem bouwt, zoals we beschreven in wat een AI-run echt kost. Een onterechte XL op een kleine chore betekent betalen voor een zwaarder model dan nodig, nog een reden waarom de schatting van jou is om te corrigeren.
De eerlijke grens: grooming leest de taaktekst en de projectcontext, niet de repository. Een S op een taak die die ene module raakt waar iedereen bang voor is, is een gok op basis van de beschrijving. De omvang die standhoudt komt later, als de specificatie tegen de code wordt opgesteld en de bestanden noemt die veranderen.
De praktische versie
Zie de vergadering als de input en beoordeel twee keer: één keer als de taken uit de notities komen (verwijder wat geen werk is, en de dubbelingen), en één keer als het groomingvoorstel terugkomt (pas de rangen aan die jij beter weet). Geen van beide kost veel tijd, want je corrigeert een concept in plaats van er een te schrijven. Daarna gaat elke taak door een specificatie voordat er code wordt geschreven, en daar begint spec-driven development. Neem je vergaderingen op, dan is de Fireflies-integratie de kortste weg om het te proberen.