✒️Door: @Jan Willem Altink
📅Datum: 28 augustus 2024
🕜Leestijd: 11 minuten
Inleiding
Met de opkomst van Large Language Models zoals ChatGPT en Claude, is programmeren toegankelijker dan ooit. Dat LLMs en code een goede combinatie zijn, hadden we al snel in de gaten. GitHub Copilot, bijvoorbeeld, is alweer sinds medio 2021 beschikbaar en heeft sindsdien talloze ontwikkelaars geholpen bij het schrijven van efficiëntere en nauwkeurigere code. Meer recente voorbeelden zijn Aider, een tool die interactief samenwerken aan code mogelijk maakt, en CursorAI, een AI gedreven IDE.
Over CursorAI gesproken, check dit fantastische filmpje van een 8 jarige gebruiker:
Het is logisch dat LLM’s goed toepasbaar zijn bij coderen, ze zijn natuurlijk grotendeels getraind op data van het internet, en het internet staat vol met code. Veel modellen zijn zelfs specifiek getraind op programmeren in algemene zin of specifieke programmeertalen.
Wat mij betreft een leuke ontwikkeling: het leren van een bepaalde taal is door LLM’s geen barriere meer tussen het hebben van een idee en de uitvoer ervan. Voor mij persoonlijk geldt dat in ieder geval absoluut. Ik heb het uitdenken van algoritmes of logica altijd leuk gevonden, maar al die ingewikkelde syntax schrok me toch vaak een beetje af. Dat is inmiddels veel minder een probleem. Voor ervaren developers voor wie dat allemaal geen probleem is, bieden LLM’s een ander groot voordeel: simpele en repeterende taken kunnen veelal veel sneller gedaan worden met behulp van AI.
Claude 3.5 Sonnet
Wat mij betreft is, zelfs na de surprise update van afgelopen week van OpenAI aan GPT4-o, Claude Sonnet het fijnste model om mee te werken als het aankomt op zowel schrijfstijl als coderen. Claude Sonnet heeft een aantal voordelen:
- Een gigantische context window (200.000 tokens; dat is ongeveer 150.000 woorden, of 300 pagina’s tekst)
- Vision
- Omdat het niet het model is met het grootst aantal parameters (dat is Opus) heel betaalbaar
- ..en uiteraard alle andere capaciteiten die je zou verwachten, zoals toolcalling, een begrijpelijke API etc.
Vandaag wil ik er een ander voordeel uitlichten, de user interface. Het heeft lange tijd geduurd voor deze beschikbaar was in Nederland. De API deed het al wel, maar dat werkte toch net wat omslachtiger. Echter: het was het wachten waard want in de user interface zitten een aantal super handige concepten: projects, artifacts en de console.
Anthropic Console
De Anthropic Console is een krachtige tool die het werken met Claude aanzienlijk vergemakkelijkt. Een van de belangrijkste voordelen is de ingebouwde prompt generator, die gebruikers helpt bij het formuleren van effectieve instructies voor Claude. Dit zorgt voor consistentere en meer gerichte resultaten.
Een ander handig kenmerk is het gebruik van inline variabelen in prompts. Dit maakt het mogelijk om delen van je prompts te hergebruiken en aan te passen, wat de efficiëntie en flexibiliteit van je interacties met Claude verhoogt. Je kunt bijvoorbeeld een basisstructuur voor een prompt maken en specifieke delen gemakkelijk aanpassen voor verschillende use-cases.
Tot slot biedt de console een evaluatiefunctie. Hiermee kun je de kwaliteit en nauwkeurigheid van Claude's antwoorden beoordelen, wat waardevol is voor het verfijnen van je prompts en het verbeteren van je resultaten over tijd.
Claude Projects
Bron: Anthropic
Claude Projects is een functie die vooral nuttig is voor grotere, complexere taken die meerdere interacties vereisen. Het stelt gebruikers in staat om gerelateerde gesprekken en outputs te groeperen binnen één project, wat de organisatie en het overzicht verbetert.
Voor LLM-begrippen zijn 'complexere' projecten taken die mogelijk meerdere stappen, iteraties of verschillende typen output vereisen. Denk bijvoorbeeld aan het ontwikkelen van een volledige webapplicatie, het schrijven van een uitgebreid onderzoeksrapport, of het ontwerpen van een marketingstrategie. Het gebruik van Projects maakt het gemakkelijker om de voortgang bij te houden, eerdere resultaten te raadplegen en de context van het gehele project te behouden.
Voor mij zit er echter een groot nadeel aan het gebruik van projects; de token limit voor gebruikers binnen Claude. Claude hanteert op dit moment een behoorlijk strikte token limit, waardoor je nogal eens tegen de gebruikerslimiet aanloopt. Super frustrerend als je net lekker bezig bent. Ik heb de indruk dat documentatie die je in een claude project verwerkt niet via toolcalling of RAG wordt opgehaald door de LLM, maar gewoon onderdeel is vand e contextwindow. Dit zorgt ervoor dat je deze tokenlimit nog veel sneller bereikt.
Bovendien heb ik gemerkt dat claude een grote context niet altijd goed verwerkt. ALs je bijvoorbeeld met een code vraagstuk aanklopt is het niet ongebruikelijk dat claude in de oplossing bepaalde class definities of utilty functies herschrijft/dupliceert in plaats van een import. Ik geef er de voorkeur aan om enigszins te cherrypicken in de context die ik Claude meegeef omdat dat a: de token usage drastisch verlaagt en b: de kwaliteit van de output van Claude verbetert. Het vergt iets meer moeite, maar ik heb een werkwijze gevonden die redelijk soepel werkt (waarover straks meer).
Claude Artifacts
Claude Artifacts zijn een bijzonder handige functie die de interactie met het model aanzienlijk verbetert. Artifacts stellen Claude in staat om substantiële, zelfstandige inhoud te creëren en te beheren binnen een gesprek. Dit is vooral nuttig voor code, diagrammen, of tekstdocumenten die apart van de hoofdconversatie worden weergegeven.
Het grote voordeel hiervan is dat gebruikers deze inhoud gemakkelijk kunnen bekijken, bewerken en hergebruiken zonder door een lange chat te hoeven scrollen. Artifacts zijn ideaal voor het iteratief ontwikkelen van code, het verfijnen van technische specificaties, of het samenstellen van gestructureerde documenten. Ze bieden een duidelijke scheiding tussen de discussie over een taak en het daadwerkelijke product, wat de workflow overzichtelijker en efficiënter maakt. Bovendien kunnen Artifacts worden geëxporteerd of gedeeld, wat samenwerking en het hergebruik van waardevolle output vergemakkelijkt. Hier wat gave voorbeelden.
Tips voor co-development met Claude
1. Maak een guidelines.md
ik vind het fijn om altijd een kleine markdown te maken met wat guidelines over de structuur van mijn project, naming conventions, gebruik van code comments, docstrings, types, classes, geprefereerde pakketten etc. De reden hiervoor is dat een LLM best wel vaak geneigd is om daar in steeds net wat te variereren, wat na verloop van tijd als je de code blind zou copy pasten zorgt voor enorme spaghetti. Los van het feit dat je deze markdown aan de LLM kunt meegeven bij het genereren van output, helpt het jezelf ook om dit vast te leggen, zodat je de door de LLM gegenereerde output op deze punten kunt valideren.
2. Cherrypick de context
Zoals al eerder beschreven ben ik er fan van om de context die we meegeven aan de LLM te cherry picken. Dit zorgt dat de focus op de juiste onderdelen van de code ligt en houdt het aantal gebruikte tokens behapbaar. Omdat het lastig is om steeds opnieuw 20 bestandjes te copy pasten, hieronder een korte uitleg over mijn werkwijze. Binnen elk project heb ik in de root altijd een werkmapje “dev” of iets dergelijks. ik zet daarin altij een tekstfile dev/generate_markdown.txt
. in deze tekstfile zet ik, als ik bestandjes wil delen voor een request/vraag aan claude alle paden van die bestandjes, bijvooorbeeld (altijd de guidelines uit stap 1 plus een lijst bestandjes):
/Users/jw/developer/ZenFiles/src/zenfiles/guidelines.md
/Users/jw/developer/ZenFiles/src/zenfiles/main.py
/Users/jw/developer/ZenFiles/src/zenfiles/explore/analyzer.py
/Users/jw/developer/ZenFiles/src/zenfiles/explore/config.py
/Users/jw/developer/ZenFiles/src/zenfiles/explore/file_utils.py
/Users/jw/developer/ZenFiles/src/zenfiles/explore/markdown_converter.py
/Users/jw/developer/ZenFiles/src/zenfiles/explore/overview_generator.py
/Users/jw/developer/ZenFiles/src/zenfiles/explore/tree_generator.py
Ik heb ook een klein shell script geschreven waarmee ik de locatie plus de inhoud van de bestanden die ik wil delen in een markdown zet. Het scriptje rekent ook al vast even het aantal tokens en karakters uit en print deze naar de terminal, ook copy paste het de inhoud van de markdown. zodat ik in Claude alleen nog maar even een nieuwe chat hoef te starten en te pasten om mijn vraag te stellen en precies de juiste context mee te geven. Het voordeel van handmatig knippen en plakken zit hem er vooral in als je wat meer dan 1 vragen hebt, het is veel sneller om even een nieuwe markdown te genereren door het script te rerunnen dan steeds alles opnieuw te copy pasten. Vermoed dat het alleen op Mac werkt, maar dit is het script dat ik op dit moment gebruik:
3. Wees extra kritisch op de volgende aspecten van de door Claude gegenereerde code
- Is er geen functionaliteit verdwenen? Ik zet het ook altijd in het prompt, want Claude heeft de neiging soms code ongevraagd weg te laten. kijk secuur of er onverwacht geen code is verdwenen
- Is er duplicate code bijgekomen? Met het cherrypicken van de context wordt het vaak al een stuk beter, maar het kan voorkomen dat bepaalde uitilty functies bijvoorbeeld toch dubbel worden gedefinieerd, ik vind vaak dat Claude niet alle overkoepelende utils en classes etc. correct toepast.
4. ga niet te lang door op een fout spoor
Als gegenereerde code van Claude niet direct werkt en je ziet de fout niet direct, ga niet telang door met het fixen van de fout, het steeds toevoegen van foutlogs aan de chat in de hoop dat een volgende iteratie wel werkt is zelden succesvol. Claude fixeert zich naarmate zo’n gesprek waarbij je steeds de fout logs deelt steeds meer op specifieke errors en vergeet de context, ook zie je claude vaak heen en weer pingpongen tussen 2 of 3 dezelfde fouten. Ikzelf doe nooit meer dan 2 pogingen binnen een chat. Het is handiger om bij foutief gegenereerde code even een nieuwe chat te starten en je prompt iets te optimaliseren.
5. wees alert op het gebruik van gedateerde packages of concepten
ik heb de indruk dat de cut off date van Claude wat minder recent is dan nieuwere versies van ChatGPT. Check bij het gebruik van bepaalde packages of toepassingen door de LLM goed of de gebruikte code up to date is, metname als je werkt met packages die veel veranderen, zoals LangChain. Ook de Docker Compose files en instructies die Claude geeft zijn meestal gedateerd heb ik gemerkt.
Tot slot
Dat waren mijn ervaringen met het gebruik van Large Language Models, met name Claude 3.5 Sonnet, voor programmeren. Maar wat vandaag werkt, kan morgen anders zijn. Nieuwe modellen en functionaliteiten verschijnen regelmatig, en best practices evolueren mee. Bovendien leer ik ook nog bijna dagelijks bij. Daarom is het lastig om definitieve conclusies te trekken.
Ik ben benieuwd naar jullie ervaringen. Heb je andere manieren gevonden om LLMs in je ontwikkelproces te integreren? Tegen welke uitdagingen ben je aangelopen?
-JW