I did two short prompting courses and honestly took almost nothing from them. The people I know who are genuinely good at this are not the ones who studied it, they are the ones using models for hours every day. Makes me wonder if there is any transferable method here or if it is just reps and taste. Did a course or a framework ever actually move the needle for you, or was it all just time on the tools?

Someone posted recently that they'd accepted the 175k Amex Platinum offer and regretted it right away because of the $895 fee. Commenters walked them through it and they landed on four credits they'd actually use, streaming, Resy, lululemon and Walmart+, which comes to about $1,155 a year. That works as long as they hit 32 separate deadlines, because those credits reset monthly or quarterly and never roll over, and missing two Resy quarters and one lululemon quarter eats the whole $260 cushion.

That's a reminders problem more than a math problem, so I wrote a prompt for it. The model looks the credits up itself with web search, because issuers change them all the time and whatever is in the training data is probably a refresh behind. It has to sort each credit into use, maybe or ignore based on stuff you already pay for, otherwise it happily tells you to buy lululemon leggings every quarter to "save" $75. And the output is an .ics file, so the reminders land in your real calendar instead of a chat you'll never open again.

You need web search on and a model that can make files, ChatGPT and Claude both do.

I want a calendar of every statement credit on my credit cards so I stop letting them expire. Use web search to look up each card's current credits on the issuer's website: the amount, how often it resets (monthly, quarterly, twice a year, yearly or by card anniversary), whether it needs enrollment, and what counts as a qualifying purchase. Tell me if any of that changed in the last 6 months.
My cards: [card name], [card name].
Today's date: [date].
Things I already pay for anyway: [streaming services, rides, delivery, gym, restaurants I go to, stores I shop at, trips planned in the next 12 months].
Credits I've already used this period: [credit and amount, or none].
Sort every credit into one of three groups. Use: it covers something on my "already pay for" list, name what. Maybe: I'd only use it by spending money I wouldn't spend otherwise. Ignore: everything else. Don't talk me into new spending just to hit a credit.
Output:
1. A table sorted by the next deadline: card, credit, amount this window, deadline, use / maybe / ignore, what I'd spend it on. Put "enroll first" next to any credit that needs enrollment.
2. One line per card: the yearly total of my "use" credits next to the annual fee.
3. An .ics calendar file with a reminder 7 days before every "use" deadline for the next 12 months. Event title = card, credit and amount.
Nothing else. No new card recommendations.

Curious if anyone has a cleaner way to get reminders out of a chat than .ics tbh

(I work on finerd, a money tracker that shows days left on each card credit, so this is kind of the manual version of a screen we built.)

This is my go-to wrapper for any task where a wrong answer is expensive. Paste as a system or lead instruction. Prompt: You are solving a task where being confidently wrong is worse than saying you are unsure. Step 1, restate the task in your own words and list what you were given and what you must produce. Step 2, solve it. Step 3, before answering, assume your step 2 answer is wrong and try to find the single most likely error. Step 4, if you found a real error, fix it and note what changed. Step 5, give the final answer, then one line rating your confidence low, medium, or high, and name the one assumption that would break it if false. End prompt. The confidence line and the named assumption are what make it useful, it surfaces the almost-right failures before I ship them.

1. Text and formatting

<badge>
<bold>
<caption>
<code>
<italic>
<label>
<math>
<strikethrough>
<text>
<title>
<underline>

2. Layout and containers

<box>
<card>
<col>
<divider>
<flow>
<flow-item>
<grid>
<grid-item>
<row>
<spacer>

3. Lists, tables, and navigation

<blockquote>
<list>
<list-item>
<table>
<table-section>
<table-row>
<table-cell>
<carousel>
<carousel-item>
<carousel-media-item>
<popover>
<popover-trigger>
<popover-content>
<pressable>

4. Inputs and interactive controls

<button>
<checkbox>
<date-picker>
<form>
<input>
<radio-group>
<radio>
<segmented-control>
<select>
<slider>
<textarea>

5. Images, media, and visualizations

<icon>
<favicon>
<svg>
<AsyncImage>
<AsyncImageGroup>
<AsyncVideo>
<Chart>
<MapWidgetV2>

6. Data, citations, and links

<Cite>
<CodeCite>
<Entity>
<FileCite>
<FileNavList>
<FollowUp>
<MemoryCite>
<Link>

7. Content editors and embedded apps

<AppBlock>
<CodeBlock>
<WritingBlock>

8. Control flow and special syntax

