Applying prompts to GenAI/LLMs

B rief recap In an earlier post, “Same prompt, four AIs: why answers aren’t always the same” , I looked at what happened when the same prompt was given to four different LLMs. Unsurprisingly, perhaps, the answers were not identical. That raised an interesting follow-on question: what was the prompt actually trying to do? The answer is that it was trying to support a form of thematic analysis. In that case, the object of analysis was an academic profile, including my Google Scholar profile. The version I discuss here is a modified prompt, used with Claude.ai, where I uploaded a CV and asked the system to find other appropriate public resources connected with a named person and institution. The aim was not simply to summarise the CV, but to identify visible and less visible themes across a whole career. Why use thematic analysis? Thematic analysis is widely used by academics, especially in qualitative research. Braun and Clarke’s well-known paper, Using thematic analysis in psy...

Same Prompt, Four AIs — Why the Answers Aren’t the Same The differences aren’t just in the answers—they’re in the thinking Generative AI tools are often discussed as if they were interchangeable—different interfaces delivering broadly similar outputs. However, when applied to complex intellectual tasks, meaningful differences begin to emerge. To explore this, I ran the same academically rigorous prompt through four leading systems—Claude, ChatGPT, Google Gemini, and Copilot. The task required a full thematic analysis of a researcher’s career using the framework developed by Virginia Braun and Victoria Clarke . What followed was not simply variation in output, but variation in how each system approached the act of analysis itself. Same Input, Different Interpretations At a high level, the experiment is simple: One prompt → Four models → Four distinct approaches What changes is not the instruction, but how each system: Interprets the task Handles uncertainty Applies methodology Defines ...

Analysing Documents with AI: A Multi-Stage Prompting Approach What happens when a data scientist and a statistician are asked to challenge each other's reading of the same paper? The coding-focused prompting technique described in  a previous post  has a natural sibling: the same multi-stage, dual-persona approach works remarkably well for document analysis. Instead of building software through iterative expert review, you are analysing a piece of work — a research paper, a dataset report, a literature review — and subjecting it to exactly the same kind of structured, adversarial scrutiny. This post walks through how that adapted prompt works, why the underlying techniques make it more than a glorified summarisation tool, and what happened when it was tested on a social network analysis of co-authorship patterns in an academic repository. Why Not Just Ask for a Summary? A single-shot summary prompt is fine if you want a précis. But analysis is different. Analysis requires aski...

Building Software with AI: A Multi-Stage Prompting Approach What if you could have two seasoned 'experts' sitting beside you as you built software (you can add more if you like) — questioning your assumptions, challenging your logic, and pushing your code toward something genuinely better? That's exactly what this prompting approach tries to recreate. This post walks through a structured, multi-stage prompt technique for AI-assisted software development. It combines three well-established prompt strategies — iterative questioning, persona simulation, and collaborative reasoning — into a single, coherent workflow. Whether you're new to prompt engineering or looking to level up your practice, this approach offers a repeatable pattern worth trying. Why This Approach? It's tempting to use AI for code in a single shot: describe the problem, get some code, move on. The results are often functional, but sometimes shallow — the AI has no real understanding of your cont...

In a companion post on context stacking, I came across an idea that stayed with me — and I wanted to explore it further. This piece isn’t just about the final blog produced, but about the process behind creating it using generative AI (specifically, Claude.ai). Rather than using AI as a writing shortcut, I used it as a thinking partner — one that could challenge my assumptions, test my reasoning, and help strengthen the argument before anything was finalised. What emerged was a structured workflow (shown below) that others can adopt when using AI to improve the rigour, not just their output. And it all starts with setting the context and the audience and telling the generative AI to pick it apart. The process: Before using Generative AI: Two drafts were produced, and the second draft went through this final process, as described by claude.ai here. Here's the workflow we followed: 1. Critical Reading and Initial Diagnosis We started with a close reading of your original draft, ...

A proof of concept argument for student-centred module leaders A tweet recently caught my attention  https://x.com/ihtesham2005/status/2041576806810370553?s=20 . It described an MIT student who had developed what he called “context stacking” — uploading lecture materials, readings and related papers into an AI tool before each class, then using carefully constructed prompts to build a mental model of the content before setting foot in the lecture hall. By the time he arrived, the professor wasn’t teaching him anything new. They were confirming, refining and occasionally surprising him. That surprise, he said, was the only thing he wrote down. This is not simply pre-reading with extra steps. Using generative AI as an external thinking partner, this student was identifying gaps in his own understanding before the lecture began — doing what good tutors have always done, asking not “what do you know?” but “where does your understanding break down?” This maps directly onto the highe...