We need to talk about how most developers use LLMs. Most of you treat ChatGPT or Claude like a magic 8-ball: throw in a vague sentence, hope the output does not take the production site down. That zero-shot habit is where the hallucinated functions and the legacy APIs come from. The 5x speedup people claim starts with few-shot prompting instead.
Fourteen years of wrestling with WordPress core taught me one thing above the rest: context is everything. Refactoring a tangled WooCommerce checkout, or chasing a race condition in a custom transient, the model needs to see your intent in real implementations rather than in a sentence describing them.
What zero-shot prompting costs you
A zero-shot prompt reads like this: “Write a function to add a custom order status to WooCommerce.” What comes back can miss the wc- prefix requirements, or never register the status in the bulk actions dropdown. The code runs. Architecturally it is a mess.
Without examples, the model has to guess your standards. Does your agency use a namespace? Do you prefix functions with bbioon_? Skip few-shot prompting and you will spend longer refactoring the AI’s help than you would have spent writing the thing yourself.
Few-shot prompting in action
What works is handing over 2 to 3 shots, meaning examples of how you solved something similar before. If I am building a new REST API endpoint, I paste in a working endpoint from an earlier project. The agent then follows the security patterns I already use, down to a proper permission_callback check.
I covered the same ground from another angle in my guide on stopping AI hallucinations with better context. A reference example trains the model on your codebase for the length of the session.
A practical example: custom WooCommerce logic
Here is the naive version and the few-shot version of the same custom status registration.
// The Naive Approach (Zero-Shot) - Generic and often buggy
function register_my_status() {
register_post_status( 'shipped-to-hub', array(
'label' => 'Shipped to Hub',
'public' => true
) );
}
add_action( 'init', 'register_my_status' );Compare that with what comes back once you hand over an existing status registration as an example. The model picks up the wc- prefix and the array parameters WooCommerce expects.
// The Senior Approach (Few-Shot Result)
// This follows the exact pattern provided in the prompt examples
function bbioon_register_hub_order_status() {
register_post_status( 'wc-shipped-hub', array(
'label' => _x( 'Shipped to Hub', 'Order status', 'bbioon' ),
'public' => true,
'exclude_from_search' => false,
'show_in_admin_all_list' => true,
'show_in_admin_status_list' => true,
'label_count' => _n_noop( 'Shipped to Hub <span class="count">(%s)</span>', 'Shipped to Hub <span class="count">(%s)</span>', 'bbioon' )
) );
}
add_action( 'init', 'bbioon_register_hub_order_status' );Organizing your work for LLM context
Few-shot prompting only pays off if you can find the examples, so I keep a library of pattern folders. Working on a CLI tool, I point the agent at my /patterns/wp-cli/ directory. Writing marketing material, I show it my previous LinkedIn carousels.
The Prompt Engineering Guide notes that even one or two examples improve output quality considerably. In my own work it has turned 2-hour debugging sessions into 15-minute refactors. The rest of the setup is in my post on my terminal-first AI coding setup.
If few-shot prompting is eating your dev hours, I can take it on. I have been wrestling with WordPress since the 4.x days.
Build the library as you go
Do not ask the model to think. Ask it to copy. Feed it good examples of your own work and most of the guessing goes away. The library grows every time you ship something, so each new prompt gets shorter and the result lands closer to what you wanted.
