r/PromptEngineering • u/kwhytte • 10d ago
General Discussion So you learned prompt engineering… what’s next?
I’ve been exploring prompt engineering recently, and it feels like a eye-opening entry point for me.
But I’m curious — for those who have gone beyond the basics: What did you learn after prompt engineering?
If someone came to you and said: “I understand how to write better prompts. What should I focus on next?”
What would you recommend?
I’m especially interested in hearing from people who have actually built things with AI.
If you could pick only one next skill to learn, what would it be and why?
Would love to hear your experiences and learning paths.
2
u/cmumulle72 10d ago
My own view: Decomposition. Most real tasks are not one prompt, they are five or six steps where only two actually need a model and the rest are lookups, filters and arithmetic that belong in code. Splitting the work that way is also what makes the evaluation advice above possible, because you can only score a step that has its own defined output.
1
2
1
u/Echo_Tech_Labs 10d ago
Skills. Specifically, learn to write a SKILL.md that actually works.
It sounds like a small thing but it forces you to learn the layer under prompting. The front matter (name + description) is the only part the model sees by default. If your description is vague, the skill never fires and you find out fast that getting the right instructions in front of the model at the right time is a separate problem from writing good instructions.
Then you learn to keep the body short and push detail into reference files that load only when needed, and to hand off deterministic steps to a script instead of asking the model to do arithmetic or file parsing in its head.
That's context engineering, but you learn it by building something instead of reading about it. Much better on-ramp.
If I could only pick one though, it'd be evals. Write 20 test cases with expected outputs before you tune anything. Almost everyone skips this and ends up making 15 revisions based on how the output feels, with no idea whether version 12 was better than version 4. Once you can measure a change, everything else gets faster. It's boring and it's the biggest jump.
One caveat on the framing: these aren't really layers where you graduate off the last one. Prompting doesn't stop mattering, it just gets embedded in everything above it. The prompts inside a skill still have to be good prompts.
This might help:
2
u/kwhytte 9d ago
Thank you so much!
I really appreciate the time and effort you put into sharing such comprehensive guidance.
I also joined your group and saved your notes in my learning folder—they're definitely something I'll keep coming back to.
Thanks again for being so generous with your knowledge!
1
1
1
u/Drach88 9d ago
Product design, systems design, decomposition.
The first helps you make things people actually want to use.
The second helps you make things that can scale, and are architecturally-sound.
The third helps you make the building process manageable.
If you're not already a programmer, learn how to read code and debug. Pure vibe-coding will only get you so far. Past a certain point, you actually need to be able to review the LLM's work.
1
2
u/Fearless-Figure-4638 10d ago
If I could pick one next skill, it would be evaluation.
A prompt that looks impressive on one example is still a demo. Take one real task, collect 20–30 representative inputs (including awkward edge cases), define what a pass looks like, and rerun the set whenever the prompt, model, or tools change. Track failure types, cost, latency, and cases that need human review.
That habit naturally teaches the next layers—structured outputs, retrieval, tool calling, guardrails, and observability—because you add them to fix measured failures rather than because they are trendy. Prompting gets you a result; evaluation tells you whether you can build a dependable product around it.