Ich gab Claude eine App und bat ihn, sich wie vier verschiedene Senior-Entwickler zu verhalten – Folgendes geschah
Erfahren Sie, wie Claude die Rolle von vier verschiedenen Senior-Entwicklern bei der Entwicklung einer einzigen Anwendung übernahm. Lernen Sie die Ergebnisse dieses einzigartigen Experiments mit künstlicher Intelligenz in der Softwareentwicklung kennen.
Die wichtigsten Dinge, die Sie wissen müssen
- Durch die Zuweisung spezialisierter Ingenieursrollen (wie Debugging-Ingenieur und Front-End-Ingenieur) für Claude werden unterschiedliche Probleme in der Anwendung sichtbar, wodurch die Überprüfung umfassender und effektiver wird als allgemeine Behauptungen.
- Das Experiment ergab, dass der Debugging-Ingenieur funktionale Probleme (wie Eingabevalidierung und Berechnungen) entdeckte, während der Frontend-Ingenieur Probleme mit der Zugänglichkeit und Benutzerfreundlichkeit aufdeckte, darunter eine Ein-Klick-Löschtaste, die der erstere übersehen hatte.
- Der Performance-Ingenieur demonstrierte Claudes Fähigkeit, einen wesentlichen Engpass (Währungsformat) zu identifizieren und Verbesserungen vorzuschlagen, wobei er gleichzeitig anerkannte, dass die meisten davon für die tatsächliche Nutzung der Anwendung unnötig waren, was eine hohe Reife in der Evaluierung widerspiegelt.
Im Internet, insbesondere auf X, kursieren zahlreiche Behauptungen, die Chatbots angeblich effektiver machen. Als ich zum ersten Mal auf die Aussagen von David Max , einem Experten für KI- Schulungen , stieß, war ich skeptisch – genau das veranlasste mich, sie auszuprobieren. Diese Behauptungen versprechen, Claude in alles Mögliche zu verwandeln, vom erfahrenen Debugger bis zum Performance-Experten. Hier ist mein Bericht zu den Ergebnissen meiner Untersuchung. Wenn Sie an weiteren effektiven Behauptungen interessiert sind, schauen Sie sich die „ 7 effektiven Claude-4-Behauptungen zur Entwicklung Ihrer Ideen und Steigerung Ihrer Produktivität“ an.
Sehen Sie sich meinen Haushaltsausgaben-Tracker auf Claude an.
Ich hatte bereits mit ChatGPT Work einen allgemeinen Ausgaben-Tracker mit Platzhaltern für Ausgaben erstellt, den ich dann nutzte und Claude anschließend viermal um eine Überprüfung der Anwendung bat. Jedes Mal wies ich ihm eine andere wichtige Entwicklerrolle zu: Full-Stack-Entwickler, Debugging-Entwickler, Frontend-Entwickler und Performance-Entwickler.
Das Ergebnis war weitaus aufschlussreicher, als Claude einfach nur aufzufordern, die App zu verbessern. Jeder der Charaktere konzentrierte sich auf unterschiedliche Probleme – und deckte mitunter sogar Fehler auf, die dem vorherigen „Entwickler“ entgangen waren. Hier ist, was geschah und welche Behauptungen sie aufstellten.
1. Der Senior Full-Stack-Entwickler hat die Anwendung erstellt.
Alles begann mit Claudes Anfrage, einen interaktiven Haushaltsausgaben-Tracker zu entwickeln, den jeder nutzen kann. Mehr zu Claudes Fähigkeiten im Bereich App-Entwicklung erfahren Sie in dem Artikel „ Ich habe mit Claude und Gemini in wenigen Minuten drei Apps erstellt: Eine davon hat jedoch eine versteckte Funktion “.
Die Herausforderung: Entwickeln Sie einen interaktiven Haushaltsausgaben-Tracker, mit dem jeder seine Ausgaben erfassen und nachvollziehen kann. Er sollte Funktionen zum Hinzufügen und Löschen von Ausgaben, zum Zuordnen von Kategorien, zum Filtern von Transaktionen, zum Berechnen der Gesamtausgaben und zum Anzeigen einer visuellen Aufschlüsselung der Kategorien bieten.
Stellen Sie sich vor, Sie sind ein erfahrener Full-Stack-Entwickler, der ein ausgereiftes MVP für ein Startup entwickelt. Bevor Sie mit dem Programmieren beginnen, erstellen Sie einen kurzen Entwurf der Architektur, der Datenstruktur und des Benutzerflusses. Anschließend entwickeln Sie die Anwendung als Cloud-Artefakt.
Es soll reaktionsschnell und benutzerfreundlich sein, aber verschwenden Sie keine zusätzliche Zeit mit dem Überprüfen, Debuggen oder Verbessern des finalen Codes. Diese Aufgaben übernehme ich für andere Entwickler.
Claude entwickelte eine erstaunlich professionelle React-App. Sie enthielt Beispieltransaktionen, Ausgabenübersichten, Kategorie-Rankings, Such- und Filterfunktionen sowie die Möglichkeit, Transaktionen nach Datum zu sortieren. Außerdem wurden Änderungen gespeichert und blieben auch nach dem erneuten Öffnen der App verfügbar.
Auf den ersten Blick wirkte es eher wie ein fertiges Produkt als ein unvollständiger Prototyp. Oben befanden sich Statistikkarten, ein übersichtliches Ausgabenformular und farbige Balken, die die Ausgaben in den einzelnen Kategorien anzeigten.
2. Der leitende Debugging-Ingenieur entdeckte einige Probleme.
Anschließend bat ich Claude, das äußere Erscheinungsbild zu ignorieren und seine eigene Arbeit als Debugging-Ingenieur, der eine Anwendung für den Start vorbereitet, zu überprüfen.
Die Forderung: Verhalten Sie sich nun wie der Chef-Debugger, der diese Anwendung vor ihrer Veröffentlichung übernommen hat.
Untersuchen Sie die Anwendung und ihren bestehenden Code sorgfältig, ohne die beabsichtigte Funktionalität oder das visuelle Design zu verändern. Testen Sie die wichtigsten Benutzerabläufe und achten Sie auf Funktionsfehler, ungültige Eingaben, Datenverlustrisiken, fehlerhafte Berechnungen, Probleme mit der Datenpersistenz und Sonderfälle.
Bevor Sie den Code ändern, senden Sie mir bitte einen kurzen Debugging-Bericht, der Folgendes enthält: Was Sie getestet haben, jedes gefundene Problem, die Ursache jedes Problems, wie schwerwiegend jedes Problem war und die von Ihnen empfohlene Lösung.
Führen Sie anschließend die Reparaturen durch und überprüfen Sie, ob die ursprünglichen Funktionen weiterhin gegeben sind. Nehmen Sie keine Neugestaltung der Fassade, keine umfassendere architektonische Umgestaltung und keine rein kosmetischen Änderungen vor.
Der Debugging-Prozess deckte viele reale Probleme auf.
Beispielsweise war die ursprüngliche Eingabe nicht im richtigen Format. Das Klicken auf die Schaltfläche „Transaktion speichern“ funktionierte, das Drücken der Eingabetaste jedoch möglicherweise nicht. Claude korrigierte dies, indem er den Abschnitt in ein korrektes Formular mit einer Absendeschaltfläche umwandelte.
Er entdeckte außerdem, dass Nutzer den Verlauf löschen und Transaktionen mit ungültigen Datumsangaben speichern konnten. Claude fügte eine Datumsvalidierung hinzu, verstärkte die Prüfungen auf ungültige Beträge und korrigierte eine Berechnung, die dazu führte, dass „Wohnen“ als größte Kategorie angezeigt wurde, selbst wenn der Tracker leer war.
Transaktionen konnten weiterhin mit einem Klick endgültig gelöscht werden. Speicherfehler blieben in der Entwicklerkonsole verborgen, sodass Nutzer fälschlicherweise annehmen konnten, ihre Daten seien gespeichert worden. Zudem implementierte Claude keine automatisierten Tests, um die Wirksamkeit der Korrekturen zu überprüfen.
3. Dem erfahrenen Front-End-Entwickler fiel eine völlig andere Anwendung auf.
In der dritten Runde bat ich Claude, den Ausgaben-Tracker wie ein Frontend-Entwickler zu behandeln, der sich auf responsives Design und Barrierefreiheit spezialisiert hat.
Die Anforderung: Handeln Sie jetzt wie ein erfahrener Front-End-Entwickler, der sich auf barrierefreie und responsive Verbraucheranwendungen spezialisiert hat.
Überprüfen Sie Ihre aktuelle Ausgaben-App aus der Perspektive eines Nutzers, der sie auf einem Smartphone, einer Tastatur oder mithilfe von Hilfstechnologien verwendet. Behalten Sie die Funktionalität und das visuelle Erscheinungsbild bei, verbessern Sie aber die Benutzerfreundlichkeit und Barrierefreiheit.
Bevor Sie den Code ändern, geben Sie eine kurze Übersicht über das Verhalten und die Reaktionsfähigkeit von Mobiltelefonen, die Tastaturnavigation, die Benutzerfreundlichkeit von Formularen, die Zugänglichkeit für Bildschirmlesegeräte, den Farbkontrast, Lade- und Fehlerzustände, destruktive Aktionen und verwirrende Steuerelemente.
Setzen Sie anschließend die Verbesserungen um. Stellen Sie sicher, dass jedes Eingabefeld und jedes interaktive Steuerelement einen barrierefreien Namen hat, dass Fokuszustände deutlich sichtbar sind, dass Bestätigungsmeldungen von einem Screenreader vorgelesen werden können und dass Ausgabendetails Informationen vermitteln, ohne sich ausschließlich auf farbige Balken zu verlassen.
Dies war die umfassendste Auswertung des Experiments.
Claude merkte an, dass die App den natürlichen Rahmen um ausgewählte Eingabefelder entfernt, ohne einen Ersatz anzubieten. Daher hätte ein Benutzer, der mit der Tastatur navigiert, Schwierigkeiten, das aktive Feld zu erkennen.
Es wurde außerdem festgestellt, dass die visuellen Beschriftungen nicht ordnungsgemäß mit den entsprechenden Eingabefeldern verknüpft waren, dass das Suchfeld ausschließlich auf dem Platzhaltertext basierte und dass Validierungsfehler nicht so eingerichtet waren, dass sie von Bildschirmleseprogrammen angesagt wurden.
Claude hat die visuellen Fokusindikatoren wiederhergestellt, Beschriftungen mit Formularfeldern verknüpft, Beschreibungen für Bildschirmleseprogramme hinzugefügt und den Kontrast vieler hellgrauer Textelemente erhöht. Außerdem hat er die Suchleiste auf kleinen Bildschirmen flexibler gestaltet und aussagekräftigere Beschriftungen für Schaltflächen mit Symbolen hinzugefügt.
Am wichtigsten war jedoch, dass diese Person ein Löschproblem entdeckte, das der Debugger übersehen hatte. Claude ersetzte die Ein-Klick-Löschfunktion durch einen zweistufigen Bestätigungsprozess, der die Benutzer zwang, die Transaktion entweder zu löschen oder beizubehalten.
Nicht alle Angaben waren korrekt. Claude beschrieb 44 x 44 Pixel als Mindestgröße für Touch-Ziele, vergrößerte aber lediglich die primäre Löschtaste auf 36 x 36 Pixel. Dies erfüllt zwar die kleinere WCAG 2.2 AA-Vorgabe, jedoch nicht die von ihm erwähnte Empfehlung von 44 Pixeln.
Die Änderung von Claudes Rolle veränderte jedoch deutlich seine Perspektive. Der Debugger überprüfte, ob die Anwendung funktionierte, während der Frontend-Entwickler untersuchte, ob ein echter Mensch sie komfortabel bedienen konnte. Dieses Experiment zeigt, wie eine einzige Anforderung Claudes Ergebnisse erheblich beeinflussen kann.
4. Der Performance-Ingenieur bestätigte, dass die Anwendung nicht viel Unterstützung benötigte.
Zum Schluss bat ich Claude , ein Ausgabenverwaltungssystem einzurichten, das mindestens 10,000 Transaktionen verwalten kann.
Die Anforderung: Sie agieren nun als Senior Performance Engineer und bereiten dieses Ausgaben-Tracking-System auf die Verarbeitung von Tausenden von Transaktionen vor.
Analysieren Sie die aktuelle Implementierung auf unnötiges Rendering, redundante Berechnungen, ineffiziente Sortierung oder Filterung, Speicherengpässe, Speicherwachstum und Interaktionen, die sich mit zunehmender Datengröße verlangsamen können.
Gehen Sie nicht von einem Leistungsproblem aus. Entwickeln Sie eine realistische Testmethode für die Anwendung mit mindestens 10,000 Transaktionen und legen Sie eine Basislinie für kritische Vorgänge fest.
Setzen Sie anschließend nur die durch die Analyse gerechtfertigten Verbesserungen um. Behalten Sie das Erscheinungsbild der App, die Verbesserungen der Barrierefreiheit und das aktuelle Verhalten bei. Behaupten Sie keine Geschwindigkeitsverbesserung, es sei denn, Sie haben diese gemessen oder klar als erwartete Verbesserung definiert.
Claude entdeckte einen besonders wichtigen Engpass. Die Anwendung erstellte jedes Mal ein neues Währungsformatobjekt, wenn ein Betrag angezeigt wurde. Bei 10,000 Zeilen maß Claude für diesen Vorgang 349 Millisekunden. Durch die Wiederverwendung eines einzigen Formatierers konnte die Zeit auf 5.2 Millisekunden reduziert werden, was laut Claude einer 67-fachen Verbesserung entspricht.
Claude fügte außerdem eine „Tabellenvirtualisierung“ hinzu. Das bedeutet, dass der Browser nur die aktuell sichtbaren Transaktionen anzeigt, anstatt Tausende von Zeilen gleichzeitig. Such- und Speicheraktualisierungen wurden um Bruchteile einer Sekunde verzögert, um kostspielige Wiederholungen nach jedem Tastendruck oder jeder schnellen Änderung zu vermeiden.
Claude hat sogar Schaltflächen hinzugefügt, mit denen sich 1,000, 10,000 oder 50,000 Beispieltransaktionen für Stresstests generieren lassen.
Der überzeugendste Teil des Berichts war jedoch Claudes Eingeständnis, dass die meisten dieser Verbesserungen für den beabsichtigten Zweck der Anwendung nicht notwendig waren.
Ein typischer Haushalt verzeichnet monatlich etwa 30 bis 50 zusätzliche Transaktionen. Selbst zehn Jahre später kam Claude zu dem Schluss, dass die ursprüngliche Anwendung die anfallenden Daten wahrscheinlich ohne größere Probleme verarbeitet hätte. Abgesehen vom Caching des Währungsformatierers waren die meisten Verbesserungen nur deshalb sinnvoll, weil ich ausdrücklich die Unterstützung für Tausende von Transaktionen angefordert hatte.
Diese Zurückhaltung (oder Selbstbeherrschung) wirkte „reifer“ und „professioneller“ als bloße Änderungen um der Möglichkeit willen vorzunehmen.
Mein abschließendes Fazit
Ich fand diese Aussagen äußerst überzeugend, da jede einzelne Claudes Stärken und Schwächen klar herausstellte. Jede Rolle bot eine einzigartige Perspektive für die Bewertung, die ich sehr hilfreich fand und die ich sicherlich auch in meinen zukünftigen Rezensionen anderer Apps und Websites anwenden werde.
Während der Debugging-Ingenieur fehlerhaftes Verhalten aufdeckte, fand der Frontend-Entwickler Probleme mit Barrierefreiheit und Benutzerfreundlichkeit. Der Performance-Ingenieur hingegen berücksichtigte die Auswirkungen des steigenden Datenvolumens und erkannte, wann eine Optimierung unnötig war.
Die Erfahrung zeigte auch, warum eine pauschale Forderung wie „Produktionsreif machen“ nicht immer optimal ist. Selbst bei einer umfassenden Forderung können bei einer einzigen Überprüfung wichtige Punkte übersehen werden. Durch die Aufteilung der Arbeit in fokussierte Phasen hatte Claude weniger Prioritäten zu bearbeiten und seine Ergebnisse ließen sich leichter auswerten.
Beachten Sie bitte die Cloud-Nutzungsbeschränkungen. Beim nächsten Mal werde ich versuchen, die Eingabeaufforderungen zu kombinieren, um das zulässige Maximum nicht zu erreichen.
Kommentarfunktion ist geschlossen.