Prompting as a Coding Skill

When people say “prompt engineering,” it often sounds like a dark art. In coding practice, prompting is simpler and more useful: it is how you specify work to a collaborator that cannot see your screen, your deadlines, or your unspoken conventions — unless you say so.

This post treats prompting as a core concept for using AI in software projects.

Prompts Are Specs With Gaps

A vague prompt:

Fix the login page.

A better prompt:

On /login, the submit button stays disabled after a failed attempt. We use React 19 and store the error in local state. Keep the existing design tokens. Propose a minimal fix and a regression test.

The second version encodes scope, stack, constraints, and definition of done. That is the same information you would give a teammate in a good ticket. AI does not invent missing product context; it fills gaps with averages from training data.

Four Layers of a Strong Coding Prompt

1. Goal

What should be true when you are done? Prefer observable outcomes over implementation guesses.

2. Context

Relevant files, APIs, error messages, versions, and architectural rules (“we do not call the DB from client components”).

3. Constraints

Performance budgets, accessibility, no new dependencies, match existing patterns, keep the public API stable.

4. Output shape

Do you want a plan, a patch, a diff against a file, unit tests, or an explanation of trade-offs? Asking for the wrong shape wastes cycles.

You do not need a template every time, but scanning these four layers before you hit send prevents most bad generations.

Techniques That Actually Matter for Code

Ask for a plan first

For non-trivial work, request steps and file touch list before code. You can reject a bad plan in thirty seconds; a bad 400-line rewrite costs an hour.

Provide counterexamples

Tell the model what not to do: “Do not introduce Redux,” “Do not rename the public props,” “Avoid any.” Negative constraints cut down on common over-engineering.

Iterate with evidence

When something fails, paste the error, the failing test, or the stack trace. A debugging prompt without evidence invites confident guessing.

Prefer diffs over rewrites

Ask to modify a specific function or add a helper next to existing code. Full-file rewrites often “fix” style issues by rewriting everything and introducing unrelated changes.

Prompting Across the Development Lifecycle

| Phase | Prompt focus | | --- | --- | | Design | Alternatives, risks, interface sketches | | Implementation | Small slices, existing patterns, types | | Review | Security, edge cases, readability | | Docs | Audience, accuracy against code, examples |

The same model can help in each phase, but the prompt genre changes. Mixing them — “design and rewrite the whole module” — usually produces mediocre results in both.

Common Failure Modes

Hallucinated APIs. The model invents a method that looks right. Fix: verify against docs or types; paste real signatures into the prompt.

Silent scope creep. You asked for a bugfix and got a new abstraction layer. Fix: “minimal change only; no new files unless necessary.”

Context drowning. Dumping the entire repo into chat confuses priorities. Fix: include the smallest set of files that define the problem.

False confidence. Fluent prose around wrong code. Fix: require tests or a short reasoning trail you can check.

Building a Personal Prompt Library

Over time, collect short snippets you reuse:

Your project’s architecture one-pager
Coding standards (naming, error handling, logging)
“How we write tests here”
Security checklist for auth-related changes

Paste or attach these as standing context. That is how prompting scales from one chat to a team practice without becoming bureaucracy.

Closing Thought

Prompting for code is not about secret magic words. It is clear specification, relevant context, tight constraints, and deliberate output shape — the same skills that make you good at writing tickets and mentoring juniors. Strengthen those, and AI becomes dramatically more useful in every project you touch.