5 Lessen voor een Productief AI Engineering Team
Hoe we razendsnel code van hoge kwaliteit opleveren met Linear en Cursor
Op dit moment wordt 99% van de code in ons engineering team geschreven door AI. De veelvoorkomende angst is dat dit leidt tot ononderhoudbare “AI-slop”. De realiteit is precies het tegenovergestelde. AI stelt ons juist in staat om extreem hoogwaardige code te leveren met extreme snelheid. Als engineers met beperkte middelen moesten we vroeger altijd compromissen sluiten tussen snelheid en kwaliteit - nu kunnen we beide hebben.
De modellen zijn zeker slimmer geworden, maar de tooling is ook aanzienlijk beter geworden. Deze combinatie heeft onze volledige ontwikkel workflow getransformeerd. Traditionele Agile sprints bestaan voor ons eigenlijk niet meer. We zijn de oude rituelen voorbij en overgegaan op een continue stroom van uitvoering.
Hier is wat momenteel voor ons werkt, na veel experimenteren:
1. We geven prioriteit aan planning met AI
Hoewel “vibe coding” met AI aanvankelijk voelde alsof we snel gingen, realiseerden we ons al snel dat volledig vertrouwen op iteratief coderen vaak betekende dat we de hele dag aan het babysitten waren op de agent. In plaats daarvan verschuiven we het zware werk nu naar de planningsfase. Planning heeft nu voorrang op coderen.
Soms besteden we een hele dag alleen maar aan planning. We itereren de plannen met meerdere modellen en AI-aanbieders. We verfijnen de architectuur totdat we de perfecte specificatie hebben. We schrijven meerdere gedetailleerde tickets met heldere, atomische vereisten in Linear.
Zodra het plan vaststaat, wordt het bouwen triviaal. We wijzen Linear-tickets in bulk toe aan Cursor-agents. Soms sturen we tickets naar 20 agents tegelijk om parallel te draaien. De AI handelt de implementatie af. Het schrijft de boilerplate, verbindt de API’s en bouwt de UI-componenten. Dit verheft onze engineers van “programmeurs” tot “systeemarchitecten” die wachtrijen beheren en logica beoordelen in plaats van syntax.
2. We laten AI zijn eigen werk vinden
Een proactieve codebase is beter dan een reactieve. Wachten tot bugs worden gemeld is inefficiënt. We laten de AI in de aanval gaan. We gebruiken Cursor vaak om onze codebase proactief te scannen op mogelijkheden. Het zoekt naar technische schuld, refactors, potentiële prestatieverbeteringen en zelfs geheel nieuwe productfuncties die impliciet zijn maar ontbreken.
Eenmaal geïdentificeerd, gebruiken we Linear MCP om automatisch backlog-tickets te genereren op basis van deze bevindingen. Onze belangrijkste taak als engineering team is dan om deze tickets te prioriteren om ervoor te zorgen dat het werk met de meeste impact als eerste wordt gedaan.
Bonus: We genereren ook de agent-prompt direct in de ticketbeschrijving. Dit creëert een zelfvoorzienende cyclus waarbij het ticket klaar is om onmiddellijk terug toegewezen te worden aan een Cursor-agent. Dit vermindert de wrijving bij het starten van nieuw werk tot bijna nul.
3. We vertrouwen AI, maar verifiëren altijd
Code schrijven met AI is ongelooflijk makkelijk en snel, maar snelheid zonder stabiliteit is in feite een race naar AI-slop en technische schuld. Agents worden vertrouwd, maar alles wordt geverifieerd. We gebruiken strikte linters en rigoureuze type-checking. Een strikt mandaat van 80-100% minimale testdekking is ingesteld als niet-onderhandelbaar (een standaard die in traditionele engineering teams altijd moeilijk te prioriteren en handhaven was).
We leunen zwaar op pre-commit hooks en GitHub Actions. De workflow is binair: de gegenereerde code wordt simpelweg niet gemerged totdat deze elke afzonderlijke check doorstaat. Er zijn geen uitzonderingen voor kleine fixes. Als de dekking daalt of de linter klaagt, moet de agent het oplossen voordat een mens het ooit beoordeelt. Dit spaart de mentale energie van ons team voor het oplossen van hoogwaardige problemen.
Bonus: Alleen vertrouwen op menselijke beoordeling is riskant, omdat we last kunnen krijgen van vermoeidheid (vooral door de volumes AI-gegenereerde code die we moeten beoordelen). Daarom wordt elke PR grondig beoordeeld door CodeRabbit voordat een mens ernaar kijkt. Het analyseert de logica, controleert op beveiligingslekken en zorgt voor consistentie. We hebben zelfs een branch-regel dat alle opmerkingen van CodeRabbit moeten worden opgelost voordat een PR kan worden gemerged.
4. We leggen hard geleerde lessen vast voor AI
We hopen niet gewoon dat de AI onze stijl begrijpt; we schrijven het op. We sturen de agents met strikte, projectspecifieke regelbestanden (zoals .cursorrules). Een van de belangrijkste regels die we bijvoorbeeld voor elk project hebben, is om na elke zinvolle wijziging te committen en te pushen. Dit zorgt ervoor dat we een gedetailleerde geschiedenis hebben voor eenvoudige rollbacks als er iets misgaat (wat vaak gebeurt).
We behandelen deze regels als levende documenten van onze institutionele kennis. Elke keer dat we een nieuw probleem of een herhalend faalpatroon tegenkomen, voegen we een specifieke beperking toe aan de regels om te voorkomen dat het opnieuw gebeurt. Na verloop van tijd levert dit een geheel op waarmee we nog sneller kunnen bewegen, omdat we niet worden vertraagd door herhaalde fouten uit het verleden.
5. We zorgen ervoor dat AI een geweldige Developer Experience heeft
Investeren in Developer Experience (DX) is altijd de sleutel geweest tot productiviteit. Met AI is het het verschil tussen speelgoed en gereedschap. Een instabiele omgeving verwardt een mens, maar breekt een agent.
We investeren zwaar in robuuste test-harnassen en puppeteering-tools waarmee de AI bijvoorbeeld de browser direct kan besturen of eenvoudig een docker-omgeving kan opzetten. Dit stelt de agent in staat om meer te doen dan alleen code schrijven; het kan de app draaien, door flows klikken, de UI verifiëren en itereren totdat de oplossing daadwerkelijk werkt. Wanneer de DX is geoptimaliseerd voor machines, wordt de AI exponentieel krachtiger omdat het zijn eigen feedbackloop kan sluiten.
Natuurlijk leren we nog steeds, maken we dingen stuk en bouwen we ze beter op. Dus hoewel het bovenstaande nog kan evolueren, is dit gewoon wat momenteel voor ons werkt.
Ik ben benieuwd welk deel van de AI-native transitie klikt voor jouw engineering team, en waar je denkt dat we het misschien mis hebben. Laten we aantekeningen vergelijken!