software development
Follow from the Fediverse
Follow #software_development from Mastodon or any other Fediverse app and its public posts arrive in your timeline. No vutuv account needed.
@software_development@tags.vutuv.de
Also known as
Software-Development, SoftwareDevelopment
The most endorsed users with this tag
-
Johannes Haubold Software Developer @ megorei Software GmbH
-
Sebastiaan Driesen Director @ Techit GmbH
-
Andreas Klapperich Software Developer => Entwicklungsleitung ...
-
Robert Hoschek Project Leader @ OMICRON electronics
Posts with this tag
3 posts
Filters
Meine bisherigen Erfahrungen mit Agentic Coding
Viele Diskussionen über KI klingen aktuell so, als würde durch Agenten automatisch Wissen verloren gehen.
Meine Erfahrung ist bisher eine andere.
Ich habe nicht das Gefühl, dass ich dadurch Fähigkeiten verliere.
Eher im Gegenteil:
Mein technischer Hintergrund wird wichtiger.
Ich kann Konzepte verstehen, Architekturen bewerten, Fehler erkennen und die richtigen Fragen stellen.
Genau diese Fähigkeiten brauche ich, um Agenten sinnvoll einzusetzen.
Agenten ersetzen kein Engineering
Ein Agent ist kein magischer Softwareentwickler, der eine Idee in ein perfektes Produkt verwandelt.
Er braucht:
- Kontext
- klare Ziele
- technische Leitplanken
- jemanden, der Ergebnisse kritisch bewertet
Ich lese weiterhin Code.
Ich schaue mir Diffs an.
Ich versuche zu verstehen, was geändert wurde und warum.
Das ist vielleicht sogar wichtiger geworden, weil die Geschwindigkeit steigt.
Wenn man in kurzer Zeit viele Änderungen erzeugen kann, muss man umso besser beurteilen können, welche davon sinnvoll sind.
Die Veränderung liegt woanders
Weniger Zeit geht dafür drauf, jede einzelne Zeile manuell zu schreiben.
Mehr Zeit fließt in:
- Architektur
- Anforderungen
- Kommunikation
- Qualität
- die Frage: Bauen wir eigentlich das Richtige?
Natürlich ist das auch eine neue Fähigkeit, die man entwickeln muss.
Man muss lernen, Agenten richtig anzuleiten, gute Kontexte bereitzustellen und die Zusammenarbeit mit ihnen zu verbessern.
Das ist kein fertiger Prozess.
Es ist eine Reise.
Nicht, weil KI den Menschen ersetzt.
Sondern weil Menschen mit einem guten Verständnis für Technologie plötzlich Dinge umsetzen können, für die früher viel mehr Zeit oder ein größeres Team notwendig gewesen wäre.
From other networks 1
Warum ich bei vutuv nicht nur diskutieren möchte
Ein weiterer Grund, warum ich vutuv spannend finde, ist die Art, wie man sich beteiligen kann.
Ich arbeite selbst seit vielen Jahren im Technologie- und Innovationsumfeld.
Ich kann ordentlich coden, bin mit Linux auf der Kommandozeile groß geworden und verstehe Softwarearchitekturen, technische Konzepte und die Entscheidungen dahinter.
Aber Softwareentwicklung ist nicht mein Vollzeitjob – und niemand beherrscht jede Programmiersprache, jedes Framework und jede Toolchain gleichermaßen gut.
Das heißt aber nicht, dass mir Ideen fehlen oder ich nicht sehr konkrete Vorstellungen davon habe, wie etwas funktionieren und technisch umgesetzt werden sollte.
Genau hier finde ich Agentic Coding spannend
Für mich bedeutet Agentic Coding nicht:
“Die KI schreibt schon irgendwas und fertig.”
Im Gegenteil.
Mein technisches Hintergrundwissen brauche ich ständig, um Agenten sinnvoll zu dirigieren.
Ich muss verstehen, welchen Weg sie einschlagen, Entscheidungen hinterfragen, Diffs lesen und mir weiterhin den Quellcode ansehen.
Was sich verändert, ist vor allem die Menge an Handarbeit zwischen einer Idee und ihrer Umsetzung.
Nicht weniger Engineering – sondern anderes Engineering
Statt mich tagelang in jede neue Programmiersprache oder jedes Framework einarbeiten zu müssen, kann ich schneller experimentieren, ausprobieren und konkrete Lösungen entwickeln.
Dabei hat mir auch @wintermeyer mit seinem letzten Heise-Beitrag zu Agenten sehr aus der Seele gesprochen.
Ich finde es schwierig, wenn Open-Source-Projekte KI entweder grundsätzlich ablehnen oder Regeln schaffen, die am Ende so kompliziert werden, dass ein großer Teil des Produktivitätsgewinns wieder verloren geht.
Natürlich brauchen Agenten Leitplanken.
Aber wir wissen heute noch nicht perfekt, wie diese aussehen müssen.
Wir müssen experimentieren, lernen und unsere Arbeitsweisen verbessern:
-
bessere Guidelines
-
bessere Skills
-
bessere Tests
-
bessere Reviews
Das ist eine Reise.
Und genau deshalb sind Open-Source-Projekte für mich eine ideale Spielwiese:
Man lernt neue Werkzeuge kennen und schafft gleichzeitig echten Mehrwert.
Deshalb möchte ich bei vutuv nicht nur Feature-Wünsche äußern.
Wenn aus “Ich hätte da eine Idee” mit Hilfe von Agenten irgendwann “Hier ist der Pull Request” wird, finde ich das ziemlich großartig.
From other networks 1
It should go without saying, but apparently, there are still companies who make the mistake to measure and communicate time to first deployment to production as the primary metric to tell how long a feature takes. But this is misleading: A feature isn’t actually finished until the last bug (sure, there will be more in the future, but “last” as in “it can be used without bugs for now as promised to the customer”) is fixed. So, trying to deploy as fast as possible might make marketing happy, but in the long run, it will hurt you (and probably your reputation as a company).
That being said, there sure are some aspects of #software_development which are in fact optional and #software_testing can cost more time than it saves—when it is done wrong. However, generally speaking, testing, be it #TDD, #BDD, #ATDD, or other approaches, should not be optional. Same goes for #code_quality. Sure, this needs to be done at a reasonable level, perfection doesn’t need to be the goal, but “no matter how bad the code is as long as it is written fast” shouldn’t be it either.
