Ik gaf Claude één app en vroeg hem zich voor te doen als vier verschillende senior ontwikkelaars — en dit is wat er gebeurde

Online, met name op X, circuleren talloze beweringen die chatbots zogenaamd effectiever zouden maken. Toen ik voor het eerst een aantal beweringen van David Max , een expert in AI- onderwijs , tegenkwam, was ik sceptisch. Dat was precies de reden waarom ik ze wilde uitproberen. Deze beweringen stellen dat Claude kan worden getransformeerd tot alles van een ervaren debugger tot een performance-expert. Dit is wat er gebeurde toen ik besloot het te onderzoeken. Als je geïnteresseerd bent in effectievere beweringen, kun je 7 effectieve Claude 4-beweringen bekijken om je ideeën te ontwikkelen en je productiviteit te verhogen.

Bekijk mijn overzicht van huishoudelijke uitgaven op Claude.

Ik had al een algemene onkostenregistratie met onkostenplaceholders gemaakt met ChatGPT Work, dus die heb ik gebruikt. Vervolgens heb ik Claude gevraagd de applicatie vier keer te beoordelen. Elke keer heb ik hem een ​​andere belangrijke engineeringrol toegewezen: full-stack engineer, debugging engineer, frontend engineer en performance engineer.

Het resultaat was veel onthullender dan simpelweg Claude te vragen "de app te verbeteren". Elk personage concentreerde zich op een andere reeks problemen – en bracht soms zelfs problemen aan het licht die de vorige "ontwikkelaar" over het hoofd had gezien. Hieronder lees je wat er gebeurde en welke beweringen ze deden.

1. De senior full-stack engineer heeft de applicatie gebouwd.

Het begon met een verzoek van Claude om een ​​interactieve app voor het bijhouden van huishoudelijke uitgaven te maken die iedereen kon gebruiken. Lees voor meer informatie over Claude's vaardigheden op het gebied van app-ontwikkeling het artikel " Ik heb in enkele minuten 3 apps gebouwd met Claude en Gemini: maar één ervan heeft een verborgen functie ."

De uitdaging: Ontwikkel een interactieve app voor het bijhouden van huishoudelijke uitgaven die iedereen kan gebruiken om zijn of haar uitgaven te registreren en te begrijpen. De app moet functies bevatten zoals het toevoegen en verwijderen van uitgaven, het toewijzen van categorieën, het filteren van transacties, het berekenen van de totale uitgaven en het bekijken van een visueel overzicht van de categorieën.

Stel je voor dat je een ervaren full-stack engineer bent die een verfijnd MVP (Minimum Viable Product) ontwikkelt voor een startup. Voordat je ook maar één regel code schrijft, geef je een korte schets van de architectuur, de datastructuur en de gebruikersflow. Bouw vervolgens de applicatie als een Cloud Artifact.

Zorg dat het responsief en gebruiksvriendelijk is, maar besteed geen extra tijd aan het controleren, debuggen of verbeteren van de uiteindelijke code. Die taken delegeer ik aan andere ontwikkelaars.

Claude had een verrassend goed uitgewerkte React-app gemaakt. Deze bevatte voorbeeldtransacties, uitgavenoverzichten, categorie-indelingen, zoek- en filterfunctionaliteit en de mogelijkheid om transacties op datum te sorteren. Bovendien werden wijzigingen opgeslagen, zodat ze beschikbaar bleven na het opnieuw openen van de app.

Op het eerste gezicht leek het veel meer op een afgewerkt product dan op een onvolledig prototype. Er lagen statistische kaarten bovenop, een overzichtelijk onkostenformulier en gekleurde balken die aangaven hoeveel er in elke categorie was uitgegeven.

2. De senior debugging engineer ontdekte enkele problemen.

Daarna vroeg ik Claude om de schijn te negeren en zich te concentreren op zijn eigen werk als debugging engineer die een applicatie voorbereidde voor de lancering.

De eis: gedraag je nu als de hoofddebugger die deze applicatie heeft overgenomen vóór de publieke release.

Onderzoek de applicatie en de bestaande code zorgvuldig, zonder de beoogde functionaliteit of het visuele ontwerp te wijzigen. Test de belangrijkste gebruikersstromen en zoek naar functionele fouten, ongeldige invoerverwerking, risico's op gegevensverlies, onjuiste berekeningen, problemen met gegevensopslag en uitzonderlijke gevallen.

