Generating Boilerplate Code with AI

1. Where AI genuinely shines at coding

Discussions about AI-assisted software development are often framed as if there were only two positions: AI will soon write all the code, or AI is unsuited for real software development. Both extremes ignore the fact that programming tasks fall into very different risk categories. At one end sit novel business logic, architectural decisions, and security-critical code, where every line has consequences that cannot be derived from the code alone. At the other end sits code whose structure is already fully determined by an established pattern.

It is precisely in this second category, so-called boilerplate code, that Claude delivers the most reliable results. A data transfer object with ten fields, a repository implementation following Magento's standard pattern, or a test fixture class all follow a shape that appears thousands of times in open-source code, official documentation, and internal codebases. The model does not need to generate new domain knowledge here, only apply a known pattern correctly to a specific context. This article draws that exact boundary and shows where low-risk generation ends and risky automation begins.

2. What boilerplate code actually is

Boilerplate code is repetitive code required to satisfy a language or framework convention, but which does not itself contain a specific business decision. Classic examples are getters and setters, interface declarations, DTO classes, constructor injection, mappers between a database model and a domain object, and the ever-identical basic structure of PHPUnit test classes. In Magento, this also includes repository interfaces, factory classes, data objects with ExtensibleDataInterface, and the accompanying di.xml entries, which look nearly identical regardless of which entity they are written for.

What matters is the distinction between form and content. The form of a repository interface with save, getById, getList, and deleteById is firmly dictated by Magento's service contract convention. The content, meaning which business rule should apply when saving or how a price should be calculated, is no longer boilerplate but core logic. Anyone who draws this line clearly can deliberately decide which tasks are suitable for AI-assisted generation and which require careful human modeling that cannot be derived from a known pattern alone.

3. Why generating boilerplate is lower-risk than generating logic

The lower risk of boilerplate code has three concrete causes. First, the solution space is small: a repository interface for an entity has only a few sensible shapes, whereas a discount calculation allows countless equally plausible-looking but factually incorrect variants. Second, boilerplate code is checkable against a known reference pattern, such as the official Magento documentation or an existing repository interface in the same module, whereas business logic is only verifiable against functional requirements that are rarely stated in full inside the prompt. Third, errors in boilerplate code are usually noticed immediately: PHPStan, Magento's interface contracts, and a simple test run reliably surface structural deviations.

The same does not hold for business logic to the same degree. An AI can produce a shipping cost calculation that is syntactically flawless, passes every test the prompt itself suggested, and still contains an incorrect rounding rule or an overlooked edge case that only surfaces in production. Such errors are more expensive because they cannot be found simply by reading the structure; they require domain understanding of the business itself. Keeping this distinction in mind lets you use Claude precisely where verification is cheap, while retaining full human control over everything else.

# 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. Generating DTOs and value objects

Data transfer objects are a textbook example of low-risk generation, because their structure can be derived purely from a field list. Give Claude a list of field names with types, whether from an existing database schema or a JSON interface description, and you get back a complete, type-safe class with constructor property promotion, readonly properties, and matching PHPDoc blocks within seconds. The value here does not lie in creative problem solving but in eliminating repetitive, error-prone manual work, such as accurately transcribing twenty field names into a constructor.

It matters to make the input as concrete as possible. A prompt with a complete field list including types and nullability markers almost always produces correct code, while a vague prompt such as "create a DTO for order data" forces the model to make assumptions about fields that then need manual correction. The more explicit the structure already is in the prompt, the smaller the error surface becomes, and the closer the task moves toward pure boilerplate rather than a modeling decision.

