An editor with an agent beside it
You will learn
How to work with an agent in your editor: you describe the change, it edits, and you decide what stays.
An editor is where you read and change files. An agent sits beside it: you describe a change in words and it edits the files for you. It edits fast, but you are the one who keeps or rejects each change. The rule in the spec is two checks: can you read the whole change, and do the tests still pass? A change of 3 lines that passes is kept. A change of 12 lines that fails is sent back. A rewrite of 90 lines is sent back even when it passes, because nobody has read it. The spec sets the reading limit at 20 lines; pick your own and keep to it.
Try it
In the spec, find READ_LIMIT and the three proposed changes. Change the last KEEP to 1 and run the player: the test that names a change too long to read fails. Then put it back to 0.
Three changes an agent might propose in your editor, and the rule that decides each one: can you read all of it, and do the tests pass. Lesson 4 of the vibecoding course.
specs/vibecoding/editor_agent.t27
// SPDX-License-Identifier: Apache-2.0
; specs/vibecoding/editor_agent.t27 -- lesson 4 of the vibecoding course: an editor with an agent beside it
; The agent proposes a change to your file; you read it and decide. This spec writes that decision
; as a rule: keep a change only if you can read all of it and the tests still pass.
; Three changes the agent might propose, as three columns of numbers.
; ASCII only (L3), English only (LANG-EN).
; phi^2 + 1/phi^2 = 3 | TRINITY
module vc_editor_agent;
; How many changed lines a person can honestly read in one go.
pub const READ_LIMIT : u8 = 20;
; Change 0 is a rename, change 1 adds a button, change 2 rewrites the whole file.
pub const CHANGED_LINES : [3]u8 = [3, 12, 90];
; 1 = the tests passed after the change, 0 = they failed.
pub const TESTS_PASS : [3]u8 = [1, 0, 1];
; The decision the rule must reach: 1 = keep, 0 = send it back.
pub const KEEP : [3]u8 = [1, 0, 0];
test a_small_change_that_passes_is_kept {
assert CHANGED_LINES[0] <= READ_LIMIT;
assert TESTS_PASS[0] == 1;
assert KEEP[0] == 1;
}
test a_change_that_fails_is_sent_back_even_when_short {
assert CHANGED_LINES[1] <= READ_LIMIT;
assert TESTS_PASS[1] == 0;
assert KEEP[1] == 0;
}
test a_change_too_long_to_read_is_sent_back_even_when_it_passes {
assert CHANGED_LINES[2] > READ_LIMIT;
assert TESTS_PASS[2] == 1;
assert KEEP[2] == 0;
}
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.