Dive diep in Mentat-codehulp

Na een spelletje met Aider, een coderingsassistent, heb ik de afgelopen weken Mentat gebruikt om code te schrijven. Vergelijking met Aider De manier waarop het werkt is soortgelijk. Het draait op de terminal met een tekstuele UI. Het laat je zelfs een licht- of donkermodus-kleurschema instellen. Code-sessies bestaan uit het toevoegen van relevante bestanden voor context. In de chatbox maak je je wensen kenbaar en het komt terug met een actieplan dat code-veranderingen omvat. Goedkeur ze en de veranderingen worden aangebracht. De ervaring als geheel is dicht bij Aider, behalve dat Aider een git-commit maakt voor elke verandering (wat je kunt uitschakelen). Mentat laat de versiebeheer over aan jou. De kwaliteit van hoe je je wensen formuleert, bepaalt de kwaliteit van het werk. Je moet behoorlijk langdradig over zijn. Wat terugkomt is een functie van je keuze van LLM. Ik zou geen slimheid toeschrijven aan de coderingsassistenten, maar ik zou een superieure ontwikkelervaring toeschrijven aan hen als dat al het geval is. Hoe dan ook, je moet nog steeds met hen praten alsof je een onwetende stagiair bent. Contextlimiet Buiten de doos heeft Mentat een magere lijst van LLM's vergeleken met Aider (dat misschien of misschien niet verandert). Ik liet dat niet een probleem worden, ik zette het aan het werk met een coderings-LLM in Together.ai. Maar het deed er niet toe; ik liep direct tegen de contextvensterlimiet aan. Gegeven dat sommige van mijn bestanden productielengte hebben, maar ik deed er niet veel van. Ik kreeg niet eens de kans om iets slims te laten doen. Ik was vastbesloten om dit te laten werken, alleen de contextlimiet stond in de weg. De oplossing is niet om gewoon een LLM te gebruiken met een grotere contextlimiet. Er is altijd een bovengrens, je zou gewoon constant tegen die limiet aanlopen. Eigen RAG bouwen Ik hoorde dat RAG de oplossing is. Dus bouwde ik een middleware die tussen Mentat en de LLM zit. Dit is een OpenAI-compatibele REST-API (http://localhost:<port>/chat/completions) die lokaal draait, allemaal gehuisvest in één Python-bestand. Ik noem het Broken Sword voor makkelijk gebruik. Zolang Mentat is betrokken, is Broken Sword een echte LLM-service. Binnen Broken Sword vang ik Mentat's verzoeken op, masseer de inputs, stuur ze naar elke LLM die ik wil en retourneer de respons in een OpenAI-compatibele manier. Wanneer ik dit doe, zie ik de uitgebreide richtlijnen gegeven door Mentat, dat is hoe prompt-engineering eruit ziet. Alleen door dit te doen heb ik Mentat in staat gesteld om elke LLM ter wereld te gebruiken. Ik ging verder en gebruikte Google Gemini 1.5 om Broken Sword te laten werken, voornamelijk omdat het de juiste balans heeft tussen kwaliteit en kosten. Dit lost de contextvensterlimiet echter niet op. Dit is niets meer dan een glorified pipe. In plaats van inputs van Mentat letterlijk te sturen, kan de enorme hoeveelheid context worden opgeslagen in een vector-database en worden gestuurd als embeddings. Als ik het goed begrijp, worden grote stukken tekst omgezet in multidimensionale matrices van nummers. Dit is veel kleiner voor LLM's om te gebruiken dan de originele teksten. Ik maakte alles werken met LangChain (het heeft de serie van processen afgezonderd), met een vleugje Flask voor een eenvoudige API. Het voelde als vals spelen toen ik nog niet weet hoe deze magie werkt, maar ik wilde dingen snel hacken. Ik weet dat ze zeggen dat je LangChain niet echt nodig hebt en ik geloof hen, maar op een dag, man, op een dag. Het werkt Toen ik klaar was, werkte Mentat zoals het zou moeten. Ik liet het eenheidstests schrijven, het werd geschreven in de stijl die consistent is met de bestaande. Ik liet het een GitHub Actions-workflow schrijven, het resultaat was zinnig. Het was voldoening toen het werkte. Wetend dat ik het had laten werken met Broken Sword was dubbel voldoening. Dit bracht me op de vraag, waarom Mentat geen RAG of vector-database gebruikt zoals ik net deed? Het voelde bijna triviaal om het te doen. Ik bladerde door de codebase van Mentat, inderdaad, Chroma DB wordt gebruikt (dezelfde vector-db die ik gebruik). Dus misschien doen ze RAG op een manier die voor mij niet relevant is. Maar het is onhandig Naarmate ik Mentat meer en meer gebruik, wordt de onhandigheid duidelijk. Het zou van tijd tot tijd crashen. Soms omdat de LLM niet terugkwam met iets dat het leuk vond, maar meestal om redenen die mij onbekend waren. Een gracieuze mislukking is niet zijn sterkste punt. Er zouden tijden zijn dat Mentat zou crashen nadat ik een verzoek had gedaan. Na herstarten en opnieuw relevante bestanden toe te voegen, herhaalde ik hetzelfde verzoek (goed dat ze een chatgeschiedenis hebben om dit makkelijk te maken) en alles werkte goed. Mengsel van handmatige codering Een vraag die ik hoopte te beantwoorden in dit avontuur is het juiste mengsel van het gebruiken van een coderingsassistent op deze manier en direct bestanden bewerken bij het oplossen van een probleem. Als dat mogelijk is, zou alle codering dan gedaan moeten worden vanuit de coderingsassistent? Of zouden we een code-editor klaar hebben op het volgende scherm? In mijn geval is de helft van mijn scherm voor Mentat, de andere helft voor emacs. Ik verwachtte dat Mentat me de meeste dingen zou geven die ik wilde, maar niet perfect, en dat ik kleine aanpassingen zou maken aan dezelfde bestanden in emacs. Als Mentat-stijl coderingsassistent een toekomst heeft, vraag ik me af of dat de manier is waarop het zou moeten.