Een avond, 25 berichten en een Firefox-port

In een avond stuurde ik ongeveer 25 berichten.

Codex, werkend binnen de structuur van Delano, veranderde een Chrome-only extensie in een werkende Firefox/Zen-versie. Onder de motorkap betekende dat: 25 bronbestanden aanpassen en meer dan 2.600 regels implementatiecode raken.

Het interessante deel is niet het aantal regels zelf. Codevolume is een slechte scorekaart. Het nuttige deel is dat dit een echt compatibiliteitsproject was, met planning, implementatie, testen, bewijs en release-oordeel, en dat het in een avond van idee naar werkende interne beta ging.

De extensie was Pointa.

Ik gebruik Zen Browser dagelijks. Het is gebouwd op Firefox, en het is stilletjes de browser geworden die ik het liefst gebruik. Snel genoeg. Rustig genoeg. Eigenwijs op de juiste plekken.

Het irritante deel: veel nuttige browserextensies gaan er nog steeds vanuit dat je in Chrome leeft.

Pointa was er daar een van.

Dus wilde ik Pointa in Zen.

Pointa draait in Zen, met browserfeedback direct aan de pagina gekoppeld.

Wat Pointa doet

Pointa laat je op een draaiende lokale webapp klikken, een UI-element selecteren, een annotatie achterlaten, een screenshot of bugcontext toevoegen, en je AI coding agent vragen om het te fixen.

Dat klinkt klein, totdat je genoeg tijd hebt besteed aan het prompten van coding agents.

Zonder Pointa schrijf je al snel dingen als:

Op de detailpagina, in de rechterzijbalk, onder het metadatablok, mag de ruimte boven het tweede label iets kleiner.

Jij weet precies wat je bedoelt. Het model moet dat reconstrueren uit proza, bestandsnamen, code, screenshots en geluk.

Pointa geeft de agent een beter startpunt. Het legt vast waar je op klikte, de paginacontext, de screenshot en de annotatie. Via MCP, het protocol dat veel coding agents gebruiken om externe context te lezen, kan de agent die feedback aan de code koppelen.

Het maakt browserfeedback iets dat dichter bij Figma-comments voor een live product komt.

Waarom de port geen snelle kopie was

Op het eerste gezicht klinkt een Chrome-naar-Firefox-port als een simpele compatibiliteitsklus.

Pak de Chrome-extensie. Genereer een Firefox-manifest. Laad hem in Zen. Los een paar waarschuwingen op.

Browserextensies werken zelden zo netjes mee.

Een browserextensie is niet alleen een klein knopje in de toolbar. Er is een package-format. De extensie vraagt permissies aan de browser. Hij injecteert code in pagina's. Hij maakt screenshots. Hij praat met een lokale development server. In het geval van Pointa verpakt hij ook nuttige context zodat een AI coding agent kan begrijpen waar je op klikte en wat je aangepast wilt hebben.

Chrome en Firefox bieden al die onderdelen niet op dezelfde manier aan. Firefox heeft een andere extension runtime, een ander permissiemodel, en geen equivalent voor Chrome's debugger API.

De port werd dus een echt compatibiliteitsproject. Een deel van het werk was zichtbaar: annotaties laten werken, screenshots laten werken, de extensie laden in Zen. Een ander deel was loodgieterswerk: het manifest transformeren, niet-ondersteunde Chrome-permissies verwijderen, detecteren wat de browser wel en niet kan, omgaan met Firefox' content-scriptgedrag, aanpassen welke browser origins de lokale server accepteert, en de MCP-context bruikbaar houden voor de coding agent.

De zakelijke betekenis is simpel: er waren veel kleine plekken waar het project klaar kon lijken, terwijl het nog onbetrouwbaar was.

Dit is precies het soort werk waarbij "gewoon beginnen" het eerste uur snel voelt en daarna een rommel wordt.

Ik begon met Delano voordat ik de code aanraakte

De belangrijkste beslissing gebeurde voordat de implementatie begon.

