Zo configureerde ik Pi als code-agent: LSP, MCP, skills en extensies

Er wordt me regelmatig gevraagd hoe ik mijn code-agent heb geconfigureerd. Het korte antwoord is één zin: ik gebruik Pi en voeg dan alleen de onderdelen toe die ik echt nodig heb. Het nuttige antwoord vereist echter een heel artikel.

Pi is niet de meest spectaculaire agent om te tonen in een video. Hij komt niet aan met een controlekamer, twaalf digitale personages en een knop die een heel team zou moeten vervangen. Hij lijkt in de eerste plaats op een interface in een terminal. Dat is precies wat me aansprak: in plaats van een fabriek op te dringen, geeft hij me een kleine, begrijpelijke en uitbreidbare kern.

Waarom minimalisme meer telt dan een lange lijst aan functies

Ik heb dit scenario al meegemaakt met veel software. Aanvankelijk voert een programma een taak uitstekend uit. Dan voegt elke versie een reader, een converter, een synchronisatiehulp, een assistent, een winkel en drie panelen toe die niemand zich nog herinnert. De software start uiteindelijk op als een klein besturingssysteem, terwijl ik gewoon een schijf wilde branden, een bestand bewerken of een commando uitvoeren.

Pi hanteert de omgekeerde logica. Het herinnert me aan wat ik zo waardeer aan een minimale Linux-distributie: de basis doet niet alsof het je ideale omgeving kan raden. Ik bouw stap voor stap die omgeving die bij mij past. Deze soberheid is geen esthetische grill. Hoe minder regels, tools en onnodige servers de agent laadt, hoe beter ik begrijp wat hij doet, hoe minder tokens ik verspil en hoe makkelijker ik de oorzaak vind van vreemd gedrag.

Maar wees eerlijk: «minimaal» betekent niet «magisch eenvoudig». Een uitbreidbare tool laat je ook kiezen, installeren en onderhouden welke extensies je wilt. Pi past bij mij omdat ik de werking graag doorgrond. Zoek je een volledig voorgeconfigureerd product, dan kan deze vrijheid als extra werk overkomen.

Installatie en werkruimte

De officiële installatie past in één commando op macOS of Linux. Zoals altijd bij een extern script, raad ik aan de herkomst te controleren voordat je het uitvoert:

curl -fsSL https://pi.dev/install.sh | sh

Je kunt ook via npm gaan — met een recente versie van Node.js — en er bestaat een aparte procedure voor native Windows. Eenmaal geïnstalleerd, controleer ik direct de versie, ga ik naar de projectmap en start ik Pi vanaf daar. De startmap doet ertoe: hij wordt gebruikt om instructies te vinden en sessies te groeperen.

pi --version
cd /pad/naar/het/project
pi

De hier getoonde configuratie komt overeen met Pi 1.0.4, de versie die ik tijdens mijn test heb gebruikt. Het project ontwikkelt zich snel: met pi update update je een installatie die met het script is gedaan, terwijl een npm- of Nix-installatie wordt bijgewerkt met zijn eigen beheerder. Het is een klein detail, maar het voorkomt dat je denkt dat een functie ontbreekt terwijl je gewoon een oude versie draait.

Pi werkt in de terminal, maar de terminal is geen detail. Ik gebruik Kitty en zijn tabbladen om mijn projecten te scheiden, en Zellij binnen elk tabblad. Ik houd vaak de code in één paneel, Pi in een tweede, het ontwikkelproces in een derde, en tests, logs of een externe omgeving in een vierde. Zo zie ik direct of de wijziging compileert, of de server herstart en of de fouten veranderen terwijl de agent werkt.

Het is geen verplichting: tmux, een standaardterminal of die van je editor werken ook prima. Het doel is niet om mijn scherm pixel-perfect na te bootsen, maar om die ene terminal te vermijden waarin Pi, de server en tests elkaar verdringen. Een agent wordt veel aangenamer als zijn werk waarneembaar blijft.

De gebruikersconfiguratie bevindt zich in ~/.pi/agent/. Pi kan ook een projectspecifieke configuratie lezen. Deze scheiding is gezond: mijn persoonlijke voorkeuren en inloggegevens mogen niet in de repository belanden, terwijl architectuurregels en testcommando's wel met het team gedeeld moeten kunnen worden.

