KI-gestützte Entwicklung braucht weiterhin Urteil

Beschleunigung verschiebt den Bottleneck

KI kann Implementation Options, Tests, Migrations, Documentation und Investigations mit bemerkenswerter Geschwindigkeit produzieren. Diese Geschwindigkeit verschiebt den Bottleneck vom Tippen zum Urteil. Engineers müssen das Problem definieren, Constraints wählen, plausible Mistakes erkennen und entscheiden, ob das Result in das System passt, das es besitzen wird.

Eine generierte Change kann syntaktisch korrekt und architektonisch falsch sein. Sie kann eine bestehende Abstraction duplizieren, Authorization umgehen, Deployment Constraints ignorieren oder eine lokale Function optimieren und zugleich die Produktboundary schwächen. Repository Understanding bleibt der Unterschied zwischen Code Generation und Engineering.

Dem Agent ein begrenztes Outcome geben

Starke Tasks beschreiben das nutzer-sichtbare Outcome, relevante Files oder Modules, Invarianten, die wahr bleiben müssen, und wie Success verifiziert wird. Sie vermeiden, jede Zeile vorzuschreiben, und verhindern zugleich, dass der Agent in unzusammenhängende Refactors expandiert.

Vor dem Editing inspizieren Sie lokale Conventions, Framework Documentation und aktuelle Dependency Versions. KI-Systeme sind auf historische Patterns trainiert; schnelllebige Frameworks invalidieren vertraute APIs häufig. Die Arbeit im tatsächlichen Repository zu grounden ist Teil der Korrektheit, nicht Zeremonie.

• Benennen Sie non-negotiable Behavior
• Nennen Sie die Tests und Environments, die zählen
• Bewahren Sie unzusammenhängende User Changes
• Bitten Sie um Alternativen, wenn eine Entscheidung teuer rückgängig zu machen ist

Den Diff als Design reviewen

Reviewen Sie generierte Arbeit auf mehreren Levels. Macht der User Flow Sinn? Sind Boundaries und Data Ownership klar? Sind Failure States gehandelt? Ist der Code im Idiom des Repositories lesbar? Dann inspizieren Sie Security, Accessibility, Performance und Operational Behavior.

Große generierte Diffs reduzieren Review Quality. Bevorzugen Sie kleine kohärente Increments mit Verification dazwischen. Wenn eine Change mechanisch ist, kann Automation breit sein; enthält sie architektonisches Urteil, halten Sie die Surface kompakt genug, dass ein Mensch sie echt verstehen kann.

Verification ist nicht optional

Führen Sie Static Analysis, Type Checks, Tests und Production Builds aus. Für Interface Work inspizieren Sie reales Browser Behavior an relevanten Breakpoints und Interaction States. Für Migrations testen Sie Forward Execution und Recovery. Für APIs verifizieren Sie Authorization und malformed Inputs, nicht nur den Happy Path.

KI kann helfen, diese Verification zu gestalten, aber sie kann Responsibility nicht verschwinden lassen. Ist die Test Suite schwach, ist auch die generierte Confidence schwach. Fügen Sie den kleinsten High-Value Test hinzu, der das geänderte Verhalten schützt.

Ownership menschlich halten

Coding Agents sind mächtige Collaborators, wenn der Engineer für Intent und Consequences accountable bleibt. Recorden Sie wichtige Entscheidungen, disclose generierte Dependencies und vermeiden Sie, Secrets oder sensitive Produktionsdaten ohne genehmigte Boundary in Tools zu senden.

Der dauerhafte Vorteil ist nicht, mehr Code zu produzieren. Es ist, den Pfad von einem gut gerahmten Problem zu einem verifizierten Outcome zu verkürzen und zugleich Systemkohärenz zu erhalten.