Ik opende de repo niet om een agent te vragen: "maak dit werkend in Firefox."

Ik voegde eerst Delano toe aan het project.

Delano is een set instructies, scripts en repo-conventies die coding agents gestructureerder laten werken. In plaats van het plan in een chatvenster te bewaren, geeft het project een plek voor context, workstreams, taken, beslissingen, bewijs en validatie.

Het komt ook met een simpele viewer, zodat je echt kunt zien waar de agent aan werkt. Voor sommigen is dat een beetje een gimmick. Voor mij is het een makkelijke manier om grip te houden op het project. Ik vind de leeservaring in VS Code gewoon niet prettig. Als een agent een uur gaat draaien, werk over taken splitst en bewijs achterlaat, wil je een schone manier om dat werk te inspecteren zonder handmatig door een stapel markdownbestanden te lezen.

Delano's viewer laat zien hoe de Firefox-port is opgedeeld in workstreams en taken.

Ik maakte Delano omdat ik steeds tegen hetzelfde probleem aanliep met coding agents. Het model kon wijzigingen maken. Soms heel goede wijzigingen. Maar het werk rondom de code was te fragiel:

• context leefde in een chatvenster;
• beslissingen verdwenen na compaction;
• taken waren impliciet in plaats van expliciet;
• validatie was makkelijk over te slaan;
• agents klonken klaar voordat het bewijs er was.

Met andere woorden: Delano zet het operating model in de repository.

Zo start ik inmiddels bijna elk project.

Voor Pointa liet ik de agent de codebase onderzoeken, de Firefox-beperkingen identificeren, een project aanmaken, workstreams definiëren, het werk in taken splitsen en acceptatiecriteria vastleggen voordat hij de extensie ging aanpassen.

Vanaf het begin waren er zes workstreams en 29 taken. De agent wist welke onderdelen van elkaar afhankelijk waren. Hij wist welk bewijs nodig was. Hij wist welke taken naar subagents konden en welke bestanden niet parallel aangeraakt moesten worden.

Daarna werkte de agent meer dan een uur door die structuur heen. Niet als een lange prompt, maar als een gepland deliveryproject. Gewoon doorwerken.

Een Delano-taak met acceptatiecriteria, technische notities en bewijs bij het werk.

De laatste bugs waren klein omdat de basis er lag

Er waren aan het einde nog steeds bugs.

Natuurlijk waren die er.

Zen weigerde een Chrome-only privacy_policy-veld in het gegenereerde Firefox-manifest. Firefox was strenger over de manier waarop code in de pagina werd geinjecteerd. Een returnwaarde werkte in Chrome, maar faalde in Firefox omdat Firefox extension data anders clonet. Screenshot capture brak nadat de toolbar opnieuw openging en een tijdelijke permissie kwijt was. Annotaties verwijderen faalde omdat de lokale server Chrome extension origins wel vertrouwde, maar Firefox extension origins nog niet.

Die bugs waren vervelend, maar te verwachten bij compatibiliteitswerk.

Het verschil was dat het geen existentiële problemen waren.

Tegen de tijd dat die bugs verschenen, stond de basis er al:

• de Firefox-build bestond;
• de manifesttransformatie bestond;
• de runtime-compatibiliteitslaag bestond;
• het permissiemodel was doordacht;
• de annotatief flow werkte;
• screenshotopslag en MCP-payloads waren getest;
• de releasescope was gedocumenteerd.

De laatste bugs waren daardoor een paar minuten gerichte fixes, niet het signaal dat het hele project onderpland was.

Dat is de les die ik hieruit wil halen.

Delano liet de agent plannen voor het rommelige funderingswerk dat mensen vaak pas ontdekken nadat ze al in een bestaande codebase zijn gaan editten.

Mijn werk schoof richting review en oordeel

Voor dit project testte ik vooral zelf het echte product.

Ik laadde de extensie in Zen. Ik gaf de daadwerkelijke browsererrors terug. De agent traceerde ze, patchte de code, bouwde de package opnieuw en werkte het bewijs bij.

