Boilerplate-Code mit KI generieren lassen

1. Wo KI beim Programmieren wirklich glänzt

Die Diskussion um KI-gestützte Softwareentwicklung wird oft so geführt, als gäbe es nur zwei Positionen: KI schreibt bald den gesamten Code, oder KI ist für echte Softwareentwicklung ungeeignet. Beide Extrempositionen ignorieren, dass sich Programmieraufgaben in sehr unterschiedliche Risikokategorien einteilen lassen. Am einen Ende stehen neuartige Geschäftslogik, Architekturentscheidungen und sicherheitskritischer Code, bei denen jede Zeile Konsequenzen hat, die sich nicht allein aus dem Code selbst ableiten lassen. Am anderen Ende steht Code, dessen Struktur durch ein etabliertes Muster bereits vollständig vorgegeben ist.

Genau in dieser zweiten Kategorie, dem sogenannten Boilerplate-Code, liefert Claude die zuverlässigsten Ergebnisse. Ein Data Transfer Object mit zehn Feldern, eine Repository-Implementierung nach Magentos Standardmuster oder eine Testfixture-Klasse folgen alle einer Form, die tausendfach in Open-Source-Code, offizieller Dokumentation und internen Codebasen vorkommt. Das Modell muss hier nicht neues Wissen über die Domäne erzeugen, sondern ein bekanntes Muster korrekt auf einen konkreten Kontext anwenden. Dieser Artikel grenzt genau diesen Bereich ab und zeigt, wo die Grenze zwischen risikoarmer Generierung und riskanter Automatisierung verläuft.

2. Was Boilerplate-Code eigentlich ausmacht

Boilerplate-Code ist wiederkehrender Code, der zur Erfüllung einer Sprach- oder Framework-Konvention nötig ist, aber selbst keine spezifische Geschäftsentscheidung enthält. Klassische Beispiele sind Getter und Setter, Interface-Deklarationen, DTO-Klassen, Konstruktor-Injektionen, Mapper zwischen Datenbank-Modell und Domain-Objekt sowie die immer gleiche Grundstruktur von PHPUnit-Testklassen. In Magento kommen dazu Repository-Interfaces, Factory-Klassen, Data-Objekte mit ExtensibleDataInterface und die begleitenden di.xml-Einträge, die fast identisch aussehen, egal für welche Entität sie geschrieben werden.

Entscheidend ist die Unterscheidung zwischen Form und Inhalt. Die Form eines Repository-Interfaces mit save, getById, getList und deleteById ist durch Magentos Service-Contract-Konvention fest vorgegeben. Der Inhalt, also welche Geschäftsregel beim Speichern greifen soll oder wie ein Preis berechnet wird, ist keine Boilerplate mehr, sondern Kernlogik. Wer diese Grenze klar zieht, kann gezielt entscheiden, welche Aufgaben sich für eine KI-gestützte Generierung eignen und welche eine sorgfältige menschliche Modellierung erfordern, die sich nicht allein aus einem bekannten Muster ableiten lässt.

3. Warum Boilerplate-Generierung risikoärmer ist als Logikgenerierung

Das geringere Risiko bei Boilerplate-Code hat drei konkrete Ursachen. Erstens ist die Lösungsmenge klein: Ein Repository-Interface für eine Entität hat nur wenige sinnvolle Formen, während eine Rabattberechnung unzählige, gleichermassen plausibel aussehende, aber fachlich falsche Varianten zulässt. Zweitens ist Boilerplate-Code gegen ein bekanntes Referenzmuster prüfbar, etwa gegen die offizielle Magento-Dokumentation oder ein bestehendes Repository-Interface im selben Modul, während Geschäftslogik nur gegen fachliche Anforderungen validierbar ist, die selten vollständig im Prompt stehen. Drittens fallen Fehler in Boilerplate-Code meist sofort auf: PHPStan, die Magento-Interface-Verträge und ein einfacher Testlauf decken strukturelle Abweichungen zuverlässig auf.

Bei Geschäftslogik gilt das nicht in gleichem Mass. Eine KI kann eine Versandkostenberechnung erzeugen, die syntaktisch einwandfrei ist, alle Tests besteht, die der Prompt selbst nahegelegt hat, und trotzdem eine falsche Rundungsregel oder einen übersehenen Sonderfall enthält, der erst im Produktivbetrieb auffällt. Diese Fehler sind teurer, weil sie sich nicht durch reines Nachlesen der Struktur finden lassen, sondern fachliches Verständnis der Domäne erfordern. Wer diesen Unterschied im Kopf behält, nutzt Claude gezielt dort, wo Verifikation günstig ist, und behält bei allem anderen die volle menschliche Kontrolle.