In de projectmap leven uitvoerbare instellingen vooral in .pi/: .pi/settings.json, .pi/mcp.json, lokale extensies, skills, prompts en thema's. Pi laadt deze configuratie pas nadat het projectvertrouwensbesluit is genomen. Contextbestanden worden daarentegen ontdekt in de huidige map en zijn bovenliggende mappen. Na een handmatige wijziging laadt /reload de bronnen opnieuw zonder een volledige herstart af te dwingen.

De exacte mapstructuur kan met Pi evolueren. Ik controleer daarom altijd de documentatie van de geïnstalleerde versie in plaats van blindelings een configuratie te kopiëren die ik zes maanden geleden heb gevonden.

Het model eerst, de accessoires daarna

Een agent zonder model is slechts een mooie toollus. De eerste echte stap is daarom de provider verbinden met /login en dan het model kiezen met /model. Het redenniveau stel je in met /thinking wanneer het model dat ondersteunt.

Voor een ingebouwde provider verkiezen ik dit pad boven het direct maken van een uitgebreide models.json. Dit bestand wordt nuttig voor een compatibel endpoint, een lokaal door Ollama, LM Studio of vLLM geleverd model, of een interne infrastructuur. Lokaal betekent overigens niet automatisch snel: een klein model kan volstaan voor zoeken of classificeren, maar een refactoring door een monorepo heen vereist veel meer redenering en context.

Hier is een opzettelijk minimaal voorbeeld voor Ollama. De sleutel is nep — Ollama negeert hem — en het adres wijst naar de lokale machine. Voor een geauthenticeerd endpoint verwijs ik naar een omgevingsvariabele in plaats van het geheim in heldere tekst te noteren.

{
  "$schema": "https://pi.dev/schemas/models.schema.json",
  "providers": {
    "ollama": {
      "baseUrl": "http://localhost:11434/v1",
      "api": "openai-completions",
      "apiKey": "ollama",
      "models": [
        { "id": "qwen2.5-coder:7b" }
      ]
    }
  }
}

De modelnaam volstaat niet. Je moet ook rekening houden met de capaciteiten, de contextvenstergrootte en de redenniveaus. Sommigen bieden alleen low, medium en high; anderen voegen xhigh of max toe. Pi beperkt /thinking normaal gesproken tot de door het model aangegeven niveaus. In de selector slaat Ctrl+S het model of het standaardniveau op, terwijl Ctrl+P snel door de toegestane modellen bladt. Een sessie onthoudt ook modelwisselingen: hervatten herstelt die keuze zonder het standaardgedrag voor nieuwe sessies te wijzigen.

Ik zet nooit een API-sleutel in AGENTS.md of in een voorbeeld dat voor de repository bedoeld is. Inloggegevens blijven in het daarvoor bestemde mechanisme. Het klinkt voor de hand liggend, maar agents lezen precies de bestanden die je ze geeft: een sleutel die «tijdelijk» in een instructie staat, belandt zeer snel in een sessie, een log of een commit.

Waarom ik de systeemprompt met rust laat

Dit is een sterke verleiding: SYSTEM.md direct herschrijven om een «perfecte» agent te krijgen. Dat is ook een goede manier om instructies te wissen die Pi gebruikt voor zijn tools en interface. Ik vervang het systeem alleen als ik precies weet wat ik wil verwijderen en welke gevolgen ik accepteer.

In de meeste projecten volstaat AGENTS.md. Ik beschrijf daar de architectuur, commando's, conventies, wat verboden is en wat «af» betekent. Een algemene regel kan in het gebruikersbestand; een repositoryregel blijft in de repository. Zo krijg ik een consistente agent zonder de motor te transformeren.

# Project
- Bestaande code lezen voordat een architectuur wordt voorgesteld.
- Betrokken tests uitvoeren na elke wijziging.
- Nooit reeds uitgewerkte migraties wijzigen.
- De diff en risico's presenteren voordat onomkeerbare acties worden ondernomen.
- De commando's gebruiken die in package.json zijn gedefinieerd.

LSP: de eerste extensie die ik installeer

Als ik maar één verbetering voor het codeerwerk mocht behouden, dan was het het Language Server Protocol. Zonder LSP inspecteert de agent het project met tekstzoekopdrachten, leest bestanden en leidt hij relaties af. Dat is nuttig, maar hij blijft deels blind voor de structuur die de compiler en de editor begrijpen.

