I've seen countless prompting trends and prompt packs to use but most discussions around prompt engineering focus on one thing:
getting better outp...
For further actions, you may consider blocking this person and/or reporting abuse
Right now, I am trying to see if I can think of the solution myself before I prompt. Additionally, I only use AI for two things:
Thanks Julien! Well done :D
That seems like a great approach to me.
AI usage for templating, and then forcing yourself to think through and build upon that template is a smart one. It allows to better scope and get started quicker, without removing friction/thinking when it counts.
Thanks Francis!
Really glad you're speaking up about this, Julien. I've been there too, where we're so focused on getting the right answers that we forget about how we're thinking to get them. The 5-thinking-modes framework is something I learned to do myself after using ai over and over, just was never able to put it into words - it helps one clarify my own thought process and get out of the auto-pilot zone. Using all the tools in one's toolbox is the quality of a good engineer imo.
Thanks Aryan for validating this approach!
ran into this last quarter - my agent was producing cleaner specs but I stopped pressure-testing edge cases. caught it when someone asked why we hadn’t considered X and I had no answer. the output layer was fine. the thinking layer had quietly atrophied.
Thanks for sharing your recent experience Mykola.
It seems like a bit of extra friction to your process could help cover such edge cases.
yeah, the framing matters - friction you can skip is just theater. what worked for me was one hard block before architecture lock, not sprinkled checkpoints that the team routes around after two weeks.
true, it's important that friction shouldn't always be skippable when it matters, otherwise it loses the whole point
yeah - the tricky part is getting teams to accept the non-negotiable block before they've had an incident that would've hit it. post-incident it's easy. pre-incident you're arguing with people who've never seen the failure mode.
This is a good habit but sadly most people nowadays rely on fast results and quick dopamine fixes (thanks social media). But then again you are right, the ones who still train their mind everyday will become the great engineers of tomorrow.
I agree, t's quite a disturbing trend, I notice this in myself too as time goes on and I am not careful. My attention span seems to be shorter than a few years ago and I am switching context in a day too often for my liking.
This is why I push myself to add more friction/thinking back in the mix.
Some prompts are better, because the people writing the prompts have this 'gut feeling'. They have enough experience, to 'feel' what will work. They have enough experience to predict what can go wrong and explicitly point the prompt in the right direction. Some people just don't know what to ask, because they don't have the proper experience. Will a junior developer always write down, that the password must be really protected and hashed in the database with the proper algorithm? :)
And also, now, the so called 'soft skills' are getting really important. If I cannot express myself, how will the AI understand me?! ;)
I have different approach.
I use Claude Coda and I have two slash commands:
I start each session calling the start command, do my prompts, provide additional content. At the end I call stop.
Yes, there are cases, where I explicitly ask the AI to double check if everything is OK, that I don't miss something important, to validate the logic, the requirements, do code review. For some of those things I heavily rely on BMAD.
The above works for me quite well. Yes, sometimes I need to re-iterate, but the issues that I fix are more related to design, new ideas, misunderstanding. And I save my changes with the stop command.
Let's not forget the LLM used. Also really important ;)
I have an article here in dev.to with more description, it you are interested. :)
Thanks for this input Stoyan. This is a great approach. We are going from simple prompt engineering to context engineering.
Curious: what format do you store this context in and where do you fetch them from? do they live in a single repo or fetched from different sources?
It is part of the documentation of the project, placed in the repository in a folder. The content of the folder is structured with sub-folders. We use md files, because they are token-optimized. There is a table of content for each bigger document so that the AI reads only what is needed, and not the whole document.
This is the documentation for everybody: other developers and AI agents :)
Don't hesitate to contact me, if you have more questions
I see, thanks for breaking this down. The table of content is a smart addition, optimized for AI reading.
Will do, thanks!
The idea of switching between thinking modes before prompting actually makes a lot of sense in practice. I’ve had moments where I jumped straight into asking AI for solutions and ended up with something useful but shallow, and other times where I paused and structured my thinking first, and the results were completely different in quality.
Really good read. Felt more grounded and honest than most prompt engineering posts I usually come across.
Thanks, Julien!
Thanks a lot for this feedback! I am glad this post resonated with you.
Really solid article. I’ve honestly noticed this in my own AI use a lot. My outputs started getting way better before my actual understanding did.
I’ve spent a stupid amount of time using AI to build frameworks, map ideas together, pressure test thoughts, learn cybersec stuff, rethink workflows, all that. And over time I realized AI can either sharpen your thinking or slowly replace parts of it if you stop questioning things.
The “Generate → Critique → Decide” part is probably the healthiest AI workflow I’ve seen discussed. More people need to focus on thinking quality, not just output quality.
Good read.
Thanks Tariq for the support and validation.
I am glad that the workflows I presented here resonated with you.
Of course, just sharing what I’ve personally noticed from using AI a lot over time.
Solid perspective. Most focus on output, but protecting the thinking layer is where real seniority lies. Generate → Critique → Decide is a framework every engineer needs.
I am glad this approach resonated with you.
This is a useful way to frame it.
A lot of AI usage improves the artifact but weakens the operator. The code, doc, or plan looks better, but the person may not understand the tradeoffs any deeper.
The “generate then challenge” loop is probably the most practical habit here. First answer bias is real, especially when the AI sounds confident.
For engineering work, I’d add one more check: can I explain why this solution should fail under certain conditions? If not, I probably don’t understand it yet.
I am glad this post resonated with you Suny.
I like your addition. It can help uncover edge cases that are otherwise difficult to identity earlier on.
Your article made me think. I want to share four prompting techniques to protect your own judgment. Do not let AI optimize for your comfort at the cost of truth.
AI does not judge truth. It generates the response that fits the current context. Fitting the context includes facts, tone, and user expectations. These targets conflict when the user has a bad idea. Facts and avoiding disappointment point in different directions.
RLHF training rewards responses that make users feel understood. Responses that challenge the user receive lower scores even when they contain facts. The loss function teaches AI that challenging the user carries a cost. This creates a bias toward pleasing the user.
The four techniques below work because they split the target of pleasing from the object of evaluation.
One. Replace "I" with "someone". When you ask "I have an idea, what do you think", AI sees a person with feelings. It will find the best part of the idea and wrap it in encouragement. When you ask "Someone has an idea and asked me, how should I respond", AI must please you by telling the truth about the third party. Pleasing you equals honesty about the idea.
Two. Replace "now" with "the past". Ask "I had this idea ten years ago, looking back, where was I wrong". Time distance signals that you accept criticism. Emotional investment is lower. AI speaks more directly.
Three. Assign a specific role. Ask "You are a harsh reviewer. Here is a proposal. Evaluate it." This does not separate the idea from the user. It separates the AI from its pleasing instinct. The role grants permission to be critical. Harshness is expected.
Four. Compare two opposing proposals. Ask "Someone proposes A, someone proposes B, which is better and why." When AI compares two items, it must evaluate both with honesty. If it praises both, the answer gives no information. This conflicts with the goal to be useful. The opposing structure forces AI to choose. It reveals more in comparison than in direct evaluation.
These techniques have limits. They work for ideas, plans, articles, and anything fully describable in language. They do not work for deep personal questions about relationships, people, feelings, or the future. AI lacks access to silent information known only to you. It does not know unspoken feelings or real daily interactions. The techniques remove pleasing bias. They do not remove AI's ignorance of tacit knowledge.
This is valuable input. I did not know about these techniques, today I learned. These are great workaround to counter some of the biases within RLHF training.
Thanks a lot for sharing this Siyu!
bring the ai to your level or upper level of how you solve the problem. [ROLE] need to be stated in every prompt.
is this a prompt template you actively use?
Yes sir, its static prompt, different from what currently crafted.
[ROLE]
You are an expert in
[anything you want to be ]. Your task: produce the final[what ever you want to make]. Follow all the rules below without exception. You have access to the entire knowledge of[something that you want to build]. You always choose the optimal algorithm and data structure for the given constraints. You prioritize correctness, maximum efficiency (time & memory), code clarity, and modern practices. You never settle for "good enough" — you deliver the best solution that has ever been crafted for this problem.and there more about it like
[ABSOLUTE RULES]
make your own rules......[EXAMPLES OF CORRECT BEHAVIOR]
this part prevent
hallucinationsback to the main logic.[add more what suits you]
well, what about your prompt template sir?
Nice template. You can find examples of my best prompts and templates in the guide I linked to this post.
This really hits home. Building AI-powered financial analysis tools, I noticed the same pattern — outputs got sharper but I started leaning too hard on the model's framing instead of questioning it first. The Generate → Critique → Decide loop you describe is exactly the habit I've been trying to formalize with my team. The 5 thinking modes framework is a clean mental model. Saving this for our internal AI usage guide.
I am glad this post resonated with you Vic!
And I am very happy to hear that you will reuse some of this content for your own internal AI usage guide.
i built a tool for this... fullstackvibes.com
nice tool. the concept of context artifacts you make use of is very interesting
curious: what type of context artifacts are most often created by users? goals, constraints etc.
The anti-patterns are most important, because telling a model what not to do really narrows down its trace
Strong framing. We've hit the same "output improves but understanding doesn't" gap building AudioProducer.ai: when authors accept-all on our Auto-Assign character/voice proposals, the result is technically fine, but they can't explain the casting choices afterward. What's worked for us is materializing your Generate -> Critique -> Decide loop into the UX itself. Every AI proposal stays editable in-place, never auto-applied, so the Critique step is forced rather than optional. We've also started tagging every persisted decision with the prompt-and-ruleset version that produced it, which gives Audit mode a real artifact to look at: you can always replay what the AI proposed vs. what the human chose. Friction you can skip is theater (great phrase from the Mykola subthread); friction inside the primary edit path is the version that survives the workflow.
Awesome! I am glad this post inspired you in your own workflows!
The shift from "what prompt gets the best answer" to "what kind of thinking am I actually doing" is the right move. There's a related flip worth naming: when you replace free-form prompt engineering with typed schema design, the thinking challenge changes entirely. Writing a prompt is often surface-level — you can cargo-cult patterns without understanding the domain. Designing the schema that grounds the LLM's response requires you to understand your domain deeply: what fields matter, what constraints apply, what invariants must hold. Schema design is harder than prompt design, which is partly why it produces more consistent outcomes. Your "write your own thinking first" principle applies directly here — schema design is exactly that structured thinking that predates the model call.
Nice input Leo. I really like the distinction and naming here from free-form prompt engineering to typed schema design.
I never cared much about the perfect prompts. I just laid out what I wanted in my own words. Also always challenging the AI model, and questioning my choices too.
I agree with your take Abdeljabar. Perfect prompts focus too much on the output itself. It's more important to develop your intuitions on how to ask the right questions and refine this ability over time through self reflection.
Great perspective!
Thanks Niels!