# Typical Claude Code workflow for boilerplate generation:
# narrow scope, point at an existing pattern, verify immediately

claude "Create a Repository interface implementation for the entity
Mironsoft\SeoSuite\Model\RedirectRule, following the same pattern as
vendor/magento/module-catalog/Model/ProductRepository.php.
Include save, getById, getList and delete methods."

# Immediately verify against the known pattern
bin/analyse app/code/Mironsoft/SeoSuite --level=5
bin/phpcs app/code/Mironsoft/SeoSuite/Model/RedirectRuleRepository.php

4. DTOs und Value Objects generieren lassen

Data Transfer Objects sind ein Paradebeispiel für risikoarme Generierung, weil ihre Struktur allein aus einer Feldliste ableitbar ist. Wer Claude eine Liste von Feldnamen mit Typen gibt, etwa aus einem bestehenden Datenbankschema oder einer JSON-Schnittstellenbeschreibung, erhält eine vollständige, typsichere Klasse mit Constructor Property Promotion, readonly-Eigenschaften und passenden PHPDoc-Blöcken in wenigen Sekunden. Der Mehrwert liegt nicht in kreativer Problemlösung, sondern darin, dass repetitive, fehleranfällige Handarbeit wie das exakte Übertragen von zwanzig Feldnamen in einen Konstruktor entfällt.

Wichtig ist, die Eingabe so konkret wie möglich zu machen. Ein Prompt mit einer vollständigen Feldliste inklusive Typen und Nullable-Markierungen liefert praktisch immer korrekten Code, während ein vager Prompt wie „erstelle ein DTO für Bestelldaten“ das Modell zwingt, Annahmen über Felder zu treffen, die dann manuell korrigiert werden müssen. Je expliziter die Struktur bereits im Prompt steht, desto kleiner wird die Fehlerfläche, und desto näher liegt die Aufgabe am reinen Boilerplate-Fall statt an einer Modellierungsentscheidung.

{
  "description": "Field contract used as Claude prompt input for DTO generation",
  "entity": "RedirectRule",
  "fields": [
    { "name": "ruleId", "type": "int", "nullable": true },
    { "name": "requestPath", "type": "string", "nullable": false },
    { "name": "targetPath", "type": "string", "nullable": false },
    { "name": "redirectType", "type": "int", "nullable": false },
    { "name": "isActive", "type": "bool", "nullable": false },
    { "name": "storeIds", "type": "int[]", "nullable": false },
    { "name": "createdAt", "type": "string", "nullable": true }
  ]
}

5. CRUD-Scaffolding und das Repository-Pattern

CRUD-Scaffolding, also das Erzeugen der immer gleichen Grundoperationen für eine Entität, ist in Magento durch das Service-Contract-Pattern besonders klar definiert. Jedes Repository folgt derselben Grundform: ein Interface im Api/-Namespace mit save, getById, getList und deleteById, eine Implementierung im Model/-Namespace, die einen ResourceModel und eine CollectionFactory injiziert, sowie ein di.xml-Eintrag, der Interface auf Implementierung mappt. Diese Wiederholung über Dutzende Entitäten hinweg macht CRUD-Scaffolding zu einer der ergiebigsten Anwendungen für KI-Generierung im Magento-Kontext.

Der Produktivitätsgewinn entsteht nicht dadurch, dass das Muster kompliziert wäre, sondern dadurch, dass es stur und ermüdend ist, wenn man es zum zehnten Mal von Hand schreibt. Genau diese Monotonie ist der Bereich, in dem Tippfehler und vergessene Null-Checks passieren, weil Aufmerksamkeit bei repetitiver Arbeit nachlässt. Eine KI ermüdet nicht und wendet das Muster beim zehnten Mal genauso präzise an wie beim ersten. Die menschliche Aufgabe verschiebt sich dadurch von der mechanischen Umsetzung hin zur Prüfung, ob das generierte Ergebnis wirklich zum bestehenden Modul passt.

<!-- di.xml: mappt das Repository-Interface auf die generierte Implementierung -->
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
    <preference for="Mironsoft\SeoSuite\Api\RedirectRuleRepositoryInterface"
                type="Mironsoft\SeoSuite\Model\RedirectRuleRepository" />
</config>

6. Praxisbeispiel: Repository-Interface für Magento generieren