Met een languageserver kan hij vragen waar een symbool is gedefinieerd, welke verwijzingen er naar wijzen, welk type er wordt verwacht, welke fouten er zijn en welke bestanden worden beïnvloed door een hernoeming. Voor TypeScript heb je de TypeScript-server nodig; voor Go gopls; voor elke taal het passende onderdeel. De Pi-extensie vervangt die server niet: hij geeft er toegang toe.

Het is een tweelaags opbouw die ik onvoldoende heb uitgelegd. Je moet eerst de echte languageserver op de machine installeren, en dan de extensie die zijn functies aan Pi blootlegt. Alleen de extensie installeren laat gopls, typescript-language-server, Pyright of rust-analyzer niet plotseling verschijnen.

pi install npm:pi-lsp-extension

# daarna, in Pi
/reload
/lsp doctor

De naam en opties van de extensie kunnen evolueren, en er zijn meerdere LSP-implementaties in de catalogus. Ik controleer daarom de bron en kies degene die bij mijn taal past. De nuttige controle is eenvoudig: de server moet actief lijken, en een verzoek om definitie, verwijzingen of diagnostics moet de LSP-tool daadwerkelijk activeren. Alleen een pakket installeren bewijst niet dat de agent het gebruikt.

Het verschil is niet theoretisch. Bij een zoekopdracht naar verwijzingen vond grep dertig voorkomen. De LSP identificeerde er vijfendertig, verdeeld over drie bestanden, omdat hij het symbool begreep en niet alleen de tekenreeks. Vijf vergeten verwijzingen zijn meer dan genoeg om een «eenvoudige» hernoeming te veranderen in een vrijdagmiddagbug.

LSP maakt het model niet foutloos. Het geeft het gewoon een nauwkeurigere kaart. Ik vraag het nog steeds om implementaties te lezen, tests uit te voeren en de diff te tonen. Maar ik geef de voorkeur aan een agent die de compilerkaart raadpleegt boven een agent die de routes raadt door naar borden te kijken.

RAG: nuttig voor kennis, niet als decoratie

Tekstzoekopdrachten beantwoorden goed «waar komt deze functie voor?». Ze antwoorden minder goed op «welke documenten verklaren ons retentiebeleid?» wanneer de teksten andere woorden gebruiken. Daar kan een RAG-systeem interessant worden.

Het principe is eenvoudig: documenten worden gesneden, omgezet in vectoren en opgeslagen in een geschikte database, bijvoorbeeld Qdrant. De vraag ondergaat dezelfde transformatie. Het zoeken levert semantisch nabije passages op, zelfs als ze de zoektermen niet exact bevatten. Pi kan ze daarna als context gebruiken.

Ik heb dit type dienst via MCP gekoppeld, met een paar duidelijke acties: documenten toevoegen, zoeken, verwijderen en de status controleren. Het werkt goed voor uitgebreide documentatie, technische beslissingen, een corpus van procedures of meerdere repositories. Voor een klein project van twintig bestanden is het vaak een onnodige complicatie. LSP en een klassieke zoekopdracht zijn daar eenvoudiger, lichter en beter te beheersen.

Zo ziet mijn lokale RAG eruit

Mijn installatie is geen mysterieuze cloud. Qdrant draait in Docker als vector database. Een kleine RAG-dienst, gestart naast de modelserv, zet documenten om in embeddings en blootstelt een paar bewerkingen: toevoegen, zoeken, verwijderen en gezondheidscontrole. Een MCP-server vertaalt die bewerkingen daarna naar tools die Pi kan aanroepen. Ik kan de processen zien, de dienst herstarten en Qdrant ondervragen onafhankelijk van de agent.

Pi
 └─ Lokale MCP-rag
     └─ RAG-dienst
         ├─ embeddings
         └─ Qdrant in Docker

In mijn geval gebruikt deze RAG ook om een grote stroom publicaties te filteren. Een letterlijke zoekopdracht op «roze bestelbus» levert mogelijk geen tekst op over een «rode vrachtwagen», terwijl semantische nabijheid beide onderwerpen als verwijd kan beoordelen. Ik gebruik dit principe om inhoud te vergelijken met mijn interesses en te classificeren. Het is een goed voorbeeld van wat RAG echt toevoegt: geen magische geheugen, maar herstel op betekenis.

Mijn set MCP-servers, en waarom ik ze niet allemaal activeer

MCP biedt een gemeenschappelijke manier om tools en bronnen aan de agent bloot te stellen. Dat is handig, dus het ecosysteem nodigt snel uit om er vijftien te installeren. Ik weersta die verleiding. Elke server voegt beschrijvingen, machtigingen, afhankelijkheden, soms geheimen en een nieuwe manier van falen toe. Mijn mcp.json is geen verzameling: het is een werkkist.

