DEV Community: Noah Miller

I Wasted Two Hours Prompting AI Before I Realized I Was Using the Wrong Tool

Noah Miller — Fri, 11 Sep 2026 02:34:17 +0000

A real account of how I kept generating the wrong mug, and what finally fixed it.

Yeah, It Was a Mug 🫖

My product photo problem was embarrassingly specific: a ceramic mug, matte white, sitting on my kitchen counter in front of a drying rack, a half-visible sponge, and what I can only describe as "ambient dish guilt."

Not exactly the clean lifestyle shot I needed for a product listing.

The mug itself was fine. Nice glaze. Good proportions. The kind of thing that photographs well if you ever get around to clearing the counter first. I hadn't.

So instead of doing the reasonable thing — which apparently is to move the sponge — I decided to let AI handle it.

The Prompt Spiral 🌀

I opened a text-to-image tool and described my mug.

"A white ceramic mug on a clean wooden table, warm morning light, minimalist, product photography."

What I got back was: a mug. Technically. A different mug. Different proportions, different handle shape, a slight sheen on it that looked more "stock photo prop" than "thing someone actually made."

Fine. I got more specific.

"Matte white ceramic mug, slightly irregular rim, handmade look, on a pale oak surface, soft diffused lighting."

Different mug again. Still wrong.

I tried adding brand descriptors. I tried "artisan." I tried "Scandinavian minimalist" and then "Japanese wabi-sabi" and at some point "not the sponge" which is not a real prompt and produced predictably chaotic results.

The problem wasn't my prompting. The problem was that I was describing a mug to a model that had never seen my mug. Every generation started from zero. Every prompt was me trying to reconstruct, in words, an object that was sitting twelve inches from my keyboard.

At some point I counted: fifteen generations. Maybe more. All of them fine. None of them mine.

Every One Was a Different Mug 🪤

It took me longer than I'd like to admit to name the actual issue.

Text-to-image tools are great at producing images from concepts. They are not great at producing your specific thing from a description, because your thing has specifics that language flattens. The curve of the handle. The weight of the glaze. The way the rim sits.

I was trying to re-create a visual from words, and that process has one unavoidable failure mode: it generates the average of all mugs, not this mug.

What I actually needed wasn't a new image. I needed to keep the image I had and change everything around it — the mood, the lighting, the scene — while keeping the mug exactly as it was.

The Actual Tool for This Job 💡

Image-to-image AI works differently. You upload your photo. The model uses it as a starting point — the subject, the composition, the specific shape of the thing you actually own. Then your prompt tells it what to change.

Not "generate a mug." More like: "same mug, warm café scene, golden hour light, lifestyle photography."

That's a fundamentally different instruction. The model isn't guessing what a mug looks like. It already knows, because you showed it.

I tried imgtoimgai.io, uploaded the original photo, and wrote: "cozy café table, warm morning light, lifestyle product shot, keep the mug."

The mug it returned was my mug. Same handle. Same rim. Same glaze. But now it was sitting on a worn wooden café table with soft golden light coming through a blurred window behind it. The drying rack was a distant memory.

I did not move the sponge. I did not do another fifteen generations.

Three Things It Actually Works For 🎯

Once I understood what the tool was doing, I used it for a few other things that had been sitting in my "too annoying to fix" pile.

Product shots with wrong vibes. You have a real photo of the thing — good. But it's sitting on a kitchen counter under fluorescent light and looks like a police evidence photo. Upload it, describe the scene and mood you actually want — a café table, a studio shelf, a sunset patio — and the model re-renders the whole atmosphere while keeping your specific product in frame.

Portraits in the wrong setting. I had a decent headshot taken in a parking garage. The face was fine. Everything else looked like a parking garage. Asked for a warm indoor portrait with soft natural light. Two minutes. Good enough for a speaker bio, which was the whole bar.

Sketches turned into reference images. I'd roughed out a layout for a product label — more of a diagram than a drawing. Uploaded it, described the finished style I was going for, and got something close enough to drop into a brief and show a designer. Not the final design. A useful, specific starting point instead of a vague description.

None of these outputs were perfect. That is not the point. The point is that the object in the output was recognizably the object in the input, which is the one thing that text-to-image genuinely cannot give you.