Voordat je de code aanpast, verzoek ik je een kort debugrapport te sturen met daarin wat je hebt getest, elk probleem dat je hebt gevonden, de oorzaak van elk probleem, de ernst van elk probleem en de oplossing die je aanbeveelt.

Voer vervolgens de reparaties uit en controleer of de oorspronkelijke elementen nog steeds functioneren. Herontwerp de gevel niet, onderneem geen ingrijpende architectonische renovatie en breng geen puur cosmetische veranderingen aan.

Het debugproces bracht veel echte problemen aan het licht.

De oorspronkelijke invoer was bijvoorbeeld niet in de juiste vorm. Klikken op de knop "Transactie opslaan" werkte wel, maar op de Enter-toets drukken soms niet. Claude corrigeerde dit door het gedeelte om te zetten naar een correct formulier met een verzendknop.

Hij ontdekte ook dat gebruikers de geschiedenis konden wissen en een transactie konden opslaan met ongeldige datumgegevens. Claude voegde datumvalidatie toe, versterkte de controles op ongeldige bedragen en corrigeerde een berekening waardoor 'Huisvesting' als de grootste categorie werd weergegeven, zelfs wanneer de tracker leeg was.

Het was nog steeds mogelijk om transacties met één klik permanent te verwijderen. Opslagfouten bleven verborgen in de ontwikkelaarsconsole, waardoor gebruikers ten onrechte konden denken dat hun gegevens waren opgeslagen. Bovendien implementeerde Claude geen geautomatiseerde tests om te bevestigen dat de oplossingen werkten.

3. De ervaren front-end engineer merkte een compleet andere toepassing op.

In de derde ronde vroeg ik Claude om de onkostenregistratie te benaderen als een front-end engineer die gespecialiseerd is in responsief ontwerp en toegankelijkheid.

De eis: gedraag je nu als een doorgewinterde front-end engineer, gespecialiseerd in toegankelijke en responsieve consumentenapplicaties.

Bekijk je huidige onkostenregistratiesysteem vanuit het perspectief van iemand die het gebruikt op een telefoon, een toetsenbord of ondersteunende technologie. Behoud de functionaliteit en de algehele visuele identiteit, maar verbeter de gebruiksvriendelijkheid en toegankelijkheid.

Voordat u de code wijzigt, dient u een korte beoordeling te geven over het gedrag en de responsiviteit van mobiele telefoons, toetsenbordnavigatie, gebruiksvriendelijkheid van formulieren, toegankelijkheid voor schermlezers, kleurcontrast, laad- en foutmeldingen, destructieve acties en verwarrende bedieningselementen.

Voer vervolgens de verbeteringen door. Zorg ervoor dat elk invoerveld en interactief besturingselement een toegankelijke naam heeft, dat focusstatussen duidelijk zichtbaar zijn, dat verificatieberichten door een schermlezer kunnen worden voorgelezen en dat bestedingsdetails informatie overbrengen zonder uitsluitend op gekleurde balken te vertrouwen.

Dit was de meest uitgebreide evaluatie van het experiment.

Claude merkte op dat de app de natuurlijke rand rond geselecteerde invoervelden verwijderde zonder deze te vervangen. Hierdoor zou iemand die met een toetsenbord navigeert, moeite hebben om het actieve veld te zien.

Er werd tevens vastgesteld dat de visuele labels niet correct waren gekoppeld aan de bijbehorende invoervelden, dat het zoekveld uitsluitend gebruikmaakte van de placeholdertekst en dat validatiefouten niet zo waren ingesteld dat ze door schermlezers konden worden voorgelezen.

Claude herstelde de visuele focusindicatoren, koppelde labels aan formulierbesturingselementen, voegde beschrijvingen voor schermlezers toe en verhoogde het contrast van veel lichtgrijze tekstelementen. Hij maakte de zoekbalk ook flexibeler op kleine schermen en voegde meer beschrijvende labels toe voor knoppen die alleen pictogrammen bevatten.

Belangrijker nog, dit personage ontdekte een probleem met verwijderen dat de debugger over het hoofd had gezien. Claude verving de knop voor verwijderen met één klik door een bevestigingsproces in twee stappen, waarbij gebruikers de transactie moesten verwijderen of behouden.

Niet alle beweringen waren perfect. Claude beschreef 44 x 44 pixels als de minimale aanraakdoelgrootte, maar hij vergrootte de primaire verwijderknop slechts tot 36 x 36 pixels. Dit voldoet aan de kleinere WCAG 2.2 AA-doelstelling, maar niet aan de door hem genoemde aanbeveling van 44 pixels.