De huidige versies van Pi kunnen MCP direct beheren. Een server kan globaal zijn in ~/.pi/agent/mcp.json of projectlokaal in .pi/mcp.json. Hier is de cyclus die ik gebruik om «geschreven in JSON» niet te verwarren met «functioneel»:

pi mcp add -l docs --url https://example.com/mcp \
  --bearer-token-env-var DOCS_TOKEN
pi mcp list

# in een reeds geopende sessie
/reload
/mcp

pi mcp list verbindt met de geactiveerde servers en toont tools of fouten. In Pi wordt /mcp gebruikt om verbindingen te inspecteren, een server te herstarten, via OAuth te verbinden en de blootstelling te wijzigen. Ik houd gewone tools in codemode, veelgebruikte kleine tools in direct, grote catalogi in deferred en alles wat gevaarlijk of nutteloos is in hidden. Dit onderscheid beperkt de hoeveelheid beschrijvingen die naar het model worden gestuurd.

Context7 voor actuele documentatie

Het model kent een bibliotheek misschien goed, maar zijn geheugen komt overeen met een verleden staat. Een methode kan van naam zijn veranderd, een optie is verdwenen of een oud voorbeeld compileert niet meer. Context7 stelt de agent in staat de actuele documentatie van een bibliotheek op te halen wanneer hij die nodig heeft. Dit voorkomt een erg irritante categorie hallucinaties: code die perfect aannemelijk is maar een niet-bestaande API aanroept.

SearXNG om te zoeken zonder een browser te besturen

Ik gebruik ook een SearXNG-exemplaar dat via MCP wordt blootgesteld. De agent kan een zoekopdracht starten, gestructureerde resultaten lezen en meerdere motoren kruisen zonder voor elke vraag grafisch een browser te openen. Voor het controleren van een recente fout, het terugvinden van documentatie of het vergelijken van meerdere pistes is dat veel lichter.

SearXNG is een metazoekmachine: afhankelijk van de configuratie aggregaat hij onder meer webresultaten, encyclopedische en code-repositoryresultaten. Het verzoek gaat via HTTP en het resultaat komt terug in gestructureerde vorm, bijvoorbeeld JSON. Context7 en SearXNG zijn dus geen concurrenten. De eerste beantwoordt «wat is de huidige API van deze bibliotheek?»; de tweede «wat vind je vandaag over deze fout of dit onderwerp?».

Dit ontslaat je niet van het controleren van bronnen. Een zoekresultaat is geen waarheid en een webpagina kan instructies bevatten die bedoeld zijn om agents te misleiden. Ik behandel opgehaalde inhoud als onbetrouwbare data, nooit als een nieuwe systeemregel.

Chrome DevTools en Playwright doen niet hetzelfde werk

Voor webontwikkeling is de Chrome DevTools-server een van de praktischste toevoegingen. De agent opent de pagina, klikt, vult een veld in, inspecteert de DOM, leest de console, onderzoekt netwerkverzoeken, antwoorden, cookies of lokale opslag en maakt een screenshot. Hij volstaat er niet meer mee te beweren dat de knop zou moeten werken: hij kan zien wat er gebeurt.

Ik gebruik de eerste om te onderzoeken terwijl ik bouw, en de tweede om het verwachte gedrag om te zetten in een duurzame test. Beiden kunnen in een pagina klikken, maar dat is geen reden om ze te verwarren.

PostgreSQL, ja; Postman, niet per se

Een beperkte PostgreSQL-toegang stelt de agent in staat het schema te lezen, een trage query te onderzoeken, een EXPLAIN uit te voeren, een ontbrekende index te sporen of een migratie voor te bereiden. Ik geef hem bij voorkeur een leesverbinding op een ontwikkelomgeving. Een agent die een query optimaliseert heeft geen reden om de productiedatabase te mogen verwijderen.

Aan de andere kant heb ik geen Postman-server in al mijn projecten als onmisbaar beschouwd. Pi kan al een API aanroepen met terminaltools, een OpenAPI-schema lezen of bestaande tests uitvoeren. Als het team al zijn waarheid in Postman-collecties bewaart, kan integratie gerechtvaardigd zijn. Anders dupliceert het vaak een reeds aanwezige capaciteit.

