Just Ask

Just Ask

Intent

Don't dive into implementation. Describe your problem, and ask your assistant for choices.

Introduction

LLMs perform very well at divergent thinking—generating ideas and suggestions. They’re less good at convergent thinking—evaluating plans contextually and judging the best course of action.

LLMs are also good at extracting meaning from existing text, including documentation and program source. Use these capabilities to your advantage by treating your coding assistant as a “co-pilot”, asking for suggestions, interpretation, and navigation that you use to construct a plan of action.

Problem

Creating software is inherently an activity free of many constraints. Creating the correct software requires understanding what your customers and organisations need and delivering software that meets those needs, but many of the design and implementation dimensions even within those boundaries allow for numerous alternatives.

In a new project, this means limitless possibilities—but also the need to think through how decisions you make now influence how you work, and the costs of change, in later work. For an existing project, it means understanding how changes you make interact with the existing architecture, features, and qualities of the software.

With so much variation, it can be difficult to think through all of the possibilities and impacts. You might choose to follow particular conventions or familiar approaches, a strategy that mitigates some risks but that means you’re unlikely to consider innovative and potentially better solutions that don’t fit the familiar pattern.

If you launch into coding without considering the impacts of your changes, you might find that you need to revert your code changes and start again with an alternative plan, if you discover that the method you first thought of introduces problems.

Solution

Use your coding assistant to orient you on your problem and your existing code, by asking questions that improve your understanding of your requirements and how to integrate your solution into your existing project. Ask questions about: existing approaches to solve problems; open source components or commercial products you could use instead of creating bespoke code; how your current codebase addresses related problems; what suggestions for organising your work the documentation proposes; strategies for implementing a solution to your current task; and suggestions for testing the work.

You Review the assistant’s answers, using your understanding and a logical evaluation of your problem and context to build a plan from the assistant’s suggestions. You can also use Model Reviews, prompting the assistant to provide comparisons of suggestions it makes or to consider any problems that its generated output doesn’t already report.

Applicability

Just Ask at the outset of any coding, software design, or software architecture task, to understand the constraints and opportunities relevant to your task and to gather input to make an informed plan.

You can also Just Ask about issues that arise while you work. For example, if you discover a bug while implementing a feature with your coding assistant, Just Ask whether you fix the bug with a targeted intervention, or replan your overall feature to avoid that bug and related issues.

Consequences

Just Ask offers the following benefits:

• Explore the problem and solution spaces.
• Consider approaches you wouldn’t have thought of.
• Combine the generative capabilities of the LLM with your own evaluation and reasoning skills.

You have to consider the following concerns when you apply the pattern:

• Balance problem exploration and action to avoid using Just Ask as a “cover” for avoiding progress.
• Seek expert input if the answers to your questions are outside your field of experience.

Implementation

Prompt your coding assistant with questions and have it generate answers. You can tell the assistant to provide a single answer, or to generate multiple answers and compare them.

Tell the assistant not to proceed to implementation, while you ask questions and evaluate the assistant’s responses. Many coding assistants have permissions systems that let you deny the model access to tools for writing or editing files, or a “plan” mode that blocks the model from using those tools. Use these facilities to keep the assistant in conversation, blocking it from making changes to your software.

Example

Approaching a Language Port

In one of my native app projects, I’ve been porting Objective-C code to an interpreted language called AppScript to enable faster iteration on development. I used the gemma4 31B model in Mistral Vibe 2.8.1, in plan mode, to Just Ask questions about porting one of the classes:

What problems might I encounter when I port @ResearchBuddy/ResearchBuddy/ResearchNotesView.m to AppScript? Does the language specification in @appscript/ARCHITECTURE.md indicate any missing language features this class would need?

Porting Analysis: ResearchNotesView.m $\rightarrow$ AppScript
Porting this class will primarily result in a significant increase in verbosity due to the removal of C-style syntax and dot notation.

[...]

Language Specification Audit (ARCHITECTURE.md)
The language specification does not indicate any missing features that would block this implementation, but it highlights several architectural requirements:
 1. 
Interop Protocol: You must define a companion Objective-C protocol for ResearchNotesView that explicitly declares - (instancetype)initWithFrame:(NSRect)frameRect;. Without this, the AppScript runtime will misbox the NSRect argument and crash (EXC_BAD_ACCESS).
 2. 
BridgeSupport Dependency: The host app must call loadBridgeSupportForFramework:@"AppKit" to enable access to the constants (e.g., NSViewWidthSizable) and C functions (e.g., NSMakeRect) via the ASAppKit proxy class.
 3. 
Verbosity Trade-off: The layout logic in setupViews will expand from a few lines of math into a series of nested message sends to NSNumber and ASStructValue.

Example of transformed layout logic:

// ObjC: CGFloat paneWidth = floor((totalWidth - divider) / 2.0);
id diff = [totalWidth numberBySubtracting:divider]
id div = [diff numberByDividingBy:@2.0]
id paneWidth = [div floored]

What kind of tests do I need to add to ensure the view continues to work correctly after the port?

To ensure the view remains functional after the port, you need a combination of structural verification (to check that the UI tree was built correctly) and runtime integration tests (to catch AppScript-specific boxing errors).
1. Critical Integration Test
Because AppScript relies on an interop protocol to handle NSRect, the most important test is a simple instantiation test:

- Instantiation: Create the view from Objective-C code using initWithFrame:. If the protocol is missing or incorrect, this will trigger an EXC_BAD_ACCESS immediately.

2. Structural & Layout Tests (Unit/UI)
Since the logic in setupViews is purely declarative layout, you should verify the resulting view hierarchy:

- Hierarchy Audit: Verify that self contains a NSSplitView, which in turn contains exactly two subviews: a PDFView and an NSScrollView.

- Leaf Node Verification: Ensure the NSScrollView has the NSTextView as its documentView.

- Initial Geometry: Verify that the initial frames of the PDF view and Scroll view are approximately equal (the 50/50 split logic).

3. Configuration Tests (State)
Verify that the specific "rich text" and "PDF" settings were ported correctly:

- PDF State: Check pdfView.displayMode == kPDFDisplaySinglePageContinuous.

- Text View Capabilities: Verify notesTextView has editable = YES, selectable = YES, and richText = YES.

- Typography: Confirm the font size is exactly 14pt.


4. Behavioral Tests (Functional)
Verify that the AppScript-configured properties behave as expected at runtime:

- Resizing: Resize the parent view and verify that both panes expand/contract (validates autoresizingMask port).

- Interactivity: Programmatically insert text into the notesTextView to ensure it is writable.

Related Patterns

Ask for Alternatives is an example of using Just Ask specifically to generate multiple approaches to a task.

Stop and Plan when you don’t have a clear idea of how to proceed.

Give Examples to prompt the model to supply answers that follow a particular pattern.