AI Coding Prompts That Actually Improve Productivity

Most lists of "best AI coding prompts" are collections of clever wording. Wording is rarely the problem. The real problem is that AI output still has to be checked by you, and checking is the slow part. A prompt that produces more code faster but leaves you reading 400 unfamiliar lines has not saved time. This article is about prompts that make the result cheaper to verify, and every example was run against a small PHP project so you can see the actual output, including where a prompt did not make the difference I expected.

Why "faster code" is not the same as productivity

The research does not support a simple "AI makes developers faster" story. In METR's 2025 randomized trial with 16 experienced open-source developers working on their own repositories, developers took 19% longer with AI tools than without, while believing afterwards that the tools had made them about 20% faster. METR's February 2026 follow-up used a larger group (57 developers, 800+ tasks) and found changes of -18% and -4% in task time for the two groups, which would mean faster, but neither result was statistically significant, and METR listed design problems: between 30% and 50% of developers said they skipped tasks they did not want to do without AI, and time measurements get unreliable when developers run several agents at once. METR's own conclusion is that developers are likely more sped up now, but it cannot show that with the current data. (I read the 2026 figures in a secondary write-up of METR's post, so check METR's site for the original numbers.)

The 2025 DORA report on AI-assisted development points the same direction from the team side: AI improves throughput, but often at the cost of stability when the underlying engineering foundation is weak. And the Stack Overflow Developer Survey 2026 shows what developers do in practice after an AI answer arrives: 76.5% run the code locally, 63.9% compare it against their codebase, 53.0% inspect tests and security implications, and only 9.6% use it as-is.

So the useful question is not "how do I get more code out of the model" but "how do I get output I can trust quickly". The prompts below are built around that.

The five habits that did the work

1. Give it a check it can run. A failing test, a command, a linter. This matters more than anything you write in the prompt.
2. Say what it must not touch. "Do not edit anything in tests/" costs ten words and prevents the classic cheat of changing the test to pass.
3. Scope the task. One bug, one file, one concern. Say "security and performance only; ignore style".
4. Ask for evidence in a fixed format. Line numbers, severity, the command it ran, the exact line it changed.
5. Ask it to report, not fix, when you want to decide. Tests that expose problems are more valuable than silent patches.

The test project

All examples use this tiny project. src/Cart.php has one real bug: it truncates instead of rounding half up.

<?php
// src/Cart.php
namespace App;

class Cart
{
    /** @param array<int, array{price_cents:int, qty:int}> $items */
    public function total(array $items, int $discountPercent): int
    {
        $sum = 0;
        foreach ($items as $item) {
            $sum += $item['price_cents'] * $item['qty'];
        }

        return (int) ($sum * (100 - $discountPercent) / 100);
    }
}

tests/run.php is a plain script with a small check($name, $expected, $actual) function and three checks. Running it fails on exactly one:

php tests/run.php

PASS  no discount
FAIL  10% off, rounds half up (expected 896, got 895)
PASS  empty cart

I ran every prompt with Claude Code 2.1.318 in print mode, giving it only the tools it needed, for example --permission-mode acceptEdits --allowedTools "Read Edit Bash(php *)". The prompts are plain text and not specific to that tool, but I only ran them in Claude Code. Model output varies from run to run, so treat each result as one sample.

Prompt 1: fixing a bug

The vague version:

The cart total is wrong, fix it

The specific version:

Running 'php tests/run.php' fails: the test '10% off, rounds half up' expects 896
but total() returns 895 for one item of 995 cents with a 10% discount. Fix the bug
in src/Cart.php only: do not edit anything in tests/. Money is integer cents, so
do not introduce floats into the return type. Run 'php tests/run.php' to confirm
all tests pass, then answer in two sentences: the root cause, and the exact line
you changed.

What happened: both fixed it, and both left the test file untouched (I compared checksums). The vague prompt worked because the failing test was already in the repository, and the agent found and ran it. That is the first lesson: the test did the real work, not the wording. The differences were smaller than I expected:

Both used the same fix:

return intdiv($sum * (100 - $discountPercent) + 50, 100);

The specific prompt gave me a shorter, easier-to-review answer and a smaller diff. It did not give a more correct fix. Which brings us to the next prompt, because this fix has a problem the original test never covered.

Prompt 2: edge-case tests that report instead of fix

Write edge-case tests for Cart::total() in tests/edge.php, reusing the check() style
from tests/run.php. Cover: quantity 0, a 100% discount, a discount over 100, a
negative price, several items in one cart, and a large quantity. Run 'php tests/edge.php'.
Do NOT modify anything in src/. For each failing test, say whether the bug is in
Cart or in my expectation, and what behaviour you think Cart should have.

I ran this against the code after the fix above. Five tests passed, three failed, src/ was untouched (checksum compared), and I re-ran the file myself to confirm the output:

PASS  qty 0 gives 0
PASS  qty 0 with discount gives 0
PASS  100% discount is free
FAIL  discount 150 is rejected (expected 'InvalidArgumentException', got -499)
FAIL  negative price is rejected (expected 'InvalidArgumentException', got -499)
PASS  several items, 10% off
PASS  large quantity
FAIL  overflowing quantity is rejected (expected 'OverflowException', got 'TypeError')