Codemode: stoppen met heen en weer schakelen voor elke schroevendraaier

Een naïeve opeenvolging van tools ziet er zo uit: het model vraagt een zoekopdracht, wacht het resultaat af, denkt na, vraagt een bestand, wacht opnieuw, en roept dan een MCP-server aan. Elke stap voegt een heen-en-terug toe en zet de context op.

Codemode stelt Pi in staat een klein JavaScript-programma te schrijven dat in een gecontroleerde omgeving wordt uitgevoerd om meerdere aanroepen te coördineren. Het kan bijvoorbeeld twee bronnen parallel ondervragen, de antwoorden filteren en alleen het nuttige resultaat naar het model terugsturen. Het is niet alleen sneller: het voorkomt ook dat het verhaal wordt gevuld met elk tussenliggend detail.

const [docs, search] = await Promise.all([
  tools.mcp__context7__lookup({ library: "next" }),
  tools.mcp__search__query({ q: "Next.js current cache behavior" })
]);

return { docs, search };

Het script draait in een QuickJS-sandbox, zonder directe toegang tot Node.js, het bestandssysteem of het netwerk: het communiceert alleen via de toegestane tools. Alleen het resultaat keert terug naar het model. Dat is belangrijk wanneer twee aanroepen elk duizenden regels produceren: JavaScript kan sorteren, filteren en samenvatten voordat tokens in het gesprek worden verbruikt.

Met een MCP-server die in codemode wordt blootgesteld, activeert Pi dit mechanisme normaal gesproken automatisch. Om het beschikbaar te houden zonder MCP, kan ik het toevoegen in settings.json:

{
  "defaultTools": ["+codemode"]
}

Ik houd toch een eenvoudige regel aan: het coördineringsprogramma moet kort en leesbaar blijven. Als de agent een half product produceert dat verborgen zit in een toolaanroep, wordt het moeilijker te onderzoeken dan de oorspronkelijke taak.

Extensies die mijn gebruik echt hebben veranderd

Het extensie-ecosysteem is waar Pi van een minimale kern naar mijn tool groeit. Hier zijn degene die zin hebben in mijn organisatie, geen verplichte lijst.

Toegang tot een andere map zonder de hele schijf te openen

Pi redeneert eerst vanuit zijn werkmap. De extensie voor extra mappen is handig wanneer een project afhankelijk is van een naastgelegen repository, een documentatiemap of een gedeeld schema. Ik geef die wegdruk expliciet op in plaats van Pi te hoog in de boomstructuur te starten. De agent ziet wat hij nodig heeft, niet mijn hele persoonlijke map.

fzf: fuzzy zoeken en multi-grep

De fzf-extensie voegt meestal meerdere tools toe: bestandzoekopdrachten, fuzzy grep en zoeken op meerdere patronen. De agent kan find of grep blijven gebruiken; fzf wordt een extra optie, geen geforceerde vervanging. In de interface opent het teken @ ook de bestandzoekopdracht en voorkomt het dat je een lang pad opnieuw typt.

Neovim: beginnen op de regel waar ik werk

Met de Neovim-integratie plaats ik de cursor in een functie, gebruik ik mijn sneltoets — in mijn configuratie een combinatie rond de leader-toets — en open ik een klein dialoogvenster. Een vraag als «verklaar dit deel» komt bij Pi met het bestand en de huidige positie. Deze context is veel preciezer dan «kijk ergens in de controller».

Subagents: alleen als de scheiding iets toevoegt

Ik werk nog vaak met één model. Subagents worden nuttig wanneer je een goedkoop model wilt reserveren voor eenvoudig zoeken en een robuuster model voor moeilijke beslissingen, of een gespecialiseerde capaciteit wilt aanroepen: afbeelding, video, audio-transcriptie of speech-to-text. Het belang ervan ligt in de rolverdeling, niet in het aantal kleine personages op het scherm.

Apply patch en Toolwatch: een zichtbare drempel herstellen

Pi minimalis onderbreekt niet elke wijziging om toestemming te vragen. Apply patch is geschikt wanneer ik de diff wil bekijken voordat elke wijziging wordt toegepast. Toolwatch speelt een vergelijkbare rol voor tools en commando's: ik kan veelvoorkomende bewerkingen toestaan, validatie vragen voor bepaalde en gevaarlijke acties blokkeren. Deze twee extensies voegen wrijving toe, maar dat is precies de wrijving die ik wil voor een verwijdering of een commando dat de omgeving raakt.

