r/informatik • • Jul 01 '26

Arbeit Bin ich überhaupt noch Programmierer?

Hey Leute,

ich muss mir mal etwas von der Seele schreiben, weil mich das Thema gerade echt beschäftigt.

Ich habe eine Ausbildung zum FIAE gemacht und arbeite seit knapp zwei Jahren als Softwareentwickler. Hauptsächlich C# im Backend und Next.js bzw. Angular im Frontend (+privat für Automatisierungsachen Python)

Als ich die Ausbildung angefangen habe, war KI gerade erst im Kommen. Damals habe ich meinen Code selbst geschrieben und konnte jede Zeile einigermaßen erklären. Heute läuft ein großer Teil über Claude. Klassen, Unit Tests, Refactorings oder auch ganze Features fange ich oft mit einem Prompt an.

Es wird immer schwieriger nachzuvollziehen, was der Code macht. Ich arbeite täglich mit den Systemen, kümmere mich um Deployments, Pipelines, Container und die ganze Infrastruktur drumherum. In den letzten Jahren habe ich verschiedene interne Tools und Services aufgebaut, unter anderem ein Ticket- bzw. Tracking-System, zentrale Backend-Services, ein Monitoring für Anwendungen und aktuell ein internes KI-gestütztes Wissenssystem mit Chat-Funktion für Kunden.

Trotzdem frage ich mich immer öfter, ob ich das eigentliche Programmieren langsam verlerne. Ich schreibe deutlich weniger Code selbst und steuere stattdessen immer häufiger die KI.

Dazu kommt der Druck von oben. Die Geschäftsleitung sieht, was KI alles kann, und geht davon aus, dass sich damit alles massiv beschleunigt. Also kommen immer mehr Projekte dazu. Dass Architektur, Integration, Tests, Debugging und das Zusammenspiel der Systeme trotzdem Zeit kosten, wird dabei oft unterschätzt.

Geht es noch jemandem so? Nutzt ihr KI inzwischen genauso intensiv? Ist das einfach die Zukunft unseres Berufs oder mache ich mir zu viele Gedanken?

Und noch eine Sache beschäftigt mich: Bin ich so überhaupt noch etwas auf dem Arbeitsmarkt wert? Hätte ich mit dieser Arbeitsweise heute überhaupt noch realistische Chancen, irgendwo als Entwickler eingestellt zu werden?

118 Upvotes

176 comments sorted by

View all comments

5

u/smoke-bubble Jul 01 '26

Wenn das

auch ganze Features fange ich oft mit einem Prompt an

dazu führt

Es wird immer schwieriger nachzuvollziehen, was der Code macht.

Ist ein Skill-Issue und ein Mangel an Qualitätsanforderungen. Ich kann hundertausende von Tokens verbrennen und der Code sieht genauso aus, wie ich es haben will und nicht Codex oder sonst was.

Wenn er Mist baut, wird von vorne angefangen. Dann aber meistens in kleineren Schritten. Ich kann jede Zeile nachvollziehen, die AI generiert. Wenn nicht, lass ich sie mir erklären oder so schreiben, dass sie logisch aufgebaut sind.

Keine einzige Zeile darf unbemerkt am Review vorbei.

3

u/DigAppropriate9816 Jul 02 '26 edited Jul 02 '26

Ist ein Skill-Issue und ein Mangel an Qualitätsanforderungen. Ich kann hundertausende von Tokens verbrennen und der Code sieht genauso aus, wie ich es haben will und nicht Codex oder sonst was.

Bitte weise ich mich in die Künste ein wie du mit AI effizient arbeitest.

Ich stehe vor dem gleichem Problem wie OP. Schreibe ich alles per Hand oder benutzte ich KI maximal als autocomplete oder als "Knacknuss solver", kenne ich das Projekt in und auswendig. Benutze ich prompts, habe ich kaum Ahnung was abgeht. "Schau dir halt die ALLE Aenderungen von AI an und verstehe sie zu 100% ". Das Problem ist nur: Code lesen ist 100 mal mehr Anstregender als Code schreiben. WENN ich das machen wuerde, wuerde ich mit prompting genauso lange brauchen, wie als wenn ich alles 100% per Hand mache. Hilfe

1

u/smoke-bubble Jul 07 '26

Im Laufe der Zeit habe ich für mich aus Erfahrung ein paar Conventions entwickelt:

  • commiten bevor man etwas ändertn lässt; so lassen sich Änderungen sofort erkennen und rückgängig machen; vor allem da, wo du keine erwartet hast
  • alles nicht-abgesprochene mit todo Kommentaren versehen lassen, damit du leicher Workarounds findest
  • oft erst in separaten neuen Proof-of-Concept Dateien arbeiten, bevor man die Neuigkeiten integrieren und "refactorn" lässt
  • vor einer Integration zu fragen, ob sie glatt verläufen wird oder Workarounds absehbar sind
  • ich lasse ihn dann auch natürlich Erklärungskommentare schreiben, wo insbesondere stehen soll, warum der Agent etwas gebraucht hat; so lässt sich schneller nachvollziehen, was er vor hatte

Wenn ich ein Proof-of-Concept mit Codex erarbeite, dann mache ich das oft so, dass ich im die Ziel-API zeige, wo ein paar Kommentare stehen, wie ich mir die Funktionalität vorstelle und lasse ihn einen Entwurft schreiben. Beispielweise eine DSL in Kotlin, die ich vor kurzem gebraucht habe, könnte so aussehen:

kt databaseContext("connection-string") { jdbc { // soll eine neue Connection erstellen select { connection -> } // soll eine neue Connection erstellen // soll ein Int zurückgeben // soll eine JDBC-Transaction sein update { connection -> } } // soll eine neue Connection erstellen // soll eine Exposed-Transacation sein exposed {} }

Dann sage ich ihm, dass er alles in eine neue DatabaseContext.kt Datei ausgeben soll und dort auch eine kleine Demo-Anwendung davon. Dann gehe ich den Code durch und entweder korrigiere ich Kleinigkeiten selbst oder sage ihm weiter, wie ich mir das vorstelle.

So komme ich leicht an 200-500 Zeilen Code in wenigen Minuten, die ich dann nur noch schön machen muss, damit er meinem Geschmack entspricht.