Ein konkretes Beispiel macht den Unterschied zwischen risikoarmer und riskanter Generierung greifbar. Für eine neue Entität RedirectRule im Modul Mironsoft_SeoSuite soll Claude ein vollständiges Repository-Interface samt Implementierung erzeugen. Der Prompt verweist explizit auf ein bestehendes Repository im selben Modul als Referenzmuster und nennt die konkreten Abhängigkeiten wie ResourceModel, CollectionFactory und SearchCriteria-Verarbeitung. Dieses Vorgehen reduziert den Freiheitsgrad des Modells auf ein Minimum: Es soll kein neues Muster erfinden, sondern ein bestehendes exakt übertragen.

Das Ergebnis ist unmittelbar gegen den PHPStan-Level und die bestehenden Interface-Verträge prüfbar. Weicht die generierte Implementierung strukturell vom Referenzmuster ab, etwa durch eine fehlende SearchCriteria-Verarbeitung oder eine falsche Exception-Klasse bei getById, fällt das sofort auf, weil das erwartete Verhalten klar definiert ist. Genau das ist der Kern des geringeren Risikos: nicht weil KI-generierter Code fehlerfrei wäre, sondern weil Abweichungen bei Boilerplate-Code schnell und eindeutig erkennbar sind, ohne dass fachliches Zusatzwissen über die Domäne nötig wäre.

<?php

declare(strict_types=1);

namespace Mironsoft\SeoSuite\Model;

use Magento\Framework\Exception\CouldNotSaveException;
use Magento\Framework\Exception\NoSuchEntityException;
use Mironsoft\SeoSuite\Api\Data\RedirectRuleInterface;
use Mironsoft\SeoSuite\Api\RedirectRuleRepositoryInterface;
use Mironsoft\SeoSuite\Model\ResourceModel\RedirectRule as ResourceModel;

/**
 * Repository implementation for the RedirectRule entity.
 * Generated from the ProductRepository reference pattern and
 * verified against RedirectRuleRepositoryInterface.
 */
class RedirectRuleRepository implements RedirectRuleRepositoryInterface
{
    /**
     * @param ResourceModel $resource
     * @param RedirectRuleFactory $ruleFactory
     */
    public function __construct(
        private readonly ResourceModel $resource,
        private readonly RedirectRuleFactory $ruleFactory
    ) {
    }

    /**
     * Saves a redirect rule.
     *
     * @param RedirectRuleInterface $rule
     * @return RedirectRuleInterface
     * @throws CouldNotSaveException
     */
    public function save(RedirectRuleInterface $rule): RedirectRuleInterface
    {
        try {
            $this->resource->save($rule);
        } catch (\Exception $exception) {
            throw new CouldNotSaveException(__('Could not save redirect rule.'), $exception);
        }
        return $rule;
    }

    /**
     * Loads a redirect rule by id.
     *
     * @param int $ruleId
     * @return RedirectRuleInterface
     * @throws NoSuchEntityException
     */
    public function getById(int $ruleId): RedirectRuleInterface
    {
        $rule = $this->ruleFactory->create();
        $this->resource->load($rule, $ruleId);
        if (!$rule->getId()) {
            throw new NoSuchEntityException(__('Redirect rule with id "%1" does not exist.', $ruleId));
        }
        return $rule;
    }
}

7. Testfixtures und Testdaten generieren lassen

Testfixtures gehören zu den am meisten unterschätzten Anwendungsfällen für KI-Generierung, obwohl sie einen erheblichen Anteil der Zeilenzahl in jeder gut getesteten Codebasis ausmachen. Eine Factory-Funktion, die ein vollständiges Testobjekt mit sinnvollen Default-Werten erzeugt und einzelne Felder überschreibbar macht, folgt in praktisch jeder Sprache demselben Muster. Der Wert einer solchen Fixture liegt nicht in kreativer Logik, sondern darin, dass sie konsistent, lesbar und wartbar ist, wenn sich das zugrunde liegende Datenmodell ändert.

Auch hier gilt die gleiche Verifikationslogik wie bei DTOs: Eine generierte Fixture ist sofort prüfbar, indem man einen bestehenden Test damit laufen lässt und das Ergebnis mit einer manuell erstellten Instanz vergleicht. Abweichungen fallen durch fehlschlagende Assertions sofort auf. Das macht Testfixture-Generierung zu einem der sichersten Einstiegspunkte für Teams, die KI-gestützte Codegenerierung erstmals etablieren wollen, weil ein fehlerhaftes Ergebnis im schlimmsten Fall einen fehlschlagenden Test produziert und nicht einen stillen Fehler in der Produktion.

