“Prompt engineering” landed in the discourse around 2022 and immediately attracted skepticism. It sounded like people were claiming expertise in typing. The criticism was that it was a temporary workaround until models got smart enough to understand vague instructions.

That criticism was partially right. Models have improved significantly at handling natural language. You no longer need to carefully format every prompt. But the core insight - that the quality of your specification determines the quality of the output - has not become less true. It has become more consequential.

What Prompting Actually Is

Prompting is specification. The model will produce something. What it produces is bounded by how clearly you can describe what you want.

This is not new. Software engineering has always been about specification. A ticket with a vague description produces vague implementation. A spec with missing edge cases produces code that misses those cases. A PR description that doesn’t explain the why produces reviews that focus on the wrong things.

What AI tools have done is make the specification-to-output cycle instant and interactive. You can write a bad specification, see a bad result, understand why it failed, and improve the specification. The feedback loop that used to span hours or days now spans seconds.

This accelerates learning about what good specification looks like - but only if you’re paying attention to the feedback.

The Two Failure Modes

Developers get bad results from AI tools in two consistent ways.

Underspecification: “write a function that handles user authentication.” The model will produce something - it will be generic, it will make assumptions, it will not know about your session management approach or your existing middleware or the specific JWT claims your system uses. The output is plausible and wrong in context-specific ways.

Wrong level of abstraction: asking the model to implement a specific approach when what you need is a solution to a problem. “Implement this using a singleton cache” might get you a correct singleton cache that solves the wrong problem. “I need to cache user preferences with a TTL of 15 minutes, avoiding duplicate database reads across concurrent requests in a multi-threaded Node.js process” gives the model the actual problem.

Both failure modes share a root: the developer hasn’t specified what they need precisely enough to distinguish the right answer from a plausible wrong answer.

What Good Specification Looks Like

The components of a prompt that consistently produce good results:

Context about the environment: what language, what framework, what version, what architectural patterns are in use. This is the difference between generic correct code and code that fits your codebase.

The problem, not just the task: “I need to cache user preferences” is a problem. “Write a cache class” is a task. Problems give the model the information to make tradeoffs. Tasks constrain it to an approach you may not have fully thought through.

Edge cases and constraints: what happens on failure? What are the performance requirements? What inputs are possible? These don’t all need to be in every prompt, but the ones that determine correctness need to be there.

Examples of desired input/output: not always necessary, but often clarifying. A concrete example is worth many sentences of description.

What to avoid: when you know you don’t want a particular approach, saying so is faster than discovering the model chose it and iterating away from it.

// Less effective
"Write a function to validate emails"

// More effective
"Write a TypeScript function to validate email format for user registration.
Should return { valid: boolean, error?: string }.
Needs to handle: basic format validation, rejecting disposable email domains
(use a lookup against provided blocklist), allow subdomains.
Do not use external libraries - standard regex is fine.
We're on Node.js 20, TypeScript strict mode."

The second version is longer. It produces code that needs substantially less revision.

Prompting as Iterative Refinement

The instinct is to try to get the right answer in one prompt. This is the wrong mental model for complex problems.

Effective prompting for non-trivial work is iterative:

1. Start with the core problem
2. Get an initial output
3. Identify what’s wrong or missing
4. Refine the specification and iterate

The iteration step is where prompting skill shows. Understanding why the output was wrong requires understanding the problem well enough to see the gap between what you specified and what you meant. This is a form of specification debugging.

Developers who are good at this can turn a rough problem into a good solution in 3-4 iterations. Developers who aren’t spend many iterations going sideways because they can’t diagnose why the output is wrong.

Specification, Review, and Ownership

The prompting skill connects directly to the rest of the engineering workflow in ways that aren’t obvious at first.

When you write a precise specification for an AI tool, you’re doing the same work that would have gone into a well-written ticket or PR description. If you can specify it precisely enough for the model, you can specify it precisely enough for a colleague - or for yourself six months later. Developers who get good at prompting tend to get better at tickets and specs too, because the habit of precision transfers.

Review is where the specification shows its value. A function you specified fully - inputs, outputs, error behavior, edge cases - has clear criteria for correctness. Reviewing the generated code means checking it against the spec, not just reading it and deciding if it “looks right.” Code that was vaguely prompted and vaguely accepted is code that nobody has actually verified.

Ownership is the downstream consequence. A prompt that was a clear specification produces code you understand and can defend. A vague prompt that produced plausible-looking code produces code you’re now responsible for but didn’t actually design. The difference is visible the first time something breaks: one developer debugs from a mental model they own, the other reads their own codebase as a stranger.

Writing Testable Prompts

The discipline of making prompts testable - including concrete input/output assertions in the specification - does two things at once: it forces you to think through the behavior, and it gives you criteria to evaluate the output.

"Write a TypeScript function `parseCSVLine(line: string): string[]` that:
- Splits on commas
- Handles quoted fields (fields wrapped in double quotes may contain commas)
- Returns ['a', 'b c', 'd'] for input: 'a,"b c",d'
- Returns ['one', 'two', ''] for input: 'one,two,'  (trailing empty field)
- Throws on unclosed quotes"

The examples are not decoration. They are the spec. They tell you whether the output is correct. If the model produces something that fails one of the examples, you haven’t reached a good specification yet - either the function is wrong, or your examples are inconsistent, and either way you’ve learned something.

This is closer to test-driven development than to “prompting tricks.” The specification and the acceptance criteria are the same document.

The Broader Skill

The reason prompting will remain a core skill - even as models improve - is that the underlying competency is specification, not syntax. Models will get better at inferring what you mean from incomplete specifications. They will not get better at knowing what you actually need, because that knowledge lives in your head and in your codebase, not in training data.

The developer who can translate a vague requirement into a precise specification - not just for AI tools, but for tickets, for PRs, for API design - is more effective in every part of the job. AI tools have made this skill immediately visible in its impact. They haven’t changed what the skill is.

The developers who will use AI tools most effectively in five years will be the ones who developed the habit of specifying clearly now, when the feedback loop is fast enough to learn from quickly.