Een extensie wordt uitgevoerd in het Pi-proces met de rechten van mijn gebruiker. Het is geen klein plugin dat magisch achter een glazen wand is opgesloten. Ik lees de code, controleer de herkomst en beperk de toegang. Willekeurig een extensie installeren die belooft «de agent tien keer krachtiger te maken» komt overeen met de software van een onbekende op je werkplek uitvoeren.

Sessies zijn bomen, geen lange magneetbanden

Pi bewaart zijn sessies als JSONL onder ~/.pi/agent/sessions. Het voordeel is niet alleen een gesprek hervatten. Een sessie vormt een boom: ik kan terugkeren naar een eerder punt, een vertakking maken en een andere oplossing proberen zonder al het vorige werk te verwerpen.

/tree gebruik ik om te navigeren of af te buigen in de bestaande sessie. /fork maakt een aparte sessie wanneer ik een piste in onafhankelijk werk wil omzetten. Ik kan een sessie ook een naam geven, klonen, exporteren of hervatten. Dit onderscheid lijkt secundair tot de dag waarop een refactoring de verkeerde kant op gaat: ik keer liever netjes terug naar het kruispunt dan het model te vragen mentaal twintig berichten te vergeten.

Het meest verhelderende voorbeeld is een proef met Redis. Ik vraag Pi om het te integreren, het wijzigt meerdere bestanden, en dan besef ik dat deze richting niet de juiste was. Met /tree keer ik terug naar het bericht vóór die beslissing en maak ik een andere vertakking in hetzelfde sessiebestand; de oude vertakking blijft raadpleegbaar. Met /fork zet ik een eerdere invoer om in een nieuwe, onafhankelijke sessie. Met /clone kopieer ik gewoon de actieve vertakking zoals die is.

Wanneer de context zijn limiet nadert, vat compaction het oude deel samen en maakt ruimte vrij. De samenvatting dient als huidige context, terwijl de oorspronkelijke gebeurtenissen in de sessie blijven. Het is geen perfect geheugen: een nuance kan in de synthese verdwijnen. Voor belangrijke beslissingen noteer ik ze in de repository — ADR, ticket, documentatie of AGENTS.md — in plaats te vertrouwen op een oneindig gesprek.

De limiet hangt af van het model: 128 000, 256 000 tokens, soms meer. Pi compacteert normaal gesproken automatisch, maar /compact stelt je in om aan te geven wat de samenvatting absoluut moet behouden. Ik houd ook in gedachten dat het originele JSONL de prompts, toolaanroepen, commando-uitvoer en soms bestandsinhoud bevat. Een geëxporteerde sessie is dus geen onschuldig document om zonder nalezing te publiceren.

Een root-AGENTS.md, daarna lokale regels

In een monorepo wordt een enkel bestand van tweehonderd regels snel even vervelend als afwezige documentatie. Pi kan instructies combineren die op verschillende niveaus staan. Ik houd daarom de algemene regels in de root, en voeg de bijzonderheden dicht bij de betreffende code toe.

monorepo/
├── AGENTS.md              # architectuur, Git, algemene commando's
├── apps/
│   ├── web/AGENTS.md      # Next.js, toegankelijkheid, UI-tests
│   └── admin/AGENTS.md    # React, rechten en interne componenten
└── services/
    └── api/AGENTS.md      # Go, migraties en integratietests

Lokale bestanden vullen de bovenliggende regels aan. Pi herkent ook de varianten CLAUDE.md en AGENTS.override.md; de laatste vervangt het contextbestand van dezelfde map, maar verwijdert niet de instructies die zijn geërfd van bovenliggende mappen. Een team kan zo overal het maken van tests afdwingen en in de API alleen specificeren hoe een migratie moet worden gegenereerd.

Ik houd deze documenten concreet: Next.js- of React-versies, strikt TypeScript, verbod op any, voorkeur voor servercomponenten, exacte commando's, mappen, beperkingen en korte voorbeelden. Preken van dertig regels over «codakwaliteit» helpen veel minder dan een correct testcommando.

Skills: een gewoonte omzetten in een procedure

Een skill is in wezen een herbruikbare instructie die de agent laadt wanneer een taak overeenkomt. Ik maak er een nadat ik hetzelfde proces meerdere keren heb herhaald: een migratie voorbereiden, een versie publiceren, een CI-fout analyseren, een pagina controleren vóór productie of een changelog schrijven.

