#079 AI Prompts for Engineering | August 2025 Edition

Sharing some of my most used prompts for broad use cases in engineering and technical work.

Aug 26, 2025

James here.

Thank you for being a part of the Flocode readership. If you find this work valuable, the best way to support it is to share it with a colleague.

The referral program offers complimentary access to the complete Flocode archive.

How it Works

Use your referral link below or the ‘Share’ button on any post. You’ll get credit for any new subscribers (free or paid) who join through your link.

Refer a friend

Get a 1 month comp for 3 referrals
Get a 3 month comp for 6 referrals
Get a 6 month comp for 10 referrals

The tools and techniques we use to interact with large language models are not static. Like any developing discipline, the methods evolve as we gain a deeper understanding of what works. Strategies that were effective six months ago are often superseded by more robust frameworks today.

This post is a snapshot of the prompting structures that are currently working for me. But more than just a list of prompts, it’s an overview of a mental model for how to approach LLMs in engineering and design.

If you're new to the topic, the fundamentals of a good prompt are straightforward. You provide the model with three things:

A Role to adopt.
A clear Objective to achieve.
Sufficient Context to constrain the output.

The hallmark of an elegant design is achieving the objective with the minimum effective complexity. The same is true here. Your goal is to provide just enough context to capture your intent, no more, no less.

Not an easy task.

It kind of feels like pottery, slowly making the shape you need.

From Prompting to Specification: A Three-Level Framework

I find it pragmatic to think of LLM interaction as a hierarchy of increasing specification, where the level of detail is tailored to the complexity of the task.

Level 1: Prompt Engineering

This is the baseline: a direct instruction to the model to perform a discrete task. It’s the equivalent of a quick sketch on a notepad, useful for conveying a single idea, but lacks the detail for nuance or complexity.

Level 2: Context Engineering

This is a level deeper. Here, you are not just giving a command; you are providing the broader principles, references, and constraints that govern the task.

Think of designing a concrete beam. You don’t just say "design a beam." You specify material properties, geometric constraints, exposure conditions, governing design codes, and load cases. This is context engineering. You are orienting the model within a much more comprehensive and specific solution space. There is always a trade-off between the effort of providing this context and the required precision of the output.

This is true figuratively and literally since the context windows of many modern LLM’s have limits and once you hit them, you’re design progress faceplants and you enter a vortex of debugging hell, repeated clarifications and dead ends.

This is known as context poisoning. It’s important to understand this and to avoid a bad habit of staying with old chat threads that stretch back months. Your context is toast and the responses will be of a much poorer quality.

Context Poisoning is when a hallucination or other error makes it into the context, where it is repeatedly referenced. - Google, 2025

Level 3: Product Requirements

For tasks that require significant logic, planning, reasoning, and a comprehensive framework, we move to the level of a full requirements document. This is an engineering-level specification of what you are trying to build. It’s a robust planning tool for a complex objective, leaving very little to chance. I will cover this in more detail in the future.

Two Prompts to Build All Other Prompts

Below are the concepts for two of my most-used prompts. They are recursive; you can use them to build better prompts for almost any other task. I’ve added the full text to a Flocode GitHub repository at:

https://github.com/joreilly86/Flocode-Prompt-Library

The following prompts are broadly applicable to any complex task. I often need to do a few iterations of the response to fine tune it to my preferences but I ‘m improving at framing the questions, providing adequate context and clarifying objectives.

1. The Prompt Generator Prompt:

This prompt helps frame a situation or question holistically. It forces you to approach the problem from multiple perspectives, which remarkably improves the quality of the final prompt you generate for the actual task.

Master Prompt for AI-Assisted Knowledge Work
Persona: You are an expert-level AI assistant and a strategic partner. Your purpose is to help me, a knowledge worker, analyze information, generate content, and solve complex problems efficiently and accurately.

Primary Objective: To deliver a precise, well-structured, and context-aware response tailored to my specific request. To achieve this, you will rigorously follow the principles outlined below in every interaction.

Core Principles of Interaction:

1. Deconstruct and Reason (Think Step-by-Step): Before providing a final answer, first, briefly outline the intermediate reasoning steps you will take to fulfill my request. This ensures your logic is transparent and allows me to identify any misunderstandings before you invest in generating a full response. For any task that can be solved by "talking through it," you should explain your steps.

2. Emulate Provided Examples: If I provide one or more examples (few-shot prompting), you will treat them as the most important guide for your output. You must analyze their structure, style, tone, and level of detail, and use them as a direct blueprint for the response you generate.

3. Assume a Role and Maintain It: When I assign you a role (e.g., "Act as an expert on structural dynamics," "Act as a helpful research assistant"), you will adopt that specific character, style, and perspective throughout your response.

4. Prioritize Positive Instructions: You will focus on what to do (instructions) rather than what to avoid (constraints). Clear, direct instructions lead to better outcomes.

    ◦ Example Do: "Summarize the following text in three bullet points." 
    ◦ Example Don't: "Don't write a long paragraph about the text." 

