A large differentiator in the quality of output you will receive from AI coding tools depends on the quality of the AI model and the framework which it can act within, together often called an “Agent”.
Context then comes next, once you have a capable agent it needs a sufficient level of context on what you are trying to solve, without so much context that would cause it to go down rabbit holes.
Context comes in a few different forms. The problem you are trying to solve, screenshots of the design, key areas of the codebase to consider and must have implementation details. These areas can be less or more well defined depending on how tightly you are wedded to a particular solution.
For example if I am unsure about the implementation I will leave details very light there, let the agent figure out that for itself. I’ll then restart the process if I’m unhappy with the result and give more implementation context depending on what I learnt from the first run.
If I’m unsure about particular context I’ll preface things with words that indicate that I’m unsure of the exact output. For example, “maybe have a look at X it might be relevant” and let the agent discover the details.
Let’s have a look at a prompt I recently used to begin the feature to add status filtering to the user story map. It’s a little embarrassing the share these prompts directly as they are often are bit sloppy, but Claude understands me so its fine!
This was a prompt where the top section was copy-pasted from the Jira ticket and the section at the bottom was some extra context and implementation details to consider.
Introduce status-based filtering for all work item levels on both the story board and backbone, enabling users to focus on items in specific workflow stages.
Key Functionality
Status Filtering Options:
- Allow users to filter work items on the story board by one or more statuses.
- Enable the same status filtering on the backbone (including epics).
- Extend this filtering capability to third-level hierarchy work items.
Performance and Compatibility:
- Ensure filtering respects the board filter criteria.
- Filtered results should be consistent with the current workflow schema and status logic.
Visual and UX Consistency:
- Filtering interface should be intuitive and align with existing filtering patterns in USM.
- Maintain status colour coding (based on status category) to ensure visual continuity.
Status category migration
- We should migrate users from the current status category filtering
- We should take their status at the time of first loading the filter after our change and migrate it to statuses by selecting every status that matches the selected cateogory
- We should then update the filter or view by removing the status category filters which we can use as a flag for knowing that the migration has happened
- We will have to update the newFiltersJql to use statuses instead of categories.
- We likely want to just store the status ids in our filters and views
Using the Cursor agent with Claude 4 then produced a working version.
Being able to get this working within minutes from prompt to output then allowed conversation with Product and Design to continue so that we could iterate to the final version. Which then probably took another ~20 prompts to refine and get something I’m happy to put up for PR.