2025-05-02

There’s a lot of hype around prompt engineering. There are books, bullshit courses, and even people branding themselves as “prompt engineers” like it’s some established discipline. And sure, crafting good prompts is important—but let me be real with you: I don’t think prompt engineering is truly engineering yet.

Here’s why.

Think about the early days of computing. Back then, programming wasn’t a standalone field. The first programmers were electrical engineers, because they had to be. There were no programming languages, no compilers, no modern abstractions. To get anything done, you had to know how the hardware actually worked. You weren’t just writing instructions—you were building the foundation those instructions would run on.

That’s where I see us right now with prompt engineering.

We’re in the early phase. The tools are new, the concepts are still forming, and most of what works today is based on intuition, experimentation, and a lot of trial and error. You can’t just read a few prompt guides and expect to master it. Not if you want to do anything beyond surface-level tasks.

The truth is, good prompting often requires knowing what’s going on under the hood. What kind of model are you talking to? How was it trained? What kind of data did it see? How does it handle tokens, context windows, or reasoning tasks? These things aren’t optional—they shape how your prompt performs.

And once you get into domain-specific tasks—like writing legal documents, helping with medical data, or generating code—it becomes even clearer: prompting alone isn’t enough. You need to understand both the model and the domain you’re applying it to. The bindings between task, model behavior, estimated outcomes and so on. You need to understand the task better than the language model does—at a fundamental level. Without that deep understanding, all you’re doing is stacking shaky buildings on top of a guessing machine. The model might be right, or it might be not, but let me ask you this: how do you know that for sure?

No doubt, one day we might have cleaner abstractions, better tooling, and established methods—just like how computer science eventually split off from electrical engineering. Maybe prompt engineering will get there too. But right now? We’re still building the foundation.

So no, I don’t buy into the idea that someone can become a “master prompt engineer” just by studying prompt patterns or flipping through guides. There’s still too much depth involved. We’ve got a long way to go, so hype it down a bit if you still think prompt engineering is real engineering.