Wer im Labor einmal mit einem Laboranten bzw. Dekadisten zusammengearbeitet hat, entwirft Elektronik nur ungern allein. Mit Googles Bard steht eine künstliche Intelligenz in den Startlöchern, die eine ähnliche Aufgabe erledigen möchte. In diesem Kurztest werfen wir einen Blick darauf, wie sich Bard bei der Bekämpfung typischer Kodierungs-Aufgaben im Labor schlägt.
Was ist es?
Systeme wie ChatGPT und Co. nutzen eine „Wissensbasis“, um Antworten zu generieren. Während sich ChatGPT bei der Erzeugung diversester Dokumente gut schlägt, ist Googles Bard auf die Arbeit als „Hilfs-Codierer“ optimiert – darunter scheint man im Lande Google einen Codierer zu verstehen, der auf Anfragen mit dem Ausscheiden schlüsselfertiger Codestücke reagiert. Der Nutzer spart sich so den Umweg der Suche von Codesamples.
Wie nutzen?
Bard ist derzeit noch in der Betaphase – wer die URL https://bard.google.com/ mit einer deutschen oder ungarischen IP aufruft, bekommt die in Abbildung eins gezeigte Fehlermeldung gezeigt.
Bildquelle: Autor.
Zur Umgehung des Problems bietet sich die Nutzung eines VPNs an: der Autor verwendete ProtonVPN; nach dem einmaligen Abnicken eine Captchas funktioniert der Service problemlos.
Die eigentliche Anmeldung in der Warteliste dauert dann Stunden bis Tage – in angelsächsischen Quellen finden sich einerseits Berichte sofortiger Aktivierung, andererseits aber auch Berichte mehrtägiger Wartezeiten.
Erster Versuch.
An dieser Stelle bietet sich ein erstes Experiment an – als „Opfer“ dient der PIC16F84A.
Der eigentliche Workflow funktioniert dabei nach Schema F – im ersten Schritt muss der Entwickler eine Frage an Bard stellen, die das System danach beantwortet. In vielen Fällen bietet Bard mehrere Antworten an, Abbildung zwei zeigt, was Bard als Blink-Programm für den PIC 16F84A generiert.
Bildquelle: Autor.
Bard lässt sich um „Ergänzungen“ bitten. Abbildung drei zeigt eine gelungene Anpassung. Die praktische Erfahrung des News-Autors lehrt allerdings, dass sich Bard beim Anpassen von bereits gemachten Änderungen mitunter verhaspelt – in diesem Fall ist es vernünftiger, eine komplett neue Anfrage zu stellen.
Interessant ist, dass sich Bard auch bei der expliziten Aufforderung, C zu benutzen, „streng“ an der Assemblersprache festhält – idiomatische MCC-Konstrukte sucht man im Allgemeinen vergebens.
Bildquelle: Autor.
Experiment GigaDevice.
Nach Versuchen mit Achtbittern wollen wir nun auf den GigaDevice GD32VF103 setzen: Ein sehr leistungsfähiger RISCV-Kern, der (Unverdienterweise) noch nicht uneingeschränkt Reichweite hat. Abbildung fünf zeigt, wie Bard auf die Anfrage zur Erzeugung von Code reagiert.
Bildquelle: Autor
Wichtig ist, dass Bard nicht immer funktionierenden Code liefert – Abbildung sechs zeigt beispielsweise ein zwar kompilierbares, aber nicht wirklich vernünftig aufgebautes Programm.
Bildquelle: Autor.
Die Unterstützung für „sehr moderne“ Mikrocontroller liegt durch die Bank vor. Die Abbildung zeigt einen (unwissenschaftlichen) Versuch, „Code“ für den beispielsweise unter Beitrag „CH32V003 – Ressourcen und Beschnupperung der HAL“ im Detail besprochene CH32 zu generieren.
Bildquelle: Autor.
Und jetzt mit Prozessrechnern.
Nach den Experimenten mit dem Mikrocontroller bietet es sich an, denn Codier-Assistenten auf den Raspberry Pi loszulassen. Bei der Aufgabe, ein Blink-Programm zu realisieren, entscheidet sich das System für die Nutzung von Python.
Bildquelle: Autor.
Interessant ist, dass Google bei generierten Antworten auf Python-Basis die Option zur Ausführung in der Cloud anbietet – beim Raspberry Pi ist dies naturgemäß wenig nützlich. Interessanter ist die Frage, ob der Codier-Assistent auch mit Drittanbieter-Bibliotheken interagieren möchte. Die Antwort darauf ist, wie in Abbildung der Abbildung gezeigt, ja.
Bildquelle: Autor.
In Tests des Autors, kam Bard übrigens auch mit ESP_IDF hervorragend zurecht.
Desktop-Entwicklung zeigt Grenzen des Sprachmodells.
Moderne Systeme setzen oft eine „Compagnon-Applikation“ am Desktop oder am Handcomputer voraus. Als erster Test bietet sich das Stellen einer komplizierten Anfrage an, was zur in der Abbildung gezeigten Ablehnung führt.
Bildquelle: Autor.
Interessant ist, dass dies nicht immer der Fall ist. Geht es beispielsweise um die Erzeugung eines MQTT-Clients, so lieferte Bard wie in der Abbildung gezeigt durchaus „gangbare“ Resultate.
Bildquelle: Autor.
In Tests des Autors erweist sich Bard bei der Android- und der .net-Desktopentwicklung mal kompetenter, mal weniger kompetent – insbesondere für „Dienst-unerfahrene“ Entwickler ist das System eine Hilfe.
Fazit: Helfer, nicht Eliminator.
Nach Ansicht des Newsautors ist Bard ein Werkzeug – nicht mehr, aber auch nicht weniger. Wie der eine oder andere Laboranten beim Auftauchen des LeCroy-Oszilloskops mit integrierten Berechnungsfunktionen Angst vor dem Ersatz hatte, so hat nun auch der eine oder andere Codierer Angst davor, durch die künstliche Intelligenz unnotwendig gemacht zu werden.
So sehr die von Bard generierten Ergebnisse auf den ersten Blick „beeindruckend aussehen“, so wenig ist das System in der Praxis ein Produkt, über das man sich als Entwickler Job-Angst machen sollte. Ganz im Gegenteil, ist Bard vielmehr ein manchmal nützlicher Helfer, der weder wefzt noch ein Gehalt einfordert. In diesem Sinne ist es empfehlenswert, schon jetzt mit Bard zu experimentieren und von den möglichen Produktivitätssteigerungen zu profitieren.
Zum alleinstehenden Codieren, der einen humanen Codierer ersetzen kann, taugt das Produkt allerdings – siehe zum Beispiel die Abbildung mit Android – noch nicht. Außerdem gilt, dass Bard zum Zeitpunkt der Drucklegung sich nicht wirklich in vorhandene Solutions integrieren kann – das Produkt beschleunigt die Literaturrecherche mitunter erheblich, mehr tut es aber nicht.
Zuerst erschienen bei Mikrocontroller.net News
Quelle: Read More