The useful part was the triage. For a discount of 150 the agent explained that 1000 * (100 - 150) + 50 is -49950 and intdiv truncates toward zero, so the customer gets a negative total, and it argued for throwing on a discount outside 0-100. For the negative price it pointed out that the + 50 rounding trick is only correct for non-negative sums: a single item of -500 with no discount returns -499. That is a genuine bug that the fix itself introduced, and it was invisible to the original test. For the overflow test it correctly said the failure was mostly its own expectation: the code fails loudly with a TypeError and never returns a wrong number, and the exception class I asked for was an arbitrary choice.

This is the main reason to ask for tests and a verdict instead of a patch: the patch that passes your test may still be wrong, and you only learn that if something probes it.

Prompt 3: structured code review

I used a small Laravel controller with real problems: a SQL string built from request input, Order::find($id)->delete() with no existence or authorization check, an N+1 loop over relations, and an unbounded get().

Vague: review src/OrderController.php

Structured:

Review src/OrderController.php (a Laravel 13 controller) for security and performance
problems only; ignore style. For each finding give: severity (high/medium/low), the
line number, why it is a problem in one sentence, and a minimal fix as a code snippet.
Order by severity. Do not report anything you cannot point to a specific line for.
Do not edit any files.

Both reviews found the SQL injection, the missing authorization on delete, the crash on a missing ID, and the N+1 queries. I checked the line numbers in the structured answer (13, 19-20, 31 and 36) against the file and they were right. So this prompt did not find more bugs. What it changed:

• The vague review returned seven findings, including a "minor" group, and a long fix-priority list. The structured one returned five findings in a fixed format with line numbers, which is easier to turn into tickets.
• It stated what it could not judge: "I can't see the routes file or policies. If a middleware or policy already ..." That sentence is worth more than the extra findings, because it tells you what to verify yourself.
• It left out two possible issues it could not tie to a specific line, which is exactly what the "do not report anything you cannot point to" instruction asked for.

The fixes it proposed for authorization are sketches (they assume an OrderPolicy exists). Treat review output as a list of places to look, not as a patch to apply.

More prompt templates (not run for this article)

These follow the same five habits. I have not tested them here, so adapt them and check the results.

# Plan before code
Plan how to add [feature]. List the files you would change, the new tests you would
write, and the risks. Do not write any code yet.

# Refactor with a safety net
Refactor [class] to [goal]. Behaviour must not change. Run [test command] before and
after, and show both results. Stop and tell me if any test fails.

# Explain unfamiliar code
Explain what [function] does in five bullets. Flag side effects (database writes,
network calls, global state) and anything that looks like a bug. Do not change code.

# SQL review
Here is a query and its EXPLAIN output: [paste]. Tell me what is slow and why, and
suggest an index. Say which assumptions you are making about the table size.

# Commit message
Write a commit message for the staged changes ('git diff --staged'). Subject under
72 characters, imperative mood, then a short body explaining why, not what.

Common mistakes

• Treating a passing test as proof. The fix in Prompt 1 passed and still broke on negative amounts. Add edge cases and read the assertions.
• No way for the agent to check itself. Without a test command, the answer is a guess presented confidently.
• Prompts that invite scope creep. "Improve this class" produces a rewrite. Name one concern.
• Not saying what to leave alone. Forbid edits to tests, migrations or config explicitly when that matters.
• Accepting fix sketches as final. Generated authorization and validation code assumes things about your app that it cannot see.
• Never measuring. If you do not track review time and defects, you cannot tell whether a habit helps. The METR results show that feelings about speed can be wrong.

Alternatives to writing better prompts every time

• Put standing rules in a project file (CLAUDE.md or AGENTS.md): the test command, the formatter, directories not to touch. Then you do not repeat them in every prompt.
• Use a tool that gives the agent project context. For Laravel, Laravel Boost does this; see How to use AI agents to build Laravel applications.
• Automate the checks. A formatter, static analysis and a test suite that run on every change catch more than any prompt wording.

Related Dev Talk articles and tools

• 10 Claude Code commands every developer should know
• Claude Code vs Cursor vs GitHub Copilot: which is best in 2026?
• How to use AI agents to build Laravel applications
• Open source tools that make developers more productive

Tools that make AI output cheaper to verify: your test runner (Pest or PHPUnit), Laravel Pint for formatting, and a static analyzer such as PHPStan.

Frequently asked questions

Do these prompts work with Cursor and Copilot?

The wording is tool-agnostic, and the five habits apply to any assistant. I only ran them in Claude Code, so I cannot show results for the others.

How long should a prompt be?

Long enough to state the failing check, the constraints and the output format. The specific bug-fix prompt above is five sentences. Length beyond that rarely helped in my runs.

Is a vague prompt ever fine?

Yes. When the repository already contains a failing test, a short prompt worked. Vague prompts get risky when there is nothing for the agent to check against.

Should I ask the AI to explain its reasoning?

Ask for evidence you can verify (the line it changed, the command it ran, the output), not for a story. A confident explanation can be wrong; a test result can be rerun.

Will good prompts make me faster?

I can't promise that. The best-known controlled study found a slowdown in 2025 and an inconclusive result in 2026. Measure your own review time and defect rate over a few weeks.