Deep Dive - Claude AI als Pair Programmer

Laten we eerst het probleem oplossen

In dit scenario gaan we ervan uit dat je een winkelwagen module moet bouwen die geïsoleerd in je codebase moet leven, maar wel events moet ontvangen wanneer nieuwe items aan de winkelwagen worden toegevoegd. Onze codebase is in dit geval een React/NextJS applicatie.

De kritieke delen van de criteria zijn de isolatie en modulariteit - dit moet overal in je codebase kunnen leven maar wel reageren op wat er gebeurt. Als junior weet je misschien nog niet precies hoe je dit moet oplossen, maar iemand in je team noemde het gebruik van Context Providers om de event triggers en listening af te handelen.

Claude, ik moet context providers gebruiken om items in mijn winkelwagen te beheren, aangezien de componenten in verschillende delen van mijn codebase zijn opgenomen. Kun je me een voorbeeld laten zien van hoe ik een context provider kan schrijven om state/event updates te verzenden en te luisteren

Dit type prompt geeft je een mooie initiële basis om je oplossing op te baseren. Kopieer en plak niet simpelweg of vraag de AI niet om dit voor je toe te passen. Begin in plaats daarvan met het zelf implementeren, waarbij je de voorbeeldcode als basis gebruikt.

Dit zal verifiëren dat je de implementatielocaties en specifieke details begrijpt. Als er dingen fout gaan, kun je beginnen te zien waarom - was het jouw begrip? Had Cursor het fout? Je kunt beginnen met vergelijken en zelf debuggen.

Inzichten verzamelen over je code

In het vorige voorbeeld hebben we Cursor gebruikt om ons te helpen en ons te introduceren aan een specifiek patroon dat vaak wordt gebruikt in React en NextJS. We hebben het handmatig geïmplementeerd en het proces doorlopen om de feature te voltooien.

Nu kunnen we een stap verder gaan voordat we de code ter review indienen door Claude te vragen om mogelijke verbeteringen voor te stellen:

Claude, zijn er optimalisaties of een betere aanpak die ik had kunnen maken om deze winkelwagenfunctionaliteit in de frontend te laten werken

Het antwoord zal waarschijnlijk dingen noemen als: Context Splitting, Memoization, localStorage persistence, SSR compatibility en waarschijnlijk meer.

Dit wordt interessant, want als senior developer kan ik beter de waarde zien in context splitting en SSR compatibility maar ben ik minder geneigd om localStorage of Memoization te gebruiken omdat het account object de winkelwagen opslaat (database) en de winkelwagen niet vaak genoeg update om Memo betekenisvolle prestatievoordelen te laten bieden.

Als Junior Developer ken je de impact misschien niet en implementeer je mogelijk alle suggesties. Dit zou een uitstekend moment zijn om iemand in je team te vragen om een snelle review van de suggesties en huidige code. Ze kunnen uitleggen wat in dit geval echt van toepassing is terwijl je handmatig je code begint te refactoren om de waardevolle optimalisaties te ondersteunen.

Het Merge Request maken

In dit stadium hebben we Cursor gebruikt om ons te helpen een nieuwe aanpak te leren, die aanpak te optimaliseren en waardevolle discussies met het team te voeren over micro-optimalisaties en over-optimalisaties.

Ervan uitgaande dat je organisatie linting tools en pre-commit hooks gebruikt om codeconsistentie in je codebase te waarborgen. Als je dit soort tools niet gebruikt, kun je Claude vragen om je project te linten op basis van de omringende codebase.

ECHTER - Ik raad aan om dit als een aparte commit te doen, zodat je je wijzigingen kunt onderscheiden van Claude's linting wijzigingen, waardoor het makkelijker wordt om terug te draaien indien nodig. Deze scheiding zorgt ervoor dat je een duidelijk zicht houdt op je daadwerkelijke wijzigingen versus geautomatiseerde formatteringswijzigingen.

Werken met Templates

Op dit niveau kan Cursor ons helpen met veel van het routinematige werk. Met hetzelfde scenario als hierboven kunnen we uitgebreidere prompts schrijven omdat we al weten welk type code we willen maken.

Claude, schrijf voor mij een context provider vergelijkbaar met #account-context.js maar in dit geval zal het een winkelwagen zijn, die de informatie opslaat in de account context met behulp van de UpdateAccount() methode, we hebben de typische functies nodig van toevoegen, verwijderen, verhogen etc van items in onze winkelwagen, link terug naar de winkel item detail pagina etc etc

Dit zal een template genereren gebaseerd op bestaande oplossingen, met de optimalisaties die we zoeken al inbegrepen.

De Impact van Technologie Populariteit

Door mijn ervaring heb ik gemerkt dat de kwaliteit van AI-assistentie aanzienlijk verschilt op basis van de populariteit en documentatie van de technologie. Deze variatie is begrijpelijk - LLMs kunnen alleen zo goed zijn als hun trainingsdata, en minder gebruikte technologieën hebben natuurlijk minder voorbeelden om van te leren.

Laat me dit illustreren met drie praktijkvoorbeelden uit hetzelfde project:

• Warcraft Logs: Als een nichedienstmet beperkte documentatie bleek het werken met deze API uitdagend. Cursor had moeite om betekenisvolle templates of oplossingen te bieden, wat veel handmatig werk en meerdere iteraties vereiste om de juiste querystructuren te bepalen.

• Prismic: Ondanks dat het breder geadopteerd is en betere documentatie heeft, waren de AI-suggesties voor Prismic-integratie nog steeds suboptimaal. De resultaten waren echter merkbaar beter dan met Warcraft Logs, wat laat zien hoe toegenomen adoptie de AI-assistentie verbetert.

• WordPress: Hier schitterde AI echt. Met WordPress's uitgebreide documentatie, talrijke repositories en wijdverbreid gebruik, was de kwaliteit van suggesties en gegenereerde code aanzienlijk hoger. Queries en prompts produceerden consistent nauwkeurigere en bruikbaardere resultaten.

Dit patroon kwam naar voren tijdens het bouwen van hetzelfde project, waar ik zowel Prismic- als WordPress-oplossingen implementeerde met Warcraft Logs als databron. Het contrast in AI-assistentiekwaliteit was opvallend en correleerde direct met de adoptiegraad en documentatiebeschikbaarheid van elke technologie.

Bedrijfslogica Overwegingen

Dit geldt ook voor je bedrijfslogica - je dataformaat en workflow kunnen vergelijkbaar zijn maar net verschillend genoeg om meer ruis, overreach en problemen te veroorzaken tenzij je je verzoeken beperkt tot specifieke zaken en kleinere iteratieve wijzigingen maakt.

Alternatieve Tools en Benaderingen

De eenvoudigste aanpak is het vermijden van editors of extensies zoals Cursor, waardoor bugs, technische fouten of gebruikersfouten je code niet naar de cloud kunnen sturen.

Als je deze tools gebruikt, probeer dan te zorgen dat je een door het bedrijf beheerd account hebt waar je data kunt verwijderen. Dit vereist echter nog steeds vertrouwen in de service en zijn betrouwbaarheid met je geïndexeerde code.

Claude.ai op het web biedt een mooie oplossing, waarmee je prompts, voorbeeldcode en context kunt geven terwijl je volledige controle houdt over wat er voor verwerking wordt verzonden.

Data Anonimisering

Denk in 'herkenbare' termen bij het interacteren met AI's.

Bijvoorbeeld, bij het bouwen van belastingsoftware of iets voor lokale energietransitie-initiatieven - politieke en gevoelige onderwerpen waar informatielekken publieke bezorgdheid kunnen veroorzaken - benader het voorzichtig.

Voor energietransitiewerk, schrijf context-bewuste maar niet data-bewuste prompts: Ik heb een functie nodig die de geproduceerde gigawatturen neemt en het transformeert naar dit formaat: XYZ, maar ook in ABC en EFG gebaseerd op props. Dit geeft je wat je nodig hebt zonder specifieke data of waarden bloot te leggen.

In een alternatief geval zou je kunnen denken aan het doorgeven van een echte API-response met echte waarden, maar dit zou gevoelige informatie kunnen bevatten over energiegebruik in specifieke gebieden of door specifieke klanten.

Meer dan Tijdsbesparing

Interessant genoeg leidt het gebruik van Cursor niet altijd tot directe tijdsbesparing. De echte waarde ligt echter in het stroomlijnen van het ontwikkelingsproces en het bieden van gestructureerde startpunten die de besluitvorming later in het proces kunnen verbeteren.

Het voordeel zit niet noodzakelijk in het sneller schrijven van code, maar in het verminderen van cognitieve belasting en het behouden van betere mentale helderheid tijdens het ontwikkelingsproces. Dit stelt ontwikkelaars in staat hun energie te richten op kritisch denken en probleemoplossing in plaats van routinematige implementatiedetails.

De Mythe van AI Vervanging

Hoewel er overtuigende verhalen zijn over complete SaaS-oplossingen die puur met AI-assistentie zijn gebouwd, moeten we deze claims zorgvuldig benaderen. Ja, AI is misschien in staat om MVP-niveau applicaties of templates te genereren, maar dit roept belangrijke vragen op over codekwaliteit en onderhoudbaarheid op lange termijn.

Overweeg deze belangrijke zorgen:

• Hoe goed begrijpt de ontwikkelaar de gegenereerde codebase?
• Wat gebeurt er als dingen kapot gaan of externe afhankelijkheden veranderen?
• Wie onderhoudt en debugt deze code in de toekomst?

Het is vergelijkbaar met constructie: het gebruik van goedkopere materialen lijkt misschien in eerste instantie kosteneffectief, maar er is meestal een goede reden waarom bepaalde standaarden bestaan. Hetzelfde principe geldt voor softwareontwikkeling - een oplossing die volledig door AI is gegenereerd werkt misschien vandaag, maar kan morgen een onderhoudsnachtmerrie worden.

De werkelijke kosten van een door AI gegenereerde oplossing openbaren zich vaak pas na verloop van tijd. Hoewel het in eerste instantie sneller en goedkoper lijkt, kunnen het gebrek aan diep begrip en potentiële kwaliteitsproblemen op lange termijn leiden tot aanzienlijk hogere kosten. Net als bij constructie, loont het zelden om shortcuts te nemen in softwareontwikkeling.