KI oder nicht?
KI oder nicht. Diese Frage hängt im Entwickleralltag inzwischen überall rum. Fast so, als müsste man sich sofort entscheiden, ob man mit dem Strom geht oder lieber am Ufer stehen bleibt und diskutiert. Aber genau so läuft Arbeit selten. Meistens ist es weniger ideologisch und mehr praktisch.
Im Alltag als Web Developer ist ohnehin selten alles hübsch sortiert. Da ist ein Ticket offen, ein Bug im Staging, ein UI-Problem im nächsten Browser und nebenbei noch ein Kunde, der „nur kurz“ etwas ändern will. Wer in Berlin schon mal an einem Vormittag versucht hat, irgendwo einen Termin, eine gute Lösung und einen halbwegs ruhigen Kopf unter einen Hut zu bringen, weiß ungefähr, wie sich das anfühlt.
Genau da wird KI interessant. Nicht als Zaubertrick. Eher wie ein schneller Kollege, der schon mal mitdenkt, während man selbst noch die Lage sortiert. Das spart nicht immer Zeit beim ersten Schritt, aber oft beim zweiten und dritten.
Alltag statt Lagerdenken
Die meisten Aufgaben im Web Development sind nicht spektakulär. Sie sind kleinteilig, wiederholbar und manchmal einfach nervig. Ein Formular soll sauber validieren. Eine Komponente soll in drei Varianten funktionieren. Ein TypeScript-Typ ist zu eng. Ein API-Response sieht aus, als hätte ihn jemand auf dem Weg zum Ergebnis einmal kurz fallen gelassen.
In solchen Momenten kann KI helfen. Sie kann eine erste Struktur bauen, eine Idee ausformulieren oder bei einem Problem drei mögliche Richtungen aufzeigen. Das ist praktisch, solange man danach selbst prüft, ob es wirklich zum Projekt passt. Denn wie bei einem guten Laden in Berlin gilt auch hier: freundlich auftauchen reicht nicht. Am Ende muss das Ergebnis stimmen.
Was KI gut kann
KI ist stark, wenn die Aufgabe eng genug ist. Ein Snippet für wiederkehrende Logik. Ein Refactor-Vorschlag für unübersichtlichen Code. Eine Erklärung für einen Fehler, den man schon dreimal gesehen hat und trotzdem wieder neu lesen muss. Oder ein schneller erster Entwurf für eine Komponente, die man danach sowieso noch an das eigene Designsystem anpasst.
Ich nutze KI eher wie ein schnelles Gegenüber. Nicht als Autorität. Eher wie jemanden, der in einer Berliner Bäckerei schon vor der Tür kurz sagt, was Sache ist, während andere noch nach der perfekten Formulierung suchen. Das ist nicht immer elegant, aber oft nützlich.
Was KI nicht kann
KI kennt keine echten Projekte mit gewachsenen Altlasten. Sie kennt keine halbfertigen Systeme, keine historisch gewachsenen Sonderfälle und auch nicht den Moment, in dem man merkt, dass die eigentliche Ursache wieder mal nicht dort liegt, wo sie zuerst vermutet wurde. Sie kennt auch nicht dieses typische Gefühl, wenn jemand mit ernstem Blick etwas „ganz Kleines“ sagt und daraus plötzlich drei Stunden Arbeit werden.
Deshalb ersetzt KI nicht den Entwickler. Sie kann Code liefern. Sie kann Texte formulieren. Sie kann Muster erkennen. Aber sie versteht nicht automatisch, warum in einem bestimmten Projekt gerade diese Lösung schiefgeht. Das ist der Teil, der Erfahrung braucht. Und ein bisschen Misstrauen auch.
Ein paar Beispiele aus dem Alltag
Nehmen wir eine neue Komponente. Sagen wir, ein Button mit Varianten, Zuständen und Typisierung. KI kann dafür schnell einen ersten Entwurf liefern. Aber danach beginnt die eigentliche Arbeit. Die API wird sauber gemacht, die Namen werden angepasst, das Verhalten wird geprüft und am Ende landet die Komponente da, wo sie ins System passt und nicht nur irgendwo im Code existiert.
Oder ein kaputter API-Response. Die Struktur ist nicht ganz das, was erwartet wurde. KI kann helfen, das Muster zu lesen, mögliche Ursachen zu sortieren oder einen Parser-Vorschlag zu machen. Trotzdem bleibt die Verantwortung bei mir. Ich muss prüfen, ob das nur ein Pflaster ist oder ob die Lösung wirklich stabil genug ist.
Auch beim Debugging kann das nützlich sein. Nicht, weil KI plötzlich die Wahrheit kennt. Sondern weil sie manchmal auf etwas zeigt, das man selbst übersehen hat. Ein falsch gesetzter Pfad. Eine Bedingung, die nie greift. Ein Type, der an einer Stelle zu viel und an einer anderen zu wenig erlaubt. Solche Dinge kosten nicht selten mehr Zeit als nötig, und genau da kann KI ein bisschen Druck rausnehmen.
Berliner Arbeitstempo
Berlin hat da seinen eigenen Takt. Nicht immer höflich, nicht immer hübsch, aber oft erstaunlich direkt. Manchmal wirkt alles ein bisschen ruppig, wie ein Verkäufer, der keine Lust auf Smalltalk hat, aber trotzdem genau weiß, wo das Produkt steht. Dafür gibt es hier eben auch eine Mischung aus Leuten, Sprachen und Arbeitsweisen, die einem schnell zeigt: Ein einziges Schema passt selten für alles.
Und genau das passt auch zur Frage nach KI. Wer sie stur ablehnt, wirkt irgendwann ein bisschen wie jemand, der immer noch behauptet, man brauche für jede Strecke unbedingt den selben Weg, obwohl die Stadt längst anders funktioniert. Wer sie blind übernimmt, landet dagegen schnell bei glatten, austauschbaren Lösungen. Beides hilft am Ende nicht.
Die bessere Haltung
Ich glaube deshalb nicht an ein Entweder-oder. Ich glaube an sauberes Handwerk, klare Entscheidungen und Werkzeuge, die man bewusst einsetzt. KI gehört inzwischen dazu. So wie Git, Terminal, Editor und alles andere, was den Alltag schneller oder besser macht. Nicht alles, was schnell ist, ist gut. Aber alles, was langsam ist, ist auch nicht automatisch besser.
Die eigentliche Frage ist also nicht, ob man KI benutzt. Die Frage ist, ob man noch weiß, was man tut, wenn sie mithilft. Wer das kann, bleibt handlungsfähig. Wer das nicht kann, wird austauschbar.
Schluss
Im Alltag als Web Developer geht es nicht darum, ein Lager zu wählen. Es geht darum, gute Arbeit zu machen. KI kann dabei helfen, gerade wenn man viele kleine Entscheidungen hintereinander treffen muss und nicht jedes Mal alles von Grund auf neu lösen will. Aber sie ersetzt weder Urteil noch Verantwortung.
Und vielleicht ist genau das die ehrlichste Antwort: Nicht KI oder Entwickler. Sondern Entwickler mit KI. Der Rest ist Diskussion am Rand.