Skip to main content

Implicit vs. Explicit Intent: Why "It Must Produce HTML Interfaces" Changed Everything

image of screen toregister pet
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 into Visual 
Studio Code including instructions to install and run this code in 
Visual Studio Code. It must produce html interfaces.

Headless by Default vs. Explicit Constraints

The trailing sentence—"It must produce html interfaces"—turned out to be the critical leverage point in the prompt.

During initial testing without that explicit instruction, the model produced a technically flawless, "headless" solution. It generated:

  • Complete REST API endpoints (GET /pets, POST /pets, GET /pets/<petId>). See REST API for more details on this,

  • Full compliance with the OpenAPI schemas, including error handling (400/404).

  • Automated test scripts that all passed.

However, it did not contain a user interface.

Because an OpenAPI specification naturally defines data contracts, backend endpoints, and status codes, the LLM defaulted strictly to the boundaries of the spec. It seemed to assume a developer or an automated system was the end user. Explicitly constraining the output to include HTML forced the model to bridge the gap between pure API specifications and a human-facing application.

What Claude Produced

Once the HTML constraint was introduced, Claude not only generated the requested web frontend, but also took some creative initiative with the visual styling:

  • app.py: Implements the full REST API per the spec alongside dedicated HTML routes (/, /ui/pets/<id>, /ui/add), both sharing the exact same in-memory data store.

  • templates/: A full set of Jinja2 templates covering the pet directory, individual pet detail pages, a "register a pet" form, and a custom 404 page.

  • static/css/style.css: Rather than defaulting to generic Bootstrap components, Claude created a custom "punched pet-tag" visual theme.

  • requirements.txt & README.md: Minimal dependencies (just Flask) alongside clear, step-by-step VS Code setup instructions (virtual environments, terminal execution, F5 debugging, and curl test commands).


Directory produced
Directory page showing all the pets




Practical Takeaways for Prompting & Teaching

  1. LLMs Assume Domain Boundaries: An LLM will align its outputs with the implicit domain of your source material. Feed it an API spec, and you will get API code. If you want a full-stack prototype, you must explicitly state the end-user modality.

  2. Rapid Prototyping for Education: For educators and developers, this workflow demonstrates how quickly standard spec files can be transformed into fully functional, human-testable boilerplate code for classroom demonstrations or student project baselines..



All opinions in this blog are the Author's and should not in any way be seen as reflecting the views of any organisation the Author has any association with. Twitter @scottturneruon
Labels:

Comments

Post a Comment

Popular posts from this blog

Using an LLM to Find Themes using Thematic Analysis in an Academic Career

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...
Post a Comment
Read more

Prompt Engineering, Context Engineering and Agentic AI in Higher Education: A Short Briefing

AI in Education Prompt engineering, context engineering and agentic AI are often used interchangeably, but the literature treats them as distinct. Prompt engineering concerns crafting effective single instructions to a model (Glean, 2026). Context engineering is the broader discipline of designing and managing the entire informational environment around a model—memory, retrieval, tool outputs and conversation state—rather than a one-off instruction (Abstracta, 2026); prompt engineering operates within the context window, while context engineering determines what fills it (arXiv:2606.12422, 2026). Agentic AI describes systems that plan and execute multi-step tasks with delegated autonomy, raising organisational questions of accountability rather than purely technical ones (MIT Sloan, 2026; Palo Alto Networks, 2026). There is genuine debate about prompt engineering's durability. IEEE Spectrum (2025) reported research suggesting prompting is increasingly performed by models themse...
Post a Comment
Read more

AI as a Mirror: Transforming Vague Student Ideas into a More Rigorous Project Agreement

The Problem: The "Generic App" and the "Time Sink" We’ve all been there: a student walks into a 1-to-1 with a vague desire to "do something with AI" or "build a fitness app." You spend 45 minutes trying to find a technical "hook" that justifies a Level 6 or Level 7 grade, only for the student to drift back into "CRUD app" territory by week three. The Philosophy: AI as a Mirror Instead of you doing the heavy lifting, this workflow uses AI as a Mirror . It reflects the student’s own skills and career goals back to them, but with the structural rigour of a virtual supervisory team. It’s not about the AI "giving" the idea; it’s about the AI forcing the student to defend and refine their own concepts until they hold water. The Framework: 3 Months of Rigour This prompt is specifically designed for intensive/conversion MSc or summer capstone projects . It assumes a tight 12-week implementation window. By forcing the AI to w...
Post a Comment
Read more