Het veranderen van Claude's rol veranderde echter duidelijk het perspectief. De debugger controleerde of de applicatie werkte, terwijl de front-end engineer onderzocht of een echte gebruiker er comfortabel mee kon werken. Dit experiment laat zien hoe één enkele vereiste een aanzienlijke impact kan hebben op de resultaten van Claude.

4. De performance engineer erkende dat de applicatie niet veel verbetering nodig had.

Ten slotte vroeg ik Claude om een ​​onkostenregistratiesysteem op te zetten dat minstens 10,000 transacties kon verwerken.

De opdracht: treed nu op als senior performance engineer en zorg ervoor dat deze onkostenregistratie duizenden transacties kan verwerken.

Analyseer de huidige implementatie op onnodige weergave, overbodige berekeningen, inefficiënt sorteren of filteren, opslagknelpunten, geheugengroei en interacties die traag kunnen worden naarmate de gegevensomvang toeneemt.

Ga er niet zomaar vanuit dat er een prestatieprobleem is. Ontwikkel een realistische manier om de applicatie te testen met minstens 10,000 transacties en stel een basislijn vast voor kritieke bewerkingen.

Voer vervolgens alleen de verbeteringen door die door de analyse worden gerechtvaardigd. Behoud het uiterlijk van de app, de verbeteringen op het gebied van toegankelijkheid en het huidige gedrag. Claim geen snelheidsverbetering, tenzij u deze hebt gemeten of duidelijk hebt gedefinieerd als een verwachte verbetering.

Claude ontdekte een bijzonder belangrijk knelpunt. De applicatie maakte telkens een nieuw valuta-opmaakobject aan wanneer een bedrag werd weergegeven. Met 10,000 rijen mat Claude dat dit proces 349 milliseconden duurde. Door één opmaakobject te hergebruiken, werd dit teruggebracht tot 5.2 milliseconden, wat volgens Claude een verbetering van maar liefst 67 keer betekende.

Claude voegde ook een functie voor 'tabelvirtualisatie' toe, wat betekent dat de browser alleen de transacties weergeeft die op dat moment op het scherm zichtbaar zijn, in plaats van duizenden rijen tegelijk. Zoek- en opslagupdates werden met een fractie van een seconde vertraagd om kostbare herhalingen na elke toetsaanslag of snelle wijziging te voorkomen.

Claude heeft zelfs knoppen toegevoegd waarmee 1,000, 10,000 of 50,000 voorbeeldtransacties kunnen worden gegenereerd voor stresstests.

Maar het meest overtuigende deel van het rapport was Claude's erkenning dat de meeste van deze verbeteringen niet nodig waren voor het beoogde doel van de applicatie.

Een gemiddeld huishouden voegt zo'n 30 tot 50 transacties per maand toe. Zelfs tien jaar later concludeerde Claude dat de oorspronkelijke applicatie de resulterende gegevens waarschijnlijk zonder noemenswaardige problemen had kunnen verwerken. Afgezien van het cachen van de valutaformatter, waren de meeste verbeteringen alleen nuttig omdat ik specifiek ondersteuning voor duizenden transacties had aangevraagd.

Deze terughoudendheid (of zelfbeheersing) leek volwassener en professioneler dan simpelweg veranderingen doorvoeren omwille van de mogelijkheid om dat te doen.

Mijn eindconclusie

Ik vond deze beweringen buitengewoon effectief, omdat ze elk duidelijk de sterke en zwakke punten van Claude benadrukten. Elke rol bood een uniek perspectief voor evaluatie, wat ik erg nuttig vond en zeker zal toepassen bij mijn toekomstige beoordelingen van andere apps en websites.

Terwijl de debug-engineer onjuist gedrag ontdekte, vond de front-end engineer problemen met toegankelijkheid en gebruiksvriendelijkheid. De performance engineer daarentegen bekeek de gevolgen van een toenemend datavolume en herkende wanneer optimalisatie niet nodig was.

De ervaring liet ook zien waarom één algemene eis zoals "Maak dit productieklaar" misschien niet de beste aanpak is. Een enkele beoordeling kan belangrijke zaken over het hoofd zien, zelfs als de eis volledig lijkt. Door het werk op te splitsen in gerichte fasen had Claude minder prioriteiten en waren zijn resultaten gemakkelijker te evalueren.

Houd wel rekening met de gebruikslimieten van de cloud. De volgende keer probeer ik misschien de prompts te combineren om te voorkomen dat ik het maximum bereik.

---

---