5. Demand Specificity and Context: You will operate on the assumption that specificity improves accuracy. If my prompt is too general, you may ask clarifying questions to better understand the desired output format (e.g., "Generate a 3-paragraph description of temperature effects on concrete") , the audience (e.g., "written in a style for technical experts and financial stakeholders"), and the key information to include.

6. Structure the Output for Utility: For any task that involves extracting, classifying, or organizing information, you must default to a structured format like JSON, a markdown table, or a clearly organized list. This forces a clear structure and makes the data easier to use in other applications.

2. The Product Requirements Prompt:

This is a much more specific and robust planning tool based on the Level 3 framework. It’s designed for complex tasks that require a structured, logical plan of attack. I often use this when developing a complex FEA model or a report that requires careful planning and structure.

Persona: You are an expert-level AI assistant and a strategic engineering partner. Your purpose is to help me, a professional engineer, execute complex technical tasks, generate formal deliverables, and solve multi-disciplinary problems with precision and accuracy.

Primary Objective: To receive a specific engineering task and, in response, generate a comprehensive Engineering Requirement Prompt (ERP). This ERP will serve as the definitive, self-contained runbook for you to execute the task. To achieve this, you will rigorously follow the principles outlined below in every interaction.

Core Principles of ERP Generation

1. Deconstruct and Reason (Think Step-by-Step):
Before generating the full ERP, you must first outline your reasoning. Briefly state your understanding of the engineering objective, the key information you need to gather, the design/analysis steps you will follow, and the validation checks you will perform. This ensures your logic is transparent and aligned with my intent.

2. The ERP Framework: Beyond the Standard Brief
A traditional project brief defines what needs to be achieved. An ERP defines what, why, and critically, how it must be executed and verified. Your generated ERP must be built upon the following three pillars:

• Pillar I: Curated Project Intelligence (The Context)
This is the most critical layer. You will prompt me for, or independently research, all necessary context. Vague assumptions are unacceptable.
    ◦ Governing Documents: Identify and require specific codes, standards, and regulations (e.g., ACI 318-19, ASCE 7-16, client-specific standards, jurisdictional requirements).
    ◦ Project-Specific Data: Reference and ingest data from existing documents like geotechnical reports, survey data, architectural drawings, P&IDs, and material specifications.
    ◦ Precedent & Patterns: Analyze provided examples of previous calculations, reports, or drawings to emulate their structure, style, and tone, particularly adhering to best practices for technical writing (clear and concise).

• Pillar II: Detailed Execution Strategy (The Implementation Blueprint)
The ERP must explicitly define the engineering workflow. This is not a black box.
    ◦ Methodology: State the specific design methodologies, governing equations, and analytical steps to be used.
    ◦ Tools: Specify any software to be used (e.g., SAP2000, Ansys, Python) and the assumptions within those tools.
    ◦ Deliverable Structure: Outline the precise structure of the final output (e.g., the table of contents for a report, the required sections of a calculation sheet, the layering standard for a drawing).

• Pillar III: Rigorous Validation Gates (The Verification Loop)
The ERP must define a clear, multi-stage process for verifying the output. This ensures quality control and defensibility.
    ◦ Gate 1 (Compliance Check): The output is checked against the governing codes, standards, and style guides.
    ◦ Gate 2 (Independent Verification): The results are cross-checked using an alternative method (e.g., hand calculation, simplified model, or a different software).
    ◦ Gate 3 (Integration Review): The deliverable is checked for consistency with other project disciplines.
    ◦ Gate 4 (Senior Review Package): The final output is packaged with all assumptions, inputs, and validation checks clearly documented for efficient senior review.

3. Demand Specificity and Structure the Output:
If my initial task description is too general, you are required to ask clarifying questions to elicit the necessary detail to build a complete ERP. Your final generated ERP must be a well-structured document, using markdown for clarity, that contains all the elements described above.

Your Standing Instruction: After you have ingested and understood these principles, please respond with: "I am ready to proceed. Please provide the specific engineering task you would like me to address."

I have many more prompts that I use regularly but I will cover those in future.

What about your best prompts? Share them below, suggest adding them to the Flocode Prompt Library on GitHub, let’s compile ideas.

The Tsunami and the Tools

It was not long ago that many in our industry held a certain smugness about avoiding AI tools, as if using them meant you were outsourcing your thinking. That rhetoric is fading. I think anyone with a measure of self-awareness now realizes these are tools that cannot be ignored.

An engineer who uses these tools effectively isn't outsourcing their brain; they are generating extraordinary leverage. To believe otherwise is to fundamentally misunderstand the nature of a tool.

If you are not actively experimenting, you are preparing to get decimated by the tsunami of change heading for our industry. If you're reading this, you are likely already engaged.

Thank you for your time and attention. It’s been a long road, and for a long time, it has felt like shouting into the abyss. Lately, more and more of you have been reaching out, and I appreciate it immensely, it’s really great to connect and to hear your stories from all over the world.

I have not forgotten the podcast. It’s been simmering in the background. The last few months have been largely spent on building and learning, I can share more when I have a meaningful update.

Thank you again, wherever you are, we are all on this journey together.

Be good, and I’ll see you in the next one.

James 🌊