{...}
{@body ...}
{@module ...}
{#if ...}
{:else}
{:else if ...}
{/if}
{#each ...}
{/each}
<escape>
<></>

Try experimenting in a new chat to see how it works! :D

TLDR: Creating complex knowledge graphs with code or markdown is prompt engineering sending a single message to a chat bot is good communication. Good example repo : https://github.com/RinDig/GPTmetrics

I've seen quite a lot of posts talking about prompt engineering, but no one's seeming to address this elephant in the room.

There's two types of prompt engineering.

One is just good communication, the other is actually engineering.

I've been writing and creating code in the NLP space for a bit. For my master's thesis, I created a data pipeline that used hundreds of lines of prompts and Python to route prompts to many different models at the same time at scale. It's rudimentary but it's a really good learning point and I linked to the repo at the top and bottom if you want to check it out—at least the original Python notebook. I turned it into a proper platform later on.

However, enough about me, let me get to the point.

There's the "prompt engineering" where people tell you how to write a prompt to a chatbot and "structure prompts", and while this could be useful and in no way am I saying that you shouldn't practice that. I wouldn't hesitate to call this a long-term engineering skill.

As for actual prompt engineering (could call it harness or context engineering) where you're writing hundreds of lines of code paired with prompts being injected at certain points or markdown structures across knowledge graphs.

I'm not explaining this difference because I don't like the first one. In fact, I'm really happy that people are learning good structure, I think that's important. That being said, I think it is important to know the levels of abstraction here.

If you want to get an understanding of what prompt engineering at the engineering level looks like but don't want to get into a complicated codebase. Here is a basic python notebook repo I made for my students (and a project on psychometric scales I mentioned earlier). ) that if you click on the python notebook "survey_agregator" can show you some basic "prompt engineering" (even I hesitate to call it that anyway) in python:

https://github.com/RinDig/GPTmetrics

Now as for the second thing about knowledge graphs.

This type of "prompt engineering" has also been called context or harness engineering. t's handling series of knowledge graphs and folder structures that uses very little code, but perhaps the actual prompts themselves are calling code.

Here is a repo I made that works as meta engineering knowledge graphs and uses folder structure as agentic architecture. (Paper in readme) :

https://github.com/RinDig/icm-architect

Now, the ability to communicate well is also a skill, which is the first type of prompt engineering, but the second type of prompt engineering, which is everything up there that I just showed, is technically just programming, but at a higher abstraction.

I hope this helps. I made a comment on someone else's post similar to this one and decided just to turn it into a whole post, so I hope this helps people get a better understanding! Happy learning.

I’ve been experimenting with how focal length instructions affect AI-generated portraits. One issue I’ve noticed is that simply adding “shot on an 85mm lens” doesn’t always produce the expected result. AI models often interpret lens specifications loosely.

So I tried a more controlled approach: keeping the same subject, outfit, location, camera (Sony A7 IV), and aperture (f/5.6), while changing the focal length and camera-to-subject distance.

Here are the six prompt variations I tested:

• 18mm — Ultra Wide: 18mm ultra-wide-angle lens, close camera distance, exaggerated foreground proportions, strong perspective expansion, distant background appears smaller
• 24mm — Wide Angle: 24mm wide-angle lens, relatively close shooting distance, dynamic environmental portrait, visible surroundings, moderate perspective expansion
• 35mm — Environmental Portrait: 35mm prime lens, moderate shooting distance, balanced subject and background, natural environmental perspective
• 50mm — Standard Lens: 50mm prime lens, natural portrait framing, balanced subject proportions, moderate shooting distance
• 85mm — Portrait Telephoto: 85mm portrait lens, longer shooting distance, flatter facial perspective, distant background elements appear larger relative to the subject
• 135mm — Telephoto: 135mm telephoto lens, distant camera position, strong background compression, flattened perspective, large distant architectural elements

The important part isn’t just the focal length.

Perspective is determined by camera position. If you want to keep the subject approximately the same size in the frame, you need to move closer with wider lenses and farther away with longer lenses.

For more consistent results, I also add this instruction: Keep the same subject, outfit, pose, location, lighting, camera model, and aperture. Maintain approximately the same subject size by adjusting camera-to-subject distance. Do not simulate focal length changes by simply cropping or changing background blur.

This doesn’t guarantee physically accurate lens simulation, but it gives the model more specific visual constraints than just naming a focal length.

Something I underrated for a long time: the output format you demand shapes how the model thinks, not just how it presents. When I ask for free prose I get mushy reasoning. When I demand a specific structure, say a table with columns for claim, evidence, and confidence, the model is forced to actually separate those things and the quality of the underlying reasoning goes up. The format is a thinking scaffold, not just formatting. If a model is being sloppy about distinguishing fact from guess, do not lecture it, give it a format that has separate slots for fact and guess and it has to fill them. Structure the output and you structure the thought.

I've been taking Karpathy's "prompts are programs" idea literally on a few client builds, and treating prompts like production code changed how I work. Every prompt lives in git with a version tag. Each one has a small eval set of 20–50 real inputs with expected outputs that runs before any change ships. Changes get reviewed like PRs, with a diff of the eval results rather than just the prompt text. I also log outputs to catch drift when the model provider updates something, and I can roll back to the last good version in one step.

The eval part is where I'm least sure. LLM-as-judge works okay for format, but it's shaky for nuance. Curious how others handle this: do you keep prompts in code or in a prompt-management tool, and what does your eval setup actually look like?

Piwora helps people discover useful resources, curate collections, and find similar websites and tools. It’s built for people who want to save their favorite finds, organize them into collections, and discover more through other people’s picks. What do you think about the idea? Would you find curated collections and similar resource suggestions useful? https://www.piwora.com/

For complex tasks, jumping straight to output gives me a confident mess. This forces a plan first. Copy-paste: Before producing any output, write a short plan: what is the goal, what are the constraints I must respect, what are the steps in order, and what is the one thing most likely to go wrong here. If the plan reveals the task is underspecified, do not output the final answer, instead ask me the single most important clarifying question. If the plan is solid, proceed: execute the steps and produce the final output, then confirm in one line that each stated constraint was met. Task: [paste]. End prompt. The clarifying-question escape hatch is the part that saves me, it stops the model from confidently building the wrong thing on a vague request.