Een goede skill zegt niet alleen «deploy de applicatie». Het beschrijft de voorwaarden, de controlevolgorde, de commando's, de stopcriteria en de elementen die aan het einde moeten worden teruggegeven. Het moet een collega in staat stellen het proces te begrijpen, zelfs zonder agent.

Ik wantrouw grote verzamelingen die in één keer worden gedownload. Ze vullen de omgeving met aannames die niet bij mijn infrastructuur passen en ze vormen onbetrouwbare code of instructies. Drie korte skills, geschreven voor mijn project en ermee onderhouden, zijn beter dan driehonderd mysterieuze recepten.

Packages: een stabiel geworden configuratie delen

Wanneer een set zijn waarde heeft bewezen, kan een Pi-package extensies, skills, prompts en thema's groeperen. Dat is handig om dezelfde omgeving op meerdere machines terug te vinden of een gemeenschappelijke basis aan een team te bieden.

Ik begin niet met het package. Ik begin met het probleem, voeg de tool toe, gebruik hem, verwijder wat niet nuttig is, en verpak het pas daarna. Anders verander ik nog onduidelijke keuzes in een interne standaard en iedereen erft mijn proefnemingen.

Het punt dat demonstraties vaak overslaan: veiligheid

Pi kan lezen, wijzigen en uitvoeren met de machtigingen van het account dat hem heeft gestart. Standaard mag je geen ondoordringbare sandbox-grens of automatische bevestiging voor elk commando verwachten. Het is een krachtige ontwikkeltool, dus het bereik is reëel.

Ik behandel het als een zeer snelle technische collega die een zin verkeerd kan begrijpen:

• werken onder Git en back-ups beschikbaar;
• geheimen tot het strikt noodzakelijke beperkt, nooit een compleet sleutelbos;
• afzonderlijk account, container of VM wanneer het project gevoelig is;
• databaseverbinding alleen-lezen voor analyse;
diff nagelezen vóór merge en tests uitgevoerd;
• destructieve commando's geblokkeerd of onderworpen aan validatie;
• webinhoud, issues en externe bestanden als onbetrouwbaar beschouwen.

Het laatste punt betreft prompt-injectie. Een pagina of ticket kan een zin bevatten die de agent moet overtuigen zijn regels te negeren of een geheim te exfiltreren. Voor mij is een geraadpleegd document een stukje bewijs om te analyseren, niet iemand die plotseling het recht krijgt de terminal te bevelen.

De configuratie die ik aanraad om te beginnen

Na al deze tools lijkt de beste initiële installatie bijna teleurstellend. Dat is een goed teken.

1. Pi installeren en één model verbinden.
2. Een korte AGENTS.md maken met de projectcommando's en -limieten.
3. De languageserver van de taal installeren en controleren of hij reageert.
4. Enkele dagen werken met de ingebouwde tools.
5. Een MCP-server pas toevoegen wanneer een tekort duidelijk terugkomt.
6. Herhalende procedures omzetten in skills.
7. Het geheel inpakken in een package na stabilisatie.

Deze voortgang voorkomt een veelvoorkomend probleem: wanneer een agent vanaf dag één twee zoekmachines, drie browsers, vier geheugens en tien databases heeft, weet ik niet meer welke component een antwoord heeft geproduceerd en waarom de context zoveel tokens kost.

Wanneer ik Pi niet gebruik

Als de taak deterministisch, bekend en eenduidig herhaald kan worden, schrijf ik een script of een test. Altijd hetzelfde bestand hernoemen, een poort controleren, een map back-uppen of een API aanroepen met vaste parameters heeft geen model nodig dat bij elke uitvoering redeneert.

Pi wordt interessant wanneer ik door onbekende code moet navigeren, meerdere bronnen moet verbinden, keuzes moet maken, een fout moet verklaren of een wijziging moet laten evolueren na de testresultaten. Met andere woorden: ik gebruik hem voor gecontroleerde onzekerheid, niet als dure vervanging van elk shell-commando.

Wat ik uiteindelijk heb gebouwd

Mijn Pi heeft niet veel weg meer van een lege installatie. Hij begrijpt code dankzij LSP, raadpleegt actuele documentatie, ondervraagt een zoekopdracht, observeert de browser, verkent bepaalde databases, delegeert subtaken en weet een gespreksvertakking te hervatten. Toch blijft het geheel leesbaar omdat elk onderdeel beantwoordt aan een specifieke reden.

