Applying prompts to GenAI/LLMs

Registration page for a new pet When using Large Language Models to convert specifications into code, the boundaries of your input heavily shape the boundaries of the model's output. If you feed an LLM an API specification, its baseline assumption is that you want an API. This short case study explores what happened when converting a standard OpenAPI 3.0 specification into a runnable Flask project using Claude.ai—and how adding a single sentence to the prompt dramatically altered the architectural and visual output. The Experiment & The Starting Prompt The goal was simple: take the standard OpenAPI 3.0 Petstore example specification and prompt Claude.ai to turn it into a complete, runnable Flask application pre-packaged for Visual Studio Code. Here was the initial prompt structure: Plaintext In the next prompt I am going to enter an OpenAPI specification. Your role is to convert this into a Flask-based program and then save the files as a zipped-up file ready for importing i...

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...

Imagine buying complex furniture, but the instructions are a chaotic pile of sticky notes. This is often the daily reality for software engineers. Whether you are "vibe coding" a new feature or trying to connect two different web services, you often find yourself digging through messy, undocumented code just to understand how things talk to each other. The OpenAPI Specification (OAS) is the "Universal Instruction Manual" that fixes this. Why This Matters for Modern Engineering I n a world of AI agents like Gemini, ChatGPT, and Claude , having a machine-readable "map" of your code is a superpower. For Humans: It provides a clear map of what a service does and what it needs. For AI Agents: Tools like Cursor or Windsurf can use an OpenAPI spec to understand your project’s "intent" (the vibe) without getting lost in the syntax of your legacy files. For Students: It allows you to take an old Python/Flask project and instantly generate interactiv...