Ask for Alternatives

Intent

Get the model to suggest multiple solutions to your problem. Compare benefits and drawbacks, costs and opportunities, and move forward with your preferred solution. Alternatively, create prototypes of the generated alternatives to explore the proposed solutions in more detail.

Motivation

Software design is the art of making trade-offs. A particular technology choice might make developing a solution easier, while complicating deployment or maintenance activities. Another might offer pre-created solutions that address some of your requirements, but require you to do more work to achieve others.

Similarly, the way you implement your design can impact how maintainable and adaptable your solution is. A given implementation might make quality goals, for example testability or performance, easier or more difficult to achieve.

Decades of experience in software engineering has shown the community that thinking about all of these concerns and trade-offs upfront, with the goal of creating a complete specification of the target software, doesn’t work well. That approach is expensive, error-prone, and causes engineers to go for long periods without feedback on their work, increasing the risk and cost of divergence between the system they build and their stakeholders’ expectations. Software teams instead choose to adopt iterative, incremental approaches, with rapid feedback cycles in which they share working software with their stakeholders, address feedback, and update their understanding of their work and its goals.

Use Ask for Alternatives to get a model to generate multiple approaches to a given task. Explore the choices available, identify unstated assumptions and unasked questions, and pick one or more routes to implement, or to investigate in detail.

Applicability

Use Ask for Alternatives to discover multiple solutions to a given problem, and weigh the pros and cons of the various options.
The alternatives can apply to any point in the software engineering life cycle: for example, you could ask for buy-vs-build options for a particular component; design choices for a programming interface; or approaches to making code changes that fix a bug.

You can usually apply Ask for Alternatives after you Disclose Ambiguity. Prompt a language model to identify areas of ambiguity in your understanding of your current task, then Ask for Alternatives to get a list of potential solutions and the trade-offs they involve. Use that list to refine your understanding of the problem, then select or eliminate potential solutions (optionally adding other alternatives that you or the language model supply). If you end up with a single solution, you might choose to implement that to complete your task. Otherwise, you can build prototypes to explore details of one or more proposed solutions, or Just Ask more questions about their implications.

You might decide that the range of alternatives available, or the specific trade-offs they present, indicate that your team has insufficient shared knowledge of the task you’re trying to complete, in which case you have a wider conversation in which you share your findings and seek consensus on the path forward.

Consequences

Ask for Alternatives offers the following benefits:

• Discover and consider multiple solutions to a given problem.
• Understand the degrees of freedom in your understanding of the problem.
• Weigh costs and benefits of alternative approaches.

Implementation

Ask for Alternatives by following these steps:

1. Write a description of the problem for which you want to generate alternatives, or the task for which you want to consider solutions. Include information about any constraints that apply (for example, business rules, existing design choices, or security goals), and any degrees of freedom in potential alternatives (for example, implementation language, acceptable software licenses, or coupling to existing interfaces).
2. Follow the description with a prompt that tells the model to generate a number of alternative scenarios that address the problem statement.
3. Choose whether You Review or the Model Reviews the proposed alternatives. Consider taking a risk-based approach to this decision; You Review (or your colleagues review) the alternatives in areas that are more critical to your software's goals or introduce more technical risk. In these situations, add instructions in your prompt that tell the model to present the benefits and drawbacks of each scenario without making a recommendation. Otherwise, add instructions so the Model Reviews the alternatives and proposes a recommended scenario, with justification.
4. Optionally, create a few-shot prompt by adding examples of the structure of output you want the model to produce.

You can iteratively Ask for Alternatives by suggesting other scenarios beyond those the model generates, excluding certain scenarios and explaining why they're inappropriate, and expressing additional constraints or degrees of freedom as you refine your understanding of the problem by considering the presented alternatives.

Example

A Website for Design Patterns

In creating this website to share this pattern language, I need to choose whether to build a web application, or to adapt an existing solution to fit my needs.

To choose an approach, I created an initial list of requirements:

* Website for hosting "Patterns in AI-Augmented Software Engineering"
** All content available read-only without logging in
** Each pattern on its own page
*** Patterns pages have a standard layout with sections in the same order
**** Intent
Explains what you get by applying the pattern.
**** Motivation
Explains the problems that give rise to the pattern being applicable.
**** Applicability
Describes when and how to use the pattern.
**** Consequences
Describes the benefits of using the pattern to solve the stated problems.
**** Implementation
Gives an abstract description of the work involved in applying the pattern.
**** Examples
One or more examples of situations where the pattern's applicable, along with demonstrations of applying the patterns and the outcomes. These examples can include sample code, which are presented as short annotated snippets inline with links to the full code. Code samples are copyleft free software.
**** Related Patterns
This is a structured collection of links to other patterns, including prose explaining how they're connected.
Additionally, add back-links from other patterns that link here, in a "Referenced in" section that doesn't have additional text.
Any pattern that's got a description in Related Patterns doesn't _also_ appear in the back-links list.
*** Editable by some users
Initially, that's just me. Design for adding more writers and editors.
Editing should include simple, linear version control, so changes can be rolled back but pages can't be "forked".
*** Commentary by any logged-in user
Any user with an account can contribute to a discussion for the overall page, which appears at the bottom. They can alternatively start or continue a discussion for a particular paragraph in the prose. A paragraph discussion appears as an icon next to the relevant paragraph, which a user can click to expand and read the comments. Comments are threaded, with replies indicated by indentation.
** Each pattern is in one category
Categories also have pages, that list each pattern in the category by title, with its intent as a "preview". Categories don't need commentary.
* Non-functional requirements
** The website must be copyleft free software, preferably AGPL3.
** Styled to use Chiron Codex fonts and colour scheme.
** Deployment
*** Site deployed using GNU Guix on GNU/Linux.
*** Initial hardware is a linode 1GB plan.
192 GB memory, 1-32 shared vCPU cores, 25 GB-4TB storage.
*** code samples are either part of the same website, or hosted on a repository such as Codeberg.
*** Initial deployment scale:
Consider growing by 10-100x in each dimension.
**** 40 patterns.
**** 5 categories.
**** 120 sample code projects.
**** 1 editor.
**** 100 commentators.
**** 10,000 unique non-logged-in visitors.
*** Access via HTTPS only.
*** Comments feature must align with GDPR and UK Online Safety Act requirements.

Source code available at website-requirements.org.

I used the following prompt in Mistral Vibe to get the Qwen 3 Coder model to generate alternative scenarios:

The web app can be developed in house, adapted from an existing wiki or CMS package, or built using the existing features of an existing wiki or CMS package. Consider different technologies, and explain the benefits and drawbacks of each. Present the pros and cons of each scenario, and show your reasoning. Don't choose a "favourite" scenario, that's for me to decide based on your report.

The model proposed 5 different scenarios: full in-house development; adapting an existing wiki or CMS; building the site using an off-the-shelf wiki or CMS; using a static site generator; or using a “headless CMS”. It generated a markdown file that describes each of the scenarios, along with a comparative analysis that compares requirements alignment, scalability, and risks of each scenario. For example, here's the list of generated strengths and weaknesses for the static site generator approach:

### Scenario 4: Static Site Generator Approach
**Strengths:**
- Excellent performance and security
- Very low hosting costs
- High reliability with no server-side dependencies
- Excellent scalability with CDN distribution
- Version control integration through Git

**Weaknesses:**
- Difficult to implement real-time commenting features
- Content management complexity with specific formats
- No built-in user management systems
- Version control implementation may require additional tooling
- Paragraph-level commenting requires custom solutions or external services

**Best For:** Organizations prioritizing performance, security, and cost-efficiency with less emphasis on real-time user interactions.

Source code available at comparative_analysis.md.

The model generated the summary statement that “Scenario 4 excels in performance and cost but requires creative solutions for complex features”.

Related Patterns

Use Disclose Ambiguity to discover unspecified concerns in your requirements, design, or problem statement, that you then Ask for Alternatives to address.

Ask for Alternatives from different models, or in multiple iterations using the same model, in a Bake Off to generate a wider range of scenarios and to evaluate how different models interpret the problem statement.

Start with a Clean Slate when you move from exploring alternatives to implementation, so that the model doesn't use information from rejected scenarios when it generates the implementation.

Build a Model of a proposed scenario to explore its properties and get feedback from stakeholders.