[alexc05]

I'll admit that it's a little shoehorned in at the end :)

... but you know how editors are with writing the headline for clicks against the wishes of the journalist writing the article. You'll always see Journos sayign stuff like "don't blame me, that's my editor, I don't write the headlines"

I did toy with the idea of going with something like: `Prompt Engineering is a wrapper around Attention.`

But my editor overruled me *FOR THE CLICKS!!!*

Full disclosure: I'm also the editor

[drfrankensearch]

There’s a repeated paragraph in it atm you may want to fix:

“This is why prompt structure matters so much. The model isn’t reading your words like you do — it’s calculating relationships between all of them simultaneously. Where you place information, how you group concepts, and what comes first or last all influence which relationships get stronger weights. This is why prompt structure matters so much. The model isn’t reading your words like you do — it’s calculating relationships between all of them simultaneously”

Reprimand the editor. ;)

I look forward to using the ideas in this, but would be much more excited if you could benchmark these concepts somehow, and provide regular updates about how to optimize.

[alexc05]

thank you so much!!

Because medium is such a squirrely interface I find myself writing in markdown in vscode then copying and pasting sections across. If I make an edit after I've stared inserting images and embedding the gists it gets a bit manual.

Your comment in addition to another one about finding a way to compare the outputs of the good/bad prompts side by side - 100% agree. This could be more robust.

While I am running a process transformation against production teams in small isolated experimental groups, I can say I'm getting really great feedback so far.

Both with the proprietary stuff happening in the job, and with the feedback I'm getting back from the engineers I've shared this with in the wider industry.

Feedback from colleages who have started taking "selected pieces" from the "vibe engineering" flow (https://alexchesser.medium.com/vibe-engineering-a-field-manu...) has been really positive.

> @Alex Chesser i've started using some of your approach, in particular having the agent write out a plan of stacked diffs, and then having separate processes to actually write the diffs, and it's a marked improvement to my workflow. Usually the agent gets wonky after the context window fills up, and having the written plan of self contained diffs helps a lot with 'checkpoints' so I can just restart at any time! Thanks!

from someone else:

> I just went through your first two prompts and I'm blown away. I haven't done much vibe coding yet as I've gotten initial poor results and don't trust the agent to do what I want. But the output for the architecture and the prompts are mind blowing. This tutorial is giving me the confidence to experiment more.

benchmarking feedback vs. qualitative devex feedback is definitely a thing though.

editor's note: title also chosen for the clicks.

[Gerardo1]

"The key difference isn’t the words — it’s how you structure the thinking process. By breaking down the task into numbered steps as we see in option B, you’re leveraging how transformer attention works: structured, sequential instructions create clearer context that guides the model’s reasoning."

Can you support that assertion in a more rigorous way than "when I do that I seem to get better results?"

[kstenerud]

TBH I almost passed this article by because of the big-o reference - it seemed like such a strange thing to say.

I'm glad I didn't, though, because I had no idea how the LLM is actually interpreting my commands, and have been frustrated as a result.

Maybe a title like "How to write LLM prompts with the greatest impact", or "Why your LLM is misinterpreting what you say", or something along those lines.