# Fixture factory pattern: same shape regardless of language,
# only field defaults change between projects
def make_redirect_rule(**overrides):
    """Return a fully populated test fixture with sane defaults."""
    defaults = {
        "rule_id": 1,
        "request_path": "old-url.html",
        "target_path": "new-url.html",
        "redirect_type": 301,
        "is_active": True,
        "store_ids": [1],
    }
    defaults.update(overrides)
    return defaults


def test_inactive_rule_is_skipped_by_matcher():
    rule = make_redirect_rule(is_active=False)
    assert rule["is_active"] is False
    assert rule["redirect_type"] == 301

8. Qualitätssicherung: Was auch bei generiertem Code zu prüfen ist

Auch risikoarmer Boilerplate-Code entbindet nicht von einer sorgfältigen Prüfung, sie fällt nur leichter und schneller aus als bei Geschäftslogik. Vier Punkte sollten bei jeder generierten Klasse zwingend geprüfte werden: Erstens, ob die tatsächlich verwendeten Interface-Signaturen mit den vorhandenen Verträgen übereinstimmen, gerade bei Magento-Interfaces mit optionalen Parametern. Zweitens, ob PHPStan auf dem geforderten Level ohne neue Fehler durchläuft. Drittens, ob Exceptions korrekt und an der richtigen Stelle geworfen werden, weil generischer Code hier gerne zu allgemeine Exception-Typen verwendet. Viertens, ob die generierte Datei tatsächlich an beiden Stellen im Dual-Vendor-Workflow existiert, falls das Projekt eine solche Konvention hat.

Ein häufiger Fehler in der Praxis: Entwickler vertrauen KI-generiertem Boilerplate blind, weil die Aufgabe „einfach“ wirkt, und überspringen den Review-Schritt komplett. Genau das untergräbt den eigentlichen Sicherheitsvorteil von Boilerplate-Generierung, der ja gerade darauf beruht, dass Abweichungen schnell erkennbar sind, sofern man tatsächlich hinschaut. Ein kurzer, aber konsequenter Review-Schritt mit statischer Analyse und einem Testlauf kostet wenige Minuten und verhindert, dass sich subtile Abweichungen unbemerkt in die Codebasis einschleichen.

9. Boilerplate-Generierung im Vergleich: geeignete und ungeeignete Aufgaben

Nicht jede repetitiv wirkende Aufgabe ist tatsächlich risikoarme Boilerplate. Die folgende Übersicht ordnet typische Entwicklungsaufgaben danach ein, wie gut sie sich für eine KI-gestützte Generierung eignen, und nennt jeweils den Grund für die Einstufung.

Das Muster in dieser Tabelle wiederholt sich: Immer dann, wenn die korrekte Form eindeutig aus einer Konvention oder einer bestehenden Vorlage ableitbar ist, sinkt das Risiko der Generierung deutlich. Sobald eine Aufgabe hingegen eine Entscheidung über fachliches Verhalten, Sicherheit oder Randfälle erfordert, die nicht im Prompt explizit vorgegeben ist, steigt das Risiko einer plausibel aussehenden, aber fachlich falschen Lösung erheblich.

10. Zusammenfassung

Boilerplate-Code ist der Bereich, in dem KI-gestützte Codegenerierung mit Claude am zuverlässigsten funktioniert, weil die Lösungsmenge klein, die Muster bekannt und Abweichungen leicht erkennbar sind. DTOs, Repository-Implementierungen nach Magentos Service-Contract-Pattern und Testfixtures folgen alle einer festen Form, die sich ohne fachliches Zusatzwissen gegen ein Referenzmuster prüfen lässt. Genau das unterscheidet Boilerplate-Generierung fundamental von der Generierung neuer Geschäftslogik, bei der plausibel aussehender, aber fachlich falscher Code deutlich schwerer zu erkennen ist.

Wer diesen Unterschied konsequent nutzt, verweist Claude bei Boilerplate-Aufgaben explizit auf ein bestehendes Referenzmuster im selben Modul, hält Prompts so konkret wie möglich und pruft jedes Ergebnis trotzdem mit PHPStan, PHPCS und einem Testlauf. So bleibt der Zeitgewinn real, ohne dass die Kontrolle über die Codebasis verloren geht. Für neuartige Geschäftslogik, Sicherheitsentscheidungen und Architekturfragen bleibt hingegen die sorgfältige menschliche Modellierung unverzichtbar.

11. FAQ: Boilerplate-Code mit KI generieren lassen