"Good Enough" Is the Actual Bar 🧭

My mug listing went up with a café-scene lifestyle photo. Nobody has mentioned the kitchen counter. A few people have mentioned the mug.

I probably spent forty-five minutes on the whole thing, including the fifteen generations I did before switching tools. If I'd started with image-to-image, it would have been ten.

I am not a designer. I do not know what most of the settings do. My version of "product photography" is "doesn't look like I took this next to a sink."

But that bar, it turns out, is meetable.

Try it at imgtoimgai.io — upload your photo, describe the change, get your thing back.

The 3 Mechanisms Behind Every AI Answer

Noah Miller — Thu, 03 Sep 2026 04:59:44 +0000

Let me start with a deceptively simple question:

Why can AI answer our questions at all? How does it "know" anything?

There are papers and textbooks that answer this in exhaustive technical detail — and most of them are genuinely hard to get through. But for the vast majority of developers and curious non-specialists, you only need to understand three mechanisms. Once these click, a lot of AI behavior that seems magical starts to make sense.

Mechanism 1: Parameters (Compressed Knowledge)

At the macro level, every large language model is essentially a mathematical model of human knowledge.

Here's how it works: the model takes all the text it's trained on and breaks it down into small units called tokens (roughly: words or word fragments). It then calculates the mathematical relationships between every pair of tokens. This process is called training.

Those relationships are encoded as parameters — the famous billions of numbers you see cited in model announcements. For example, GLM 5.3 has 744 billion parameters. Each one is a tiny weight that captures some aspect of how tokens relate to one another.

Training, in essence, is the process of finding those 744 billion weights — the ones that best represent the structure of human knowledge as seen in the training data.

Once training is done, when you ask the model a question, it uses those weights to find the most probable sequence of tokens to generate as a response.

The mental model to hold here: LLMs are a compression-and-generation engine. Human knowledge gets compressed into parameters during training, then decompressed into language when you query the model.

Mechanism 2: Reasoning (Derived Knowledge)

More parameters generally means better performance — more parameters mean finer-grained representations of more knowledge, which translates to more accurate outputs.

But there are two hard limits on just scaling parameters forever:

Cost. Training and inference costs scale fast. So does latency.
Redundancy. Not all knowledge needs to be memorized. A lot of it can be derived.

Consider a simple example: if a model knows a city's birth rate and death rate, it doesn't need to have the net population growth rate stored as a separate fact — it can calculate it on the fly.

This is the reasoning mechanism. Given the knowledge encoded in its parameters, the model applies logical rules to infer things it was never explicitly trained on. Modern "reasoning models" (o1, DeepSeek-R1, etc.) are largely an amplification of this mechanism — they're designed to spend more compute at inference time working through chains of logic before producing an answer.

Mechanism 3: Web Access (Retrieved Knowledge)

No matter how many parameters a model has, and no matter how strong its reasoning, there will always be questions it can't answer.

The classic example: "What was the closing price of the S&P 500 today?"

That fact wasn't in the training data. It can't be derived through logic. The model simply doesn't know — and it shouldn't pretend to.

This is where the third mechanism kicks in. Via agents or application frameworks, the model can reach out to the internet, query an API, or search a database to fetch what it doesn't know internally.

Tools like web search, code execution, and external API calls are all expressions of this mechanism. Rather than the model "knowing" everything, it knows how to find what it doesn't know.

Putting It Together

These three mechanisms form a layered system:

Mechanism	What it provides	When it's used
Parameters	Knowledge baked in during training	The baseline — always active
Reasoning	Inferences from existing knowledge	When the answer can be derived
Web Access	Real-time or external knowledge	When parameters + reasoning fall short

Most AI answers you get are a blend of all three. The model pulls from its parameters, reasons across them, and if equipped with tools, fetches what's missing.

Understanding this stack doesn't just satisfy curiosity — it changes how you prompt, how you architect AI features, and how you debug why a model gets something wrong. A hallucination is often a parameter problem (the training data was wrong or sparse). A stale answer is a web-access problem. A logical error is a reasoning problem. The diagnosis changes based on which mechanism failed.