Writing a prompt isn't engineering. It's typing.
You type what you want. The AI figures out the rest That's not a skill. that's having a conversat...
For further actions, you may consider blocking this person and/or reporting abuse
"AI can code" still means it produces (mostly) syntactically correct code that's good enough for a prototype / MVC. And if all the people telling me their code is 90% written by AI have to argue with AI begging for refinements, then it's still true that a senior can code more efficiently. Especially with the help of AI as a sidekick to look up documentation and finish boilerplate code and boring configurations.
Ingo senior can code more efficiently, especially with AI as a sidekick that's the real productivity story Not AI replaces seniors AI makes seniors faster. The sidekick model documentation lookup boilerplate boring configs that's where AI shines.
And your point about 90% AI code still needing refinement exactly. The 90% is cheap The 10% refinement is where the value (and the argument) lives.
Thanks for the grounded take. 🙌
Those who know how to talk and interact with the AI, knows what is a prompt. Well, the majority of them think of it as a magic or some kind of Alien Intelligence.
A prompt is a means to communicate your intent to the LLM. That's it. Period!
Ranjan Prompt is a means to communicate your intent That's it. Period Couldn't have said it better.
The magic isn't in the prompt The magic is in the intent knowing what you want, why you want it, and whether the answer is right. The prompt is just the messenger.
Thanks for the crisp take. 🙌
Thanks for introducing the blog post related to the Prompting. I suggest the readers to also take a deep dive at I Have Spent 500+ Hours Programming With AI. This Is what I learned
People keep arguing that prompting isn't a skill because it doesn't look like traditional skills.
Driving an automatic isn't manual transmission.
Digital snooker isn't table snooker.
Different interface. Different muscle memory. Different advantages.
That's why someone vibe-coding with AI can occasionally build what a senior developer spent years imagining. 🤣
I'm not a prompt engineer.
I'm a vibe engineer. 😂.
Maybe prompting isn’t a standalone skill, just a layer over thinking. 🤔
Ekong great analogies. But one difference: automatic drivers can still drive manual (badly) Digital snooker players can still hold a cue Vibe coders without AI? Many can't write a line.
Vibe Engineer love it. 😂 Thanks for the perspective. 🙌
I've never considered prompt engineering to be a real thing, tbh.
anyone who claims are they a " prompt engineer " or " prompt architect " ( you know what, just stamp the word engineer and architect behind everything and they'll think it's something sophisticated ) are just coping and adapting stupid market buzzwords.
Regarding the conversational usage part, I think it's important to distinguish it between " i dont know what the hell am i doing, so please code it write, i'm begging you " and an engineer who converses casually because he actually knows the trade-offs. I use Cursor extensively and most of the projects I do, the conversation is extremely casual because everything just depends my review and my manual edit. The AI’s acting as a fast feedback loop, a suggestion engine, and sometimes a thinking partner that helps surface alternatives faster than I would on my own.
on another note, i am also pretty far behind on AI, they're doing parallel agents, orchestration layers, fine-tuning pipelines, building local LLMs... and I'm here with a single agent like " could u pls not write it like this? it's already handled in the decorator " insert crap tons of pleading emojis 🥺🥺
Adam stamp the word engineer or architect behind everything and people think it's sophisticated exactly The buzzword inflation is real the distinction you're drawing is crucial casual conversation from ignorance vs casual conversation from knowing the trade-offs Same words completely different meaning.
AI as a fast feedback loop, a suggestion engine, a thinking partner this is the healthy relationship. Not AI does the work AI helps me think faster And the last line I'm here with a single agent like 'could u pls not write it like this? 😂 painfully relatable The gap between what's possible in AI research and what actually works for my daily workflow is enormous.
Thanks for the honesty and the laugh. 🙌
Yeah "prompt engineer" is just a hype/marketing-driven BS term - we're still "software engineers" or "developers", prompting is only one aspect of a vast array of skills ...
Main takeaway - the foundations of our profession are still the same, and are still of vital importance - AI is just a tool to arrive at a result quicker ...
P.S. what's with the missing periods between sentences? :-)
prompt engineer job is dead!
They should just stop using that term, unless it's for business users who are "vibe coding" apps - fine with me to call them "prompt engineers" ;-)
We should instead call it as "Dumb Engineers" as the whole thing about the AI doesn't make sense at all. There is ZERO intelligence and nobody knows how it internally works including the so-called creators of AI 🤣
Haha, "dumb engineers", I like that ...
Interesting (and true) that nobody really knows how LLMs produce their magic, they call it "emergent behavior" ... on the other hand, nobody understands how our own brains work either - it's just too complex!
Leob agree on all counts Prompt engineer is marketing The foundations haven't changed. AI is a tool, not a replacement for judgment.
Periods fixed Thanks for the catch and the thoughtful comment. 🙌
Interesting article! I agree with your core premise, but I think it helps to draw a line between conversational usage and actual systems engineering.
You made a great point that 'Prompting isn't the skill. Judgment is.' I couldn't agree more. But isn't it very similar with traditional coding? Knowing syntax without technical judgment leads to fragile systems, but having great judgment without knowing how to properly formulate the logic limits what you can build. It’s the combination of both that makes a great developer.
To me, natural language is just a new abstraction layer, much like Python was to C. When you're integrating an LLM into a production app, you still have to manage context windows, mitigate hallucinations, enforce strict formatting, and orchestrate tools. And how do you manage all this technical complexity under the hood? Through prompting (system prompts, semantic routers, etc.). Structuring these instructions and making them reliable and testable via evals is exactly what true 'Prompt Engineering' is."
I think the frustration you're highlighting comes from the buzzword abuse. Generating a script in ChatGPT is a bit like using Wix to build a website: it's incredibly useful and fast, but it's not engineering. However, that shouldn't take away from the very real technical discipline required to build complex, AI-driven systems under the hood.
You've articulated the nuance I should have included. Thank you Natural language is a new abstraction layer, like Python was to C. yes. The abstraction doesn't make the underlying engineering less real.
Prompting isn't the skill. Judgment is. Same with traditional coding. fair point. Syntax without judgment is useless. Judgment without syntax (or prompt structure) is also useless.
The distinction you're drawing between chatting with ChatGPT (low stakes, anyone can do it) and engineering production AI systems (context windows, hallucinations, structured outputs, evals) is exactly the line I blurred My frustration is with the buzzword abuse. The person who generates a script and calls themselves a prompt engineer is like someone who drags a Wix template and calls themselves a web developer.
But the person building reliable, testable, production-grade agent systems? That's real engineering. And yes, that requires structured prompting.
Thanks for the thoughtful pushback it made the conversation better. 🙌
Thanks! I completely understand your frustration with the buzzword abuse—it drives me crazy too. That’s actually why I'm actively trying to change this perception and show people what real, production-grade LLM engineering actually looks like.
Really enjoyed the exchange, thanks for being so open to the nuance!
Trying to change the perception and show what real production-grade LLM engineering looks like that's the work that matters. Not defending a title, just building good systems and letting the work speak.
Thanks for the thoughtful conversation, Quentin. 🙌
This is the cleanest framing of the AI/dev skill issue. The prompt is just the input layer. The real value is knowing what the model assumed, what needs testing, and when the answer is plausible but wrong.
Alex prompt is just the input layer that's it. The interface, not the engine the skill is everything underneath: assumptions, testing, judging plausible wrongness.
Thanks for the clean summary. 🙌
Exactly. The prompt can ask for a behavior, but the skill is where the behavior becomes repeatable: assumptions, tests, recovery paths, and when to stop.
That is the difference between a clever demo and something you can hand to an agent more than once.
Agree with this that at the end of the day if you don't understand the engineering fundamentals a perfect prompt is not going to help and you'll most likely dig yourself further into a hole. I do see that as we're shifting more from text prompts to workflows this part of understanding is becoming even more critical.
Mixture of Experts shift from text prompts to workflows this is the quiet evolution Prompts are linear. Workflows are systems. And systems require understanding architecture, state, failure modes, recovery paths the same fundamentals we've always needed Perfect prompt won't help if you don't understand engineering fundamentals Worse, it will help you dig the hole faster. Speed without direction is just faster chaos.
Thanks for adding the workflow angle that's where the real complexity (and real skill) lives. 🙌
I agree that judgment is the most important part, but I do not think prompting should be dismissed as “just typing.”
A casual builder’s prompt and a senior developer’s prompt can produce completely different results. A strong technical prompt requires careful requirement analysis, architectural context, clear constraints, edge-case awareness, acceptance criteria, and knowledge of the appropriate technology stack.
Senior developers usually receive better results because their prompts reflect years of engineering experience and better problem framing. Prompting does not replace software engineering, but professional prompting is a practical engineering skill built on top of technical judgment.
The prompt is the input method, but creating the right input is still part of the craft.
Austin fair pushback. Article went too far in one direction Senior's prompt produces different results yes Because it encodes engineering judgment. The prompt itself isn't the skill, but writing a good prompt reflects skill Professional prompting is an engineering skill built on technical judgment better framing. Skill isn't in typing. It's in thinking that shapes typing.
Prompt is input method, but creating right input is still craft agree Danger isn't calling prompting a skill It's calling any prompting engineering.
Thanks for the nuance. 🙌
Interesting perspective. I’d frame it slightly differently: prompting is easy to learn, but consistently getting valuable outcomes from AI isn’t.
The biggest difference I see between experienced engineers and everyone else isn’t who can write the cleverest prompt it’s who can spot hidden assumptions, evaluate trade-offs, and recognize when an answer is confidently wrong.
That’s why AI has made judgment more valuable, not less. Code generation is increasingly commoditized, but architecture, debugging, scalability, security, and long-term maintainability still require human experience.
We’ve seen this repeatedly at IT Path Solutions while working on AI-assisted development projects: the speed gains come from AI, but the success of the product still depends on the people making the engineering decisions behind it.
Prompts start the conversation. Judgment determines whether the result survives production.
Mateo prompting is easy to learn, but consistently getting valuable outcomes from AI isn't That's the distinction the article missed the biggest difference isn't who can write the cleverest prompt it's who can spot hidden assumptions, evaluate trade-offs, and recognize confidently wrong answers.
This is the line The prompt is visible. The judgment is invisible. And the invisible part is what separates reliable engineers from everyone else AI has made judgment more valuable, not less.
Yes. The commodity (code generation) gets cheaper The rare skill (knowing what good looks like) gets more valuable. Same pattern as every other automation wave.
Prompts start the conversation. Judgment determines whether the result survives production.
Perfect closing line. Thank you for this it's the most balanced comment in the thread. 🙌
Well can't blame though they are just going with the hype Anyway it's like you said it's not about the code it's about why that why even code and stuffs like that which current Ai really don't excel at
Ahmad it's not about the code, it's about the why that's the sentence I should have put in the title.
AI can generate the what It can't generate the why And the why the purpose, the trade-offs, the reason one solution is better than another that's the part that still needs a human.
Thanks for adding that. 🙌
completely agree, and I'm speaking as your neighbor who understands nothing about code😆, the difference isn't in the prompting but, as you rightly say, in the engineering skills. You guys can predict the errors, steer the AI however you like, know the bottlenecks in advance and be able to fully replace the AI to avoid future problems. Your friend (and me) can only test in production, watch a run maybe for days and then have to start all over again. Don't worry, your job is and will stay essential, even more so with the new AI tools you'll have available, 4 ragtag hobbyists like me will never be able to compete
Translated by Claude
Cartone most humble, honest comment here You predict errors, steer AI, know bottlenecks, replace AI to avoid problems that's the skill. Not the prompt Seeing around corners Your friend (and me) can only test in production we learned the same way Years ago, we were also testing in production, watching runs, starting over.
And ragtag hobbyists build the most interesting things.
Thanks for this grounding. 🙌
This lands hard, and I think it names the problem better than most “AI coding” debates do.
The prompt is not the skill. The prompt is just the input surface.
The real skill is knowing what the system is supposed to preserve, what assumptions the model quietly made, and whether the output still belongs inside the actual repo you’re working in.
That’s the part I think gets lost when people talk about “prompt engineering.” The model can produce code. It can produce a lot of code. But it does not automatically know the repo’s contracts, which layer owns which behavior, what the tests are actually proving, or whether a change moved a boundary without saying so.
That is where judgment still matters.
And honestly, it is where AI-assisted development gets dangerous if teams treat generation as the hard part. Generation is the easy part now. Verification is the hard part. Diagnosis is the hard part. Knowing whether the patch preserved the system’s truth is the hard part.
I’ve been working in this exact space lately: deterministic diagnostics before repair. Not asking the AI to “fix everything,” but first asking: what does the repo currently believe, where did that belief stop matching the code, and what repair lane is actually safe?
The interesting thing I’m seeing in field tests is that when Codex is given that kind of bounded diagnostic context, the repair behavior changes. It stops wandering as much. The patch gets smaller. The validation target gets clearer. The work becomes less about prompting harder and more about giving the agent a verified repair lane.
So yes — I agree completely. The future is not “better prompts replace engineering.” The future is developers using AI while still owning judgment, verification, architecture, and failure boundaries.
Typing is not engineering. Knowing what must remain true is.
Scarab Systems this is the most important comment in the thread. Thank you for writing it the prompt is not the skill. The prompt is just the input surface that's the framing I was reaching for but couldn't land on. The prompt is the interface. The skill is everything behind it Generation is the easy part now. Verification is the hard part. Diagnosis is the hard part.
This is the shift. We're optimizing for generation speed when the real bottleneck has already moved to verification. The industry is solving the wrong problem Not asking the AI to fix everything first asking: what does the repo currently believe, where did that belief stop matching the code, and what repair lane is actually safe? This is the methodology. Diagnose before you repair. Understand the system's belief before you change it. That's not prompt engineering that's engineering engineering.
The future is not 'better prompts replace engineering.' The future is developers using AI while still owning judgment, verification, architecture, and failure boundaries this is the sentence that should be pinned at the top of every AI coding discussion.
Typing is not engineering. Knowing what must remain true is.
Line of the year.
Thank you for this it's going to stick with me. 🙌
for new generation of coders that have never written code code all by themselves and vibecode majority of times, what woulld you suggesst them inorder to prompt well, think like an engineer and build something meaningful despite not having much experience of building and system design without ai?
Keshav this is the most important question in the thread. Thank you for asking it. 🙏
Here's what I'd suggest:
Build something without AI first. Even something tiny. A to-do list. A calculator. A weather app. The goal isn't the output it's the struggle. You need to know what hard feels like before AI can make it easier.
When you use AI, ask why after every line. Why did it choose this approach? What assumptions is it making? What could go wrong? Don't just accept the code interrogate it.
Break the problem yourself before you prompt. Write down the steps in plain English. Draw a diagram. Think about edge cases. Then prompt. The AI will fill in the syntax but the structure should be yours.
Learn to read code more than you write code. Read open source projects Read your own AI-generated code closely. Reading teaches you patterns, trade-offs, and what good looks like.
Remember: AI is a tool, not a teacher. It can show you the answer It can't teach you why the answer is right. That still requires practice, failure, and reflection.
The fact that you're asking this question means you're already ahead. Keep going. 🙌
Totally agree. Prompting is a design skill: framing the goal, constraints, and evaluation. It's about thinking through failures, not just typing a sentence. Teach prompt literacy, not glorified copy-paste.
Yunetzi Teach prompt literacy, not glorified copy-paste That's the line Prompting as design skill framing, constraints, evaluation Thinking through failures not just typing sentences.
This should be on a poster in every coding bootcamp.
Thanks for the perfect summary. 🙌
The framing conflates two things. Nobody serious in the industry thinks typing a sentence into ChatGPT is engineering. The actual work people call prompt engineering is system prompt design for agentic pipelines, where token efficiency, tool-calling reliability, and context window management directly affect production cost and latency. Thats closer to API contract design than casual conversation. The term is overloaded yeah but the underlying work is real.
You're right. And this is the nuance the article blurred the person who writes write a function in ChatGPT and calls themselves a prompt engineer? That's the problem The person designing system prompts for agentic pipelines managing token efficiency tool-calling reliability context windows production cost latency? That's real work. That's closer to API contract design than casual conversation.
The term is overloaded. That's the issue. A single phrase covers both:
Someone prompting ChatGPT (low stakes, anyone can do it)
Someone engineering production-grade agent systems (real skill, real impact)
Thanks for the clarification this makes the conversation more precise. 🙌
Not every "conversation" with AI will result in a product. You need to give the suggestions in a such a way that it will give the product that you intent. I can give it a prompt and the agent will say, "Oh that's not allowed" but the same thing when tweaked and given by my manager will result in a different product, why is that?
Aneesha that's the key question Why does the same intent produce different results from different people?
Because the AI isn't reading your mind. It's reading your words And your manager knows which words work not because they're a prompt engineer but because they understand how to translate intent into instructions the AI can follow The AI didn't say not allowed to you because it's biased. It said it because your prompt missed a framing or a constraint that your manager knew to include that's the skill. Not prompting. Knowing how to frame the request so the AI understands what's actually allowed, what's at stake, what "good" looks like.
Same intent. Different framing. Different result.
Thanks for asking this is exactly why the conversation matters. 🙌
I agree, and my own prompts are the proof 🙂I type them as plainly as your dinner-party friend would - no clever phrasing, no techniques. But the prompt is just one small piece of the workflow.
IMO, the real skill - picking the right tools, fitting the approach to the task, knowing what to verify and how - needs constant upkeep, because the ground shifts every few months. Not much different from software development itself, where the learning never stops.
Over the past couple of years I've gone through plenty of AI tools, models and approaches; right now I've settled on a two-agent workflow - one builds, another reviews, both against a carefully prepared spec. What it'll look like tomorrow - we'll see.
Michael my own prompts are the proof this is the most honest answer in the thread Plain language. No clever techniques. The prompt is just one piece The real skill needs constant upkeep, because the ground shifts every few months This is the part people miss. Not learn prompting once and done. The tools change. The models change. The workflows change. The skill is adapting, not memorizing.
Two-agent workflow one builds, one reviews, both against a carefully prepared spec This is the practical pattern. Not "prompt better." Design the system so review is built in, spec is the source of truth, and the agents have clear boundaries.What it'll look like tomorrow we'll see.
Honest closing. No one knows. The skill isn't predicting the future it's adapting when it arrives.
Thanks for sharing the real workflow. 🙌
Interesting perspective. I think the article highlights an important distinction: prompting is an interface, not the core skill. The real value comes from judgment—understanding requirements, spotting hidden assumptions, evaluating trade-offs, and knowing when an AI-generated answer is wrong. AI has lowered the barrier to generating output, but it hasn't removed the need for critical thinking and engineering experience. In many ways, AI is making expertise more valuable, not less, because someone still has to validate and own the result.
AI is making expertise more valuable, not less that's the counterintuitive truth that most people miss Lower barrier to output ≠ lower value of judgment. If anything, more output means more need for validation Someone still has to validate and own the result.
That's the job. Not generating Owning The prompt is the input The judgment is the work.
Thanks for the thoughtful comment. 🙌
Welcome bro! ❤️
The framing I keep using in practice: the prompt is the cheapest part of the pipeline.
In a payments system, the hard problems aren't what to type. They're what state transitions should be impossible, which retry logic uses a specific backoff because of how banks behave at 2am, which edge cases will silently move real money if wrong. None of that surfaces in the prompt. It comes from someone who's been burned by the absence of those guards.
The prompt is the delivery mechanism. The judgment about what to ask for — and when to reject a confident answer — that's the skill. And it only comes from years of operating systems under real consequences.
arun the prompt is the cheapest part of the pipeline That's the line Payments example is perfect. The prompt doesn't know about banks at 2am. The prompt doesn't know about silent money-moving edge cases. The prompt doesn't know about state transitions that must be impossible None of that surfaces in the prompt. It comes from someone who's been burned by the absence of those guards. This is the truth the article was circling. The skill isn't in the prompt. The skill is in the scars knowing what to guard against because you've felt the cost of not guarding.
Years of operating systems under real consequences No prompt template can replace that. No prompt engineering course can teach that.
Thank you for the perfect real-world example. This is the most valuable comment in the thread. 🙌
The distinction between "typing a prompt" and actual engineering skill is sharp, but I think it misses one thing — prompts are interface design in disguise.
When you write a prompt for an AI, you're making decisions about: what context matters, what constraints apply, how to handle ambiguity, when to escalate to a human. Those are the same decisions an experienced engineer makes when writing a spec. The difference is the medium.
The real problem is that "being good at prompts" looks like a soft skill, so companies undervalue it. They don't see the reasoning underneath.
What's your take on distinguishing prompt fluency from actual systems thinking?
Mote prompts are interface design in disguise that's the nuance the article needed You're right. Writing a good prompt isn't just typing. It's making decisions about context, constraints, ambiguity, escalation. Same decisions as writing a spec. Different medium Being good at prompts looks like a soft skill, so companies undervalue it. This is the real problem. The visible output is a sentence The invisible work the reasoning underneath is engineering. But it doesn't look like engineering, so it doesn't get treated like engineering.
Distinguishing prompt fluency from systems thinking Prompt fluency is knowing which words work. Systems thinking is knowing why those words work understanding the underlying architecture, trade-offs, failure modes, and being able to build without the prompt when needed.
Fluency without thinking is just pattern matching Thinking without fluency is slow but still valuable The best is both.
Thanks for the question this made the conversation richer. 🙌
Judgment needs a prerequisite the post skips: a definition of "right" that exists before you see the answer. Without it, "is this correct?" degrades into "does this look plausible and run?", which is the same failure you're describing one level up. And fluency at prompting erodes exactly this, because the AI is good enough that you can skip writing the criteria down and still get something that works often enough to feel fine. The skill under the skill is specification: making the trade-offs and constraints explicit enough that judgment has something concrete to check against. That part was the job before LLMs, and it's more of the job now, not less.
Theo this is the most important comment in the thread. Thank you A definition of 'right' that exists before you see the answer Yes Without that, judgment becomes does this look right? which is exactly the problem. The AI can make anything look right. The definition the spec, the criteria, the constraints that's what makes judgment possible Prompting fluency erodes this you skip writing criteria down and still get something that works often enough to feel fine This is the quiet danger The AI is good enough that you don't feel the missing spec. You get plausible output, you ship it, and you never notice that you didn't define what right meant.
The skill under the skill is specification This is the line. Not prompt engineering Not judgment. Specification making trade-offs and constraints explicit before the answer exists That was the job before LLMs, and it's more of the job now, not less The tools changed. The hard part didn't. Specification is harder now, because you have to write it for both humans and AI to read.
Thank you for this it's the most valuable comment in the thread. 💎
This is the kind of uncomfortable truth that gets whispered in slack channels but rarely said out loud. You're right: the gap between "typing what you want" and "knowing what to ask for" is the whole career.
Two things I'd add from watching this play out on teams:
The "prompt engineer" title is dangerous not because it's wrong, but because it's static. A prompt you wrote last month is probably stale. But judgment accumulates. The skill isn't in the prompt — it's in knowing when to update the prompt because the system or the data shifted. That's not a prompt skill; it's a monitoring habit dressed up as engineering.
The empty list assumption example is perfect. But the scarier version is when the AI makes the right assumption for 99% of cases and the 1% edge case quietly breaks months later. That's not a logic error — it's a scope error. Only experience knows to ask "what does 'empty' mean in this domain?" (Empty list of users? Of permissions? Of audit logs? Each fails differently.)
One small suggestion: your non‑technical friend analogy lands hard, but it implies that anyone can do the workflow. They can. What they can't do is the repair. Maybe the skill isn't prompting or even judgment — it's debugging under pressure. That's what the AI can't fake, because it's never been paged at 3 AM by a customer who's losing money.
And because your friend's question earned it:
Anyway, this post should be printed and pinned next to every "Prompt Engineering Certification" ad. Thanks for writing it.
This comment is the whole article just better. Thank you The gap between typing what you want' and knowing what to ask for' is the whole career Not a course. Not a certification. A career The prompt engineer title is dangerous because it's static. Judgment accumulates The prompt doesn't remember last month's outage The prompt doesn't learn from the edge case that broke at 2 AM. You do The scarier version 99% works, 1% breaks months later. Not a logic error a scope error This is the diagnosis I was missing. The code wasn't wrong. The scope was wrong The AI didn't know what empty meant in this domain because no one told it.
Maybe the skill isn't prompting or even judgment it's debugging under pressure Reframe. Judgment knows what's wrong. Debugging under pressure fixes it when the customer is losing money. AI can't fake being paged at 3 AM I know when it's lying because I've been lied to by better systems before The scars. The experience. The history of being burned. That's not prompt engineering. That's career engineering.
Thank you for this it's the best comment I've received. 💎
The distinction between "prompting" and "judgment" is the most important line in this piece. I'd add one layer: the best way I've found to develop judgment is to build the same thing twice — once with AI, once manually. The second pass is where you catch everything the AI assumed quietly, and that gap is where real learning lives.
The danger isn't that prompting isn't a skill. It's that it feels like one, because AI gives you fast, plausible output. Feeling productive and being productive have never been more decoupled.
Pizza Cat build the same thing twice once with AI, once manually this is the most practical advice in the thread The second pass is where you catch everything the AI assumed quietly. That gap is where real learning lives. Not the first pass. The second pass. After you know what the AI built, you rebuild it yourself That's where you feel the assumptions. That's where the learning happens.
Feeling productive and being productive have never been more decoupled This is the line. Speed feels like productivity. Output volume feels like progress. But the real productivity is understanding and that's invisible.
Thank you for this actionable, honest, and perfectly said. 🙌
Strongly agree with the distinction between prompting and judgment. A prompt can start the work, but the real skill is knowing the system, constraints, failure modes, and what “done” means. Without that, AI just makes uncertainty look polished.
Manuel AI makes uncertainty look polished that's the quiet danger Not AI is wrong. Just uncertainty dressed up in clean syntax.
Thanks for the perfect closing line. 🙌
The distinction between "prompting" and "judgment" is the most important line in this piece. I'd add one layer: the best way I've found to develop judgment is to build the same thing twice — once with AI, once manually. The second pass is where you catch everything the AI assumed quietly, and that gap is where real learning lives.
The danger isn't that prompting isn't a skill. It's that it feels like one, because AI gives you fast, plausible output. Feeling productive and being productive have never been more decoupled.
Pizza Cat build same thing twice once with AI, once manually most practical advice here First pass: what AI can do. Second pass: what you actually understand. Gap learning AI quietly assumes. You won't notice until you rebuild.
Feeling productive and being productive have never been more decoupled the line.
Thanks. 🙌
I agree. Prompting helps you get output faster, but the real value comes from knowing what to trust, what to challenge, and what could break later. AI can generate answers, but judgment is still what turns those answers into reliable solutions.
Alfred judgment turns answers into reliable solutions that's the line Prompting gets you output. Judgment gets you trust Two different things.
Thanks for the perfect summary. 🙌
Personally, I don't think that prompt makes the agent code better. It just like you instruct a child what to do, if you instruct them clearly, they will understand what to do but less mistake than you let them do without any instruction. So, prompt is not important as everyone think that is.
Alexoy like instructing a child simple analogy that works Clear instructions help. But the child still needs to understand the task, the tools, the context. Same with AI The prompt isn't magic. It's just clarity. The real skill what to instruct, what to assume what to check afterward still comes from experience.
Thanks for the grounded take. 🙌
the part about 'what the AI assumed' is where i'd push this further — what matters more than the prompt is what you put around it. the teams i've seen get consistent output aren't writing better prompts, they're engineering the context: which constraints to surface, which prior decisions to reference, what the model should and shouldn't see. that decision is invisible in the prompt itself. it's the judgment call that happens before the prompt. in agentic setups, the model makes that decision autonomously. so the real question: do you trust what the agent chose to include in its own context?
Mudassir this is the next level. Thank you for pushing it further What matters more than the prompt is what you put around it Yes. The prompt is visible. The context engineering constraints, prior decisions, what the model should and shouldn't see is invisible. And that's where the real skill lives The judgment call that happens before the prompt.
This is the line. The decision isn't in the prompt. It's in the preparation for the prompt. What do I surface? What do I hide? What prior decision does the model need to know?In agentic setups, the model makes that decision autonomously. Do you trust what the agent chose to include in its own context?
This is the question. Not can the agent decide? can you trust what it decided to look at?
You've shifted the conversation from prompt engineering to context governance That's a different discipline entirely.
Thank you for this it's the most forward-looking comment in the thread. 🙌
💯 agree. Another thing is that AI still lacks contextual knowledge and nuances, which needs domain specific knowledge and this thing is sth that AI can't replace.
Tanay contextual knowledge and nuances AI can't replace that Exactly The prompt can ask the right question. But understanding why it's the right question that comes from domain experience. From knowing the business, the users, the unspoken constraints.
AI can generate. It can't know.
Thanks for adding this. 🙌
I have over a decade experience in coding/infra but nowadays I don't write code anymore. I know how to use the proper words in a prompt but can you say the same thing from a vibe coder?
cim you've named the real difference You know which words work because you've spent a decade learning what matters. The vibe coder doesn't. They're guessing. You're translating experience into prompts Same output? Maybe. Same understanding? Not even close.
That's why prompt engineer as a standalone title is hollow. The prompt is just the delivery mechanism. The expertise is what you bring to it.
Thanks for the honest take. 🙌
What title would you give to someone like me?
Totally agree with you. 💯
Thanks Abhijeet appreciate the support. 🙌
Great take. Would you say that ‘prompting’ is more like UI design for LLMs rather than a standalone skill? Because good UI also feels obvious in hindsight but designing it still needs expertise.
Urmia UI design for LLMs brilliant reframe Good UI looks obvious after the fact Designing it takes expertise Same with prompting Anyone can type write a function Crafting prompts that handle edge cases and produce reliable output? That's design.
The problem isn't that prompting takes no skill. It's that we call any prompt engineering.
Thanks for this. 🙌
Exactly DEV exists for learning, not for outsourcing thinking.
AI can suggest AI can assist But if you're here just to copy-paste without understanding, you're missing the point.
Thanks for reading and for being part of the community that actually wants to learn. 🙌
Most developers aren't choosing AI because they trust it. They're using it because speed is the metric that gets measured. The judgment still happens just on the backend, catching what the AI broke.
Iman speed is the metric that gets measured that's the root cause Not developers trust AI Not AI is good enough. Just: the dashboard shows velocity It doesn't show debugging hours. It doesn't show the quiet debt accumulating.
Judgment still happens just on the backend, catching what the AI broke Same work, shifted later The judgment didn't disappear. It just moved from before ship to after ship. That's not efficiency that's deferral.
Thanks for naming the metric problem. This is the real conversation. 🙌