An example beats an adjective
You will learn
Why one example and its wanted output pins down a rule better than an adjective, and why a second example is worth adding.
An adjective such as bigger or shorter fits many rules, so the agent picks one of them, and not always yours. An example input with the output you want fits far fewer. In prompt_example.t27 the rule you mean is add 3, and the examples are 1 to 4, 2 to 5 and 5 to 8. The opening example fits two rules, add 3 and multiply by 3 then add 1, so it cannot choose between them. The second example, 2 to 5, rules the other one out, because it would give 7. The lesson plants one bug: change the step from 3 to 2, and the examples fail.
Try it
Open the table and find the row where rule B stops matching; then in the spec change A_STEP to 2 and count the tests that fail.
One example input and output fits two rules; a second example drops one. Why an agent follows an example better than the word bigger. Vibecoding from zero, Prompting.
specs/vibecoding/prompt_example.t27
// SPDX-License-Identifier: Apache-2.0
; Vibecoding, module Prompting, lesson 2: an example beats an adjective.
; "Make it bigger" fits a hundred rules. An example input and the output you want fits few.
; Here the wanted rule is "add 3". One example fits two rules; a second example drops one of them.
module vibecoding_prompt_example;
; The examples you give the agent: inputs and the outputs you want back.
pub const EX_IN : [3]u8 = [1, 2, 5];
pub const EX_OUT : [3]u8 = [4, 5, 8];
; Rule A is the one you meant: add 3. Rule B is another rule an agent could read from one example.
pub const A_STEP : u8 = 3;
pub const B_MUL : u8 = 3;
pub const B_ADD : u8 = 1;
pub fn rule_a(x: u8) -> u8 {
return x + A_STEP;
}
pub fn rule_b(x: u8) -> u8 {
return x * B_MUL + B_ADD;
}
; How many examples a rule must match before it is the rule you meant.
pub const EXAMPLES_GIVEN : u8 = 3;
test the_first_example_fits_both_rules {
assert EX_OUT[0] == EX_IN[0] + A_STEP;
assert EX_OUT[0] == EX_IN[0] * B_MUL + B_ADD;
}
test the_second_example_rules_out_b {
assert EX_OUT[1] == EX_IN[1] + A_STEP;
assert EX_OUT[1] != EX_IN[1] * B_MUL + B_ADD;
}
test every_example_fits_rule_a {
assert EX_OUT[0] == EX_IN[0] + A_STEP;
assert EX_OUT[1] == EX_IN[1] + A_STEP;
assert EX_OUT[2] == EX_IN[2] + A_STEP;
}
test the_last_example_is_read {
assert EX_IN[EXAMPLES_GIVEN - 1] == 5;
assert EX_OUT[EXAMPLES_GIVEN - 1] == 8;
}
All lessons
Module 1 · What vibecoding is
You describe, an agent writes, you run it and check. What a program is, and five myths put to a test.
Module 2 · Your desk
An editor with an agent beside it, ten terminal commands, and reading an error message.
Module 3 · Save points with git
A commit is a save point, a branch is a safe try, and a key is a pair of which one stays private.
Module 4 · Prompting
The parts of a prompt, an example in place of an adjective, and one small step at a time.
Module 5 · The working loop
Four phases from idea to ship, the loop of ask, run, read and fix, and what to do when it is stuck.
Module 6 · A test as the judge
A test says yes or no, a planted bug shows the test works, and a diff is read before it is accepted.
Module 7 · The parts of an agent
What an agent answers with, what it can do with tools, and what it keeps between messages.
Module 8 · A first bot
A bot is a message loop, a bot comes from a spec, and a secret stays out of the repository and the prompt.
Module 9 · Your own project
A spec for your own idea, one thing measured after it runs, and an honest plan for the next month.