In short: A good prompt for PHP or Shopware is basically a good technical task description. It names the environment and versions, describes the current and target state, defines what must not be changed and asks for tests. And it explicitly tells the AI to state open questions instead of inventing methods. That doesn't guarantee bug-free code, but it saves a lot of time fixing plausible-sounding answers.
Why "write me a Shopware plugin" doesn't work
With a request like that, the AI knows neither which Shopware version is running nor which extensions are installed or which edge cases exist. It fills the gaps with assumptions. The result often looks good but doesn't fit the real system.
Typical consequences:
- code for a different Shopware version
- events or services that don't exist
- changes in places that shouldn't be touched
- no consideration of languages, variants or permissions
Context is not a side issue
When I work on an existing application, I first describe the technical environment: framework, versions, components involved and the observed behaviour. For Shopware that includes the exact version, whether it is about the storefront or the Administration, and possible interactions with other extensions.
Just as important is separating the current state from the target state. A symptom is not automatically the cause. So I first ask for hypotheses and verifiable diagnostic steps before moving on to a solution.
How I structure technical prompts
- Environment: software, versions, relevant dependencies
- Starting point: what already exists and what works?
- Problem: reproducible bug or new requirement
- Constraints: which files, data or interfaces must not be changed?
- Result: the desired solution with explanation and tests
A simplified example:
Project: Shopware 6.7 with a custom storefront extension, PHP 8.3.
Problem: A product property should be shown in the cart.
Constraints: No changes to the Shopware core, texts as snippets in German and English.
Approach: First check possible data sources and extension points. Don't invent methods or services. If information is missing, ask.
Result: A solution for exactly this version with test cases, including products without this property.Keep changes small
Especially with older systems, I ask for the smallest possible change first. Large, automatically generated rewrites can silently break existing logic. So I always ask which files are affected and why.
One sentence belongs in almost every prompt I write: "State assumptions and open questions before you write a solution." If important information is missing, I want to know, instead of getting an invented answer.
Tests belong in the prompt
A solution always includes the cases you don't think of at first:
- empty or missing values
- users without the required permissions
- multilingual content
- products with many variants
- large data volumes
These questions decide the quality of a shop extension. If I name them in the prompt, the AI takes them into account in the solution.
Name versions explicitly
PHP and Shopware keep evolving. What is allowed in one version is deprecated in the next. How much changes with PHP 8.5, for example, is covered in PHP 8.5: The Changes That Actually Matter for Developers. Without a version, the AI often falls back on older patterns it has seen more often.
What a good prompt doesn't replace
Even the best prompt doesn't guarantee correct code. It only lowers the chance that the AI misses the problem. I still have to check, test and take responsibility for the result. Why I mainly use AI before the code is explained in AI in Everyday Development.
Checklist for your next technical prompt
- Versions of Shopware, PHP and key extensions named?
- Current and target state described separately?
- Constraints defined, i.e. what must not be changed?
- Asked for assumptions and open questions?
- Test cases and edge cases requested?
- Asked for a small, explained change instead of a big rewrite?
Frequently asked questions
Does a prompt have to be long?
Not long, but complete. Five precise lines with versions, problem and constraints achieve more than a long text without them.
Does it help to give the AI a role, such as "you are a Shopware expert"?
A little, but much less than concrete context. The exact version and the observed behaviour matter more than any role description.
Should I give the AI my entire code?
Only the relevant parts, and only if you are allowed to. Too much code dilutes the answer, too little leads to assumptions. For client code, clarify beforehand what is allowed.