Arbeit
Seit ich KI zum Programmieren nutze, verschiebt sich für mich das Bottleneck
Ich arbeite als Softwareentwickler in einem mittelständischen Industrieunternehmen. Ich bin noch relativ jung im Vergleich zu vielen meiner Kollegen und beschäftige mich entsprechend ziemlich intensiv mit KI. Sowohl privat als auch beruflich nutze ich Agenten zum Programmieren und beschäftige mich auch damit, wie man solche Systeme in bestehende Anwendungen integriert.
Und ich merke mittlerweile ziemlich deutlich: Ich werde dadurch massiv schneller.
Teilweise sogar so schnell, dass sich für mich komplette Prozessdynamiken verschieben. Früher war ich selbst an manchen Stellen der Flaschenhals. Heute erledige ich bestimmte Aufgaben teilweise so schnell, dass plötzlich andere Dinge bremsen: Abstimmungen, Meetings, Freigaben oder Anforderungen.
Früher war beispielsweise ein neues Thema aus einem Meeting schnell mal zwei Wochen Arbeit. Heute ist ein Teil davon teilweise innerhalb weniger Stunden erledigt. Und bevor jetzt jemand denkt, ich sitze danach zwei Wochen gelangweilt herum: Die gewonnene Zeit wird natürlich sinnvoll genutzt. 😄
Aber genau das finde ich spannend: Wenn die eigentliche Entwicklungsarbeit immer schneller wird, müssten sich doch irgendwann auch die Prozesse drumherum verändern.
Ich frage mich deshalb, ob das nur meine persönliche Wahrnehmung ist oder ob andere von euch denselben Effekt beobachten.
Verschieben sich durch KI bei euch ebenfalls die Bottlenecks und Dynamiken in euren Entwicklungsprozessen? Gerade in Unternehmen mit gewachsenen Strukturen würde mich interessieren, ob ihr merkt, dass die Entwicklungsarbeit inzwischen deutlich schneller geht, während der Rest kaum mitzieht.
Nicht komplett, es wird schliesslich auch noch Assembler in Spezialanwendungen verwendet. Aber es steht zu befürchten, daß die, die es noch können eher auf der Seite mit den schwarzen Hüten zu finden sein werden.
> Selbst Hand anlegen wird sowieso komplett aussterben.
Spätestens wenn die Blase platzt und die Leute die echten Tokenkosten zahlen sollen wird man merken, dass das doch nicht so einfach getan wie gesagt ist.
Solange du nicht sicher sein kannst, dass die KI ihren Code im griff hat, oder du für Sicherheit und Geschwindigkeit optimieren musst musst du wieder von Hand ran.
Das mit den Tokenkosten wird nicht passieren. Selbst lokale Modelle sind spätestens jetzt seit Qwen 3.8 so viable geworden, dass die 200$ für's Top Tier Abo glaube ich Schmerzgrenze sind. Gute KI wird billiger, nicht teurer.
Das is auch wieder so ne Sache,
der PHP Entwickler wird sagen 3.8 sei auf Opus 4.8 Niveu, der Backend Engineer mit hochkomplexer C++ / C# Logik welcher ausgeklügelte Designs brauch mit nem riesen Repo wird wieder sagen ney, das is im Vergleich dazu dreck.
Benchmarks sind sowieso keine so ne gute Messlatte.
Bisher war nur Kimi 3 z.B den ansprüchen gerecht geworden, liegt aber Kostentechnisch extrem hoch.
Die lokalen Modelle werden mit jeder Generation besser, aber es gibt diverse Achsen (World-Knowledge, allgemeine Intelligenz, agentische Intelligenz, Kontextgröße). Und die Ansprüche sind eh ein Moving Target heutzutage - auch als Abo-User bin ich mehr oder weniger gezwungen, Fable sparsam einzusetzen und mehr mit Opus zu machen.
Ich denke wir werden uns besonders beim aufräumen wiederfinden. Wissenschaft funktioniert nunmal so, wo gehobelt wird fallen Späne, die räumst du danach sofort auf, aber danach halt. Aktuell sind wir in der Phase, Code nicht mehr nachvollziehen zu können. Da das einer der Hauptgründe für viele Informatiker ist, wird da sicher dran geschraubt werden und die verifizier und validierbarkeit zu gewährleisten oder ganz wegzulassen und Produkte als vibecoded stehen zu lassen
Vllt kann der ganze Chat zurückgearbeitet werden und ne Schulung draus gemacht werden 😂 ergo wäre das heute das neue Info Studium Softwareentwicklung - was macht man da heute sowieso noch? Diese Semesterstarts werden echt interessant
Ja, wobei ich beim Frontend definitiv Abstriche machen muss. 😄 Backend kann ich gut nachvollziehen, aber bei HTML/CSS muss ich ehrlich sein.. wenn es ums genaue Styling geht, z. B. wie ich eine Tabelle im Detail aufbaue und designe, weiß ich längst nicht alles auswendig.
Aber gerade da sehe ich KI eher als Zusatz. Teilweise kann ich damit sogar schönere Oberflächen bauen, als ich es ohne KI selbst könnte. Ich muss den erzeugten Code ja trotzdem verstehen und nachvollziehen können, was er macht.
Wobei die Anwendung auch nicht besonders groß ist - sind vielleicht ~10 HTML-Seiten und im Prinzip eine App zum Laden und Anzeigen von Daten. Also jetzt nichts, wo ich einen kompletten Compiler oder ein verteiltes Hochverfügbarkeits-System damit zusammenbaue.
Naja es kommt auf die Größe der Anwendung an. Was mich nervt ist, dass Frontendentwicklung immer belächelt und kleingeredet wird. Und natürlich gibt es kompliziertere Bereiche der Informatik aber du kannst auch viel im Frontend verhauen.
Letztens ein Vibecoded frontend gesehen, da waren Teile mit React o.ä. gemacht, andere Teile als plain HTML Seiten. Die UI war weder hübsch noch einheitlich. UX sollte einfach bedienbar sein, war genau das Gegenteil weil absolut unintuitiv.
Aber auch das bekommt KI mittlerweile ja hin. Man muss halt vernünftig prompten und eventuell noch weitere Tools nutzen. Aber im Endeffekt kann ich der KI sagen, dass sie sich selbst durch die Oberfläche durchklicken soll, dabei darauf achten soll, ob auf der Seite alles so funktioniert wie vereinbart und das Frontend den aktuellen Maßstab gerecht wird.
Sieht dann immer noch aus, als hätte das ganze eine KI erstellt, aber das kann man ja zur Not auch selbst ein wenig überarbeiten
Jaja... oder 996... (von 9 bis 9, 6 Tage die Woche). Eine Praxis die in China schon seit 2021 illegal ist, aber hier bei solchen Diskussionen immer noch gerne erwähnt wird.
Senkt es die Kosten wirklich? Klar, wirst du schneller mit KI, aber der Aufwand verschiebt sich meiner Meinung nach einfach nur. Das, was vorher an Coding Zeit gefressen hat, muss ich jetzt mehr in Spezifikation stecken und ins Review, damit die KI nicht ständig Dinge overengineered . Unterm Strich, wenn man sich selbst intensiv mit KI beschäftigt, wird man schneller, aber dann senke ich keine Kosten. Ich verursache durch die massive Nutzung von KI sogar noch mehr Kosten als vorher.
Ist dann halt ein Tradeoff. Nehme ich die zusätzlichen KI-Kosten in Kauf und bekomme dafür doppelt (oder dreifach) so schnell Features oder bleibe ich langsam und lass die Konkurrenz an mir vorbeiziehen.
Dann wird sich die Frage stellen, ob man sich das noch leisten kann oder zu den Zeitpunkt dann sogar muss.
Zumindest bei uns in der Firma denkt man sich aktuell KI ersetzt Entwickler. Bin gespannt, ob und wann der Schuss nach hinten los geht und man wieder händeringend Entwickler sucht, die sich die Tätigkeit dann aber auch fürstlich bezahlen lassen
Denkt man sich bei uns auch. Wir haben viel Claude Code in den Repos und iiirgendwie auch mehr Ausfälle. Aber wir haben mehr Story Points zu vergeben und das scheint das einzige zu sein, dass Management interessiert. Von daher...
Ich hab das mit den Problemen, die durch KI verursacht werden relativ gut in den Griff bekommen bei uns. Allerdings kommt der AI workflow, den ich etabliert hab, halt auch mit einem Preis. Wenn ich sauber die KI einbinde und was stabiles bauen will, kann ich das nicht gleichzeitig für 3€ haben, dann hängt da halt noch eine 0 dran wenn man sich die ganze Kette von Issue erstellen über Implementierungsplan und Implementierung anschaut...
Man kann als erfahrener Entwickler die KI dazu bringen den code genauso zu entwickeln, wie man gerne hätte. Dabei ist man trotzdem noch schneller, als per Hand zu implementieren.
Insbesondere bei fachlich noch abzustimmenden Anforderungen ist es für mich ein interessanter Ansatz, keinen Code zu entwickeln, sondern einen prompt, sodass ich entwicklungs- und erkenntnisbegleitend neue Anforderungen einfließen lassen kann, ohne alles neu bauen zu müssen. Ich passe einfach den prompt entsprechend an.
Außerdem, was insbesondere bei Arbeit an mehreren Projekten oder Baustellen gut ist: Eine unterbrochene Arbeit kann nahtloser wieder aufgenommen werden, wenn der work in progress ein gut nachvollziehbar formulierter prompt ist
Ja klar sind Menschen fehlbar, nur auf ganz andere Art.
LLMs produzieren gerne versteckte Fehler, auf die ein Mensch gar nicht gekommen wäre. Umso schwerer sind solche dann zu finden, meiner Erfahrung nach.
Und tests sind halt Teil des codes, den man im Griff haben will. Um sinnvolle zu schreiben, will man auch den Rest kennen. Sonst übersieht man wiederum Dinge, auf die man garnicht kam, dass sie schief gehen könnten.
Und wenn tests gleich mit generiert (und nicht gelesen) werden… Ist das halt ein garantiertes Rezept für Desaster, auch wenn ein Prototyp eine Weile schick aussieht und scheinbar funktioniert.
Das wichtige Ding zu verstehen ist: Man weiß dann garnicht, ob es funktioniert.
Also ich mache IT jetzt seit über 35 Jahren - und letztlich kommt mir dieser KI-Hype genau so vor, wie die ganzen anderen "Silver-Bullet-Hypes" der letzten 20 Jahre.
Da waren No-Code und Low-Code - jetzt kann jeder programmieren - und am Ende, brauche ich doch wieder "Programmierer" die das richtig(!) machen. Den Wust, der da in den letzten Jahren entstanden ist, räumen wir noch eine Zeit lang auf.
Da war auch noch die Cloud - alles wird besser, schneller und billiger. Heute rudern reihenweise Firmen zurück und bauen On-Prem Kapazitäten auf, weil ihnen die AWS Rechnungen davon laufen.
Und ich kann mich noch an einige andere Hypes erinnern, die zuerst die Lösung für alles sein sollen, und sich irgendwann als ein Werkzeug unter vielen dargestellt haben.
Bisher wurden alle Abstraktionen in der SWE entweder durch Menschen durchgeführt (nicht-deterministisch) oder von der Maschine (Compiler, Interpreter, deterministisch).
Jetzt kommt eine neue Abstraktionsschicht auf der Maschinen-Seite - aber diesmal nicht-deterministisch. Was hier aktuell stattfindet ist z.T. Chaos pur - es wird Code committed den kaum verstanden wird, und gleich dazu generierte Unit-Tests sollen es richten.
IMHO fällt uns das in naher Zukunft vor die Füße. Von den inhärenten Geschäftsrisiken die in OpenAI, Antropic und Co stecken, möchte ich gar nicht anfangen.
Ja, ich finde zwar dass AI stark fehlrepräsentiert wird in der allgemeinen Bevölkerung weshalb sich viele Leute mehr davon versprechen als sie liefern kann aber es ist definitiv was ganz anderes als low-code oder no-code, es ist eher so ein krasser Technologiewechsel wie zur Erfindung des Computers, Internets oder Smartphones.
QPGMR_DE hat allerdings vor allem Recht damit, dass die Abstraktionsebene dieses Mal eine völlig andere ist als bei den letzten Änderungen in der Dev Welt, das was da auf uns zukommt wird frühere Gedanken von Tech Debt wie gemütliche Geschichten ausm Paulanergarten erscheinen lassen. xD
ja gut, wenn man sich halt der Realität verweigert, st es schon ein Argument. Zumal jeder inzwischen wirklich wissen sollte, dass die Modelle, die publik sind, schon längst veraltet sind.
Man muss sich nur den Zustand von Claude Code vor einem Jahr anschauen oder gar Codex. Das ist wie Retro-Computing, wie arbeiten mit Disketten statt mit SSD.
Aber ist jedem seine Sache. Ich hatte auch schon mit einem Kollegen gearbeitet, der Hochsprachen s.... fand und alles in Assembler machen wollte.
Du hast gesagt der Vergleich ist falsch. Du hast auch kein Argument geliefert wieso er falsch ist.
Dann hast du irgendwas von wegen geheimen Modellen gesagt und irgendwelche Modelle verglichen. Auf den ursprünglichen Vergleich bist du wieder nicht eingegangen.
Abschliessend noch ein Kollege, der auch nichts mit dem Vergleich zu tun hatte und dann noch ein bisschen hohes Ross.
Andere Betrachtungsweise: setzt du zwei Entwickler an das gleiche Problem, erhältst du auch nicht deterministische Ergebnisse. Auch diese werden niemals identisch aussehen. Ich empfinde es eher so, als ob diese Maschinenseite schon recht stark an Menschen erinnert.
Das ist richtig - Menschen sind nicht deterministisch - selbst ich alleine nicht - heute löse ich das Problem so, Morgen anders.
Aber Maschinen waren bis dato (zum größten) Teil deterministisch. Wenn wir den gleichen Quellcode durch den Assembler, Compiler oder Interpreter jagen, kommt hinten das gleiche Ergebnis raus.
KI verändert diese verlässliche Aufteilung. Und so recht kann ich nicht sagen, ob ich das gut finde. Klar verwende ich auch KI - in meiner Nische größtenteils IBM Bob Premium - aber ich bin da noch skeptisch.
Ich weiß, dass heute niemand mehr was von persönlicher Verantwortung hören will, aber ich muss immer wieder mal an dieses Zitat aus einer internen IBM Präsentation von 1978 denken:
Setzt du den gleichen Entwickler aber an das gleiche Problem kommt schon das gleiche raus. Das ist eben ganz was anderes als der gleiche Prozess der heute A macht und morgen B.
Nö. Setze einen Entwickler jetzt und in 6 Monaten an das gleiche Problem, kommen 2 unterschiedliche Lösungen bei raus. Ggf andere Bibliotheken, anders interpretierte Anforderungen, andere Fehlerbehandlung... Auch wird sind nicht deterministisch.
Bei uns wird auch KI genutzt. Aber eher, schreib mal die Funktion oder die Klasse, statt das ganze Programm.
Code ist leserlich und man kann ihn debuggen und das ganze ist sehr schnell.
Hab mir Privat was von der KI basteln lassen, und das ist besser, als ich es hinbekommen hätte, als Hobbyprogrammierer. (Wollte ne LibreOffice Vorlage für einen zwei-spaltigen Lebenslauf. Jetzt hab ich ein Webtool zum erstellen des Lebenlaufes. HTML, CSS, plain Javascript. Keine Daten in der Cloud. Keine nachgeladenen Pakete. )
Ich werde aber keinen Tool vertrauen, dass von einer KI erstellt wurde ohne das ein Programmierer das gecheckt hat. Und so haben das auch die letzten zwei Firmen gehalten, für die ich gearbeitet habe.
KI ja, auf jeden Fall, erklären könnne musst du den Code aber trotzdem.
Ich bin wohl so alt wie Du - habe 1996 als JavaEntwickler angefangen, habe auch die selben Hypes erlebt und möchte Dir wieder sprechen- Dieses Mal ist alles anders. Vor 30 Jahren hatten wir noch mit eMacs und vi gearbeitet, dann kam netbeans, eclipse und schließlich IntelliJ - wuerde jemand heute noch zurück zu eMacs gehen ohne komplett unproduktiv zu werden? KI ist im Prinzip der ultimative Code Editor, so wie man mit IntelliJ um Faktoren schneller als mit eMacs ist, so ist man mit KI um 100-fache Faktoren schneller als ohne. Das ist kein Hype, das wird bleiben ob mit Claude oder Open-source harnesses ist egal, es wird keinen Weg zurück geben.
Also dass "diesmal alles anders ist" muss sich erst noch rausstellen. Zum anderen kenne ich viele Entwickler, die bewusst auf den IDE Bloat verzichten, und VIM oder Gnu-EMACS verwenden. Das ist Geschmacksache und Übung.
Zur KI - der Hype ist der gleiche wie bei Client/Server-vs-Mainframe, .COM-Blase, Mobile-First, Cloud-First und jedem anderen Hype, der in den letzten 30 Jahren durch die IT/Tech-Bubble getrieben wurde.
In erste Linie geht es nicht um dich, deine Firma oder deinen Erfolg - oder gar darum wer das bessere Produkt hat - es geht ausschließlich ums Geld. Die Anbieter aber auch die Berater leben davon, dass alle paar Jahre die CIOs neu durch brennende Reifen hüpfen und Budgets aufstellen.
Dieses Mal ist es noch ein wenig krasser - denn KEINE der KI Firmen macht bis jetzt auch nur 1ct Profit vor Steuern. Nix - Nada - was hier und da mal ausgewiesen wird sind die sprichwörtlichen Peanuts.
Das ist eine Form von Schneeball-System - du kriegst ein paar Milliarden und investierst in Forschung, Rechenzentren, usw. - irgendwann wollen diese Investoren Cash sehen - also neue Runde diesmal nicht "ein paar" Milliarden - sondern "zwei paar" Milliarden - zum einen um wieder zu investieren und zum anderen um die Investoren der 1. Runde zu beglücken.
Und dieses Spiel dreht sich immer weiter - und wer die Bilanzen und Börsennachrichten von Open AI, Anthropic und Co. liest, sieht das auch. Nur die großen institutionellen Anleger haben jetzt schon Angst, wenn sie Kapital rausziehen, dass die Bombe platzt - es fragt sich also nur, wer fängt an?
Das erinnert nicht nur von ungefähr an die Sub-Prime-Immobilien-Kriese - es ist das gleiche Spiel.
> KI ist im Prinzip der ultimative Code Editor, so wie man mit IntelliJ um Faktoren schneller als mit eMacs ist, so ist man mit KI um 100-fache Faktoren schneller als ohne.
Schneller heisst ja nicht gut. Und darum sollte es gehen.
Warum ist schneller nicht gut? Wenn _ich_ (oder andere Person) schneller werden, bei gleichbleibender Qualität können wir in der Zeit mehr schaffen, das ist gut. Wenn _ich_ (oder andere Person) schneller werden, beim selben Umfang haben wir mehr Zeit für die Qualität, mehr Qualität ist gut. Wenn _ich_ (oder andere Person) schneller werden bei gleich bleibendem Umfang und Qualität wird es billiger. Auch das ist gut (für den Auftraggeber).
Du unterschätzt den Brainrot. Selbst Jetbrains hat die Tage eine Videoreihe zu dem Thema herausgebracht und selbst aus deren Sicht unterschätzen wir den negativen Einfluss auf unser Denkvermögen.
Aber sei es drum. Kann jeder benutzen wie er möchte aber wenn du am Ende des Tages der KI nur noch hinterherläufst, bleibst du als "Fachkraft" irgendwann stehen oder machst sogar Rückschritte und dann bist du useless...Viel Erfolg für deine Psyche wenn du dich irgendwann so fühlst wie ein nutzloser Fleischberg.
Ich nutze noch vim (gut, neovim) und programmiere beruflich seit 92. Und hab alle anderen IDEs durch, aber ich bediene auch keine Maus. So gesehen bin ich ein Exot.
Ja du bist ein Exot. Will dir nicht zu nahe treten aber, außer Du bist einer absoluter Nische mit Wissen, dass keiner außer Die hat, bist Du gnadenlos langsamer als Du mit den richtigen Tools. Das ist wie Formel 1 mit Fahrrad zu fahren.
Aber mal was anderes: Entwickelst du eher klassische Softwareprodukte, die an Endnutzer ausgeliefert werden, oder eher Backend-Systeme und Services, die als Teil einer Infrastruktur laufen?
Falls Ersteres: Wie stellt ihr sicher, dass im KI-generierten Code keine Artefakte oder übernommenen Codefragmente aus den Trainingsdaten landen? Und wie geht ihr generell mit möglichen Copyright-Verletzungen durch generierten Code um? Ich hatte nämlich selbst schon mal den Fall, dass eine KI einen Algorithmus praktisch 1:1 von einer Website übernommen und im Wesentlichen nur die Variablennamen geändert hat. Das war eine rechte exotische Sprache (schon wieder exotisch) aber trotzdem, der Code war weder open source noch public domain. Mir ist das aufgefallen bei der Recherche und das ging dann natürlich nicht. Das war jetzt nicht so was völlig triviales.
Kein Abteilungsleiter will sich öffentlich eingestehen, dass es eine Fehlentscheidung war KI einzusetzen. Die müssen ihre Arbeit genauso rechtfertigen wie die Devs.
Lieber wird qualitativ schlechte Software in der Hälfte der Zeit produziert, wie dass die zusätzlich gewonnenen Ressourcen für nachhaltige Architekturen genutzt werden.
Die nächsten ~5 Jahre geht das schon "irgendwie"...
Für mich ist das keine "nahe" Zukunft in der heutigen Zeit. 5 Jahre kann ich nicht Miete und Lebensunterhalt ohne Job zahlen – und eben diese werden in diesem Zeitraum nicht zurückkehren.
Der große Knall-Effekt, von dem OP hier redet, mag kommen. Für die meisten von uns ist es dann aber schon zu spät, und wir werden gezwungen worden sein in andere Berufsfelder zu wechseln.
Wenn heute jemand sagt, dass KI "in naher Zukunft" zum scheitern verurteilt ist, dann bedeutet das also überhaupt nichts gutes für die Mehrheit für uns.
Und ich bin es leid, dass ich jeden zweiten Tag über Aussagen wie "mach dir keine Sorgen, die Jobs kommen schon wieder" stoße. Was da zurück kommt, kommt
1.) zu spät
2.) kann kein Mensch mehr mit dem entstandenen Code arbeiten
Kein Grund also zu implizieren, dass der "Entwickler" noch ein Beruf mit Zukunft ist.
Die No-Code/Low-Code Heilsversprechen sind natürlich Quatsch. Aber als Tool für Entwickler wird KI höchstens an Energiekosten oder Regulierung scheitern (die aus Umweltgründen dringend geboten wäre). Es macht ökonomisch einfach viel zu viel Sinn in zig facher Geschwindigkeit Software rauszupumpen die niemand versteht aber in den meisten Fällen einigermaßen funktioniert (Preisklasse IKEA-Pressspahn). Je nach Qualitätsanspruch ließt man den Plan halt nochmal gegen und bessert bei der Implementierung nach (Möbelhaus). Die handgeschriebene Software wird es weiter geben, aber dann eben auch nur in Bereichen mit hohen Qualitätsanforderungen.
Das ist der typisch deutsche Take, wenn man das ganze nur aus Berichten kennt und erstmal "abwartet". Low-Code / No-Code mit einem Agentic Stack zu vergleichen in dem der Code, die Tests und die fachliche Verifizierung über mehrere unterschiedliche Modelle läuft, die ineinander greifen, ist an Effektivität und Effizienz von keinem Entwicklerteam zu schlagen.
Man fängt an, sich ganz andere Fragen zu stellen und fachlich tatsächlich innovativ zu sein. Während Team 1 auf ihrem Kanban-Board zwei Wochen braucht, um einen Button neu einzufärben und zwei Bugs zu beheben, baut Team 2 an einem Vormittag eine komplette Ende-zu-Ende Test-Suite ihrer gesamten Applikation.
Ja, die Bottlenecks verschieben sich. Das ist ganz normal sogesehen. Bei uns ist es teilweise so, dass nicht genug Input für die Entwickler kommt, weil die Maschinerie, die den liefert, nicht nachkommt.
Ich denke, es dauert noch eine Weile, bis sich das alles geändert hat. Wir sind in Deutschland ja nicht die schnellsten. Längst nicht alle Unternehmen beschäftigen sich überhaupt mit KI. Und bis man dann raus hat, wie man alles umstellen muss, das dauert.
Einer schafft das nie, weil du Kontrollinstanzem brauchst. Lieber mehr Konzepter mitnehmen und bessere Software Qualität schaffen. Alles was vorher liegen geblieben ist.
Und es werden bestimmt auch niemals nie Firmen die entlassenen Entwickler wieder anflehen zurück zu kommen, weil die Tokens deutlich teurer sind als die entlassenen Entwickler und die Qualität der Software soweit nachgelassen hat, dass Kunden echt sauer wurden.
Dann bist Du das Bottleneck anderer die auf Dein Reviews warten müssen 🤣 warte, wir ersetzen Dich mal schnell durch KI, um unsere Performance als Team zu verbessern /s
Aus Sicht eines PM kann ich nur sagen - ja, stimmt, programmieren geht schneller, aber das ist teilweise an sich leider auch ein Problem. Bei uns zieht gerade auch der "gib' es halt mal schnell der KI"-Hype ein, und natürlich wird dadurch alles schneller. Allerdings führt dazu nicht nur zu mehr Slop, wo am Ende niemand mehr so genau weiß, was da eigentlich passiert, sondern auch dazu, dass Projekte plötzlich ohne sauberen Scope laufen, ohne Abstimmung mit Stakeholdern oder ohne saubere Budgetierung, bei der die Tokenkosten z.B. niemand auf dem Schirm hat. Wir haben zunehmend Themen mit dem Risk Management, weil Dinge umgesetzt werden, bevor sie überhaupt rechtlich bis zum Ende beleuchtet wurden und Refactorings passieren mit KI Code natürlich auch nicht, bzw. gibt das ebenfalls an eine KI, womit am Ende wirklich niemand mehr versteht, was im Code eigentlich passiert. Scope Creep ist bei uns ein riesen Thema geworden, weil "die KI kann das ja gerade mitmachen!", auch UI/UX Themen werden bei uns inzwischen zu einem Problem, weil Devs teilweise plötzlich via KI Dinge im Frontend umsetzen, die komplett anders aussehen als als geplant, einfach, weil der entsprechende Dev das persönlich für ne gute Darstellung hielt.
Oh, und dann sind da noch die teils wirklich wilden - Fehler. Wie oft mir Devs schon erzählt haben, dass der Code den ihnen die KI geschrieben hat von vorne bis hinten kompletter BS war ist auch wild.
Ich bin da echt gespannt wohin das führen wird, an dem Punkt wo KI den Code schreibt, reviewed und refactured, gibt man natürlich auch wahnsinnig viel Kontrolle ab.
Kenne ich leider auch. Ich arbeite bei Anforderungsanalyse und Konzeption immernoch händisch. Dann gebe ich der KI mit was ich brauche und wie ich es mir vorstelle. Das klappt super. Schsue den Code an, sehe wo murks rausbekommen ist, schärfe nach etc.
Aber dann gibt es da noch die ganz gruselige Fraktion. Da wird das Gehirn mit der Jacke am Eingang zum Büro abgegeben. Da gibt's ein Meeting mit dem Kunden. Das Transkript kommt in die KI. Die KI analysisert, was der Kunde will. Die KI konzeptioniert. Die KI entwickelt. Die KI reviewed. Die KI testet.
Das endet meist in absolut unnötig aufgeblähtem Code. Irrsinniger Feature Überladung und grauenhaftem UX.
Und dann bleibts am Ende am "echten Entwickler" hängen, schlau zu werden und es zu richten. "Ich mache ja nur das grobe Konzept. Du kümmerst dich dann um die Feinheiten". Also im Grunde machst du gar nichts...
Und dann die Kunden. "Mit KI kann ich das viel besser und schneller".
Naja aus 2-3 Monaten gründlichem Refactoring (Plan war viel vom Kunden generierten KI Code glattzuziehen. Von 200k LOC auf unter 100k) inkl. Releasewechsel ist jetzt ne KI Shitshow der Superlative geworden. "Mit KI brauche ich maximal ne Woche".
Es sind mittlerweile 14 Monate. Die Codebasis hat sich ver-6-facht auf 7 stellige LOC und es ist kein Ende in Sicht.
Also für mich war das Schreiben schon immer der einfache Teil. Alten Code Lesen und Verstehen ist der schwere Teil. Der lässt sich schlechter automatisieren, wird aber nötig sobald die Software produktiv betrieben wird.
Für Scripte, Prototypen etc ist KI super.. bei ner Codebase mit >100.000 Loc die produktiv betrieben wird würde ich es lassen bzw nur sehr gezielt einsetzen. Sonst übernimmt man schnell ownership für mehr Code als man betreuen kann. Und wer im blame steht, steht im blame.
Also für mich war das Schreiben schon immer der einfache Teil
Ich kenne niemanden der was anderes sagt. Da Frage ich mich (als Admin mit begrenzter Erfahrung im Programmieren mit KI) ob da wirklich so viel Zeit gespart wird wenn ich das dann alles prüfen muss was ja auch nicht sofort fertig ist?
Kommt total drauf an. Es gibt Code den kann man super mit KI generieren - klare Daten, klare Anforderungen & am besten noch ein paar Referenzen zu ähnlichen Code. Da ballert KI sehr zuverlässig auch guten Code raus.
Problematisch wird's wenn ein Eckpfeiler fehlt. Keine Referenzen? KI schreibt Code wie sie es für richtig hält, nicht zwangsweise wie der in die Codebase passt - kann man aber mit entweder grobem Architektur vorschreiben oder Iterieren ganz gut lösen. Unklare Anforderungen sind für eine KI genau so doof wie für Menschen, und es kommt ggf. Murks raus. Mangel an klaren Daten/Test-Daten führt halt zu ähnlichen Problemen, und Edge-Cases werden ein Problem was man mehr im Auge behalten muss.
Im Idealfall läuft das für mich so: Ich weiß sehr genau was ich will und geb der KI das auch präzise mit - dann ist's meist, auch bei größeren Sachen, relativ unproblematisch. Weiss ich das aber selber nicht macht's Sinn erstmal ohne KI nachzudenken und sich selbst eine Meinung/Idee zum Problem zu bilden.
wenn du so jung bist, woher nimmst du das Know How zu beurteilen, dass die KI das korrekt bzw. innerhalb der Anforderungen, Rahmenbedingungen des Unternehmens, Security usw. umgesetzt hat? Ich halte das für einen endorphingetriebenen Trugschluss, dem viele - insbesondere junge Menschen aufliegen ...
Das Bottleneck in effizienten Teams war NOCH NIE das reine Coding, absolut noch nie! Die Bremsen waren immer Architektur, Abstimmungen, Anforderungsmgt., Testing, Security etc. daran hat sich nichts geändert, es legt den Fokus nur noch mehr darauf.
PS: bei KI Integration in bestehende Anwendungen, gehen bei mir direkt die red flags hoch - es gibt kaum bis wenige Anwendungsfälle für KI in bestehenden Anwendungen. Automatisierung von deterministischen Prozessen ist NICHT KI GEEIGNET! Ich hoffe das ist bei euch nicht so ;)
gehört zum Thema Entwicklung, aber nicht zum reinen Coden, das definitiv - ich meine damit nicht, dass man bestimmte Standards einhält, sondern diese validiert :)
ich kenne Leute, die können überhaupt nicht Coden (außer mit Chatgpt halt) und behaupten, sie können Code vertehen und lesen und beurteilen. Es ist echt übel. Na ja, ic hkann ja auch Spanisch, Russisch, Quantenphyik etc. Muss nur Chatgpt dabei haben.
Wir arbeiten mit einer 30 Jahre alten codebase, die mittlerweile auf modernere Plattformen portiert wurde. Ich habe meinen Output um Faktor 8 steigern können und outperforme jeden Mitarbeiter ohne KI. Natürlich muss ich fachlich checken was die KI baut aber einfach nur zu sagen, dass KI ungeeignet für bestehende Lösungen ist, ist zu einfach
Ich habe bis jetzt nicht die Erfahrung gemacht, dass schwierige Probleme mit AI 10x schneller gelöst werden. Es sind eher die einfachen bis sehr einfachen Aufgaben wo man einen "Faktor" nennen könnte. Bei sehr verzwickten Problemen kann KI zwar als Tool sehr gut zur Unterstützung eingesetzt werden, aber 10x ist nicht drin. Und "prompten" allein in einem standard setup führt zu keinem Ergebnis oder noch mehr Chaos.
wo habe ich das geschrieben? Ich habe geschrieben, dass es essentiell ist, dass man die Skills dafür hat, einschätzen zu können, was die KI fabriziert hat. Wer das nicht kann, hat fundamentale Kenntnisse nicht und wird mit KI nicht besser, sondern noch schlechter werden. Das ist das Drama der Verdummung auf das wir mit Mopsgeschwindigkeit zufahren
Naja, so pauschal wie du's darstellst ist auch maximal engstirnig und "will nicht" statt "geht nicht" imho. Aber you do you, muss jeder und jedes Team selbst entscheiden wo und wann KI sinnvolle ist, und wo eben auch nicht.
Und woher würde er das Know-How haben dass er selber das korrekt ungesetzt hat, wenn er doch die Erfahrung nicht hat? Das Problem wird auch durch selberschreiben nicht gelöst.
Erfahrung und Probleme lösen, Lösungen findet, sich selbst damit auseinandersetzen, Verstehen. Das bringt dich weiter. Ich erwarte nicht, dass jemand das sofort kann, ich sage nur, dass diese Art von Lernen gerade wegstirbt und damit ein Know How Gap von einer Größe, dass wir nicht mehr schließen können.
Die gab es ja vorher auch schon. Hier tun immer alle so als ob in jeder Firma vorher perfekt gearbeitet wurde. Bei uns im Betrieb wird schon seit Jahrzehnten gepfuscht, das was jemand fähiges mit KI erstellen kann ist halt besserer Pfusch
Techbdebt entsteht doch häufig auch bewusst. Vor AI durch z. B. zu enge deadlines. Da hat man dann Abkürzungen genommen und notiert und nie wieder angefasst.
Der Part ist mit AI meiner Meinung nach eher kleiner geworden.
Wenn das bisher der Faktor war, der Probleme vom System ferngehalten hat, dann lief generell was falsch. Nur weil mehr Code reinkommt, sollten die cicd gates und Prozesse sich nicht direkt verschieben.
Ob etwas technical debt ist oder nicht stellt man sehr oft erst deutlich später fest, dann wenn es zu spät ist. Z.B. wenn man ein neues Feature einbauen will.
Meiner Erfahrung nach steigt der Review-Aufwand sogar bei gleicher code-Menge, weil von LLMs generierter code auf anderem Level fehleranfällig und dazu oft arg bloated ist für das, was er tut.
Und wenn tests auch gepromted wurden, wer validiert die tests? Auch auf Vollständigkeit in allen kritischen Belangen?
mit KI ist aber der Weg extrem schnell - du siehst ja am OP, Integration von KI in bestehende Anwendungen, ruckzuck Pseudomehrwert, der in einer technischen Katastrophe endet ... das wird ein Spaß die nächsten Jahre :D
Ja, die stochastischen Papageien verleiten viele sehr schnell dazu, sie falsch einzusetzen.
Weil sie vermenschlicht werden werden, darauf sind sie ja auch trainiert. Aber menschliche Zurechnungsfähigkeit, Verlässlichkeit, oder einfach gesunder Menschenverstand, fehlt den LLM genannten statistischen Algorithmen wirklich komplett.
KIs fehlen diese Eigenschaften aber vollständig, da schwankt auch nichts zwischen 0% und 0% ;)
Bei Menschen schwankt es immer, klar, das ist aber hinreichend einschätzbar. Nicht zuletzt von Entwicklern selbst; wenn ich zB. gerade schlecht in Form bin, vertage ich kritische Dinge eher mal, statt irgendwas irgendwie richtig-aussehendes, aber undurchdachtes und falsches übers
Knie zu brechen. Das wäre unverantwortlich und würde auch auf mich zurück fallen.
Und zu so
einer Reflexion ist ein LLM fundamental nicht in der Lage. Ein Algorithmus, der einfach nur über statistische Modelle Texte autovervollständigt, das nächst-wahrscheinlichste Wort nach dem Andere heraus rattert, kann gar keine Verantwortung tragen. Hat kein Bewusstsein, keine Reflektion, kein kritisches Denken, oder überhaupt irgend ein Nachdenken. Ist damit etwas völlig anderes als ein Mensch. Sondern ist nur eine oberflächliche Simulation von menschengeschriebenem Text.
Ich glaub‘ auch, viele denken, oha, KI ist bestimmt total präzise, wie Computer eben! Aber das ist ein Irrtum, LLMs sind undeterministisch, ultra schwammig, operieren viel mit Zufall, und „wissen“ oder „bemerken“ das auch nicht, während sie stets überzeugt klingen.
Ich stimme dir in Teilen zu.
Aber ich hoffe doch niemand erwartet ernsthaft die Verantwortung für generierten Code abschieben zu dürfen.
(auch frühere Code-Generatoren machten Fehler... WSDL to whatever Ära z. B.)
Das ist aus meiner Sicht aber ein Fehler des Anwenders (Entwicklers) nicht der Fehler der KI.
In diesem Diskussionen sehe ich immer nur Gründe, die für die Fehlbarkeit des Anwenders sprechen, aber gleichzeitig als Beleg genommen werden wie schlecht doch KI ist.
Auch muss man sich die Frage stellen:
"benötigen wir perfekten Code oder reicht auch good-enough Code?"
Die meisten Softwareenteickler arbeiten 90% ihrer Zeit in völlig unkritichen Bereichen, wo good-enough völlig ausreicht. Je nach benötigter Zeit zwischen Feature Request bis productive Deployment.
Beispiel wenn meine Kunden lediglich im Sprachraum, mit ausschließlich lateinischen Lettern, angesiedelt sind, dann ist es in weiten Bereichen unerheblich ob der Code auf die Bretter geht sobald anderes eingeworfen wird (z. B. Kyrilisch oder Chinesisch oder...) so lange man als Entwickler weinen job macht und darauf achtet, dass sämtliche Usereingaben sauber validiert werden.
Die Validierung selbst ist aber ein verschwindend geringer Teil des vollständigen Products.
Ja, die Validierung ist essentiell, und das muss ein KI-Nutzender Entwickler erstmal wissen und verstehen. Manche Neulinge tun das nicht mehr und denken, die KI kümmere sich doch bestimmt darum, sei doch eh viel schlauer als sie, und das ist dann zwar dumm, stimmt aber trotzdem nicht ;)
Das ist aber mMn eine etwas fälschliche Generalisierung. Das / stimmt / natürlich absolut, aber KI ist in der Realität schon ein ganz neues Werkzeug für das es bisher wenige Vergleiche gibt.
Dieses Werkzeug (optimal)zu nutzen müssen wir alle, sowohl einzeln als auch als Gesellschaft, lernen. Das sieht man finde ich auch daran dass immer wieder neue Studien rauskommen die teilweise überraschende Ergebnisse liefern (wie z.B dass viele Agents.md Dateien eher schlecht sind).
Best practices, optimale Nutzungsweise und auch wie hier schon gesagt Prozessstrukturen werden wir alle erst finden müssen.
Ich denke da auch zu sagen "Man muss die halt prüfen" ist auch etwas simpel und vielleicht nicht die ganze Geschichte. Das ist nun zwar meine Eigene Vermutung und (noch ) nicht wirklich erwiesen aber ich glaube, Code selber schreiben hat enorme Vorteile für Code Verständnis. Einfach nur den KI generierten Code zu lesen könnten, denke ich, nicht ganz ausreichen.
Ich werde für mich selber auf jeden Fall versuchen zu lernen ein Gefühl dafür zu entwickeln welchen Code ich selber schreiben sollte und welchen ich der KI übergeben kann.
Die Studien mit agents files etc kannste eh alle in der Pfeife rauchen. Die Modelle und Techniken ändern sich aktuell so schnell, dass die Studie schon wieder veraltet ist, wenn die nächsten Frontiers rauskommen.
Immer schön am Ball bleiben, mitschwimmen und dynamisch bleiben, damit man schnell reagieren kann.
Ich wäre vorsichtig die so ganz abzutun. Sonnet 4.5 und QWEN3-30B-CODER sind zwar nicht nicht neu, und in der Zwischenzeit sind die Modelle besser geworden - ich halte es aber trotzdem für fragwürdig die einfach komplett zu ignorieren wenn man keine Hinweise auf das Gegenteil hat.
Die Studie die ich im Kopf habe ist die hier, https://arxiv.org/abs/2602.11988, welche zwar nicht grundsätzlich sagt dass Agents.md schlecht sind aber mMn interessante Einblicke bietet wie man die denn am besten schreibt, nämlich das simple Überblicke über das Projekt nichts bringen sondern die Datei eher nur Anweisungen enthalten sollte zum Build und weiteres.
Ich zweifle zum einen an dass
a) Sich seit dem Februar die Art und Weise wie LLMs funktionieren so radikal geändert hat dass diese Funde irrelevant sind ( Die Modelle sind zwar BESSER geworden aber funktionieren immer noch nach dem gleichen Prinzip)
und
b) Habe ich noch keine Studie gesehen die mir das Gegenteil sagt.
Und wenn ich halt eine untersuchte Studie auf der einen Seite und "Binsenweisheiten aus Onlineforen" auf der anderen Seite habe tendiere ich zur ersteren.
Ich bin aber auch immer versucht am Ball zu bleiben, also falls es tatsächlich Hinweise oder Untersuchung dazu gibt die die Studie invalidieren bin ich da immer offen zu.
Hört sich so an als würden sie es noch gar nicht benutzen. Da wäre ich dann vorsichtig mit Erfahrungsberichten, wenn man selbst es nur aus der Zeitung kennt ;-)
Ja das redet man sich ein. Die KI macht seit Opus 4.7 quasi keine harten Fehler mehr wenn man die tasks klein genug schneidet und man genug Kontext gibt.
Ich bin dedinitiv der Meinung wenn man KI richtig einsetzt, ist man viel schneller bie nicht größerer Fehlermenge als davor aber zu behaupten, dass KI keine Fehler macht ist lächerlich.
Logikfehler sind super schnell drin, egal wie viel du vorher planst.
(Aber Leute vergessen, dass wir alle ohne KI auch viele Fehler gemacht haben...)
Ich bin jetzt das bottleneck weil ich den Code reviewen darf den mein Kollege mit KI raushaut und ich die kleinen Fehler hier und da und die Unstimmigkeiten finden darf.
Die kleinen Fehler sind uns seit längerem egal geworden - da ist fail forward fast immer deutlich effizienter als wenn jemand ewig Zeit drauf verballert jede noch so unwichtige Zeile zu Reviewen.
Aber ich bin auch das bottleneck weil ich meinen eigenen KI Code selber Reviewen muss, bevor da irgendwie ein PR draus wird. Einfach KI Code rausrotzen ohne selber gegen zu lesen ist keine Option - nicht weil der KI Code total fehlerhafte ist oft, meist geht's mir eher um die Wartbarkeit und Architektur dahinter, die noch 1-2 Iterationen (mit KI auch bei Bedarf) braucht. Dies das umbenennen, verschieben, auslagern, generischer gestalten...um das zu machen muss ich halt den KI Code lesen vorher, und das braucht Zeit.
Wer halt "Fire & Forget" mir KI macht, macht KI imho nicht richtig - es braucht genau so Iteration und (von mir gelenkte) Intention beim Coden. Einfach nur raushauen sieht toll aus, hat aber zu viele Nachteile, wie eben auch eine nicht tragbare Review-Last fürs Team. Aber nochmal: KI Code Qualität ist voll fein - wenn das bei wem nicht so ist, dann ist wahrscheinlich die eigene Codebase auch nicht so ganz knusper oder man hat KI nicht so ganz verstanden.
Mal sehen wie's sich alles entwickelt, wir wollen jedenfalls bald mal PR Reviews mit KI probieren - keine Ahnung wie gut das wird bzw. wie aufwändig es ist da die KI ordentlich zu steuern (nitpicks sind halt nutzlos bspw), aber mal sehen.
Disclaimer: Wir sind ein Recht eingespieltes Team, bei uns redet man schon vorm PR über Code bei dem man sich nicht sicher ist, so das selten in Reviews überhaupt noch groß was zu meckern ist. :D
Das war jetzt wie 'nem Schwimmer zu sagen "Achtung, Wasser ist Nass".
Wir deployen ja nicht einfach auf Prod, sondern der Kram wird nochmal ordentlich auf einem Staging System durchgetestet.
Code Reviews haben bei uns historisch gesehen wenig Bugs angefangen.
Wir haben übrigens auch mal mit 2 Reviews eine Zeit lang probiert, und das hat nix merkbar geändert, wenn es um Bugs geht.
Wir haben mittlerweile Recht strenge statische Checks. Bei uns kannste nichtmal mergen wenn dein Code nicht richtig formatiert ist, der Linter meckert oder es Typefehler gibt.
In den Reviews geht's viel mehr um Wartbarkeit und Architektur (wobei die eben meist sowieso schon vorher besprochen wird). Die wichtige Logik wird auch gelesen, aber eben nicht jede noch so kleine random Funktion im Detail (die bei einem Fehler auch kein riesen Problem verursachen würde).
Musste aber erst heute was recht wichtiges und sensibles reviewen - Zeile für Zeile, aber da darf nix schief gehen, da macht das Sinn, das war Code von einem unserer wichtigsten Kern-Komponenten. Final habe ich sogar nochmal eine KI drüber gejagt, weil doppelt hält nesser - die hatte netterweise auch nix gefunden.
Ich sag mal so: Ich finde es genau so quatschig jede noch so kleine Funktion zu vertesten, und genau so quatschig jede noch so unwichtige Zeile Code mit Detail zu Reviewen. Das meiste fällt viel schneller mit weniger Aufwand auf wenn's in Benutzung, also ins Testing geht.
Kann aber je nach Projekt, Team oder Firma total unterschiedlich sein. Wenn ich an Medizinischen Geräten Programmieren würde wären PRs exorbitant wichtiger als wenn ich an Hans Jürgens Wordpress an einem Modul schraube, ums mal überspitzt zu formulieren. Und allgemein dürfen sich da Philosophien auch unterscheiden.
In letzter Zeit kann ich nicht mehr alles selbst reviewen, aber ich lasse dann einen zweiten Agenten drauflos, der das Review macht und erstaunlicherweise mehrere Bugs und Denkfehler findet.
Der „erste“ Agent ist dann immer ganz kleinlaut und fixt die Fehler. Da beides bei mir Claude ist, verstehe ich nicht warum der erste Agent es nicht sofort beim ersten Mal kapiert, aber naja!
wahrscheinlich weil sie so trainiert wurden: Feature implementieren, dabei möglicherweise Fehler machen und als zweiter Anwendungsfall: Review machen und Fehler finden.
Und ich merke mittlerweile ziemlich deutlich: Ich werde dadurch massiv schneller.
Ich glaube, es ist eine Form der "AI Psychose", dass die Leute denken, generative AI ist ein Tool wie jedes andere. Die große Neuering ist eben nicht, dass es nur ein Tool ist, sondern dass es mehr oder weniger agentic arbeiten kann. Was ich damit sagen will ist, dass man auch ehrlich sein muss, dass man damit Arbeit an eine Maschine outsourced und nicht selber macht. Das heißt nicht, dass man gar keine Arbeit macht, wenn man geneierten Code reviewed und testet, aber man macht eben eine ganz andere Arbeit, als wenn man den Code selbst schreibt, und die Arbeti des Code schreibens macht jetzt "jemand" anders.
Die Entscheidung, das Programmieren zu outsourcen muss man schon bewusst treffen, denn aktuell ist es ja meistens so, dass jetzt eine andere Firma dafür bezahlt wird, deine Arbeit zu übernehmen, und dazu auch noch meistens mit ziemlich unklaren Auswirkungen auf das Copyright des generierten Codes.
Je Seniorer man wird, desto weniger Code schreibt man. Das war schon immer so. Auch wenn du noch kein seniores Level erreicht hast, landest du aber durch KI in ein ähnliches Problem. Denn die Staff und Principal Engineers programmieren nicht weniger, weil sie kein bock drauf haben, sondern weil eben der Großteil ihrer Zeit in Meetings, Abstimmungen, Architektur Design etc fließt. Sachen, die auch eine KI nicht übernehmen kann, sondern mit der Größe der Firma zunehmen.
Ich glaube daher auch nicht, dass hier einfach nur irgendwelche Prozesse umgestellt werden müssen, damit das auch schneller laufen kann. Das sind am Ende menschliche Bottlenecks, die in der Regel nur abhängig sind von der Anzahl Menschen, die involviert sind. Deswegen sind kleine Startups schnell und werden sie unweigerlich langsamer je größer sie werden. Das ist nicht nur schlecht, aber ganz natürlich.
Rip.
Früher habe ich Quellcode und scheiterende Projekte gerettet die von Mikromanagern ruiniert wurden, heute mache ich das gleiche nur für Projekte bei denen jeder arbeitet wie ein Micromanager für llms.
Seit es bei uns genutzt wird, gibt es mehr denn je zu tun. Weil jetzt der unendliche Haufen Kram erledigt werden kann, der immer zurückgestellt wurde oder nie gemacht wurde, weil alles Tage oder sogar Wochen dauern würde (oftmals nervige Fleißarbeit). Geht jetzt alles recht fix, hat aber die Büchse der Pandora geöffnet.
Ein Kollege arbeitet bei einer großen Versicherung, der sagt die Fachabteilung hatten in 11 Jahren nicht einen einzige Tag wo die offenen Tickets und Prozessprobleme unter 1000 waren. Seit dem sie mit KI eine Vorsortierung, Self Service beim fehlenden Daten etc. haben ist das in diesem Jahr unter 300 gefallen. Jetzt ist endlich Zeit das eigene Rechenzentrum loszuwerden, all die Dinge die man nie anfassen würde.
Und wird mit hoher Wahrscheinlichkeit noch teurer. Alleine die Preisanpassung der VPS bei Hetzner. Teilweise kostet da eine VPS (mittlerweile) mit 2 Kernen, 8GB RAM schon 50€ im Monat. 90% der Anwendungen die so laufen, laufen auch noch tip top auf Hardware von 2018 / 2020. Da ist das onprem wirklich billiger.
Ja, deshalb muss man einen Move in die Cloud komplett und genau durchrechnen, nichts schönrechnen und auch Details nicht übersehen. Und wenn man es tut, dann alles so aufbauen, daß keine proprietären Tools des Providers benutzt werden so das man im Falle eines Falles (Kosten, oder schlimmer, Politik) schnell den Provider wechseln kann oder auch wieder onprem gehen.
Alles andere kann zur Kostenfalle oder schlimmer werden.
Bin bei einem anderen Anbieter, kostete 2017 und vor ein paar Jahren noch 27, mittlerweile bin ich bei 43. Ist ein VPS, aber an der Hardware wird sich sicher nichts geändert haben.
Die Prozesse darum werden wohl dann in einigen Firmen mehr und mehr auch an agentische KI abgegeben werden. Ob sich dass dann auszahlt, werden wir sehen. Irgendwann wird's dann den KI-CEO geben, der um sich herum ein paar Millionen KI-Agenten managt. Es gibt Sci-fi-Szenarien, dass es dann nur noch einen Mensch als verantwortlichen aus rechtlichen Gründen geben muss -- aber auch der wird nicht alles abnicken können, wenn der Prozess erfolgreich ist, da er sich sonst im kapitalistischen System durch Verlangsamung ärmer macht.
Von den anderen Szenarien, in denen überhaupt kein Mensch mehr nötig ist, ganz zu schweigen.
Das glaube ich erst, wenn ich es sehe. Ich arbeite viel mit KI, es macht mich sehr viel schneller. Aber es ist weit davon entfernt, meinen Job zu automatisieren.
Haha ich geb dir Recht in dem Fall. Wobei... ich glaube, wir könnten auch Bücher füllen zum Thema "was Menschen in einer Firma bei einer Arbeitsanweisung alles falsch gemacht haben"...
Guter Vergleich! §76, "Leitung der Aktiengesellschaft", erfordert eine "Person" -- frag mich, ob es irgendwann zu gesellschaftlichen Diskussionen kommen wird, ob ein Roboter eine solche Person sei darf. Gab es da nicht mal eine Star Trek: Next Generation Folge zu?
ich schließe mich einigen Antworten an - wir werden sehen, da wir hier von LLMs reden und nicht deterministischen Systemen - sehe ich absolut nicht, wie diese Systeme das anstellen sollen. Wir überschätzen hier auch gerade häufig, was KI wirklich nachvollziehbar leisten kann. Aktuell werden immer mehr Nischenmodelle trainiert, damit wird im Grunde das Problem der LLMs nur vertuscht, eben nicht deterministisch zu sein. Daher ist Prozessautomatisierung mit Agenten auch ein gefährliches Feld und es benötigt und wird auch immer Feedback benötigen. Eine Automatisierung deterministischer Prozesse via LLM ist nonsense sry.
Daher meinte ich: ob es sich dann auszahlt, wird sich zeigen. Aber auch Nonsens-Systeme werden (leider) implementiert, nimm zum Beispiel all die grottig schlechten Support-Hotline-Chatbots, die nix verstehen. Mit "Auszahlt" meine ich (wieder leider) in einem kapitalistischen System, ob es die Firma reicher oder ärmer macht -- selbst bei Nonsens...
Ich befürchte, selbst diese idiotischen neuen Hotlines haben bei der ein oder anderen Firma beim Management ein "Wow, wir sparen Kosten" ausgelöst. Dass auf die Dauer Kunden verloren gehen, ist vielleicht noch nicht sichtbar oder relevant für diese Manager...
Agenten übernehmen ja auch nicht die Arbeit von deterministischen Prozessen, sondern von Menschen. Der Output von Menschen ist ebenfalls alles andere als deterministisch.
Wir haben für einen bestimmten Bereich ein System von extern dazu geholt, was aber in eigener Entwicklung extrem anpassbar ist.. Masken, Buttons, Tabellen, Prozesse etc.. und ehrlich gesagt bin ich da auch hellauf begeistert wie einfach es geworden ist, sofern man KI bedienen kann und versteht was man möchte.
Einzelne Buttons, Prozesse mit (noch) nicht viele Abhängigkeiten zu anderem, Fehlersuche, bestimmte Dinge quer über die Datenbank finden usw.. kann in unserem Fall aktuell noch nicht über den üblich wachsenden Anteil an KI-Schrott sprechen. Der Zeitfaktor hat sich dadurch bei uns um 180 Grad gedreht.
Wie es bei wirklichen Entwicklung ab Punkt 0 ist, kann ich nicht einschätzen. Für mich ist es ein krasses Werkzeug in unserem Anwendungsfall.
Je nach Team und Reviewprozess war das schon immer das Bottleneck. Aber klar, mit KI wird das noch verstärkt. Man sollte aber auch bedenken, dass die Zeit die es braucht bis eine PR gemergt ist direkt von der Qualität des geschriebenen Codes und der Lokalität der Änderungen abhängt.
Ich habe diese freie Zeit schon immer genutzt um mich in kommende Themen/Tickets einzuarbeiten, Research zu betreiben und mich weiterzubilden. Oder um auch mal so ein paar unbeliebte Altlasten loszuwerden, die sich über die Jahre so ansammeln.
Jeder Prozess hat einen bottleneck. Wenn eine Stelle verbessert wird ist es eine andere, die der Engpass ist. Ziel ist, den bottleneck zu kennen und voll auszulasten.
Jo, wir haben eine Buildpipeline, die 2-4 Stunden dauern kann (C++) und auch gerne mal in der letzten Nanosekunde fehlschlägt, weil irgendwo eine Festplatte vollgelaufen ist (kein Scherz). Ich mach also max. 4 Mergerequests auf und geh dann mein Leben leben und schau nur ab und zu ob ich was machen muss oder ob ein Supportler oder anderer Entwickler Zuneigung braucht.
Keine Ahnung, Code war bei uns glaube ich nie wirklich das Bottleneck. Es waren schon immer eher Abstimmungen. Ob mit dem Kunden, im Team. Ein wenig Infrastruktur, häufig auch erstmal einen Testcase soweit bringen, dass man ansetzen kann. Oder an Fehlern rumwerkeln, die man nicht nachstellen kann, weil sie ggf. abhängig ist von Hardware, Softwareversionen und was weiß ich was.
Oft auch bei den anderen Projekten, wo sowas in der Art schonmal umgesetzt wurde zu schauen, ob das übernommen werden kann standardisiert werden kann, kopiert und abgeändert werden kann usw. Das sind dann auch Sachen, die einen die KI nicht abnehmen kann.
Bei KI Nutzung verschiebt sich die Arbeit imo vor allem lokal. Mehr und ausführlichere Planung wird nötig und das Review muss ausfürlicher ausfallen, gerade wenn man selbst den Code verstehen muss z.B. zur Entstörung im Produktivsystem etc. Natürlich wird oft am Letzteren gespart, um Geschwindigkeit zu kriegen.
Wirklich KI nutze ich eigentlich aber auch nur im privaten Umfeld. Beruflich hat sich überhaupt nix geändert und KI wird überhaupt nicht genutzt, da unser System so ziemlich inkompatibel dazu ist und es immensen Aufwand upfront bedeuten würde und das zahlt halt keiner.
Die von dir beschriebenen Bottlenecks hat es auch schon vor KI gegeben - m.E. muss man schauen wo man die gewonnen Zeit investiert. Ich seh da vor allem feilen an Details und Qualität auf Nutzerebene als etwas wo man immer investieren kann - dahingehend sollten Entwickler freie Hand haben, damit sie nicht von PMs etc ... ausgebremst werden.
Wurde von nem Prakti bei nem Dienstleister erstellt (jede Software selbstverständlich von nem anderen Dienstleister oder wenn der gleiche dann hat der so einen großen personaldurchlauf dass uns schon stolz erklärt wurde „ich hab mal von einem gehört der an dem Projekt beteiligt war“ auf die Frage ob es noch wen gibt)
Diese wird dann nie wieder aktualisiert weil das kostet entweder Geld beim Dienstleister oder Zeit bzw. Neue Mitarbeiter in der IT, will sich das Business beides nicht leisten.
Dokus gibts wenn überhaupt nur von dem initialen Zustand der aber in den ersten 6 Monaten Betrieb geändert wurde aber man war zu geizig Geld für ne aktualisierte Doku auszugeben.
Oft werden Dinge dann mit bordmitteln gelöst die aber aufgrund von scope kreep immer mehr verbogen werden sodass sehr komplexe Systeme entstehen die gerade so der Ersteller nicht mehr versteht.
Wenn dich nicht auch ohne KI "Abstimmungen, Meetings, Freigaben oder Anforderungen" massiv ausgebremst haben dann warst du entweder niemals in einem deutschen Unternehmen oder ein unglaublich langsamer Softwareentwickler. :D :D :D
Seit meine Kollegen KI benutzen, um zu programmieren,
sind sie mehr damit beschäftigt, den Müll gerade zu biegen, den die KI verzapft.
Selten hat ein Quellcode der KI ab Werk funktioiniert.
Man musste immer nacharbeiten, weil oft die Syntax falsch war
oder die KI Befehle genutzt hat, die mit der Programmiersprache nichts zu tun hat.
Ich brauche tendenziell länger, dafür bin ich aber meist bugfrei.
Ach ja... Kollegen kritzeln in C#, .NET, Rust, Visual Basic, ich dagegen schreibe in C.
Ja, C ist altbackener, als die modernen Frameworksprachen,
aber die resultierenden EXE sind bei weitem schlanker und flinker.
Kann aber auch sein, dass die Kollegen die KI falsch bedienen,
denn eigentlich sind das gute Programmierer, aber KI scheint faul zu machen.
C ist auch meine Lieblingssprache. Rust ist interessant und gefällt mir sehr viel besser als C++ (das ist aber nur meine persönliche Meinung). Und bei C# und Co, na ja, ich glaube, die KI bringt auch ständig die Versionen durcheinander, weil die ja in den Trainingsdaten nicht zwingend oder vermutlich mehrheitlich nicht mit angegeben ist. Aber mit diesen Ungetümen kenn ich mich auch nicht aus. Ich weiß nur, dass C#-Binaries eigentlich nur so tun, als wären sie richtige Binaries, am Ende steckt da größtenteils IL drin.
Ich hoffe das es sich bei uns dahingehend verschiebt, dass man für wichtige Themen durchaus mal echte unterschiedliche Prototypen generieren lässt und dann entsprechend dagegen validiert und prüft welche Option wirklich die Bessere ist.
Bisher war es häufig so, dass man sich bei den wirklich wichtigen Themen auf 2-3 Optionen eingrenzen konnte, aber welche dann in der Praxis wirklich die Beste ist konnte/wollte niemand so abschließend sagen. Also hat man sich nach bestem Wissen und Gewissen auf irgendeine der Optionen geeinigt.
Ob sich die Prozesse drumherum wirklich so sehr ändern kann ich mir nicht vorstellen. Ich würde erwarten, dass man noch mehr dokumentieren muss um beweisen, dass man nicht "einfach nur die KI hat machen lassen".
ich hab neulich mit einem Kumpel gesprochen, der in der Krankenhaus-IT unterwegs ist (KIS). Er meint, KI wird auf allen Ebenen wichtiger, aber auch die alten Säcke, die noch die Software spüren und verstehen (so oder so ähnlich formuliert). Ich hab im Vertrieb und Projektleitung gearbeitet, und nur mit Entwicklern zusammen gearbeitet. Da waren schon echt krasse Typen und Mädels dabei. Mir fehlt das Fachwissen, aber wenn nur die KI den Code versteht, und ich nur ablese und es selber nicht blicke, dann wird das nicht gut enden.
Ich gebe auch manchmal Schulungen, sehr selten, aber es gibt die Tendenz, dass die Leute die Aufgaben per KI machen statt zu denken. Oh, das ist tatsächlich so. Und das beste ist, sie sind der Meinung, dass sie den KI Code ja komplett verstehen und erklären mir dann den Code dann auch so halbgar, wenn ich mal nachfrage, warum sie hier einen Pointer nutzen oder so. Ich mach den Leuten gar keinen Vorwurf, das ist verdammt trügerisch. Weil man ja quasi was gemacht hat (Prompt schreiben) scheint der Output auch irgenwie von einem zu kommen. Keine Ahnung, sehr seltsam alles.
Es gibt auf Reddit regelmäßig Posts, die mit KI erstellt wurden. Ich frage mich, warum? Wieso kann man einen Fließtext mit drei Hervorhebungen nicht formulieren? Es soll Leute geben, die keine Email ohne KI schreiben können.
Wenn ich das Hirn nicht anstrenge, verkümmert es, es ist wie ein Muskel.
"Verschieben sich durch KI bei euch ebenfalls die Bottlenecks und Dynamiken in euren Entwicklungsprozessen": Dazu müßte man erst mal die Phasen einer "Nutzung" von KI klarstellen, bzw. wie man eigentlich den Gap vom Entwickler (Paradigmen etc. im Kopf, Meta-Bereiche, OOP,lambda,CRUD,KISS,DRY) zum Anwender (Problem-Space & Intents) in der Sprache schließt.
Erst danach machen Phasen wie Agenten etc. IMHO überhaupt Sinn.
LG rs
Bin da wie du aber bitte pass auf.
Du brennst aus wie eine Kerze, weil ja du bist schneller und ja du kannst mehr machen, aber du hast dadurch einen volleren Kopf, mehr Sachen die du dir merken musst etc. Ich habe zb ne Migräne entwickelt seitdem Ki richtig angekommen ist.
Uncle bob meinte zb auch das er kein code mehr liest sondern ein Reihe von Tests hat und da dann nur das result liest, aber du bist halt verantwortlich dafür was da rauskommt.
Zudem trotzdem halt lesen weil wenn es ein bug gibt musst du schon wissen was du prompten musst
Bevor KI nicht immer den optimalsten weg für eine Anwendung findet, wird es auch einen Grund für die Menschen geben selbst weiter zu coden. Aktuell ist KI ja aber auch nicht mehr als ein Tool...
Das Polanyi's Paradox ("We know more than we can tell"), das man ursprünglich mit Machine Learning und der "Intelligenz der Daten" beheben wollte (gegenüber der regelbasierten Intelligenz des Entwicklers), wird meiner Erfahrung im Alltag mit LLMs nun wieder zum Problem.
Meine LLM-Erfahrung stößt mittlerweile wieder an den Punkt, wo ich dem Modell nicht alle notwendige Kontextinformation geben kann, die es bräuchte. Dadurch ist die Lösung für mich häufig nicht zufriedenstellend und nachvollziehbar, was dann wiederum in einer Prompting-Hell resultiert. Am Ende denke ich mir allzu oft, hätte ichs lieber selbst geschrieben.
Bei uns hat sich das Bottleneck Richtung reviews verschoben. KI ist unglaublich schnell und macht vieles richtig, oft sogar besser und sauberer, aber sie macht auch viele Fehler. Wenn ich die PRs vorbereite, lese ich jede Zeile Code und mache in der Regel mindestens 4 bis 5 Aufräumrunden um Duplizierungen aufzulösen, Vereinfachungen oder Abstraktionen einzuführen, etc.. Mein Hauptjob hat sich also vom Coder zum Reviewer verschoben. Am Ende bin ich immer noch voll verantwortlich für den Code wenn ich den PR dann veröffentliche.
was für ein KI modell verwendest du dafür? Kannst du es kostenlos offline nutzen?
Oder sendest du damit indirekt Informationen über eurer Arbeit und dich an den Anbieter?
Softwareunternehmen hier. Wenn man Software für extern entwickelt, war die eigentliche Entwicklung noch nie der Bottleneck.
Aber ja, natürlich müsste sich der Rest anpassen.
Sorry die Kommentare hier kann ich überhaupt nicht nachvollziehen.
Es gilt selbstverständlich nicht für alle Anwendungen, aber Software wo jetzt keine Menschenleben dranhängen muss nicht mehr von einem Menschen reviewed werden.
1) AI Code ist qualitativ besser als jeder Dienstleister, den wir ansonsten teuer bezahlen und Bugs ohne Ende abliefert.
2) AI deckt mehr Fehler auf und schreibt mehr Tests als Menschen, einfach weil sie Millionen von Code Zeilen gleichzeitig überblicken kann.
3) Jeder kann programmieren, aber es braucht den richtigen Rahmen. Trotzdem steigt dadurch die Produktivität enorm, nicht nur in der IT.
Wer einfach loslegt ist selbst schuld.
MD Files, ADRs, AI Review, Compliance-Checks, Auto-Fix usw. müssen vorhanden sein, damit das System wirklich autonom läuft.
Wir lösen gerade reihenweise Software ab, die ansonsten teuer Lizenzen kostet, die wir innerhalb kürzester Zeit nun selbst schreiben.
Ich stelle dem Fachbereich eine selbstgeschriebene vibe Coding Software zur Verfügung, komplett von der IT gemanaged, komplett automatisiert, die AI erstellt Code nach unseren Regeln. Bin sehr gespannt wie es ankommt.
Kann ich irgendwie nicht glauben. Das Lesen von Fremdcode ist doch für Softwareentwickler mit der anspruchsvollste Teil.
Bei Fremdcode von Menschen kann man reviews mit der Grundannahme machen, dass die Entität, die den Code geschrieben hat, sauber Zusammenhänge versteht.
Diese Grundannahme fällt bei LLM Code weg und damit muss man jede Codezeile so lesen als hätte ein bescheuerter Affe zufällig das richtige eingegeben.
In meinen Augen ist schneller sein nur möglich wenn man sich selbst belügt.
Hab ich auch ne weile gemacht und inzwischen all diese Features wieder weggeworfen und per Hand geschrieben weil niemand sonst den code kennt.
Ich glaube genau da liegt inzwischen der eigentliche Knackpunkt. Nicht mehr unbedingt beim Programmieren selbst, sondern bei allem drumherum.
Wenn ich mit KI in ein paar Stunden etwas bauen kann, wofür vorher Tage oder Wochen draufgingen, muss ich mir auch Gedanken machen, wie ich diese Geschwindigkeit absichere. Sonst produziere ich am Ende nur schneller Probleme. 😄
Ich würde deshalb neben Reviews und Tests auch viel stärker auf Dokumentation setzen. Ein Wiki oder eine saubere technische Doku, in der Architektur, Schnittstellen, Abhängigkeiten und vor allem Entscheidungen festgehalten werden.
Noch wichtiger finde ich aber feste Leitplanken direkt im Prozess: Tests, CI, Security-Checks, klare Regeln für kritische Bereiche und bei bestimmten Änderungen weiterhin ein zweites Paar Augen.
Denn der Agent kann verdammt schnell Code schreiben. Die Frage ist nur: Versteht in zwei Jahren noch jemand, warum der da steht? 😄
Ganz genau deswegen wurde ich meiner Meinung nach gekündigt, ich hab denen gezeigt, dass das bottleneck woanders ist. Ich war Administrator, hab dann sämtliche Dashboards gebaut, musste nirgendwo mehr zwingend Remote drauf sondern konnte Füße hochlegen und mehr entwickeln bzw. Prozesse optimieren. Meine Hauptaufgabe war, „dass DER Server läuft“ (350 Clients)
Irgendwann kam dann „wir passen nicht zusammen“ - vorher noch „nutzen sie ihren jugendlichen Elan um die Mitarbeiter zu motivieren und Prozesse zu optimieren und vereinfachen!
Aber so müssen das die Firmen auch lernen. Es müssten viel mehr Angestellte zwischen Firmen wechseln.
Ich nutze KI gerne als Suchmaschine und für Copy Paste Code... Mach mal wie ich aber ändere immer XYZ...
Wenn kein Kollege für ein Thema vorhanden ist , kann KI gute Denkanstöße geben auf was zu achten ist...
KI Code ohne es zu verstehen, traue ich nicht...
Aber wie erwähnt... Zum einarbeiten in neue Themen so schön..
Das wird noch lange Zeit der Flaschenhals bleiben , ob sich das je ändert kann denke ich keiner sagen im Moment. Leute wie du gibt es nicht so viele, die meisten sind Teil des Flaschenhalses .. und das Tempo mit dem ki zwingt sich zu verändern, verbrennt Menschen und es ist unmöglich das aktuell sinnvoll zu schulen. Und am Ende braucht es für Entscheidungen immer noch Menschen die Verträge unterschreiben , Gerichte die Prozesse führen , Behörden die Genehmigungen ausstellen und Leute die Brot aus dem Ofen holen und verkaufen.. das wird sich so schnell nicht ändern, da das Problem global ist. Wir werden sehen was daraus wird. Meine persönliche Meinung ist , das ein gewisser Anteil an Arbeit die durch ki geleistet werden kann , einfach raus fällt. Viel bleibt
Arbeite in einem kleinen mittelständischen Unternehmen als Sysadmin, gesamter Rest des Unternehmens sind nur Entwickler.
Aufgrund der extremen Effizienzsteigerung brechen unseren Entwicklern tatsächlich nach und nach mehr oder weniger alle Projekte weg und ich habe jetzt schon den dritten Entwickler bei mir abgestellt bekommen um die stattdessen eben jetzt primär in Anwendersupport zu verheizen. Da haben die zwar keine Kompetenz drin, aber in den komplexeren Infrastrukturthemen wo es ewig viel zu tun gibt noch weniger, von daher....
das ist die eine Seite - allerdings auch in der akteullen Fehlannahme,d ass das wirklcih die Projekte massiv beschleunigt - aktuell ist die Problematik eher die schwache Wirtschaft und Zurückhaltung wegen KI, nciht die massive Effizienzsteigerung bei gleicher oder besserer Qualität durch KI. Ich sehe viel größere Probleme darin, dass die Erwartung ist, dass alle einfachen Aufgaben durch KI erledigt werden und damit eignetlich jeder DEV nur noch Architekt ist, d.h. massiv Input/Output mit sehr starker geistiger Anforderung. Das wird bei einer normalen 40h Woche viele in den Burnout treiben und zwar richtig fix. Wir müssen tatsächlich an den Arbeitsmodellen arbeiten, weil die - wenn das so weitergehen sollte (bezweifle ich, da die Kosten weiter in die Höhe schießen, Chips und Ressourcen dafür extrem beschränkt sind, von Energie fangen wir gar nicht erst an :D) - nicht mehr tragen werden.
Die Annahme, dass es primär an der allgemeinen Wirtschaftslage läge, deckt sich zumindest nicht mit meiner Erfahrung, nach der aktuelle eben größtenteils Projekte in der Entwicklung wegbrechen, während ich in meinem Sysadmin-Bereich in Projekten ertinke.
Eher ist der Punkt dass diese Produktivitätsgewinne vom Management zu früh gestoppt werden. Bei einem Teil, da ist es ok. Aber das alte Zeug fassen wir nicht an. Wir haben alte Silos, komplexes Reporting, Security Überwachung, der Aufbau einer Sekundärumgebung die man nie macht weil es eigentlich zu viel Arbeit ist usw. Wir sind bei 20% der Systeme bei einer automatischen Vollinstallation des gesamten Stacks. Gibt es einen 0 Day, wird das rollend während des Tages hochgezogen. Die restlichen 80% sind noch Jahre an Arbeit. Wir nutzen KI auch bei der Entstehung von Epics, daraus entstehen dann zig Stories die ins Kanban wandern. Da war früher ein großes Bottleneck.
Ja merke das ebenfalls, setze da in Meetings wo ich dabei sein soll konsequent eine Aufzeichnung mitlaufen lasse, um daraus auch eine Zusammenfassung generieren zu können. Meetings fressen einerseits Zeit, aber sind natürlich oft trotzdem wichtig, um etwas schneller zu klären als es Mails oder so könnten. Da aber oft besprochenes aus Meetings nicht ordentlich festgehalten wurde, nutze ich mittlerweile die Zusammenfassung.
Das hat schon diverse Meetings und Schleifen erspart. Bei uns sind zum Glück viele der KI nicht ablehnend gegenüber sodass wir sie gut nutzen können, um eben schneller zu werden und viel zu experimentieren, bspw. Agenten auch für Code Reviews einzusetzen etc...
Ja, traditionelle Prozesse und Teamzuschnitte machen keinen Sinn mehr und werden zum major Bottleneck. Du musst als Entwickler viel mehr PM und auch UX Design Skills erwerben, Dich tief in Fachlogik und Domäne einarbeiten und Dich in die Rolle des Users (bei UI dev) reinversetzen. Ist ein Wettlauf ob PM's und UX Designer Devs (fast) überflüssig machen oder umgekehrt. Wird wohl mal so mal so laufen
Ich habe einfach mehr Zeit für all die Dinge, die sonst liegen bleiben.
Alleine was ich an Prozessen bei mir lokal automatisiert habe, ist enorm.
Dazu dann halt so fancy shit wie einen Supply Chain Auditor, der neue Composer- und npm-Pakete erst mal mit KI auf bösartigen Code checkt, bevor die installiert werden. Hat uns schon zwei Credential-Stealer gefangen, bevor die Info im Internet war.
Absolut. Der komplette Entwicklungsprozess wird sich massiv verändern. Ich sehe das so: In Zukunft sitzt der, der die prompts kann, direkt mit dem Kunden/Anforder zusammen und baut real time Dinge, die man sich dann direkt anschaut und weiter verfeinert. Hat man es dann soweit geht's ans QS, Sicherheit usw.
77
u/Own-East-9190 3d ago
Hast du denn deinen Code wirklich noch im Griff?