Longbow
Here to stay
|
hrhr 
ja. ohne senior software dev da code in prod hauen spielts noch ned.
ich hab letztens was mit der atlassian cli gemacht.
acli installiert und dann einen agent skill dazu installiert.
er hat mir dann in jira alles brav ausgelesen, eingefügt etc.
zum schluss bin ich draufgekommen dass der skill nicht im richtigen ordner war.
er hat nen fehler im hintergrund geworfen und dann einfach geschaut ob acli installiert war und dann diese genutzt anhand der befehle und rückmeldungen. das is schon krass... und auch der grund warum ich sowas nicht ausser einer vm verwenden würde. (also jetzt opencode) "hau in code in prod, do magic" ist ja noch weit weg von "nimm das absolut bekannteste monitoring stack, von dem es 200mio vorlagen gibt und gib mir eine _in sich konsistente version_" man merkt einfach wie die LLM Technologie ständig in das inhärente Limit läuft, dass es halt den "Wahrscheinlichsten" output produziert. Und der war halt anscheinend ständig von irgendeinem anderen github gist, bis dahin, dass er angefangen hat meine versionen oder images zu ändern, weil die training data war halt noch ned auf v30 sondern damals war v21 etc.... --- zweites experiment war: "hier is mein repo, war bisher zfäu für readme, bitte mach das". Same old story. 80% eh ok und dann fängt er an Sätze rein zu halluzinieren, womit das Repo nix zu tun hatte.
|
JDK
Oberwortwart
|
Code wird "im besten Fall" gar nicht mehr reviewed, es werden Specs getestet.
Wenn das Ergebnis den Anforderungen gerecht wird, sind alle happy. Ja das ist der feuchte Traum grad, aber bis die Specs umfangreich genug sind, ist viel Zeit vergangen und du weißt nach wie vor nicht welche Sicherheitslücken und Ineffizienzen vorhanden sind. Klar, kannst alles nach und nach entdecken (viel Spaß wenn da wichtige Kunden dran hast) und einpflegen mit neuen Specs etc, aber da hättest die Zeit auch gleich fürs Review aufwänden können. Wenn die Specs nicht das umfangreiche Domänenwissen eines gestandenen Entwicklers abbilden und genügend Details für die Features, Tech Stack, APIs und Services innerhalb der Firma usw mitbringen, hast am Ende ein Ergebnis, wo erst wieder viel rumdoktorn musst. Ein Opus 4.6 oder 5.3-Codex sind schon sehr gute Sparring-Partner und Kickstarter, aber ich persönlich bin noch nicht soweit, der LLM ohne Review zu vertrauen, wenn ich meinen Kopf für deren Output hinhalten muss. Dafür passiert noch zu viel Tohuwabohu. z.B. Zahlenhalluzinationen; die AI erklärt mir XY sei ein Known Issue, den sie sich aber zamgedichtet hat, nachdem sie sich verrannt hat; installierte verwaiste Dependencies, die komplett unnötig wären etc Blogbeitrag/Podcast zum Thema:
The dark factory is real, most developers are getting slower, and your org chart is the bottleneck (plus 5 prompts to get from level 2 to 5)Watch now | Three engineers at StrongDM run a software factory where no human writes code and no human reviews code. Link: natesnewsletter.substack.com
Oder als Clickbait auf Youtube:
The 5 Levels of AI Coding (Why Most of You Won't Make It Past Level 2)
Was ich mir aus dem Video mitgenommen hab: der KI Tests schreiben lassen ist nicht unbedingt eine gute Idee, weil der Code dann vielleicht nur zur Testerfüllung getrimmt wird. Besser: Testanforderungen extern ablegen/durchführen lassen oder wirklich selbst machen. War ein paar Mal an dem Punkt, wo ich das als "go vibe!" abtun wollte, aber er spricht die Themen relativ nüchtern und umfangreich an. Danke fürs Sharen. Er spricht eh auch den Punkt mit der Komplexität bzw der neuen Herausforderung von guten Specs an.
|
Daeda
Renegade
|
Ja das ist der feuchte Traum grad, aber bis die Specs umfangreich genug sind, ist viel Zeit vergangen und du weißt nach wie vor nicht welche Sicherheitslücken und Ineffizienzen vorhanden sind. Klar, kannst alles nach und nach entdecken (viel Spaß wenn da wichtige Kunden dran hast) und einpflegen mit neuen Specs etc, aber da hättest die Zeit auch gleich fürs Review aufwänden können.
Wenn die Specs nicht das umfangreiche Domänenwissen eines gestandenen Entwicklers abbilden und genügend Details für die Features, Tech Stack, APIs und Services innerhalb der Firma usw mitbringen, hast am Ende ein Ergebnis, wo erst wieder viel rumdoktorn musst.
Ein Opus 4.6 oder 5.3-Codex sind schon sehr gute Sparring-Partner und Kickstarter, aber ich persönlich bin noch nicht soweit, der LLM ohne Review zu vertrauen, wenn ich meinen Kopf für deren Output hinhalten muss. Absolut, meine "" bei "im besten Fall gar nicht mehr reviewed" waren auch halb sarkastisch, halb ungläubig gemeint. Ich review den output meiner Agents zuerst selbst und dann noch zusätzlich von einem externen Tool, zB CodeRabbit, bevor ichs an Kollegen zum PR weitergebe. War ein paar Mal an dem Punkt, wo ich das als "go vibe!" abtun wollte, aber er spricht die Themen relativ nüchtern und umfangreich an. Danke fürs Sharen.
Er spricht eh auch den Punkt mit der Komplexität bzw der neuen Herausforderung von guten Specs an. Ging mir ähnlich damit - hab gehofft mit dem Artikel dazu wirkt es etwas seriöser, als es auf YT vor Allem am Anfang ist.
|
rad1oactive
knows about the birb
|
Bei uns versuchns grad zB einen first level support bot zu bauen in unserer IT, der auf basis bestehender Tickets antwortet und wenn er keine Lösung findet ein neues ticket erstellt.
|
semteX
liebt die große KI
|
Wenn die Specs nicht das umfangreiche Domänenwissen eines gestandenen Entwicklers abbilden und genügend Details für die Features, Tech Stack, APIs und Services innerhalb der Firma usw mitbringen, hast am Ende ein Ergebnis, wo erst wieder viel rumdoktorn musst. das stimmt imho nicht (und selbst wenns stimmt, wird es so nicht ewig bleiben). claude ist im plan-modus durchaus fähig sich durch die vorhandene architektur domainwissen zu erschließen und auch unterdurchschnittlich schlechten input auf diese domäne zu mappen. oder halt auch retour zu melden, dass der input auf keinem auge zum aktuellen domänenmodell und behavior passt, weil ein entwickler das ticket mit viel "ich glaub" und "so sollts sein" und "er wirds schon merken" geschrieben hat. weiters rede ich noch ned davon, dass der CEO selber rein-prompted. aber für was brauchst 100 devs, wenn du 3 vision keeper (aka architekten) und 10 prompter hast. der viel größere punkt aktuell ist aber imho tooling. ich hab mir in der einen woche mehr scripte und ui clients geschrieben als in den letzten 20 jahren zusammen. and i love it. edit: ich hab mir gestern abend übrigens noch docker & k8s scripts erzeugen lassn. mein PaceTrace(tm) rennt jetzt in einem k8s container. edit2: ❯ ok **** it.
● Yeah, Rancher Desktop + WSL2 networking is a pain. Port forwarding with kubectl port-forward svc/pacetrace 8080:80 is the simplest way to just get it working locally. If you ever want proper LAN access, consider running K3s on a dedicated Linux box or VM with a bridged network adapter.
Bearbeitet von semteX am 21.02.2026, 08:53
|
XeroXs
Vereinsmitglied10ideen.at
|
Kurz zu meinen Erfahrungen mit Claude Code (gestartet mit 4.0 dann 4.5 und jetzt 4.6): Ja, wenn man das ganze "ungesteuert" laufen lasst, dann hat man am Ende einen Haufen Code den man nicht mehr warten kann. Noch. Mit 4.6 ist das wieder deutlich besser geworden, und man darf gespannt sein wie groß der Sprung mit 5.0 sein wird. Ich hab vor einiger Zeit schon ein Experiment gestartet: Ich schon länger ein "Lernkonzept" für meinen Sohn (der sich mit Auswendiglernen schwer tut) im Kopf. Hab daraus mit Claude ein Produktkonzept erarbeitet, und dann daraus einen SW-Entwicklungsplan (Konzept, Architektur, User Stories (inkl. Akzeptanz und Testkriterien), Sprints). Das Ergebnis war ein Entwicklungsplan für ein 10köpfiges Team und ca. 9 Monate Entwicklungsaufwand. Ich fand das etwas hoch, aber auch wenn wir das halbieren wäre das immer noch ein riesen Aufwand, und etwas was man nie und nimmer selber stemmen könnte. Ich hab das dann Sprint für Sprint in Claude Code reingeworfen, das Konzept und Architekturdokument als Begleitung, ein paar extra Regeln definiert (80% code coverage, nach jedem sprint deploybar, ...) und was soll ich sagen  Ja, es hat hin und wieder etwas Feintuning und Korrektur benötigt, aber Claude hat mir eine Version hingestellt die schon ganz gut funktioniert, viele "Nebenprobleme" gelöst an die ich garnicht dachte, und ca 70% davon in 5 Abenden (je ~2 Stunden vielleicht) umgesetzt. Habe dann vorerst aufgehört weil alle Funktionen die ich brauchte bereits da waren. (Inkl. Responsive Design dass ich so nie hinbekommen hätte, verspielten Animationen, i18n, Oauth, Magic Link Login, Administration, User Statistiken (via Prometheus und Google Analytics), Wunderschönes Postgres Schema, GitHub Actions zum automatisch deployen,...). Payment und Abo-Management via Stripe hab ich dann mal übersprungen  Anbei noch ein paar Screenshots:    Klar, das ist jetzt in der Qualität nichts was man als Firma so haben möchte, aber die Definition der Userstories mit Test & Akzeptanzkriterien hat die Qualität schon sehr gut oben gehalten. Wenn man das ganze auch noch vor Implementierung lesen und verfeinern würde dann wäre das Ergebnis bestimmt noch besser. Da sehe ich auch das Hauptproblem.. als Dev bleibt dir eigentlich nur mehr der lästige Teil der Arbeit: Dokumentieren, Reviewen und Testen. Den kreativen Teil des Jobs der allen Spass macht geht damit dahin.
|
semteX
liebt die große KI
|
Da sehe ich auch das Hauptproblem.. als Dev bleibt dir eigentlich nur mehr der lästige Teil der Arbeit: Dokumentieren, Reviewen und Testen. Den kreativen Teil des Jobs der allen Spass macht geht damit dahin. ich seh das anders, ich kann noch immer an den technischen cornerstones herumkniefeln, mit leuten syncen, sachn bedenken die die AI noch nicht weiß (z.b. wie der input aussieht).. noch... ich seh mich halt als problemlöser, code ist mein werkzeug.
|
Vinci
hatin' on summer
|
Ich nicht, wenn i Manager spün will hättat I BWL studiert. In der letzten ProgrammierBar Folge war das auch Thema. Da hat einer gmeint er is am End vom Tag paniert wenn er parallel zig Agenten bedient, viel mehr als vom bisherigen Tagesablauf.
|
d0lby
reborn
|
Ich würde nicht sagen, dass billige junge Menschen betroffen sind.
Der kennt sich bissl aus, den nimmst als Junior auf, der ist billig, kann etwas und ergänzt sein Wissen selbst oder mit der KI. In 5 Jahren hat er eine gewisse Erfahrung.
Den 55 jährigen Senior brauchst nicht
Zumindest bis zum ersten tiefgründigen Problem den weder KI noch der Junior lösen können.
Danach gibt es Maßnahmen, wie man sich verbessert. Bis zum nächsten Problem. Und irgendwann sind 10 Jahre vorbei, der Junior hat schon viel dazu gelernt. Problem solved. Firma hat sich Geld gespart.
|
JDK
Oberwortwart
|
das stimmt imho nicht (und selbst wenns stimmt, wird es so nicht ewig bleiben). claude ist im plan-modus durchaus fähig sich durch die vorhandene architektur domainwissen zu erschließen und auch unterdurchschnittlich schlechten input auf diese domäne zu mappen.
oder halt auch retour zu melden, dass der input auf keinem auge zum aktuellen domänenmodell und behavior passt, weil ein entwickler das ticket mit viel "ich glaub" und "so sollts sein" und "er wirds schon merken" geschrieben hat.
weiters rede ich noch ned davon, dass der CEO selber rein-prompted. aber für was brauchst 100 devs, wenn du 3 vision keeper (aka architekten) und 10 prompter hast.
der viel größere punkt aktuell ist aber imho tooling. ich hab mir in der einen woche mehr scripte und ui clients geschrieben als in den letzten 20 jahren zusammen. and i love it. Ja vom Tooling red ich da ned. Ob dir jetzt ein Script für irgendeine 0815 Automation zamstoppeln lässt oder eine komplexere Software, die mit 45 Jahren Firmengeschichte klarkommen muss, sind halt zwei Paar Schuhe. Da reden wir von einer Vielzahl an Domänen und APIs, die sich durch ein halbes Dutzend Mergern mit anderen Firmen zu einer schönen Ranzsuppe entwickelt hat. Bissl vorschnell da auch "das stimmt imho nicht" zu schreien, wenn du offensichtlich weder im gleichen Umfeld, noch an den gleichen Aufgaben arbeitest. Wenn der KI der Context fehlt, wird sie zwangsläufig von Dingen abweichen - was wiederum manuelle Intervention bzw Nacharbeiten erfordert. Die KI kann nicht zaubern. Sie kann nur mit dem arbeiten, mit dem sie an irgendeinem Punkt (per Training oder Context) gefüttert wurde. Ich sehe ständig Themen, wo die KI struggled oder irgendetwas halluziniert bzw produziert und man Hand anlegen muss. Selbst bei Projekten die nicht Greenfield sind und entsprechend viel implizite Information vorhanden ist. z.B. KI macht aus einer Sample Response von einer REST API TypeScript Types, verwechselt aber manche Objekte mit ihnen ähnlichen und "verliert" dementsprechend Properties. Oder KI berechnet Koordinaten falsch, weil der Kontext über die Daten fehlt (SVG verwendet top-left, Daten centered). Oder KI installiert komplett irrelevante Packages. Oder KI hat absolute Nervenzusammenbrüche mit einem jüngeren Framework. Da gibt's dann noch tausend andere Themen, wie Auth, interne Policies & best practices usw. Ja, das SOLLTE niedergeschrieben sein. Ist aber erstens zerstreut und zweitens muss die KI davon in Kenntnis gesetzt werden. So etwas braucht Zeit, Struktur und entsprechend große Context-Windows. Und wenn wir so weit sind, dann sind die Bedingungen, die ich vorhin erwähnt habe, eh gegeben. Klar sind das Themen, die später in 2026 eventuell wieder ganz anders aussehen, aber Stand jetzt mache ich diese Erfahrungen und habe dementsprechend diese Ansicht. Zum Thema "Skill development" hat Anthropic selbst eine Studie gemacht (weiß nicht mehr, ob ich die eh aus einem Thread hier hab oder es in der Arbeit geshared wurde): How AI assistance impacts the formation of coding skillsIt’s unclear whether this cognitive offloading can prevent people from growing their skills on the job, or—in the case of coding—understanding the systems they’re building. Our latest study, a randomized controlled trial with software developers as participants, investigates this potential downside of using AI at work. Link: www.anthropic.com tl;dr: vibe coding == schlechteres Skill Development (surprise pikachu)
Bearbeitet von JDK am 21.02.2026, 21:20
|
semteX
liebt die große KI
|
das hört sich aber auch für jeden neuen mitarbeiter nach der vollkommenen hölle an, tbh. bei uns gehen die leute schon durchs tal der tränen, aber das is nochmal... anders...
|
JDK
Oberwortwart
|
Das sind Situationen die du in vielen größeren Firmen hast. Natürlich kommt damit eine gewisse Komplexität im Einstieg, aber du setzt den neuen Kollegen ja nicht auf jeden Task an.
Wir reden hier auch hoffentlich nicht davon, dass die KI den neuen Mitarbeiter (potenziell) ersetzt, sondern - wie zuvor formuliert - "gestandene" Entwickler. Gemeint war natürlich jemand, der in der Firma voll etabliert ist.
Dass die jetzt schon mehr bringt als ein Day 1 Hire, steht wohl außer Frage.
|
semteX
liebt die große KI
|
ja, da kann ich mit. ich tu seit 15 minuten nichts anderes dem claude bugs reporten nachdem er deep linking einbaun musste. wir sind halt trotzdem noch 100x so schnell wie wenn ichs selbst gemacht und 10x so schnell wie wenns wer gemacht hätt, der react kann. aber zu den 3.5% erfolgsquote zählt das jedenfalls ned. is aber trotzdem ein immenser erfolg
|
JDK
Oberwortwart
|
Na eh, keine Frage. Ich seh ja selber die Gains (in bestimmten Usecases).
Mir ging es rein um den "let's yolo into spec driven development only, no reviews, only outcomes"-Move (den meine Führungsetage ja auch anstrebt), der halt (noch) nicht so ezpz ist.
Aber abgesehen von den Firmengegebenheiten muss ich da natürlich auch selber am Spec-Skillset arbeiten.
|
KruzFX
8.10.2021
|
Bin jetzt auch geflasht, hab gerade mit Claude meine erste Android App gebaut, mit der man ausgedruckte Terminpläne scannen und in ics Files umwandeln kann oder gleich direkt in den Google Kalender einlesen kann. 3-mal nachgebessert und funktioniert. Das hätte ich so niemals geschafft, über ein bisschen Python am Rasperry Pi komme ich mit meinen Programmierkenntnissen sonst nicht.
|
Anmeldung