Prompt Improvement Techniques: A Practical Lesson
Level: Beginner to Intermediate
Estimated time: 30–45 minutes
Goal: Learn how to write better prompts, improve AI responses iteratively, and use AI more effectively for coding, learning, research, and building projects.
1. The Fundamental Principle
The biggest improvement you can make to your prompts is to stop asking AI for an answer and start specifying the outcome you want.
Think of prompting like programming. A vague prompt is like passing incomplete arguments to a function. A clear prompt defines the inputs, constraints, and expected output.
For example:
Weak prompt:
Teach me Ruby.
Improved prompt:
Act as an experienced Ruby engineer and mentor. I know basic Ruby, but I want to improve my debugging skills for entry-level software engineering interviews. Teach me through realistic examples, let me attempt solutions before showing the answers, and give me feedback on my reasoning.
The second prompt defines the goal, context, teaching method, and expected interaction.
Key principle: More words do not automatically produce better results. Relevant information matters more than length.
2. The Six Ingredients of a Strong Prompt
2.1 Goal
What are you trying to accomplish?
Weak:
Make my app better.
Better:
Improve the onboarding experience so new users can complete their first workout log with less friction.
2.2 Context
Give AI the information it needs to understand your situation.
Example:
This is an existing Ruby on Rails application. It already has authentication, workout models, and a dashboard. I want to improve the onboarding flow without rebuilding existing functionality.
2.3 Constraints
Explain what AI should and should not do.
Example:
Preserve existing routes and database behavior. Avoid adding dependencies unless necessary. Do not refactor unrelated files.
2.4 Process
Specify how AI should approach the task.
Example:
Inspect the current implementation, identify the root cause of the problem, propose the smallest reasonable change, and implement it only after explaining the approach.
2.5 Output Format
Define what a useful response should contain.
Example:
Return the diagnosis, proposed fix, files affected, relevant tests, and any remaining risks.
2.6 Success Criteria
Explain how you will judge whether the result is good.
Example:
The feature must work for authenticated users, handle invalid input, preserve existing behavior, and pass the relevant tests.
You do not need all six ingredients in every prompt. Use the ones that materially affect the outcome.
3. The G-C-C-F Framework
A simple framework for everyday prompting is:
- G — Goal: What outcome do you want?
- C — Context: What does AI need to know?
- C — Constraints: What rules must it follow?
- F — Format: What should the answer look like?
Example: Learning Data Structures and Algorithms
Goal: Prepare for entry-level software engineering interviews.
Context: I know basic Ruby and have used Rails, but I need to strengthen my problem-solving skills.
Constraints: Start with easy problems. Do not reveal solutions before I attempt them. Use idiomatic Ruby.
Format: Give me one problem at a time, provide hints when needed, and evaluate correctness, efficiency, edge cases, and readability.
Combined prompt:
Act as an experienced Ruby engineer and interview coach. Help me prepare for entry-level software engineering interviews. I know basic Ruby and have used Rails, but I need to strengthen my data structures and algorithms skills. Start with easy problems and gradually increase the difficulty. Use idiomatic Ruby and do not reveal solutions before I attempt them. Give me one problem at a time, offer hints when needed, and evaluate correctness, efficiency, edge cases, and readability after each attempt.
4. The Ten Most Useful Iterative Prompting Techniques
Iterative prompting means improving a response through successive, targeted instructions rather than expecting the first attempt to be perfect.
Technique 1: Change One Thing at a Time
If an answer is too long, do not rewrite the entire prompt.
Instead, say:
Keep the same content, but cut the length in half. Preserve the important examples and recommendations.
This makes it easier to understand which adjustment improved the result.
Technique 2: Diagnose Before Retrying
Avoid repeatedly saying, "Try again."
Instead, say:
Identify the three biggest weaknesses in your previous answer. Explain what needs to change, then produce a revised version that addresses those weaknesses.
This gives the next iteration a specific direction.
Technique 3: Give Specific Feedback
Weak feedback:
I don't like it.
Useful feedback:
The explanation is accurate, but too theoretical. Use a practical Ruby example, explain what happens at each step, and finish with a short practice problem.
Specific feedback is easier to act on than vague dissatisfaction.
Technique 4: Define What Better Means
Tell AI what criteria matter.
Examples:
- Reduce the answer to 200 words.
- Improve readability without changing behavior.
- Include three realistic examples.
- Ensure the proposed solution handles empty input.
- Prioritize low-cost options with measurable benefits.
For software, define success in terms of observable behavior and test results.
Technique 5: Break Complex Tasks Into Stages
For complicated work, use a sequence:
- Research the problem.
- Identify possible approaches.
- Compare trade-offs.
- Choose an approach.
- Implement the solution.
- Test the result.
- Review remaining risks.
This gives you opportunities to catch misunderstandings before they become expensive mistakes.
Technique 6: Request Alternatives
When you do not know the best approach, ask AI to compare options.
Give me three substantially different approaches. Explain their advantages, disadvantages, implementation costs, and risks. Recommend one based on my constraints.
This is useful for architecture decisions, product features, career planning, and technical trade-offs.
Technique 7: Ask Clarifying Questions
When missing information could materially change the answer, tell AI to ask before proceeding.
Identify the most important missing information. Ask me one clarifying question before making a recommendation.
Do not use this unnecessarily for straightforward tasks. Clarification is most valuable when assumptions could lead to the wrong result.
Technique 8: Verify Instead of Trusting Confidence
A confident answer is not necessarily correct.
For coding:
Review the proposed solution against the requirements. Check edge cases, identify potential regressions, and run relevant tests if possible. Clearly distinguish verified results from assumptions.
For research:
Support important factual claims with reliable sources. Identify conflicting evidence and state when the available information is insufficient.
Technique 9: Preserve What Already Works
Prevent useful material from being rewritten unnecessarily.
Keep sections one and two unchanged. Revise only section three to make it more practical. Preserve the original tone and examples.
For code:
Preserve existing behavior and unrelated functionality. Limit changes to the files necessary for the requested feature.
Technique 10: Know When to Stop
Do not continue revising indefinitely.
Stop when the response meets your success criteria, important uncertainties have been addressed, and additional changes offer little value.
Further revisions can introduce mistakes or waste time for marginal improvements.
5. Advanced Technique: Role Prompting
Assigning AI a role can establish a useful perspective, but the role should be paired with specific responsibilities and evaluation criteria.
Weak:
Act as a senior developer.
Better:
Act as a senior Ruby engineer reviewing a junior developer's pull request. Prioritize correctness, readability, security, and maintainability. Identify serious issues first, explain why each matters, and avoid rewriting code that already works.
The value comes from the expertise, priorities, and behavior you specify, not from the title alone.
6. Advanced Technique: Few-Shot Prompting
Few-shot prompting means giving AI examples of the type of output you want.
For example:
Explain Ruby concepts using this format:
Definition: One sentence.
Simple example: A short code snippet.
Real-world example: How the concept appears in an application.
Common mistake: A typical error.
Practice: One interview-style question.
Examples establish a pattern that AI can follow consistently.
Use this when you need structured lessons, consistent documentation, repeated code reviews, or standardized output across many tasks.
7. Advanced Technique: Prompt for a Process, Not Just an Answer
For complicated tasks, explicitly define the sequence of work.
Example:
Help me add a workout history feature to an existing Rails application.
- Inspect the current models, routes, controllers, and views.
- Explain the existing architecture relevant to this feature.
- Propose a minimal implementation plan.
- Identify potential security and regression risks.
- Implement the feature in small, testable steps.
- Run relevant tests and report the actual results.
- Summarize changed files and remaining limitations.
Preserve unrelated behavior and do not claim tests passed unless they were actually run.
This is especially useful when working with AI coding agents that can inspect repositories, edit files, and execute commands.
8. Real-World Vibe Coding Techniques
Vibe coding uses AI to accelerate software development. The most reliable workflow combines rapid generation with careful inspection and verification.
Technique 1: Plan Before Generating
Do not begin a large task by asking AI to build the entire application.
Instead:
Inspect my existing repository and explain how the relevant functionality works. Identify the files involved, propose the smallest safe implementation, and list potential risks. Do not modify any files yet.
This prevents AI from inventing unnecessary architecture or replacing existing functionality.
Technique 2: Make Changes in Small Slices
For a workout logging feature, work incrementally:
- Display the form.
- Validate the input.
- Save the record.
- Display saved records.
- Add editing and deletion.
- Test permissions and edge cases.
Each step should leave the application in a reasonably working state.
Technique 3: Use the Smallest-Change Prompt
Implement the requested feature with the smallest safe change. Preserve existing routes, APIs, styling conventions, database contracts, and behavior unless a change is necessary. Avoid unrelated refactoring and unnecessary dependencies. Explain the files changed and any potential regressions.
This helps prevent scope creep.
Technique 4: Provide Real Debugging Evidence
When debugging, provide:
- Expected behavior.
- Actual behavior.
- Steps to reproduce the issue.
- Relevant error messages and logs.
- Recent changes.
- Relevant source code or test failures.
Then ask:
Trace the execution path and identify the most likely root cause based on the evidence. Explain your reasoning before proposing the smallest fix. Add a regression test that reproduces the original failure.
Do not assume that the first visible error identifies the underlying cause.
Technique 5: Generate Tests Alongside Features
After implementing a feature, ask AI to:
- Identify critical success cases.
- Identify edge cases and failure modes.
- Write or update appropriate automated tests.
- Run the relevant tests if tool access permits.
- Report actual results and anything that could not be verified.
Do not let AI weaken tests merely to make the implementation pass.
Technique 6: Use Screenshots for Visual Iteration
For interface work:
- Run the application.
- Capture the current interface.
- Provide a screenshot and describe the intended result.
- Ask AI to identify the most important visual differences.
- Fix one or two issues at a time.
- Capture another screenshot and compare.
Screenshots help diagnose visual issues but do not establish that backend functionality works.
Technique 7: Maintain a Project Brief
Keep a short document containing:
- Application purpose and architecture.
- Important files and conventions.
- Requirements and decisions.
- Known bugs and technical debt.
- Tests last run and their results.
- The next concrete task.
Ask AI to update the document after significant changes. This provides a reliable handoff between sessions.
Technique 8: Use Git Checkpoints
Before risky changes:
- Check the working tree with
git status. - Review existing changes.
- Commit or otherwise preserve a known-good state.
- Inspect the proposed changes.
- Run relevant tests.
- Prepare a rollback plan when data or production behavior is at risk.
Do not blindly reset files or run destructive commands just because AI recommends them.
9. The Four-Stage Debugging and Refinement Loop
When a feature does not work, avoid an endless sequence of "fix it" prompts.
Use this process.
Stage 1: Diagnose
Trace the behavior from the user interface through the controller and model. Identify the likely root cause and the evidence supporting it. Do not edit files yet.
Stage 2: Fix
Implement the smallest fix for the identified root cause. Preserve unrelated behavior and explain which files changed.
Stage 3: Verify
Reproduce the original failure and run relevant tests. Report what actually passed, failed, or could not be run.
Stage 4: Harden
Identify likely edge cases that could still break the feature. Add regression tests and address any newly discovered issues.
Each stage has a different purpose. Separating diagnosis, implementation, verification, and hardening makes failures easier to understand.
10. Common AI Coding Failure Modes
| Failure mode | Better instruction |
|---|---|
| Editing before understanding the app | Inspect and explain the existing implementation first. |
| Rewriting unrelated files | Make the smallest safe change. |
| Claiming tests passed without running them | Report verified results separately from assumptions. |
| Fixing symptoms repeatedly | Trace the execution path and identify the root cause. |
| Adding unnecessary dependencies | Prefer existing dependencies unless there is a clear reason. |
| Generating a huge feature in one pass | Break implementation into small, testable steps. |
| Ignoring regressions | Compare the change against original requirements and existing tests. |
| Overwriting important changes | Review Git status and preserve a known-good state. |
11. A Reusable Iterative Prompt
Copy this template when you want AI to improve an existing answer or implementation.
Let's improve your previous response iteratively.
- Evaluate it against my original goal.
- Identify the three most important weaknesses or gaps.
- Propose specific improvements instead of rewriting everything indiscriminately.
- Preserve the parts that already work.
- Produce a revised version that addresses the weaknesses.
- Explain briefly what changed and why.
If important information is missing, ask me one clarifying question before revising. Do not invent facts or claim improvements that have not been verified.
For code, add:
Inspect the existing implementation before editing. Keep changes scoped to the requested outcome. Run relevant tests if possible and report the actual results, including failures and unverified assumptions.
12. Practice Exercise
Challenge: Improve a Weak Coding Prompt
Your goal is to add a workout history page to an existing Ruby on Rails application.
Weak prompt:
Add workout history to my app.
Rewrite the prompt to include:
- The goal and relevant context.
- What AI should inspect before making changes.
- Constraints that preserve existing behavior.
- An incremental implementation strategy.
- Tests and success criteria.
Example Answer
Act as an experienced Ruby on Rails engineer working in an existing fitness application. Add a workout history page that allows authenticated users to view their previously saved workouts.
Before editing, inspect the existing models, routes, controllers, views, authentication, and authorization rules. Explain the relevant architecture and propose the smallest safe implementation.
Implement the feature in small steps, preserving existing behavior and styling conventions. Avoid unnecessary dependencies and unrelated refactoring. Ensure users can only access workouts they are authorized to view.
Add appropriate tests for populated and empty histories, authentication, authorization, and relevant edge cases. Run the relevant tests if possible and report the actual results, files changed, and remaining limitations.
Why This Prompt Is Better
It defines the feature, gives the AI a discovery phase, limits unnecessary changes, establishes incremental implementation, addresses access control, and specifies how to verify success.
13. Final Rules of Thumb
- Inspect before editing.
- Give one primary goal per prompt.
- Provide context and real evidence.
- Make small, targeted changes.
- Diagnose before retrying.
- Preserve what already works.
- Verify results instead of trusting confidence.
- Use Git to protect working code.
- Understand the important parts of anything you ship.
- Stop iterating when the result meets your success criteria.
The central lesson: Prompt engineering is specification writing, and iterative prompting is a feedback loop. The goal is not to make AI produce more output. It is to guide AI toward the right outcome, detect mistakes early, and improve results through evidence and targeted changes.
For vibe coding specifically, the real skill is not merely generating code. It is making the right changes, understanding the important decisions, catching incorrect assumptions, and shipping reliable software faster.
Top comments (0)