{
  "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 and the repository pattern

CRUD scaffolding, meaning generating the ever-identical basic operations for an entity, is especially clearly defined in Magento through the service contract pattern. Every repository follows the same basic shape: an interface in the Api/ namespace with save, getById, getList, and deleteById, an implementation in the Model/ namespace that injects a resource model and a collection factory, and a di.xml entry mapping interface to implementation. This repetition across dozens of entities makes CRUD scaffolding one of the most productive applications for AI generation in a Magento context.

The productivity gain arises not because the pattern is complicated, but because it is tedious and tiring to write by hand for the tenth time. This exact monotony is where typos and forgotten null checks tend to happen, because attention lapses during repetitive work. An AI does not get tired and applies the pattern on the tenth repetition just as precisely as on the first. The human task shifts from mechanical implementation toward reviewing whether the generated result truly fits the existing module.

<!-- di.xml: maps the repository interface to the generated implementation -->
<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. Practical example: generating a repository interface for Magento

A concrete example makes the difference between low-risk and risky generation tangible. For a new RedirectRule entity in the Mironsoft_SeoSuite module, Claude should produce a complete repository interface along with its implementation. The prompt explicitly points to an existing repository in the same module as a reference pattern and names the concrete dependencies, such as the resource model, collection factory, and search criteria handling. This approach reduces the model's degrees of freedom to a minimum: it should not invent a new pattern but transfer an existing one exactly.

The result is immediately checkable against the PHPStan level and the existing interface contracts. If the generated implementation deviates structurally from the reference pattern, for instance through missing search criteria handling or the wrong exception class on getById, this stands out immediately because the expected behavior is clearly defined. That is exactly the core of the lower risk: not because AI-generated code is error-free, but because deviations in boilerplate code are quick and unambiguous to spot, without requiring additional domain expertise.

<?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. Generating test fixtures and test data

Test fixtures are among the most underrated use cases for AI generation, even though they make up a substantial share of the line count in any well-tested codebase. A factory function that produces a fully populated test object with sensible default values and lets individual fields be overridden follows practically the same pattern in every language. The value of such a fixture lies not in creative logic but in it being consistent, readable, and maintainable when the underlying data model changes.

The same verification logic that applies to DTOs applies here too: a generated fixture is immediately checkable by running an existing test against it and comparing the result to a manually created instance. Deviations show up immediately through failing assertions. That makes test fixture generation one of the safest entry points for teams looking to establish AI-assisted code generation for the first time, because a flawed result produces, at worst, a failing test rather than a silent bug in production.

# 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. Quality assurance: what to check even in generated code

Even low-risk boilerplate code does not exempt you from careful review, it just makes review faster and easier than it would be for business logic. Four points should be mandatory for every generated class: first, whether the interface signatures actually used match the existing contracts, especially for Magento interfaces with optional parameters. Second, whether PHPStan runs at the required level without new errors. Third, whether exceptions are thrown correctly and in the right place, since generic code tends to use overly general exception types. Fourth, whether the generated file actually exists in both places under a dual-vendor workflow, if the project follows such a convention.

A common mistake in practice: developers trust AI-generated boilerplate blindly because the task feels "simple," and skip the review step entirely. That undermines the actual safety advantage of boilerplate generation, which rests precisely on the fact that deviations are quickly recognizable, provided someone actually looks. A short but consistent review step with static analysis and a test run costs a few minutes and prevents subtle deviations from creeping unnoticed into the codebase.

9. Boilerplate generation compared: suitable and unsuitable tasks

Not every task that looks repetitive is actually low-risk boilerplate. The following overview classifies typical development tasks by how well suited they are for AI-assisted generation, along with the reasoning behind each classification.

The pattern in this table repeats: whenever the correct shape can be unambiguously derived from a convention or an existing template, the risk of generation drops significantly. The moment a task requires a decision about business behavior, security, or an edge case that is not explicitly given in the prompt, the risk of a plausible-looking but factually wrong solution rises substantially.

10. Summary

Boilerplate code is the area where AI-assisted code generation with Claude works most reliably, because the solution space is small, the patterns are known, and deviations are easy to spot. DTOs, repository implementations following Magento's service contract pattern, and test fixtures all follow a fixed shape that can be checked against a reference pattern without requiring additional domain expertise. That is precisely what fundamentally distinguishes boilerplate generation from generating new business logic, where plausible-looking but factually incorrect code is significantly harder to detect.

Anyone who consistently applies this distinction points Claude explicitly at an existing reference pattern in the same module for boilerplate tasks, keeps prompts as concrete as possible, and still reviews every result with PHPStan, PHPCS, and a test run. That way the time savings stay real without losing control over the codebase. For novel business logic, security decisions, and architectural questions, careful human modeling remains indispensable.

11. FAQ: Generating Boilerplate Code with AI