Toen screenshots faalden, vond hij het permissieprobleem. Toen deletes faalden, vond hij het server-originprobleem. Toen ik een testannotatie maakte, inspecteerde hij de opgeslagen annotatiedata en verifieerde hij de screenshot: 1124 bij 946 pixels, opgeslagen als WebP-attachment.

Dat was een goed human-in-the-loop patroon voor dit specifieke project, omdat browserextensies nog steeds ongemakkelijke permissie- en runtimegedragingen hebben die je het makkelijkst in de echte browser blootlegt.

Maar handmatig testen hoeft niet altijd de eindstaat te zijn. Ik had waarschijnlijk meer hands-off kunnen zijn als Computer Use betrokken was geweest.

In andere projecten automatiseerde ik meer van deze loop. Bij het bouwen van een Android-applicatie kan een agent bijvoorbeeld Android Studio draaien, een Android-emulator starten, de applicatie openen en Maestro gebruiken om door de flows te lopen die ertoe doen. Hij kan bouwen, testen, de fout vinden, het probleem patchen en de test opnieuw draaien.

Ik wil niet naast een agent zitten en elke kleine command goedkeuren. Ik vertrouw ook geen black box die bestanden wijzigt en daarna overwinning claimt.

Het nuttige midden is praktisch:

Ik bepaal de uitkomst. De agent draagt de implementatie. De echte workflow wordt getest, door mij of door automatisering. Delano houdt het bewijs zichtbaar.

Volledigheid is een belangrijk voordeel

Snelheid hielp, maar het nuttigere deel was dat het werk niet stopte zodra de extensie alleen maar laadde in Firefox.

Het project ging door totdat de release-state duidelijk was:

• build tooling werd toegevoegd;
• Firefox bleef gegenereerd vanuit gedeelde broncode;
• niet-ondersteunde Chrome-paden werden afgeschermd;
• evidence capture werd opnieuw opgebouwd rond APIs die Firefox ondersteunt;
• docs werden toegevoegd voor gebruikers, developers, QA, privacy, AMO-waarschuwingen en release readiness;
• validatieresultaten werden vastgelegd;
• onaf werk bleef zichtbaar.

De release note zegt dat Firefox/Zen klaar is voor interne beta. Hij claimt geen publieke release. Chrome-regressie en AMO-warning cleanup staan nog steeds zichtbaar als open werk.

Wat dit verandert

Een project als dit kost normaal gesproken senior engineering attention over onderzoek, planning, compatibiliteitstesten, follow-up fixes, documentatie, release-oordeel en taakadministratie. De code is maar een deel van het werk.

Met Delano schoof meer van dat omliggende werk het project zelf in. De agent had repo-context, taken, validatiegates, bewijs en open risico's. Ik moest het resultaat nog steeds beoordelen, maar ik droeg niet de hele coördinatielaag in mijn hoofd of in een chatthread.

Dat maakt kleine, specifieke softwareprojecten goedkoper om serieus te proberen.

Deze Firefox/Zen-versie werd gemaakt met GPT-5.5 via mijn Codex-abonnement; geprijsd per gebruik, zoals in veel enterprise-setups, zou dezelfde run ongeveer $70,15 hebben gekost.

Het verandert ook de build-versus-buy-vraag. Voor interne tools was de oude vraag vaak: kunnen we het ons veroorloven dit te bouwen? De scherpere vraag is nu: is deze workflow belangrijk genoeg om zelf te bezitten, nu een serieuze eerste versie veel minder kost?

Dat haalt de noodzaak voor technische review niet weg. Het maakt de afstand wel korter tussen "ik weet precies welke workflow ik nodig heb" en "er is een werkende eerste versie."

De Pointa-port gaf me het directe resultaat dat ik wilde: de extensie werkt nu in Zen.

Dat gebeurde niet via een magische prompt. Het gebeurde omdat de agent een deliverystructuur om zich heen had: plan het werk, splits het op, implementeer, test de echte workflow, leg bewijs vast en laat het resterende risico zichtbaar.