I mostly agree with your framing, but I think you’re underselling something important: prompt engineering is architecture—just at the human↔model boundary. Yes, it exposes ambiguity, but designing constraints, interfaces, and failure modes at that boundary is real engineering work. We don’t dismiss API design because it’s “just middleware.” The fact that it looks like text doesn’t make it less structural.
Great point—prompt engineering is architectural work at the human–model boundary, shaping constraints, interfaces, and failure modes much like API design does. Treating it as “just text” misses how much system behavior and reliability are determined by that layer.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I mostly agree with your framing, but I think you’re underselling something important: prompt engineering is architecture—just at the human↔model boundary. Yes, it exposes ambiguity, but designing constraints, interfaces, and failure modes at that boundary is real engineering work. We don’t dismiss API design because it’s “just middleware.” The fact that it looks like text doesn’t make it less structural.
Great point—prompt engineering is architectural work at the human–model boundary, shaping constraints, interfaces, and failure modes much like API design does. Treating it as “just text” misses how much system behavior and reliability are determined by that layer.