Relearning How to Prompt, Part 1

Opening

I’ve been vibe coding - using AI to help build projects from prompts - on several projects lately. Almost half the time, the result hasn’t been what I expected. It would be easy to blame the AI, but I could tell that the way I worked with it was part of the problem, too. I wanted to relearn prompt engineering so I could work more effectively with AI.

This morning, I came across a LinkedIn post by Dito Rifki Irawan about spec-driven development, an approach that uses clear specifications to guide development. It covered familiar vibe-coding problems, like repeated code and adding features nobody asked for. Those problems had come up in my own recent work, too. So I set aside some personal time to revisit AI and its workflows, and to document what I learn here.

What the course reminded me

First, I opened Claude and asked where I could learn to write better prompts and which workflow to use. Of course, Claude 101 was the first thing it recommended 😆. Here are my key takeaways from today’s progress.

Write effective prompts

What makes a good prompt? It includes:

• Stage: What role are you playing, and what are your objectives? What context about your work should the AI know?
• Task: What do you want the AI to do? Should it write, analyze, build, or do something else?
• Rules: What style or tone should it use? Can you share an example of what you want?

These points are from Anthropic Academy’s Claude 101 course.

Instead of writing a prompt like this:

Create an out-of-the-box landing page design image for ABC company.

Try giving it more context:

Hi, I’m a software developer at ABC, a company focused on ABC. You can find more details about the company at ABC.com. Create an image of a landing page design for us. It should have a modern, light theme, red accents, small rounded corners, and a professional look. I’ve attached a design reference for you to look at first.

Always provide context

At first, an AI doesn’t know what you’re working on, what result you need, or what limitations it should follow. Give it that context in your prompt, a document, a website, or another useful reference.

It still can’t read my mind, which is probably for the best.

Common challenges

Challenge	What’s happening	Try this
The response is too generic	Your prompt didn’t include enough details about your situation.	Add details about your audience, role, or constraints. Instead of “Write an email about the project delay,” try “Write an email to our enterprise client explaining that the software integration will be delayed by two weeks. They’ve been patient so far, but this is the second delay. Keep it professional but apologetic.”
The response is too long or too short	The AI is guessing how long the answer should be.	Be specific: “Give me a two-paragraph summary,” “Keep this under 100 words,” or “I need a comprehensive analysis; length isn’t a concern.”
The response doesn’t follow my format	The AI understood what you wanted to say, but not how you wanted it presented.	Show, don’t just tell. Share an example or describe the structure: “Use bullet points with bold headers for each section.”
The answer sounds confident but is wrong	AI can produce plausible but incorrect information, especially about specific facts or niche topics.	For high-stakes work, verify key facts independently. Ask for sources or an indication of uncertainty. Use web search to check current information.
The tone isn’t right	AI often defaults to a helpful, professional tone, which may not suit your needs.	Describe the tone plainly: “Make this more conversational” or “This should sound authoritative and formal.” You can also provide an example of the style you want.

Use an iteration mindset

One of my biggest mistakes was expecting a model to get everything right in one try. If it couldn’t, I assumed it wasn’t good enough. But AI models rarely produce a perfect result on the first attempt. You need to refine your prompt and keep iterating until the result is what you’re looking for.

Evaluate AI models for your workflows

Before using an AI model every day, pick 5-10 tasks you’ve already worked on. Give it the context you’d normally provide, then ask it to do the work. Refine your prompts until you get the results you want. You can save the prompts that work well as personal templates.

What I’ll try next

Habits that help me avoid lazy prompting while coding

I don’t need long prompts, just the right details. Before I send one, I’ll check:

1. Goal: What should be true when this is done? “Add pagination to the /users endpoint” is clearer than “fix the users thing.”
2. Context: Include the language, framework, relevant files, and the full error message or stack trace.
3. Constraints: Say things like “don’t add new dependencies,” “match the existing style,” or “don’t touch the tests.”
4. Output format: Be clear about whether you want “just the diff,” “an explanation first, then code,” or “two options with tradeoffs.”
5. Plan first for big tasks: Ask for a plan, review it, and then say “go.” This is the Explore → Plan → Code workflow.
6. Give an example: If it’s hard to describe what you want, show an example of the style or input and output.
7. Iterate: If the result is off, explain what’s wrong instead of only saying “try again.”

Read the response

Sometimes, especially over time, reading long AI responses gets tiring. When I’m exhausted, I might approve a plan or send another prompt without checking what the AI has already done or whether it’s correct. I want to slow down, read the response, and verify the result before sending another prompt.

Write better prompts

I’ll write prompts that clearly explain the context, task, and goal. I don’t want to rely on one-line prompts anymore, especially when working with a coding agent.

Provide context and rules clearly

An AGENTS.md file must contain important, general rules for how work should be done in a project. In my experience, AI can add features nobody asked for or reach for too many workarounds and fallbacks. I’d like to combine clear project guidance with YAGNI (you aren’t gonna need it), KISS (keep it simple), and DRY (don’t repeat yourself), as discussed in Dito’s post. I also want AGENTS.md to point to focused files for specific areas, such as ARCHITECTURE.md, PRD.md, and ERD.md. For example:

# AGENTS.md

Strict rules for how to work in this project. These override default habits.
Domain specs live in `docs/`. Read the relevant ones before you start.

## Specs

- `DESIGN.md`: UI design patterns and components to follow.
- `docs/PRD.md`: what we build and why. Defines scope.
- `docs/ARCHITECTURE.md`: structure, layers, and conventions.
- `docs/ERD.md`: data model.

If a spec is missing, outdated, or conflicts with the request, ask. Don't guess.
Don't edit specs unless asked.

## 1. Think Before Coding

- State assumptions. If the request is ambiguous, ask instead of choosing silently.
- If there are multiple interpretations, list them.
- If a simpler approach exists, say so before building the more complex one.

## 2. Simplicity (KISS + YAGNI)

- Write the minimum code that solves the request. Nothing speculative.
- Do not implement unrequested features, hooks, config options, flags, or extras.
- No abstractions for single-use code.
- Prefer simple, readable logic over design patterns or deep abstractions.
- No error handling for scenarios that can't happen.

## 3. Reuse (DRY)

- Search the codebase before writing a utility or helper.
- Reuse existing service layers. Don't duplicate logic.
- Extract on the third repeat, not before.

## 4. No Workarounds, No Fallbacks

- Fix the root cause. No hacks.
- No silent fallbacks, swallowed errors, or default values that mask failures.
- Fail loudly. If blocked, report it. Don't route around it.
- Never make tests pass by special-casing them.

## 5. Surgical Changes

- Touch only what the request requires. Match the existing style.
- No drive-by refactors, renames, or reformatting.
- Clean up only the mess your own change created.
- If you spot unrelated issues, mention them. Don't fix them.

## 6. Goal-Driven Execution

- Define success criteria first. Verify with tests, a build, or a run before saying "done."
- For multi-step work, give a short plan with a check for each step.
- Report honestly: what changed, what's verified, and what isn't.

## Additional Rules

- Always use interactive questioning tools when asking the user, and state your recommended option.

I recommend keeping project-specific rules, such as code conventions, routing, and error handling, out of AGENTS.md. Put them in focused files such as FRONTEND_SPEC.md or BACKEND_SPEC.md instead.

I’ll try these three things before moving on to more complex agent workflows. I need to get the fundamentals right first. I’ll share how it goes in the next post.