Hier wordt minimalisme echt interessant. Het gaat niet om het behouden van de minste functies. Het gaat om het kunnen verklaren waarom elke functie er is, welke gegevens hij ziet en wat er gebeurt wanneer hij uitvalt.

Ik zoek dus niet de beste agent in abstracte zin. Ik zoek een tool die ik kan vormen, inspecteren en stoppen. Pi past bij mij omdat hij klein begint en mij laat beslissen hoe groot hij mag worden. In een wereld waarin elke software een totaal platform wil worden, is deze bescheidenheid bijna een premiumfunctie.

Technische referenties

• Pi: installatie en eerste stappen
• Pi: configuratiebestanden en niveaus
• Pi: providers, modellen en redenniveau
• Pi: MCP-servers en toolblootstelling
• Pi: werking van codemode
• Pi: sessies, vertakkingen, export en context
• Pi: extensies
• Pi-pakketcatalogus: LSP-extensie gebruikt in deze gids
• Pi: skills
• Pi: sessies en contextcompaction
• Pi: veiligheidsmodel

🔗 Источники: [1] CERTS pi.dev https://crt.sh/?q=%25.pi.dev [2] DNS pi.dev https://dns.google/resolve?name=pi.dev [3] Pi.dev https://pi.dev/ [4] Pi · Documentation - Pi coding agent https://pi.dev/docs/latest [5] Choose a Model · Documentation - Pi coding agent https://pi.dev/docs/latest/models [6] Quickstart · Documentation - Pi coding agent https://pi.dev/docs/latest/quickstart [7] Model Catalog · Pi https://pi.dev/models [8] Package Catalog - Pi coding agent https://pi.dev/packages [9] pi-crew · Packages - Pi coding agent https://pi.dev/packages/pi-crew [10] Press Kit - Pi https://pi.dev/press-kit [11] WHOIS pi.dev https://rdap.org/domain/pi.dev [12] kasmweb/workspaces https://hub.docker.com/r/kasmweb/workspaces [13] sky-valley/pi https://github.com/sky-valley/pi [14] airbyte/source-google-workspace-admin-reports https://hub.docker.com/r/airbyte/source-google-workspace-admin-reports [15] nktkt/pi https://github.com/nktkt/pi [16] airbyte/source-always-works-shim https://hub.docker.com/r/airbyte/source-always-works-shim [17] kiroguzitto/pi-zig https://github.com/kiroguzitto/pi-zig [18] @earendil-works/pi-coding-agent - npm https://www.npmjs.com/package/@earendil-works/pi-coding-agent [19] SDK · Documentation · Pi https://pi.dev/docs/latest/sdk [20] Pi - AI Agent Toolkit https://pi-earendil-works.apposters.com/ [21] @earendil-works/pi-coding-agent - npm.io https://npm.io/package/@earendil-works/pi-coding-agent [22] pi-coding-agent SDK | earendil-works/pi | DeepWiki https://deepwiki.com/earendil-works/pi/7.1-pi-coding-agent-sdk [23] GitHub - earendil-works/pi: AI agent toolkit: unified LLM API, agent ... https://github.com/earendil-works/pi [24] @earendil-works/pi-tui - npm https://www.npmjs.com/package/@earendil-works/pi-tui [25] @earendil-works/pi-ai - npm https://www.npmjs.com/package/@earendil-works/pi-ai [26] earendil-works/pi | DeepWiki https://deepwiki.com/earendil-works/pi [27] Built-in Tools | earendil-works/pi | DeepWiki https://deepwiki.com/earendil-works/pi/2.4-built-in-tools

Daarna lezen

• Ik testte OpenClaw twee weken: dit heb ik geleerd AI en automatisering · 42 min

Over de auteur

Jeremy Kraft beheert de infrastructuur en de zelfgehoste diensten van het IBCSC. Deze gidsen beschrijven configuraties die echt zijn uitgerold en voor publicatie opnieuw zijn nagekeken.

Een vraag stellen Alle gidsen

Discussie

Reacties

0

Nog geen reacties. U kunt de discussie openen met een vraag of uw eigen ervaring.

Website

Uw naam Hebt u een account? Aanmelden

Uw reactie

Platte tekst, maximaal 2 000 tekens. Nieuwe reacties worden gemodereerd. Uw naam wordt bij de reactie getoond. Er wordt geen e-mailadres gevraagd; alleen een onomkeerbare vingerafdruk van uw IP-adres wordt bewaard tegen spam.

Reactie versturen